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.
Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
41–50 of 118 posts
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#42Cool, 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/stei…
Precisely, there are about 100 of these, and everyone makes a new one every week.
there is nobody making a new one ever week.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#43> 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.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#44Why 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 gi…
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.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#45> 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.
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)
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#46Doubtful 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
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#47We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...
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
Agents can't write bash correctly so... I wonder about your claim
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#48> 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.
Yes we just RAG to be applied on tools. Very simple to implement.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#49For 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?
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#50This 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.