Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 118 posts

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

#71

Post by Terretta »

kristopolous wrote: post #58

Cool to see this! I started a similar project in January but but nobody seemed interested in it at the time. Looks like I'll get back on that. https://github.com/day50-dev/infinite-mcp Essentially (1) start with the aggregator mcp repos: https://github.com/day50-dev/infinite-mcp/blob/main/gh-scrap... . pull all of them down. (2) get the meta information to understand how fresh, maintained, and popular the projects ar…

> If you like this project, please tell me. Your encouragement means a lot to me! I don't want to spend my time on things that nobody seems to be interested in.

Great implementation details, but what is the end goal? Ah ha, a readable readme (which itself is promising):

InfiniteMCP is a an MCP server that acts as a universal gateway to thousands of other MCP servers. Instead of manually configuring each MCP server you want to use, InfiniteMCP lets Claude discover, understand, and use any MCP server on demand through natural language queries.

Think of it as an "MCP server of MCP servers" - a single connection that unlocks the entire MCP ecosystem.

So, yeah, that's interesting.

> and then provide it as a free api

Oh, oops, that just became a supply chain threat. Central registries outside of targets' control are grails, and the speculated implementation for secrets makes this a lovely injection path...

If you pursue this, work with someone like control-plane.io to blue/red team it and make noise about that on your README with a link to their findings and your mitigations. And consider sync up with folks like kusari.dev (see also SLSA and GUAC) to include a vulns rating on each MCP itself (their mapping is super fast and a SBOM scanned MCP directory would be a real value add).

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

#72

Post by jancurn »

_pdp_ wrote: post #53
jancurn wrote: 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…

Also https://github.com/mcpshim/mcpshim It turns out everyone is having the same idea.

Added.

Here's the comparison table: https://github.com/apify/mcpc?tab=readme-ov-file#related-wor...

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

#73

Post by doix »

CharlieDigital wrote: post #65
edgyquant wrote: post #60

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

So just to clarify, in your case you're running a centralized MCP server for the whole org, right?

Otherwise I don't understand how MCP vs CLI solves anything.

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

#74

Post by stephantul »

hrmtst93837 wrote: post #30
stephantul wrote: post #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.

[flagged]

Are you an llm? That would be so ironic

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

#75

Post by wild_egg »

jancurn wrote: post #57
ffsm8 wrote: post #55

Earlier quoted context omitted.

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…

Exactly. Once you start looking at MCP as a protocol to access remote OAuth-protected resources, not an API for building agents, you realize the immense value

Aside from consistent auth, that's what all APIs have done for decades.

Only takes 2 minutes for an agent to sort out auth on other APIs so the consistent auth piece isn't much of a selling point either.

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

#76

Post by [deleted] »

Terretta wrote: post #71
kristopolous wrote: post #58

Cool to see this! I started a similar project in January but but nobody seemed interested in it at the time. Looks like I'll get back on that. https://github.com/day50-dev/infinite-mcp Essentially (1) start with the aggregator mcp repos: https://github.com/day50-dev/infinite-mcp/blob/main/gh-scrap... . pull all of them down. (2) get the meta information to understand how fresh, maintained, and popular the projects ar…

> If you like this project, please tell me. Your encouragement means a lot to me! I don't want to spend my time on things that nobody seems to be interested in. Great implementation details, but what is the end goal? Ah ha, a readable readme (which itself is promising): InfiniteMCP is a an MCP server that acts as a universal gateway to thousands of other MCP servers. Instead of manually configuring each MCP server yo…

[deleted]

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

#79

Post by wat10000 »

short_sells_poo wrote: post #52
oulu2006 wrote: post #35

Earlier quoted context omitted.

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

This is entirely predictable: we get an army of vibe coders, vibe coding up tools to make vibe coding easier.

For simple stuff like this, it's easier to have the agent build something than it is to figure out how to install someone else's.

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

#80

Post by sathish316 »

alkh wrote: post #77

Can someone please explain how one would tell LLM to use such a CLI over a natively supported MCP server? Do you need to add the info about CLI into persistent memory(ex. AGENTS.md) and run an mcp server manually? Or it is something else?

A simple prompt that tells the agent how to use gh cli to use GitHub using —help commands makes the agent start learning how to use a specific cli and just use it.

This method was popularised by beads with a simple command “bd quickstart” to teach the basics to an agent. Think of this as an adaptive learning method for the agent.

I’ve not seen the details of mcp2cli, but let’s just say you had a mcp2cli wrapper over stripe, you can just tell the agent to run mcp2cli for stripe as a provider to learn how to use the rest of the APIs

Post reply on HN