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.
No
Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
101–110 of 118 posts
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#102Earlier quoted context omitted.
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?
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 canonic…
Sandboxing and auth is a problem solved at the agent ("harness") level. You don't need to reinvent OpenAPI badly.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#103Earlier quoted context omitted.
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 canonic…
Sandboxing and auth is a problem solved at the agent ("harness") level. You don't need to reinvent OpenAPI badly.
> Sandboxing and auth is a problem solved at the agent ("harness") level
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
For prompts and resources to work, industry would have to agree on defined endpoints, request/response types. That's what MCP is.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#104Interesting! is this exclusive for LLM usage?
it's also for humans!
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#105Earlier quoted context omitted.
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?
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 canonic…
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?
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#106Earlier quoted context omitted.
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
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.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#107[dead]
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#108[dead]
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#109Should 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.
Re: Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP
#110The 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?