Composing APIs and CLIs in the LLM era | Hacker News Reader

Composing APIs and CLIs in the LLM era

walters.app

77 pointszerf14 comments

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.

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.

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.

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...

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!

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.

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

I suspect the main trade-off is structured data versus text parsing. While CLIs are composable, relying on stdout is brittle for anything complex. MCP enforces a schema (types), which acts as a contract between the model and your backend. If you're building reliable pipelines rather than just one-off scripts, that structure is pretty critical to avoid parsing errors downstream.

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

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

It has been fascinating watching the cargo cult fall progressively deeper into AI psychosis. The amount of fanfare and marketing around different ways of writing text files is impressive. Still no amazing real-world software that anybody actually uses made by vibe coding, but boy are there options for writing .md files. Just a couple of years ago, I never could've imagined how far .md-writing technology would've advanced. The future is now.

You can make the same argument about the ever-growing list of programming languages, which are just weirdly formatted lists of computer commands.

which are equivalent to lists of computer commands. A compiler is a hell of a formatter.

> What's the source of truth? Nobody knows.

Except everyone who ever used standards like OpenAPI and JSON Schema.

Reply on news.ycombinator.com