I had deepseek explain MCP to me. Then I asked what was the point of persistent connections and it said it was pretty much hipster bullshit and that some url to post to is really enough for an llm to interact with things.
lol
Making MCP cheaper via CLI
41–50 of 127 posts
Re: Making MCP cheaper via CLI
#42After reading Cloudflare's Code Mode MCP blog post[1] I built CMCP[2] which lets you aggregate all MCP servers behind two mcp tools, search and execute.
I do understand anthropic's Tool Search helps with mcp bloat, but it's limited only to claude.
CMCP currently supports codex and claude but PRs are welcome to add more clients.
[1]https://blog.cloudflare.com/code-mode-mcp/ [2]https://github.com/assimelha/cmcp
Re: Making MCP cheaper via CLI
#43After reading Cloudflare's Code Mode MCP blog post[1] I built CMCP[2] which lets you aggregate all MCP servers behind two mcp tools, search and execute. I do understand anthropic's Tool Search helps with mcp bloat, but it's limited only to claude. CMCP currently supports codex and claude but PRs are welcome to add more clients. [1] https://blog.cloudflare.com/code-mode-mcp/ [2] https://github.com/assimelha/cmcp
did you check the token usage comparison between cmcp and cli?
Re: Making MCP cheaper via CLI
#44Earlier quoted context omitted.
personal experience, definitely yes. You can try it out with `gh` rather than `Github MCP`. You'll see the difference immediately (espicially more if you have many MCPs)
The models are trained on gh though. Try with a lesser-known CLI.
I did - I have my almost a dozen CLIs that are custom built that I'm using. Very reliable.
It still needs to do discovery (--help etc.), always gets the job done
Re: Making MCP cheaper via CLI
#45True for coding agents running SotA models where you're the human-in-the-loop approving, less true for your deployed agents running on cheap models that you don't see what's being executed. But yeah, a concrete example is playwright-mcp vs playwright-cli: https://testcollab.com/blog/playwright-cli
Probably oversold here because if you read the fine print, the savings only come in cases when you don't need the bytes in context.
That makes sense for some of the examples the described (e.g. a QA workflow asking the agent to take a screenshot and put it into a folder).
However, this is not true for an active dev workflow when you actually do want it to see that the elements are not lining up or are overlapping or not behaving correctly. So token savings are possible...if your use case doesn't require the bytes in context (which most active dev use cases probably do)*
Re: Making MCP cheaper via CLI
#46A very good example of this is playwright-cli vs Playwright MCP:
https://github.com/microsoft/playwright-cli
The biggest difference is state, but that's also kind of easy from CLI, the tool just have to store it on disk, not in process memory.
Re: Making MCP cheaper via CLI
#47Hehe... nice one. I think we are all thinking the same thing. I've also launched https://mcpshim.dev ( https://github.com/mcpshim/mcpshim ). The unix way is the best way.
Pretty sure I saw this one a couple of weeks back, or something very similar to it..
https://github.com/philschmid/mcp-cli
Edit: Turns out was https://github.com/steipete/mcporter noted elsewhere in the thread, but mcp-cli looks like a very similar thing.
Re: Making MCP cheaper via CLI
#48So much incorrect and misinformation in these comments. As someone who is building an agent[0] with MCP tools, neither the MCP tool description nor the response is the problem. Both of those are easily solved by not bloating them.
The real killer is the input tokens on each step. If you have 100k tokens in the conversation, and the LLM calls an MCP tool, the output and the existing conversation is sent back. So now you've input 200k tokens to the LLM.
Now imagine 10 tool calls per user message - or 50. You're sending 1-5M input tokens, not because the MCP definitions or tool responses are large, but because at each step, you have to send the whole conversation again.
"what about caching" - Only 90% savings, also cache misses are surprisingly common (we see as low as 40% cache hit rate)
"MCP definitions are still large" - not compared to any normal conversation. Also these get cached
We've seen the biggest savings by batching/parallelizing tool calls. I suspect the future of LLM tool usage will have a different architecture, but CLI doesn't solve the problems either.
[0] https://ziva.sh, it's an agent specialized for Godot[1]
Re: Making MCP cheaper via CLI
#49Is there any redeeming quality of MCP vs a skill with CLI tool? Right now it looks like the latter is a clear winner.
Maybe MCP can help segregate auto-approve vs ask more cleanly, but I don't actually see that being done.
Re: Making MCP cheaper via CLI
#50I feel like the permanent fix is for the AI labs to figure out better attention methods that increase context length without extra inference cost, plus deeper discounts (like -99%) for people being able to add system prompts to their accounts that are cached permanently.
This way you build all your MCPs into the system prompt, save the prompt to the AI provider, then use it without overpaying API costs.
The current "tools-on-demand" workarounds should be great for infrequent tools but the future will probably bring agents with dozens of tools that need them in context to flexibly many of them in the same context window. So we just need to make the context windows longer and make this capability cheaper to use.