10 years from now: "Can you believe they did anything with such a small context window?"
“640K ought to be enough for anybody”
Apideck CLI – An AI-agent interface with much lower context consumption than MCP
11–20 of 149 posts
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#12We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message. The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts. The post covers the benc…
How is progressive discovery not more expensive due to the increased number of steps?
In short: JSON. Plan prose or markdown is way more token efficient than JSON. I think that responding in JSON was always a mistake in the spec; it should have been free-form text (which could then be JSON if required).
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#13[flagged]
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#14While I generally prefer CLI over MCP locally, this is bad outdated information.
The major harnesses like Claude Code + Codex have had tool search for months now.
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#15We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message. The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts. The post covers the benc…
How is progressive discovery not more expensive due to the increased number of steps?
It depends on what your "currency" is: inference cost vs. models getting dumber/slower with a fuller context.
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#16What I've done with my MCPs is turning them into a CLI, except there's still an MCP server that only has the instructions to tell the the agent about the CLI.[1] Claude and GLM-5 seem to have no problems with it. As a bonus, the entire thing now works as a plain old CLI too - which it honestly should have from the beginning. [1]: https://github.com/jcdickinson/ferrisfetch/blob/main/cmd/mcp...
Can the MCP tell them how to use the CLI? Surely that would mean less time wasted on discovering it each time.
Going to try this with fastmail-cli and see what happens.
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#17Why not use skills? They follow a three-tier loading approach, and you can stick an MCP as part of the toolset for the skills, so it will only load it when the skill is selected.
See the progressive disclosure section in the skills docs: https://agentskills.io/what-are-skills
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#18We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message. The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts. The post covers the benc…
How is progressive discovery not more expensive due to the increased number of steps?
I assume because the discovery is branching. If the an agent using the CLI for for GitHub needs to make an issue, it can check the help message for the issue sub-command and go from there, doesn't need to know anything about pull requests, or pipelines, or account configuration, etc, so it doesn't query those subcommands.
Compare this to an MCP, where my understanding is that the entire API usage is injected into the context.
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#19What I've done with my MCPs is turning them into a CLI, except there's still an MCP server that only has the instructions to tell the the agent about the CLI.[1] Claude and GLM-5 seem to have no problems with it. As a bonus, the entire thing now works as a plain old CLI too - which it honestly should have from the beginning. [1]: https://github.com/jcdickinson/ferrisfetch/blob/main/cmd/mcp...
You don't need a whole server to tell agents that, I think you can just write a skill file or two and be done with it.
That would work, and is still an option. However I think this makes deployment/installation simpler (which is also why I write my MCPs in go).
Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP
#20Why not use skills? They follow a three-tier loading approach, and you can stick an MCP as part of the toolset for the skills, so it will only load it when the skill is selected. See the progressive disclosure section in the skills docs: https://agentskills.io/what-are-skills
Three tiers? I thought it was two?