Live data from Hacker News

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

github.com

31–40 of 118 posts

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

#31

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.

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.

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

#32
post #31

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.

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.

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.

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

#34
post #15

We 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

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

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

Precisely, there are about 100 of these, and everyone makes a new one every week.

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

#36

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.

The AI prose is getting so tiring to read

"We measured this. Not estimates — actual token counts using the cl100k_base tokenizer against real schemas, verified by an automated test suite."

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

#37
post #25

Earlier quoted context omitted.

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-net... So you need to restrict not only where the age…

But this is no different to using an API key with access controls and curl and you get the same thing. MCP is just as worse version of the above allowing lots of data exfiltration and manipulation by the LLM.

But MCP uses Oauth. That is not a "worse version" of API keys. It is better.

The classic "API key" flow requires you to go to the resource site, generate a key, copy it, then paste it where you want it to go.

Oauth automates this. It's like "give me an API key" on demand.

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

#38
post #25

Earlier quoted context omitted.

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-net... So you need to restrict not only where the age…

But this is no different to using an API key with access controls and curl and you get the same thing. MCP is just as worse version of the above allowing lots of data exfiltration and manipulation by the LLM.

An MCP server lets you avoid giving the agent your API key so it can't leak it. At least in theory.

You could do the same with a CLI tool but it's more of a hassle to set up.

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

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

Post reply on HN