MCP only exists because there's no easy way for AI to run commands on servers.
Oh wait there's ssh. I guess it's because there's no way to tell AI agents what the tool does, or when to invoke it... Except that AI pretty much knows the syntax of all of the standard tools, even sed, jq, etc...
Yeah, ssh should've been the norm, but someone is getting promoted for inventing MCP
Tokens saved should not be your north star metric. You should be able to show that tool call performance is maintained while consuming fewer tokens. I have no idea whether that is the case here.
As an aside: this is a cool idea but the prose in the readme and the above post seem to be fully generated, so who knows whether it is actually true.
Token counts alone tell you nothing about correctness, latency, or developer ergonomics. Run a deterministic test suite that exercises representative MCP calls against both native MCP and mcp2cli while recording token usage, wall time, error rate, and output fidelity.
Measure fidelity with exact diffs and embedding similarity, and include streaming behavior, schema-change resilience, and rate-limit fallbacks in the cases you care about. Check the repo for a runnable benchmark, archived fixtures captured with vcrpy or WireMock, and a clear test harness that reproduces the claimed 96 to 99 percent savings.
> Every MCP server injects its full tool schemas into context on every turn
I consider this a bug. I'm sure the chat clients will fix this soon enough.
Something like: on each turn, a subagent searches available MCP tools for anything relevant. Usually, nothing helpful will be found and the regular chat continues without any MCP context added.
Yup, routing is key. Just like how we've had RAG so we don't have to add every biz doc to the context.
I agree with the general idea that models are better trained to use popular cli tools like directory navigation etc, but outside of ls and ps etc the difference isn't really there, new clis are just as confusing to the model as new mcps.
It works by schematising the upstream and making data locally synchronised + a common query language, so the longer term goals are more about avoiding API limits / escaping the confines of the MCP query feature set - i.e. token savings on reading data itself (in many cases, savings can be upwards of thousands of times fewer tokens)
For me (actually trying to get shit done using this stuff) it's validation.
Being able to have a verifiable input/output structure is key. I suppose you can do that with a regular http api call (json) but where do you document the openapi/schema stuff? Oh yeah...something like mcp.
I agree that mcp isn't as refined as it should be, but when used properly it's better than having it burn thru tokens by scraping around web content.
The point is authorization. With full web access, your agent can reach anything and leak anything.
You could restrict where it can go with domain allowlists but that has insufficient granularity. The same URL can serve a legitimate request or exfiltrate data depending on what's in the headers or payload: see https://embracethered.com/blog/posts/2025/claude-abusing-net...
So you need to restrict not only where the agent can reach, but what operations it can perform, with the host controlling credentials and parameters. That brings us to an MCP-like solution.
A few things: in this case, you have to provide the tool list in your prompt for the AI to know it exists. But you probably want the AI agent to be able to act and choose tools without you micromanaging and reminding it in every prompt, so then you'd need a tool list... and then you're back to providing the tool list automatically ala MCP again.
MCP can provide validation & verification of the request before making the API call. Giving the model a /tool/forecast URL doesn't prevent the model from deciding to instead explore what other tools might be available on the remote server instead, like deciding to try running /tool/imagegenerator or /tool/globalthermonuclearwar. MCP can gatekeep what the AI does, check that parameters are valid, etc.
Also, MCP can be used to do local computation, work with local files etc, things that web access wouldn't give you. CLI will work for some of those use cases too, but there is a maximum command line length limit, so you might struggle to write more than 8kB to a file when using the command line, for example. It can be easier to get MCP to work with binary files as well.
I tend to think of local MCP servers like DLLs, except the function calls are over stdio and use tons of wasteful JSON instead of being a direct C-function call. But thinking of where you might use a DLL and where you might call out to a CLI can be a useful way of thinking about the difference.
I built one specifically for Cognition's DeepWiki (https://crates.io/crates/dw2md) -- but it's rather narrow. Something more general like this clearly has more utility.
I may be showing my ignorance here, but wouldn't the ideal situation be for the service to use the same number of tokens no matter what client sent the query?
If the service is using more tokens to produce the same output from the same query, but over a different protocol, than the service is a scam.
That doesn't explain why the protocol matters. Surely for equivalent responses, you need to send equivalent payloads. You shouldn't be able to hack this from the client side.
Someone had to do it. mcp in bash would make them composable, which I think is the strongest benefit for high capability agents like Claude, Cursor and the like, who can write Bash better than I. Haven't gotten into MCP since early release because of the issues you named. Nice work!
Cool, adding this to my list of MCP CLIs:
Precisely, there are about 100 of these, and everyone makes a new one every week.
there is nobody making a new one ever week.
We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...
MCP is a dead end, just ignore it and it will go away.
> but we created MCP. Now we're wrapping MCP into CLIs...
Next we'll wrap the CLIs into MCPs.
MCP only exists because there's no easy way for AI to run commands on servers.
Oh wait there's ssh. I guess it's because there's no way to tell AI agents what the tool does, or when to invoke it... Except that AI pretty much knows the syntax of all of the standard tools, even sed, jq, etc...
Yeah, ssh should've been the norm, but someone is getting promoted for inventing MCP
Tokens saved should not be your north star metric. You should be able to show that tool call performance is maintained while consuming fewer tokens. I have no idea whether that is the case here.
As an aside: this is a cool idea but the prose in the readme and the above post seem to be fully generated, so who knows whether it is actually true.
Token counts alone tell you nothing about correctness, latency, or developer ergonomics. Run a deterministic test suite that exercises representative MCP calls against both native MCP and mcp2cli while recording token usage, wall time, error rate, and output fidelity.
Measure fidelity with exact diffs and embedding similarity, and include streaming behavior, schema-change resilience, and rate-limit fallbacks in the cases you care about. Check the repo for a runnable benchmark, archived fixtures captured with vcrpy or WireMock, and a clear test harness that reproduces the claimed 96 to 99 percent savings.
The AI prose is getting so tiring to read
"We measured this. Not estimates — actual token counts using the cl100k_base tokenizer against real schemas, verified by an automated test suite."
> Every MCP server injects its full tool schemas into context on every turn
I consider this a bug. I'm sure the chat clients will fix this soon enough.
Something like: on each turn, a subagent searches available MCP tools for anything relevant. Usually, nothing helpful will be found and the regular chat continues without any MCP context added.
Yup, routing is key. Just like how we've had RAG so we don't have to add every biz doc to the context.
I agree with the general idea that models are better trained to use popular cli tools like directory navigation etc, but outside of ls and ps etc the difference isn't really there, new clis are just as confusing to the model as new mcps.
Nice project! I've been working on something very similar here https://github.com/max-hq/max
It works by schematising the upstream and making data locally synchronised + a common query language, so the longer term goals are more about avoiding API limits / escaping the confines of the MCP query feature set - i.e. token savings on reading data itself (in many cases, savings can be upwards of thousands of times fewer tokens)
Looking forward to trying this out!
Why is the concept of "MCP" needed at all? Wouldn't a single tool - web access - be enough? Then you can prompt:
And then the tools url can simply return a list of urls in plain text like Which return the data in plain text.What additional benefits does MCP bring to the table?
For me (actually trying to get shit done using this stuff) it's validation.
Being able to have a verifiable input/output structure is key. I suppose you can do that with a regular http api call (json) but where do you document the openapi/schema stuff? Oh yeah...something like mcp.
I agree that mcp isn't as refined as it should be, but when used properly it's better than having it burn thru tokens by scraping around web content.
The point is authorization. With full web access, your agent can reach anything and leak anything.
You could restrict where it can go with domain allowlists but that has insufficient granularity. The same URL can serve a legitimate request or exfiltrate data depending on what's in the headers or payload: see https://embracethered.com/blog/posts/2025/claude-abusing-net...
So you need to restrict not only where the agent can reach, but what operations it can perform, with the host controlling credentials and parameters. That brings us to an MCP-like solution.
But this is no different to using an API key with access controls and curl and you get the same thing.
MCP is just as worse version of the above allowing lots of data exfiltration and manipulation by the LLM.
But MCP uses Oauth. That is not a "worse version" of API keys. It is better.
The classic "API key" flow requires you to go to the resource site, generate a key, copy it, then paste it where you want it to go.
Oauth automates this. It's like "give me an API key" on demand.
An MCP server lets you avoid giving the agent your API key so it can't leak it. At least in theory.
You could do the same with a CLI tool but it's more of a hassle to set up.
A few things: in this case, you have to provide the tool list in your prompt for the AI to know it exists. But you probably want the AI agent to be able to act and choose tools without you micromanaging and reminding it in every prompt, so then you'd need a tool list... and then you're back to providing the tool list automatically ala MCP again.
MCP can provide validation & verification of the request before making the API call. Giving the model a /tool/forecast URL doesn't prevent the model from deciding to instead explore what other tools might be available on the remote server instead, like deciding to try running /tool/imagegenerator or /tool/globalthermonuclearwar. MCP can gatekeep what the AI does, check that parameters are valid, etc.
Also, MCP can be used to do local computation, work with local files etc, things that web access wouldn't give you. CLI will work for some of those use cases too, but there is a maximum command line length limit, so you might struggle to write more than 8kB to a file when using the command line, for example. It can be easier to get MCP to work with binary files as well.
I tend to think of local MCP servers like DLLs, except the function calls are over stdio and use tons of wasteful JSON instead of being a direct C-function call. But thinking of where you might use a DLL and where you might call out to a CLI can be a useful way of thinking about the difference.
One thing that I currently find useful on MCPs is granular access control.
Not all services provide good token definition or access control, and often have API Key + CLI combo which can be quite dangerous in some cases.
With an MCP even these bad interfaces can be fixed up on my side.
The prophecy of the hypermedia web
I feel like I haven’t read anything about this in combination with mcp and like I am taking crazy pills: does no one remember hateoas?
Proxying / gatekeeping
There are a handful of these. I've been using this one: https://github.com/smart-mcp-proxy/mcpproxy-go
cool!
anthropic mentions MCPs eating up context and solutions here: https://www.anthropic.com/engineering/code-execution-with-mc...
I built one specifically for Cognition's DeepWiki (https://crates.io/crates/dw2md) -- but it's rather narrow. Something more general like this clearly has more utility.
I may be showing my ignorance here, but wouldn't the ideal situation be for the service to use the same number of tokens no matter what client sent the query?
If the service is using more tokens to produce the same output from the same query, but over a different protocol, than the service is a scam.
When you're using an agent, the "query" isn't just each bit of text you enter into the agent prompt. It's the whole conversation.
But I do wonder about these tools whether they have tested that the quality of subsequent responses is the same.
That doesn't explain why the protocol matters. Surely for equivalent responses, you need to send equivalent payloads. You shouldn't be able to hack this from the client side.
How is this the 5th one of these I have seen this week, is everyone just trying to make the same thing?
Basically yes.
How does this differ from mcporter? https://github.com/steipete/mcporter/
Someone had to do it. mcp in bash would make them composable, which I think is the strongest benefit for high capability agents like Claude, Cursor and the like, who can write Bash better than I. Haven't gotten into MCP since early release because of the issues you named. Nice work!
How would the LLM exactly discover such unknown CLI commands?
Skills or tell it the --list command would be my guess.
How is it different from 'mcporter', already included in eg. openclaw?
I kind of feel like it might be better to go from CLI to MCP.
mcp just need to add dynamic tools discovery and lazy load them, that would solve this token problem right?
MCP itself is a flawed standard to being with as I said before [0] and its wraps around an API from the start.
You might as well directly create a CLI tool that works with the AI agents which does an API call to the service anyway.
[0] https://news.ycombinator.com/item?id=44479406
This post and the project README are obviously generated slop, which personally makes me completely skip the project altogether, even if it works.
If you want humans to spend time reading your prose, then spend time actually writing it.