Precisely, there are about 100 of these, and everyone makes a new one every week.
short_sells_poo 12 hours ago [-]
This is entirely predictable: we get an army of vibe coders, vibe coding up tools to make vibe coding easier.
wat10000 9 hours ago [-]
For simple stuff like this, it's easier to have the agent build something than it is to figure out how to install someone else's.
casey2 13 hours ago [-]
there is nobody making a new one ever week.
knowsuchagency 8 hours ago [-]
lol I didn’t know there were so many but I’m not surprised.
I was inspired by clihub (I credited them) but I also wanted 3 additional things.
1. OpenAPI support
2. Dynamic CLI generation. I don’t want to recompile my CLI if the server changes.
3. An agent skill
Aperocky 9 hours ago [-]
The biggest surprise of this list is someone grabbed "f" as github username, clever.
siva7 11 hours ago [-]
Which one do you recommend?
jebus989 11 hours ago [-]
Roll your own
rodchalski 2 hours ago [-]
The token savings are real and the on-demand discovery approach is the right design. MCP's schema bloat is a genuine problem for multi-tool environments.
Worth noting what this doesn't change: the authorization surface. Whether the agent discovers 120 tools eagerly (native MCP) or lazily (mcp2cli), the set of tools it's permitted to call is the same. Token efficiency doesn't reduce blast radius.
MCP today has no authorization layer in the spec. Every connected server grants the agent full access to every tool it exposes. The agent decides what to call based on its own reasoning. If prompt injection hijacks that reasoning, the agent calls tools it shouldn't — and there's no enforcement boundary between "agent wants to call X" and "X executes."
Two distinct problems:
1. Context efficiency: how does the agent learn what tools exist? (mcp2cli solves this well)
2. Authorization scoping: which tools is this agent permitted to invoke for this specific task? (nobody in the MCP ecosystem is solving this yet)
Solving #1 without #2 means you have a more efficient agent with the same unrestricted access. That's useful — but it's not safer.
Curious if you've thought about adding permission metadata to the CLI discovery layer — something like --allowed-tools that an orchestrator could set, so the agent only sees tools it's authorized to use for the current task.
Doublon 15 hours ago [-]
We had `curl`, HTTP and OpenAPI specs, but we created MCP.
Now we're wrapping MCP into CLIs...
re-thc 13 hours ago [-]
> but we created MCP. Now we're wrapping MCP into CLIs...
Next we'll wrap the CLIs into MCPs.
otabdeveloper4 13 hours ago [-]
MCP is a dead end, just ignore it and it will go away.
ffsm8 12 hours ago [-]
And yet without MCP these CLI generators wouldn't be possible.
It building on top of them, because MCP did address some issues (which arguably could've been solved better with clis to begin with - like adding proper help texts to each command)... it just also introduced new ones, too.
Some of which still won't be solved via switching back to CLI.
The obvious one being authentication and privileges.
By default, I want the LLM to be able to have full read only access. This is straightforward to solve with an MCP because the tools have specific names.
With CLI it's not as straightforward, because it'll start piping etc and the same CLI is often used both for write and read access.
All solvable issues, but while I suspect CLIs are going to get a lot more traction over the next few months, it's still not the thing we'll settle on- unless the privileges situation can be solved without making me greenlight commands every 2 seconds (or ignoring their tendency to occasionally go batshit insane and randomly wipe things out while running in yolo mode)
jancurn 12 hours ago [-]
Exactly. Once you start looking at MCP as a protocol to access remote OAuth-protected resources, not an API for building agents, you realize the immense value
wild_egg 9 hours ago [-]
Aside from consistent auth, that's what all APIs have done for decades.
Only takes 2 minutes for an agent to sort out auth on other APIs so the consistent auth piece isn't much of a selling point either.
ffsm8 8 hours ago [-]
Yes, MCP could've been solved differently - eg with an extension to the openapi spec for example, at least from the perspective of REST APIs... But you're misunderstanding the selling point.
The issue is that granting the LLM access to the API needs something more granular then "I don't care, just keep doing whatever you wanna do" and getting promoted every 2 seconds for the LLM to ask the permission to access something.
With MCP, each of these actions is exposed as a tool and can be safely added to the "you may execute this as often as you want" list, and you'll never need to worry that the LLM randomly decides to delete something - because you'll still get a prompt for that, as that hasn't been whitelisted.
This is once again solvable in different ways, and you could argue the current way is actually pretty suboptimal too... Because I don't really need the LLM to ask for permission to delete something it just created for example. But the MCP would only let me whitelist action, hence still unnecessary security prompts. But the MCP tool adds a different layer - we can both use it as a layer to essentially remove the authentication on the API you want the LLM to be able to call and greenlight actions for it to execute unattended.
Again, it's not a silver bullet and I'm sure what we'll eventually settle on will be something different - however as of today, MCP servers provide value to the LLM stack. Even if this value may be provided even better differently, current alternative all come with different trade-offs
And all of what I wrote ignores the fact that not every MCP is just for rest APIs. Local permissions need to be solved too. The tool use model is leaky, but better then nothing.
edgyquant 12 hours ago [-]
It’s not, they are a big unlock when using something like cursor or copilot. I think people who say this don’t quite know what MCP is, it’s just a thin wrapper around an API that describes its endpoints as tools. How is there not a ton of value in this?
CharlieDigital 11 hours ago [-]
MCP is the future in enterprise and teams.
It's as you said: people misunderstand MCP and what it delivers.
If you only use it as an API? Useless. If you use it on a small solo project? Useless.
But if you want to share skills across a fleet of repos? Deliver standard prompts to baseline developer output and productivity? Without having to sync them? And have it updated live? MCP prompts.
If you want to share canonical docs like standard guidance on security and performance? Always up to date and available in every project from the start? No need to sync and update? MCP resources.
If you want standard telemetry and observability of usage? MCP because now you can emit and capture OTEL from the server side.
If you want to wire execution into sandboxed environments? MCP.
MCP makes sense for org-level agent engineering but doesn't make sense for the solo vibe coder working on an isolated codebase locally with no need to sandbox execution.
People are using MCP for the wrong use cases and then declaring them excess when the real use case is standardizing remote delivery and of skills and resources. Tool execution is secondary.
retrochameleon 4 hours ago [-]
You sound more like you like skills than MCP itself. Skills encapsulate the behavior to be reused.
MCP is a protocol that may have been useful once, but it seems obsolete already. Agents are really good at discovering capabilities and using them. If you give it a list of CLI tools with a one line description, it would probably call the tool's help page and find out everything it needs to know before using the tool. What benefit does MCP actually add?
doix 10 hours ago [-]
So just to clarify, in your case you're running a centralized MCP server for the whole org, right?
Otherwise I don't understand how MCP vs CLI solves anything.
CharlieDigital 8 hours ago [-]
Correct.
Centralized MCP server over HTTP that enables standardized doc lookup across the org, standardized skills (as MCP prompt), MCP resources (these are virtual indexes of the docs that is similar to how Vercel formatted their `AGENTS.md`), and a small set of tools.
We emit OTEL from the server and build dashboards to see how the agents and devs are using context and tools and which documents are "high signal" meaning they get hit frequently so we know that tuning these docs will yield more consistent output.
OAuth lets us see the users because every call has identity attached.
otabdeveloper4 7 hours ago [-]
Sandboxing and auth is a problem solved at the agent ("harness") level. You don't need to reinvent OpenAPI badly.
CharlieDigital 5 hours ago [-]
> Sandboxing and auth is a problem solved at the agent ("harness") level
If you run a homogeneous set of harnesses/runtimes (we don't; some folks are on Cursor, some on Codex, some on Claude, some on OpenCode, some on VS Code GHCP). The only thing that works across all of them? MCP.
Everything about local CLIs and skill files works great as long as you are 1) running in your own env, 2) working on a small, isolated codebase, 3) working in a fully homogeneous environment, 4) each repo only needs to know about itself and not about a broader ecosystem of services and capabilities.
Beyond that, some kind of protocol is necessary to standardize how information is shared across contexts.
That's why my OP prefaced that MCP is critical for orgs and enterprises because it alleviates some of the friction points for standardizing behavior across a fleet of repos and tools.
> You don't need to reinvent OpenAPI badly
You are only latching onto one aspect of MCP servers: tools. But MCP delivers two other critical features: prompts and resources and it is here where MCP provides contextual scaffold over otherwise generic OpenAPI. Tools is perhaps the least interesting of MCP features (though useful, still, in an enterprise context because centralized tools allows for telemetry)
For prompts and resources to work, industry would have to agree on defined endpoints, request/response types. That's what MCP is.
Charon77 14 hours ago [-]
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
edgyquant 12 hours ago [-]
No it’s more like - because AI can’t know every endpoint and what it does, so MCP allows for injecting the endpoints and a description into context so the ai can choose the right tool without additions steps
ekianjo 13 hours ago [-]
Agents can't write bash correctly so... I wonder about your claim
mannyv 4 hours ago [-]
It can. Not sure what AI you're using, but Gemini outputs great bash. Of course you need to test it.
You do have to make sure to tell it what platform you're using, because things like MacOS have different CLIs than Linux.
anonzzzies 12 hours ago [-]
They cannot? We have a client from 25 years ago and all the devops for them are massive bash scripts; 1000s of them. Not written by us (well some parts as maintenance) and really the only 'thing' that almost always flawlessly fixes and updates them is claude code. Even with insane bash in bash in bash escaping and all kinds of not well known constructs. It works. So we habe no incentive to refactor or rewrite. We did 5 years ago and postponed as we first had to rewrite their enormous and equally badly written ERP for their factory. Maybe that would not have happened either now...
12 hours ago [-]
jamiemallers 8 hours ago [-]
[dead]
DieErde 15 hours ago [-]
Why is the concept of "MCP" needed at all? Wouldn't a single tool - web access - be enough? Then you can prompt:
Tell me the hottest day in Paris in the
coming 7 days. You can find useful tools
at www.weatherforadventurers.com/tools
And then the tools url can simply return a list of urls in plain text like
/tool/forecast?city=berlin&day=2026-03-09 (Returns highest temp and rain probability for the given day in the given city)
Which return the data in plain text.
What additional benefits does MCP bring to the table?
SyneRyder 15 hours ago [-]
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.
Phlogistique 15 hours ago [-]
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.
rvz 14 hours ago [-]
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.
acchow 13 hours ago [-]
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.
regularfry 13 hours ago [-]
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.
fennecbutt 13 hours ago [-]
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.
ewidar 15 hours ago [-]
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.
iddan 15 hours ago [-]
The prophecy of the hypermedia web
Traubenfuchs 15 hours ago [-]
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?
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!
stephantul 16 hours ago [-]
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.
hrmtst93837 14 hours ago [-]
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.
stephantul 10 hours ago [-]
Are you an llm? That would be so ironic
danlitt 8 hours ago [-]
I found this comment because I was wondering the same thing on a completely unrelated thread. I strongly suspect this is a bot.
hrmtst93837 8 hours ago [-]
You can post this under every of my comments, that does not make it true. I can go to your account and do the same on your comments.
danlitt 8 hours ago [-]
ok, I'll stop. I am not the only person who suspected you!
hrmtst93837 8 hours ago [-]
I use LLMs to support in writing comments, like brainstorming and fixing grammar + spelling. But many people use that these days.
7 hours ago [-]
stephantul 8 hours ago [-]
This is such a funny interaction
hrmtst93837 7 hours ago [-]
Happens all the time nowadays here on HN. IMHO, The llm accusations go out of hand
hrmtst93837 8 hours ago [-]
No, unless you ask danlitt who tries to suspect me of llm under every of my comments.
rakag 13 hours ago [-]
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."
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.
acchow 13 hours ago [-]
> 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.
phh 13 hours ago [-]
Absoultely.
I'll add to your comment that it isn't a bug of MCP itself. MCP doesn't specify what the LLM sees. It's a bug of the MCP client.
In my toy chatbot, I implement MCP as pseudo-python for the LLM, dropping typing info, and giving the tool infos as abruptly as possible, just a line - function_name(mandatory arg1 name, mandatory arg2 name): Description
(I don't recommend doing that, it's largely obsolete, my point is simply that you feed the LLM whatever you want, MCP doesn't mandate anything. tbh it doesn't even mandate that it feeds into a LLM, hence the MCP CLIs)
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.
Terretta 11 hours ago [-]
> > 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.
ANTHROP\C's Claudes manage/minimize/mitigate this reaonably.
edgyquant 12 hours ago [-]
That’s a trade off, now you need multiple model calls for every single request
ekianjo 13 hours ago [-]
Yes we just RAG to be applied on tools. Very simple to implement.
edgyquant 12 hours ago [-]
I don’t think so. Without a list of tools in context the ai can’t even know what options it has, so a RAG like search doesn’t feel like it would be anywhere near as accurate
ekianjo 11 hours ago [-]
The RAG helps select the tool needed for the task at hand. Semantic search returns only the tools that match. Very efficient.
jofzar 15 hours ago [-]
How is this the 5th one of these I have seen this week, is everyone just trying to make the same thing?
hnlmorg 14 hours ago [-]
Basically yes.
sathish316 9 hours ago [-]
Since there is no friction and everyone is generating an idea to code using GitHub training data, this is basically the future
hnlmorg 9 hours ago [-]
Not invented here (NIH) syndrome has always been a thing but I think what we are seeing at the moment is an artificial high vs new ideas because
1. People are looking for excuses to learn to use AI because they’re scared of being left behind.
2. People are looking for examples of AI projects to add to their LinkedIn profile so they appear a tech leader and thus more employable
One pattern we've been seeing internally is that once teams
standardize API interactions through a single interface
(or agent layer), debugging becomes both easier and harder.
Easier because there's a central abstraction,
harder because failures become more opaque.
In production incidents we often end up tracing through
multiple abstraction layers before finding the real root cause.
Curious if you've built anything into the CLI to help with
observability or tracing when something fails.
ryanholtdev 8 hours ago [-]
The lazy discovery pattern is clever. Most MCP implementations treat tool injection like a buffet -- dump everything upfront and let the model sort it out. The problem is you pay the context cost whether the model uses those tools or not, and at 120+ tools that cost compounds fast.
The analogy I'd draw is database query planning: you don't load the entire schema into memory before every query, you resolve references on demand. Same principle here. Does the CLI maintain a tool cache between invocations, or does it re-fetch schemas each time?
knowsuchagency 8 hours ago [-]
It caches the spec with a default TTL of 1 hour
alkh 9 hours ago [-]
Can someone please explain how one would tell LLM to use such a CLI over a natively supported MCP server? Do you need to add the info about CLI into persistent memory(ex. AGENTS.md) and run an mcp server manually? Or it is something else?
sathish316 9 hours ago [-]
A simple prompt that tells the agent how to use gh cli to use GitHub using —help commands makes the agent start learning how to use a specific cli and just use it.
This method was popularised by beads with a simple command “bd quickstart” to teach the basics to an agent. Think of this as an adaptive learning method for the agent.
I’ve not seen the details of mcp2cli, but let’s just say you had a mcp2cli wrapper over stripe, you can just tell the agent to run mcp2cli for stripe as a provider to learn how to use the rest of the APIs
Intermernet 14 hours ago [-]
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.
sathish316 9 hours ago [-]
If you intercept what an agent (client) sends to the LLM with multiple MCP servers and tools, the context or header is filled with available MCP servers and all tools as part of the conversation.
With a CLI, you avoid sending this context to the LLM and it progressively discovers only what is needed.
The input token costs come down because of using a CLI instead of MCP
mvc 14 hours ago [-]
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.
Intermernet 14 hours ago [-]
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.
philipp-gayret 16 hours ago [-]
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!
Essentially I've cloned thousands of mcp servers, used the readmes and the star rating to respond to the qdrant query (star ratings as a boost score have been an attack vector, yes I know, it's an incomplete product [1]), then presents it as a JSON response with "one-shots" which this author calls clis.
I think I became discouraged from working on it and moved on because my results weren't that great but search is hard and I shouldn't give up.
I'll get back on it seeing how good this tool is getting traction.
[1] There needs to be a legitimacy post-filter so that github user micr0s0ft or what-have-you doesn't go to to the top - I'm sure there's some best-of-practice ways of doing this and I shouldn't invent my own (which would involve seeing if the repo appears on non-UGC sites I guess?!) but I haven't looked into it
Mashimo 15 hours ago [-]
Skills or tell it the --list command would be my guess.
ramoz 11 hours ago [-]
Skills is the right abstraction.
vicchenai 12 hours ago [-]
the token math is compelling but I'm curious about the discovery step. with native MCP the host already knows what tools exist. with this, the agent has to run --list first, which means extra roundtrips. for 120 tools that might still be a net win, but the latency tradeoff seems worth calling out
termwatch 9 hours ago [-]
Interesting! is this exclusive for LLM usage?
knowsuchagency 5 hours ago [-]
it's also for humans!
jkisiel 15 hours ago [-]
How is it different from 'mcporter', already included in eg. openclaw?
Ozzie_osman 15 hours ago [-]
I kind of feel like it might be better to go from CLI to MCP.
tuananh 15 hours ago [-]
mcp just need to add dynamic tools discovery and lazy load them, that would solve this token problem right?
andai 12 hours ago [-]
Time is a flat circle...
rakamotog 13 hours ago [-]
For a typical B2B SaaS usecase (non technical employees) -> MCP is working great since its allows people to work in Chat interfaces (ChatGPT, Claude). They will not move to terminal UX's anytime soon.
So, I dont see why a typical productivity app build CLI than MCP. Am I missing anything?
lagrange77 8 hours ago [-]
It's about letting LLM Agents use the CLI, the end user still interfaces with the agent via chat.
16 hours ago [-]
kristopolous 12 hours ago [-]
Cool to see this!
I started a similar project in January but but nobody seemed interested in it at the time.
The intention is to get this working better and then provide it as a free api and also post the entire qdrant database (or whatever is eventually used) for off-line use.
This will pair with something called a "credential file" which will be a [key, repo] pair. There's an attack vector if you don't pair them up. (You could have an mcp server for some niche thing, get on the aggregators, get fake stars, change the the code to be to a fraud version of a popular mcp server, harvest real api keys from sloppy tooling and MitM)
Anyway, we're talking about 1000s of documents at the most, maybe 10,000. So it's entirely givable away as free.
If you like this project, please tell me. Your encouragement means a lot to me!
I don't want to spend my time on things that nobody seems to be interested in.
Terretta 11 hours ago [-]
> If you like this project, please tell me. Your encouragement means a lot to me! I don't want to spend my time on things that nobody seems to be interested in.
Great implementation details, but what is the end goal? Ah ha, a readable readme (which itself is promising):
InfiniteMCP is a an MCP server that acts as a universal gateway to thousands of other MCP servers. Instead of manually configuring each MCP server you want to use, InfiniteMCP lets Claude discover, understand, and use any MCP server on demand through natural language queries.
Think of it as an "MCP server of MCP servers" - a single connection that unlocks the entire MCP ecosystem.
So, yeah, that's interesting.
> and then provide it as a free api
Oh, oops, that just became a supply chain threat. Central registries outside of targets' control are grails, and the speculated implementation for secrets makes this a lovely injection path...
If you pursue this, work with someone like control-plane.io to blue/red team it and make noise about that on your README with a link to their findings and your mitigations. And consider sync up with folks like kusari.dev (see also SLSA and GUAC) to include a vulns rating on each MCP itself (their mapping is super fast and a SBOM scanned MCP directory would be a real value add).
9 hours ago [-]
ekianjo 13 hours ago [-]
Doubtful that a 16 tokens summary is the same as she JSON tool description that uses 10x more tokens. The JSON will describe parameters in a longer way and that has probably some positive impact on accuracy
rvz 15 hours ago [-]
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.
It turns out everyone is having the same idea.
Here's the comparison table: https://github.com/apify/mcpc?tab=readme-ov-file#related-wor...
I was inspired by clihub (I credited them) but I also wanted 3 additional things.
1. OpenAPI support 2. Dynamic CLI generation. I don’t want to recompile my CLI if the server changes. 3. An agent skill
Worth noting what this doesn't change: the authorization surface. Whether the agent discovers 120 tools eagerly (native MCP) or lazily (mcp2cli), the set of tools it's permitted to call is the same. Token efficiency doesn't reduce blast radius.
MCP today has no authorization layer in the spec. Every connected server grants the agent full access to every tool it exposes. The agent decides what to call based on its own reasoning. If prompt injection hijacks that reasoning, the agent calls tools it shouldn't — and there's no enforcement boundary between "agent wants to call X" and "X executes."
Two distinct problems: 1. Context efficiency: how does the agent learn what tools exist? (mcp2cli solves this well) 2. Authorization scoping: which tools is this agent permitted to invoke for this specific task? (nobody in the MCP ecosystem is solving this yet)
Solving #1 without #2 means you have a more efficient agent with the same unrestricted access. That's useful — but it's not safer.
Curious if you've thought about adding permission metadata to the CLI discovery layer — something like --allowed-tools that an orchestrator could set, so the agent only sees tools it's authorized to use for the current task.
Next we'll wrap the CLIs into MCPs.
It building on top of them, because MCP did address some issues (which arguably could've been solved better with clis to begin with - like adding proper help texts to each command)... it just also introduced new ones, too.
Some of which still won't be solved via switching back to CLI.
The obvious one being authentication and privileges.
By default, I want the LLM to be able to have full read only access. This is straightforward to solve with an MCP because the tools have specific names.
With CLI it's not as straightforward, because it'll start piping etc and the same CLI is often used both for write and read access.
All solvable issues, but while I suspect CLIs are going to get a lot more traction over the next few months, it's still not the thing we'll settle on- unless the privileges situation can be solved without making me greenlight commands every 2 seconds (or ignoring their tendency to occasionally go batshit insane and randomly wipe things out while running in yolo mode)
Only takes 2 minutes for an agent to sort out auth on other APIs so the consistent auth piece isn't much of a selling point either.
The issue is that granting the LLM access to the API needs something more granular then "I don't care, just keep doing whatever you wanna do" and getting promoted every 2 seconds for the LLM to ask the permission to access something.
With MCP, each of these actions is exposed as a tool and can be safely added to the "you may execute this as often as you want" list, and you'll never need to worry that the LLM randomly decides to delete something - because you'll still get a prompt for that, as that hasn't been whitelisted.
This is once again solvable in different ways, and you could argue the current way is actually pretty suboptimal too... Because I don't really need the LLM to ask for permission to delete something it just created for example. But the MCP would only let me whitelist action, hence still unnecessary security prompts. But the MCP tool adds a different layer - we can both use it as a layer to essentially remove the authentication on the API you want the LLM to be able to call and greenlight actions for it to execute unattended.
Again, it's not a silver bullet and I'm sure what we'll eventually settle on will be something different - however as of today, MCP servers provide value to the LLM stack. Even if this value may be provided even better differently, current alternative all come with different trade-offs
And all of what I wrote ignores the fact that not every MCP is just for rest APIs. Local permissions need to be solved too. The tool use model is leaky, but better then nothing.
It's as you said: people misunderstand MCP and what it delivers.
If you only use it as an API? Useless. If you use it on a small solo project? Useless.
But if you want to share skills across a fleet of repos? Deliver standard prompts to baseline developer output and productivity? Without having to sync them? And have it updated live? MCP prompts.
If you want to share canonical docs like standard guidance on security and performance? Always up to date and available in every project from the start? No need to sync and update? MCP resources.
If you want standard telemetry and observability of usage? MCP because now you can emit and capture OTEL from the server side.
If you want to wire execution into sandboxed environments? MCP.
MCP makes sense for org-level agent engineering but doesn't make sense for the solo vibe coder working on an isolated codebase locally with no need to sandbox execution.
People are using MCP for the wrong use cases and then declaring them excess when the real use case is standardizing remote delivery and of skills and resources. Tool execution is secondary.
MCP is a protocol that may have been useful once, but it seems obsolete already. Agents are really good at discovering capabilities and using them. If you give it a list of CLI tools with a one line description, it would probably call the tool's help page and find out everything it needs to know before using the tool. What benefit does MCP actually add?
Otherwise I don't understand how MCP vs CLI solves anything.
Centralized MCP server over HTTP that enables standardized doc lookup across the org, standardized skills (as MCP prompt), MCP resources (these are virtual indexes of the docs that is similar to how Vercel formatted their `AGENTS.md`), and a small set of tools.
We emit OTEL from the server and build dashboards to see how the agents and devs are using context and tools and which documents are "high signal" meaning they get hit frequently so we know that tuning these docs will yield more consistent output.
OAuth lets us see the users because every call has identity attached.
Everything about local CLIs and skill files works great as long as you are 1) running in your own env, 2) working on a small, isolated codebase, 3) working in a fully homogeneous environment, 4) each repo only needs to know about itself and not about a broader ecosystem of services and capabilities.
Beyond that, some kind of protocol is necessary to standardize how information is shared across contexts.
That's why my OP prefaced that MCP is critical for orgs and enterprises because it alleviates some of the friction points for standardizing behavior across a fleet of repos and tools.
You are only latching onto one aspect of MCP servers: tools. But MCP delivers two other critical features: prompts and resources and it is here where MCP provides contextual scaffold over otherwise generic OpenAPI. Tools is perhaps the least interesting of MCP features (though useful, still, in an enterprise context because centralized tools allows for telemetry)For prompts and resources to work, industry would have to agree on defined endpoints, request/response types. That's what MCP is.
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
You do have to make sure to tell it what platform you're using, because things like MacOS have different CLIs than Linux.
What additional benefits does MCP bring to the table?
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.
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.
MCP is just as worse version of the above allowing lots of data exfiltration and manipulation by the LLM.
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.
You could do the same with a CLI tool but it's more of a hassle to set up.
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.
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.
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!
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.
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.
"We measured this. Not estimates — actual token counts using the cl100k_base tokenizer against real schemas, verified by an automated test suite."
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 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.
I'll add to your comment that it isn't a bug of MCP itself. MCP doesn't specify what the LLM sees. It's a bug of the MCP client.
In my toy chatbot, I implement MCP as pseudo-python for the LLM, dropping typing info, and giving the tool infos as abruptly as possible, just a line - function_name(mandatory arg1 name, mandatory arg2 name): Description
(I don't recommend doing that, it's largely obsolete, my point is simply that you feed the LLM whatever you want, MCP doesn't mandate anything. tbh it doesn't even mandate that it feeds into a LLM, hence the MCP CLIs)
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.
> I consider this a bug. I'm sure the chat clients will fix this soon enough.
ANTHROP\C's Claudes manage/minimize/mitigate this reaonably.
1. People are looking for excuses to learn to use AI because they’re scared of being left behind.
2. People are looking for examples of AI projects to add to their LinkedIn profile so they appear a tech leader and thus more employable
One pattern we've been seeing internally is that once teams standardize API interactions through a single interface (or agent layer), debugging becomes both easier and harder.
Easier because there's a central abstraction, harder because failures become more opaque.
In production incidents we often end up tracing through multiple abstraction layers before finding the real root cause.
Curious if you've built anything into the CLI to help with observability or tracing when something fails.
The analogy I'd draw is database query planning: you don't load the entire schema into memory before every query, you resolve references on demand. Same principle here. Does the CLI maintain a tool cache between invocations, or does it re-fetch schemas each time?
This method was popularised by beads with a simple command “bd quickstart” to teach the basics to an agent. Think of this as an adaptive learning method for the agent.
I’ve not seen the details of mcp2cli, but let’s just say you had a mcp2cli wrapper over stripe, you can just tell the agent to run mcp2cli for stripe as a provider to learn how to use the rest of the APIs
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.
With a CLI, you avoid sending this context to the LLM and it progressively discovers only what is needed.
The input token costs come down because of using a CLI instead of MCP
But I do wonder about these tools whether they have tested that the quality of subsequent responses is the same.
Essentially I've cloned thousands of mcp servers, used the readmes and the star rating to respond to the qdrant query (star ratings as a boost score have been an attack vector, yes I know, it's an incomplete product [1]), then presents it as a JSON response with "one-shots" which this author calls clis.
I think I became discouraged from working on it and moved on because my results weren't that great but search is hard and I shouldn't give up.
I'll get back on it seeing how good this tool is getting traction.
[1] There needs to be a legitimacy post-filter so that github user micr0s0ft or what-have-you doesn't go to to the top - I'm sure there's some best-of-practice ways of doing this and I shouldn't invent my own (which would involve seeing if the repo appears on non-UGC sites I guess?!) but I haven't looked into it
So, I dont see why a typical productivity app build CLI than MCP. Am I missing anything?
I started a similar project in January but but nobody seemed interested in it at the time.
Looks like I'll get back on that.
https://github.com/day50-dev/infinite-mcp
Essentially
(1) start with the aggregator mcp repos: https://github.com/day50-dev/infinite-mcp/blob/main/gh-scrap... . pull all of them down.
(2) get the meta information to understand how fresh, maintained, and popular the projects are (https://github.com/day50-dev/infinite-mcp/blob/main/gh-get-m...)
(3) try to extract one-shot ways of loading it (npx/uvx etc) https://github.com/day50-dev/infinite-mcp/blob/main/gh-one-l...
(4) insert it into what I thought was qdrant but apparently I was still using chroma - I'll change that soon
(5) use a search endpoint and an mcp to seach that https://github.com/day50-dev/infinite-mcp/blob/main/infinite...
The intention is to get this working better and then provide it as a free api and also post the entire qdrant database (or whatever is eventually used) for off-line use.
This will pair with something called a "credential file" which will be a [key, repo] pair. There's an attack vector if you don't pair them up. (You could have an mcp server for some niche thing, get on the aggregators, get fake stars, change the the code to be to a fraud version of a popular mcp server, harvest real api keys from sloppy tooling and MitM)
Anyway, we're talking about 1000s of documents at the most, maybe 10,000. So it's entirely givable away as free.
If you like this project, please tell me. Your encouragement means a lot to me!
I don't want to spend my time on things that nobody seems to be interested in.
Great implementation details, but what is the end goal? Ah ha, a readable readme (which itself is promising):
InfiniteMCP is a an MCP server that acts as a universal gateway to thousands of other MCP servers. Instead of manually configuring each MCP server you want to use, InfiniteMCP lets Claude discover, understand, and use any MCP server on demand through natural language queries.
Think of it as an "MCP server of MCP servers" - a single connection that unlocks the entire MCP ecosystem.
So, yeah, that's interesting.
> and then provide it as a free api
Oh, oops, that just became a supply chain threat. Central registries outside of targets' control are grails, and the speculated implementation for secrets makes this a lovely injection path...
If you pursue this, work with someone like control-plane.io to blue/red team it and make noise about that on your README with a link to their findings and your mitigations. And consider sync up with folks like kusari.dev (see also SLSA and GUAC) to include a vulns rating on each MCP itself (their mapping is super fast and a SBOM scanned MCP directory would be a real value add).
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
If you want humans to spend time reading your prose, then spend time actually writing it.