6 ms·

Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP

146 points by knowsuchagency 6mo ago

Every MCP server injects its full tool schemas into context on every turn — 30 tools costs ~3,600 tokens/turn whether the model uses them or not. Over 25 turns with 120 tools, that's 362,000 tokens just for schemas. mcp2cli turns any MCP server or OpenAPI spec into a CLI at runtime. The LLM discovers tools on demand: mcp2cli --mcp https://mcp.example.com/sse --list # ~16 tokens/tool mcp2cli --mcp https://mcp.example.com/sse create-task --help # ~120 tokens, once mcp2cli --mcp https://mcp.example.com/sse create-task --title "Fix bug" No codegen, no rebuild when the server changes. Works with any LLM — it's just a CLI the model shells out to. Also handles OpenAPI specs (JSON/YAML, local or remote) with the same interface. Token savings are real, measured with cl100k_base: 96% for 30 tools over 15 turns, 99% for 120 tools over 25 turns. It also ships as an installable skill for AI coding agents (Claude Code, Cursor, Codex): `npx skills add knowsuchagency/mcp2cli --skill mcp2cli` Inspired by Kagan Yilmaz's CLI vs MCP analysis and CLIHub. https://github.com/knowsuchagency/mcp2cli https://github.com/knowsuchagency/mcp2cli

tokenbar 6mo ago
[dead]
jkisiel 6mo ago
How is it different from 'mcporter', already included in eg. openclaw?
jofzar 6mo ago
How is this the 5th one of these I have seen this week, is everyone just trying to make the same thing?
- hnlmorg 6mo ago
  Basically yes.
  - sathish316 6mo ago
    Since there is no friction and everyone is generating an idea to code using GitHub training data, this is basically the future
    - hnlmorg 6mo 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
nwyin 6mo ago
cool! anthropic mentions MCPs eating up context and solutions here: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc... I built one specifically for Cognition's DeepWiki (https://crates.io/crates/dw2md https://crates.io/crates/dw2md) -- but it's rather narrow. Something more general like this clearly has more utility.
deleted 6mo ago
[deleted]
stephantul 6mo 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 6mo ago
  [flagged]
  - stephantul 6mo ago
    Are you an llm? That would be so ironic
    - danlitt 6mo 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 6mo ago
        [flagged]
        danlitt 6mo ago
        ok, I'll stop. I am not the only person who suspected you!
        hrmtst93837 6mo ago
        [flagged]
        stephantul 6mo ago
philipp-gayret 6mo 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!
liminal-dev 6mo ago
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.
- knowsuchagency 6mo ago
  No
silverwind 6mo ago
How would the LLM exactly discover such unknown CLI commands?
- Mashimo 6mo ago
  Skills or tell it the --list command would be my guess.
  - ramoz 6mo ago
    Skills is the right abstraction.
- kristopolous 6mo ago
  I've got a qdrant based approach that I'm working on that solves that here: https://github.com/day50-dev/infinite-mcp https://github.com/day50-dev/infinite-mcp 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
DieErde 6mo 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?
- iddan 6mo ago
  The prophecy of the hypermedia web
  - Traubenfuchs 6mo 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?
- ewidar 6mo 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.
- Phlogistique 6mo 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-network-access-and-anthropic-api-for-data-exfiltration/ 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.
Ozzie_osman 6mo ago
I kind of feel like it might be better to go from CLI to MCP.
rvz 6mo 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. [0] https://news.ycombinator.com/item?id=44479406 https://news.ycombinator.com/item?id=44479406
tuananh 6mo ago
mcp just need to add dynamic tools discovery and lazy load them, that would solve this token problem right?
Doublon 6mo ago
We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...
- Charon77 6mo 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
  - ekianjo 6mo ago
    Agents can't write bash correctly so... I wonder about your claim
    - anonzzzies 6mo 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...
    - mannyv 6mo 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.
  - deleted 6mo ago
    [deleted]
  - 6mo ago
benvan 6mo ago
Nice project! I've been working on something very similar here https://github.com/max-hq/max 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!
techpulse_x 6mo ago
[flagged]
ejoubaud 6mo ago
How does this differ from mcporter? https://github.com/steipete/mcporter/ https://github.com/steipete/mcporter/
tern 6mo ago
There are a handful of these. I've been using this one: https://github.com/smart-mcp-proxy/mcpproxy-go https://github.com/smart-mcp-proxy/mcpproxy-go
jancurn 6mo ago
Cool, adding this to my list of MCP CLIs: - https://github.com/apify/mcpc - https://github.com/chrishayuk/mcp-cli - https://github.com/wong2/mcp-cli - https://github.com/f/mcptools - https://github.com/adhikasp/mcp-client-cli - https://github.com/thellimist/clihub - https://github.com/EstebanForge/mcp-cli-ent - https://github.com/knowsuchagency/mcp2cli - https://github.com/philschmid/mcp-cli - https://github.com/steipete/mcporter - https://github.com/mattzcarey/cloudflare-mcp - https://github.com/assimelha/cmcp
- Aperocky 6mo ago
  The biggest surprise of this list is someone grabbed "f" as github username, clever.
- oulu2006 6mo ago
  Precisely, there are about 100 of these, and everyone makes a new one every week.
  - casey2 6mo ago
    there is nobody making a new one ever week.
  - short_sells_poo 6mo ago
    This is entirely predictable: we get an army of vibe coders, vibe coding up tools to make vibe coding easier.
    - wat10000 6mo 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.
- _pdp_ 6mo ago
  Also https://github.com/mcpshim/mcpshim https://github.com/mcpshim/mcpshim It turns out everyone is having the same idea.
Intermernet 6mo 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.
- mvc 6mo 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 6mo 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.
- sathish316 6mo 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
yogin16 6mo ago
[dead]
acchow 6mo 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.
- fennecbutt 6mo ago
  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.
- ekianjo 6mo ago
  Yes we just RAG to be applied on tools. Very simple to implement.
  - edgyquant 6mo 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 6mo ago
      The RAG helps select the tool needed for the task at hand. Semantic search returns only the tools that match. Very efficient.
- phh 6mo 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)
ekianjo 6mo 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
rakamotog 6mo 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 6mo ago
  It's about letting LLM Agents use the CLI, the end user still interfaces with the agent via chat.
devrimozcay 6mo ago
This looks useful. 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.
kristopolous 6mo ago
Cool to see this! 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 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-scrape.sh 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-meta.sh 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-liner.sh 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_mcp.py 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.
- Terretta 6mo 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).
vicchenai 6mo ago
[dead]
andai 6mo ago
Time is a flat circle...
alkh 6mo 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 6mo 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
termwatch 6mo ago
Interesting! is this exclusive for LLM usage?
- knowsuchagency 6mo ago
  it's also for humans!
ryanholtdev 6mo 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 6mo ago
  It caches the spec with a default TTL of 1 hour
rodchalski 6mo ago
[dead]
RealMrNida 6mo ago
[dead]
tom_m 6mo ago
Should make one for skills. I'm curious how effective this ends up being though. The model does need to know something about the tools (or skills) after all.
brianwmunz 6mo ago
The token savings bit is interesting but seems incomplete without showing that tool call accuracy holds up. I like the CLI-as-interface idea...the model already knows how to use CLIs, and on-demand discovery is genuinely smarter than front-loading every schema. How are you handling cases where a tool's schema changes between discovery and invocation? is there a cache invalidation story there or does it just re-fetch?
- knowsuchagency 6mo ago
  There's a default TTL of one hour for how long it caches the spec for.
bbtc3453 6mo ago
The token reduction is a big deal. I've been building a tool that calls GitHub API via AI and token costs add up quickly. Curious how it handles pagination for large API responses?
ryanschaefer 6mo ago
> Per turn Isn’t this somewhat misleading? Any system context is going to be added “per turn” because it’s included in the first turn. Is any context removed on a turn by turn basis (aside from thinking?)
0coCeo 6mo ago
Mcp2cli is a runtime approach — CLI translation at query time. There's a complementary build-time angle worth knowing about: fixing the schemas directly so they're token-efficient before they're ever served to a client. We graded 201 MCP servers (3,991 tools, 512K tokens total). 97% have quality issues that waste tokens: descriptions that repeat the parameter name verbatim, markdown formatting inside tool descriptions, missing type info, descriptions starting with 'This tool...' or 'Allows you to...'. None of this helps the LLM; it just costs tokens. agent-friend fix server.json > fixed.json reduces token count ~30% for most servers without changing functionality. The two approaches stack — fix the schema first, then serve via CLI if needed. https://github.com/0-co/agent-friend https://github.com/0-co/agent-friend

146 points by knowsuchagency 6mo ago

tokenbar 6mo ago

[dead]

jkisiel 6mo ago

How is it different from 'mcporter', already included in eg. openclaw?

jofzar 6mo ago

How is this the 5th one of these I have seen this week, is everyone just trying to make the same thing?

hnlmorg 6mo ago
Basically yes.
- sathish316 6mo ago
  Since there is no friction and everyone is generating an idea to code using GitHub training data, this is basically the future
  - hnlmorg 6mo 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

nwyin 6mo ago

cool! anthropic mentions MCPs eating up context and solutions here: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc... I built one specifically for Cognition's DeepWiki (https://crates.io/crates/dw2md https://crates.io/crates/dw2md) -- but it's rather narrow. Something more general like this clearly has more utility.

deleted 6mo ago

[deleted]

stephantul 6mo 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 6mo ago
[flagged]
- stephantul 6mo ago
  Are you an llm? That would be so ironic
  - danlitt 6mo 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 6mo ago
      [flagged]
      - danlitt 6mo ago
        ok, I'll stop. I am not the only person who suspected you!
        hrmtst93837 6mo ago
        [flagged]
        stephantul 6mo ago

philipp-gayret 6mo 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!

liminal-dev 6mo ago

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.

knowsuchagency 6mo ago
No

silverwind 6mo ago

How would the LLM exactly discover such unknown CLI commands?

Mashimo 6mo ago
Skills or tell it the --list command would be my guess.
- ramoz 6mo ago
  Skills is the right abstraction.
kristopolous 6mo ago
I've got a qdrant based approach that I'm working on that solves that here: https://github.com/day50-dev/infinite-mcp https://github.com/day50-dev/infinite-mcp 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

DieErde 6mo 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?

iddan 6mo ago
The prophecy of the hypermedia web
- Traubenfuchs 6mo 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?
ewidar 6mo 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.
Phlogistique 6mo 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-network-access-and-anthropic-api-for-data-exfiltration/ 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.

Ozzie_osman 6mo ago

I kind of feel like it might be better to go from CLI to MCP.

rvz 6mo 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. [0] https://news.ycombinator.com/item?id=44479406 https://news.ycombinator.com/item?id=44479406

tuananh 6mo ago

mcp just need to add dynamic tools discovery and lazy load them, that would solve this token problem right?

Doublon 6mo ago

We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...

Charon77 6mo 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
- ekianjo 6mo ago
  Agents can't write bash correctly so... I wonder about your claim
  - anonzzzies 6mo 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...
  - mannyv 6mo 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.
- deleted 6mo ago
  [deleted]
- 6mo ago

benvan 6mo ago

Nice project! I've been working on something very similar here https://github.com/max-hq/max 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!

techpulse_x 6mo ago

[flagged]

ejoubaud 6mo ago

How does this differ from mcporter? https://github.com/steipete/mcporter/ https://github.com/steipete/mcporter/

tern 6mo ago

There are a handful of these. I've been using this one: https://github.com/smart-mcp-proxy/mcpproxy-go https://github.com/smart-mcp-proxy/mcpproxy-go

jancurn 6mo ago

Cool, adding this to my list of MCP CLIs: - https://github.com/apify/mcpc - https://github.com/chrishayuk/mcp-cli - https://github.com/wong2/mcp-cli - https://github.com/f/mcptools - https://github.com/adhikasp/mcp-client-cli - https://github.com/thellimist/clihub - https://github.com/EstebanForge/mcp-cli-ent - https://github.com/knowsuchagency/mcp2cli - https://github.com/philschmid/mcp-cli - https://github.com/steipete/mcporter - https://github.com/mattzcarey/cloudflare-mcp - https://github.com/assimelha/cmcp

Aperocky 6mo ago
The biggest surprise of this list is someone grabbed "f" as github username, clever.
oulu2006 6mo ago
Precisely, there are about 100 of these, and everyone makes a new one every week.
- casey2 6mo ago
  there is nobody making a new one ever week.
- short_sells_poo 6mo ago
  This is entirely predictable: we get an army of vibe coders, vibe coding up tools to make vibe coding easier.
  - wat10000 6mo 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.
_pdp_ 6mo ago
Also https://github.com/mcpshim/mcpshim https://github.com/mcpshim/mcpshim It turns out everyone is having the same idea.

Intermernet 6mo 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.

mvc 6mo 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 6mo 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.
sathish316 6mo 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

yogin16 6mo ago

[dead]

acchow 6mo 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.

fennecbutt 6mo ago
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.
ekianjo 6mo ago
Yes we just RAG to be applied on tools. Very simple to implement.
- edgyquant 6mo 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 6mo ago
    The RAG helps select the tool needed for the task at hand. Semantic search returns only the tools that match. Very efficient.
phh 6mo 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)

ekianjo 6mo 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

rakamotog 6mo 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 6mo ago
It's about letting LLM Agents use the CLI, the end user still interfaces with the agent via chat.

devrimozcay 6mo ago

This looks useful. 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.

kristopolous 6mo ago

Cool to see this! 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 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-scrape.sh 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-meta.sh 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-liner.sh 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_mcp.py 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.

Terretta 6mo 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).

vicchenai 6mo ago

[dead]

andai 6mo ago

Time is a flat circle...

alkh 6mo 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 6mo 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

termwatch 6mo ago

Interesting! is this exclusive for LLM usage?

knowsuchagency 6mo ago
it's also for humans!

ryanholtdev 6mo 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 6mo ago
It caches the spec with a default TTL of 1 hour

rodchalski 6mo ago

[dead]

RealMrNida 6mo ago

[dead]

tom_m 6mo ago

Should make one for skills. I'm curious how effective this ends up being though. The model does need to know something about the tools (or skills) after all.

brianwmunz 6mo ago

The token savings bit is interesting but seems incomplete without showing that tool call accuracy holds up. I like the CLI-as-interface idea...the model already knows how to use CLIs, and on-demand discovery is genuinely smarter than front-loading every schema. How are you handling cases where a tool's schema changes between discovery and invocation? is there a cache invalidation story there or does it just re-fetch?

knowsuchagency 6mo ago
There's a default TTL of one hour for how long it caches the spec for.

bbtc3453 6mo ago

The token reduction is a big deal. I've been building a tool that calls GitHub API via AI and token costs add up quickly. Curious how it handles pagination for large API responses?

ryanschaefer 6mo ago

> Per turn Isn’t this somewhat misleading? Any system context is going to be added “per turn” because it’s included in the first turn. Is any context removed on a turn by turn basis (aside from thinking?)

0coCeo 6mo ago

Mcp2cli is a runtime approach — CLI translation at query time. There's a complementary build-time angle worth knowing about: fixing the schemas directly so they're token-efficient before they're ever served to a client. We graded 201 MCP servers (3,991 tools, 512K tokens total). 97% have quality issues that waste tokens: descriptions that repeat the parameter name verbatim, markdown formatting inside tool descriptions, missing type info, descriptions starting with 'This tool...' or 'Allows you to...'. None of this helps the LLM; it just costs tokens. agent-friend fix server.json > fixed.json reduces token count ~30% for most servers without changing functionality. The two approaches stack — fix the schema first, then serve via CLI if needed. https://github.com/0-co/agent-friend https://github.com/0-co/agent-friend