Composing APIs and CLIs in the LLM era

I built a tool specifically for dealing with remote mcp servers via the cli. No config files needed. FUSE (and Bash) is all we need. This way we can still get benefits of discoverability of mcp endpoints, but can use cli tools and bash to do things easier.

https://github.com/turlockmike/murl

I'm working on tpmjs.com the npm registry for ai tools (just the vercel ai sdk flavor atm)

which lets users create collections of any publicly available tool which let's us do awesome things

We can auto generate a skills.md for collections https://tpmjs.com/ajax/collections/unsandbox/skills.md (https://tpmjs.com/ajax/collections/unsandbox to see the collection)

We analyze all the tools source code to write the skills.md using LLM's and then we auto inject three different ways agents can iteract with them

- hosted mcp servers for collections automatically e.g. https://tpmjs.com/api/mcp/ajax/unsandbox/sse

- a cli tool that can invoke each tool in the collection e.g. tpm run --collection ajax/unsandbox --tool [tool-name] --args '{"key": "value"}'

- restful endpoints for direct execution of tools e.g. curl -X POST https://tpmjs.com/api/mcp/ajax/unsandbox/http

It's very much alpha, but after building this, I don't see why you can't let agents choose any method they want of interacting with your service.

It means your agents can use CLI, MCP or REST, only in one style or any style all at once.

thanks for sharing this, it resonates with me. as some other commenters have said, CLIs, cURL, and other shell tools are composable and discoverable. it seems like a good direction.

auth considerations are present in the design of MCP. this, as opposed to the hodgepodge auth story with CLIs. there are APIs that either don't support OAuth or where using bare credentials is more expedient, and using agent-visible env vars is a security incident waiting to happen. but that doesn't necessarily mean we must use MCP. i think it's a matter of time before agentic tools come bundled with a proxy layer from which secrets / env vars can be set and used but not directly read [0].

[0] https://www.joinformal.com/blog/using-proxies-to-hide-secret...

I've been beating this drum for the last 8 months.

The next frontier is using hooks to guide agents to use tools better and avoid doom loops.

We also use CLI tools for agents because it is obvious that they are good at it.

Our approach is slightly more complex because we need to supported fully authenticated sessions for end users and for shared credentials. It works by creating scoped API tokens to our service which get bundled into dynamically generated CLI clients. We point the agent to the client and voila. The agent can now run `some-command list-gmail-messages --query "tom"`. The oauth complexities, credential lifecycle and everything is handled automatically by the platform on the fly - it does not matter if the user is on Slack or access the agent through some chat interface or if the agent runs in the background doing work. It just works!

This is what I’ve been doing too. Give the LLM a link to an OAS for an API and let it use curl for everything after that. I don’t even wrap the API or use restish all, the LLM knows how to use curl well enough.

This lets me add quick skills that are essentially just: “this is the OAS link, this is how you store and use the authorization, this is when I want you to use it”. That combined with pointing it at the documentation for common workflows and usage examples, and it’s been great.

The only thing I’ve had trouble with is auth really. MCPs are treated as first class citizens by most model provider’s agents and trying to provide a shell-based alternative for hiding the secret credentials from the LLM has been difficult.

Of all the interface modalities available, CLIs seem like the most natural for copilots to work with. Lots of examples in the training data, universal interface for help, maps well to the sequential nature of token generation, similar syntax for different OSs… I can see them replacing skills and MCP et al from the model’s perspective.

Building an API client : https://voiden.md/

The points made in the article can be included in the design choices.

this seems like what MCPs should have been from the beginning. If you think MCPs are better, can you explain why?

[dead]