Live data from Hacker News

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

github.com

111–118 of 118 posts

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

#111

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?

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

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

#114
post #28

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/stei…

I understand the need to do your own, I do it all the time.

But why advertise it and try to make it into a product?

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

#115
post #8

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 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…

[dead]

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

#116
post #55

Earlier quoted context omitted.

MCP is a dead end, just ignore it and it will go away.

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…

Of course they would be possible we could just turn the rest api into a cli.

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

#118
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

Post reply on HN