Live data from Hacker News

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

github.com

1–10 of 118 posts

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

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

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

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

#2
cool!

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.

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

#4
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.

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

#5
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!

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

#6
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.

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

#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 given city)
Which return the data in plain text.

What additional benefits does MCP bring to the table?

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

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

The prophecy of the hypermedia web
Post reply on HN