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

51–60 of 118 posts

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

#51

Post by anonzzzies »

ekianjo wrote: post #47
Charon77 wrote: post #34

Earlier 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

They cannot? We have a client from 25 years ago and all the devops for them are massive bash scripts; 1000s of them. Not written by us (well some parts as maintenance) and really the only 'thing' that almost always flawlessly fixes and updates them is claude code. Even with insane bash in bash in bash escaping and all kinds of not well known constructs. It works. So we habe no incentive to refactor or rewrite. We did 5 years ago and postponed as we first had to rewrite their enormous and equally badly written ERP for their factory. Maybe that would not have happened either now...

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

#52

Post by short_sells_poo »

oulu2006 wrote: post #35
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…

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.

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

#53

Post by _pdp_ »

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.

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

#54

Post by [deleted] »

Charon77 wrote: post #34
Doublon wrote: 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

[deleted]

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

#55

Post by ffsm8 »

otabdeveloper4 wrote: post #41
Doublon wrote: post #15

We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...

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 the LLM to be able to have full read only access. This is straightforward to solve with an MCP because the tools have specific names.

With CLI it's not as straightforward, because it'll start piping etc and the same CLI is often used both for write and read access.

All solvable issues, but while I suspect CLIs are going to get a lot more traction over the next few months, it's still not the thing we'll settle on- unless the privileges situation can be solved without making me greenlight commands every 2 seconds (or ignoring their tendency to occasionally go batshit insane and randomly wipe things out while running in yolo mode)

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

#56

Post by kristopolous »

silverwind wrote: post #7

How would the LLM exactly discover such unknown CLI commands?

I've got a qdrant based approach that I'm working on that solves that here: https://github.com/day50-dev/infinite-mcp

Essentially I've cloned thousands of mcp servers, used the readmes and the star rating to respond to the qdrant query (star ratings as a boost score have been an attack vector, yes I know, it's an incomplete product [1]), then presents it as a JSON response with "one-shots" which this author calls clis.

I think I became discouraged from working on it and moved on because my results weren't that great but search is hard and I shouldn't give up.

I'll get back on it seeing how good this tool is getting traction.

[1] There needs to be a legitimacy post-filter so that github user micr0s0ft or what-have-you doesn't go to to the top - I'm sure there's some best-of-practice ways of doing this and I shouldn't invent my own (which would involve seeing if the repo appears on non-UGC sites I guess?!) but I haven't looked into it

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

#57

Post by jancurn »

ffsm8 wrote: post #55
otabdeveloper4 wrote: post #41

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…

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

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

#58

Post by kristopolous »

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 are (https://github.com/day50-dev/infinite-mcp/blob/main/gh-get-m...)

(3) try to extract one-shot ways of loading it (npx/uvx etc) https://github.com/day50-dev/infinite-mcp/blob/main/gh-one-l...

(4) insert it into what I thought was qdrant but apparently I was still using chroma - I'll change that soon

(5) use a search endpoint and an mcp to seach that https://github.com/day50-dev/infinite-mcp/blob/main/infinite...

The intention is to get this working better and then provide it as a free api and also post the entire qdrant database (or whatever is eventually used) for off-line use.

This will pair with something called a "credential file" which will be a [key, repo] pair. There's an attack vector if you don't pair them up. (You could have an mcp server for some niche thing, get on the aggregators, get fake stars, change the the code to be to a fraud version of a popular mcp server, harvest real api keys from sloppy tooling and MitM)

Anyway, we're talking about 1000s of documents at the most, maybe 10,000. So it's entirely givable away as free.

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.

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

#60

Post by edgyquant »

otabdeveloper4 wrote: post #41
Doublon wrote: post #15

We had `curl`, HTTP and OpenAPI specs, but we created MCP. Now we're wrapping MCP into CLIs...

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

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?
Post reply on HN