alt.hn

3/9/2026 at 5:18:46 AM

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

 https://github.com/knowsuchagency/mcp2cli

by knowsuchagency

3/9/2026 at 8:53:51 AM

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/steipete/mcporter
  - https://github.com/mattzcarey/cloudflare-mcp
  - https://github.com/assimelha/cmcp

by jancurn

3/9/2026 at 9:31:27 AM

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

by oulu2006

3/9/2026 at 10:39:59 AM

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

by short_sells_poo

3/9/2026 at 2:08:55 PM

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.

by wat10000

3/9/2026 at 10:04:21 AM

there is nobody making a new one ever week.

by casey2

3/9/2026 at 3:23:10 PM

lol I didn’t know there were so many but I’m not surprised.

I was inspired by clihub (I credited them) but I also wanted 3 additional things.

1. OpenAPI support 2. Dynamic CLI generation. I don’t want to recompile my CLI if the server changes. 3. An agent skill

by knowsuchagency

3/9/2026 at 2:24:30 PM

The biggest surprise of this list is someone grabbed "f" as github username, clever.

by Aperocky

3/9/2026 at 12:06:32 PM

Which one do you recommend?

by siva7

3/9/2026 at 12:09:52 PM

Roll your own

by jebus989

3/9/2026 at 9:30:23 PM

The token savings are real and the on-demand discovery approach is the right design. MCP's schema bloat is a genuine problem for multi-tool environments.

Worth noting what this doesn't change: the authorization surface. Whether the agent discovers 120 tools eagerly (native MCP) or lazily (mcp2cli), the set of tools it's permitted to call is the same. Token efficiency doesn't reduce blast radius.

MCP today has no authorization layer in the spec. Every connected server grants the agent full access to every tool it exposes. The agent decides what to call based on its own reasoning. If prompt injection hijacks that reasoning, the agent calls tools it shouldn't — and there's no enforcement boundary between "agent wants to call X" and "X executes."

Two distinct problems: 1. Context efficiency: how does the agent learn what tools exist? (mcp2cli solves this well) 2. Authorization scoping: which tools is this agent permitted to invoke for this specific task? (nobody in the MCP ecosystem is solving this yet)

Solving #1 without #2 means you have a more efficient agent with the same unrestricted access. That's useful — but it's not safer.

Curious if you've thought about adding permission metadata to the CLI discovery layer — something like --allowed-tools that an orchestrator could set, so the agent only sees tools it's authorized to use for the current task.

by rodchalski

3/9/2026 at 7:54:58 AM

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

by Doublon

3/9/2026 at 9:54:19 AM

> but we created MCP. Now we're wrapping MCP into CLIs...

Next we'll wrap the CLIs into MCPs.

by re-thc

3/9/2026 at 9:59:40 AM

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

by otabdeveloper4

3/9/2026 at 10:54:22 AM

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)

by ffsm8

3/9/2026 at 11:00:20 AM

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

by jancurn

3/9/2026 at 1:38:25 PM

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.

by wild_egg

3/9/2026 at 3:09:17 PM

Yes, MCP could've been solved differently - eg with an extension to the openapi spec for example, at least from the perspective of REST APIs... But you're misunderstanding the selling point.

The issue is that granting the LLM access to the API needs something more granular then "I don't care, just keep doing whatever you wanna do" and getting promoted every 2 seconds for the LLM to ask the permission to access something.

With MCP, each of these actions is exposed as a tool and can be safely added to the "you may execute this as often as you want" list, and you'll never need to worry that the LLM randomly decides to delete something - because you'll still get a prompt for that, as that hasn't been whitelisted.

This is once again solvable in different ways, and you could argue the current way is actually pretty suboptimal too... Because I don't really need the LLM to ask for permission to delete something it just created for example. But the MCP would only let me whitelist action, hence still unnecessary security prompts. But the MCP tool adds a different layer - we can both use it as a layer to essentially remove the authentication on the API you want the LLM to be able to call and greenlight actions for it to execute unattended.

Again, it's not a silver bullet and I'm sure what we'll eventually settle on will be something different - however as of today, MCP servers provide value to the LLM stack. Even if this value may be provided even better differently, current alternative all come with different trade-offs

And all of what I wrote ignores the fact that not every MCP is just for rest APIs. Local permissions need to be solved too. The tool use model is leaky, but better then nothing.

by ffsm8

3/9/2026 at 11:20:35 AM

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?

by edgyquant

3/9/2026 at 11:37:48 AM

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 canonical docs like standard guidance on security and performance? Always up to date and available in every project from the start? No need to sync and update? MCP resources.

If you want standard telemetry and observability of usage? MCP because now you can emit and capture OTEL from the server side.

If you want to wire execution into sandboxed environments? MCP.

MCP makes sense for org-level agent engineering but doesn't make sense for the solo vibe coder working on an isolated codebase locally with no need to sandbox execution.

People are using MCP for the wrong use cases and then declaring them excess when the real use case is standardizing remote delivery and of skills and resources. Tool execution is secondary.

by CharlieDigital

3/9/2026 at 7:05:33 PM

You sound more like you like skills than MCP itself. Skills encapsulate the behavior to be reused.

MCP is a protocol that may have been useful once, but it seems obsolete already. Agents are really good at discovering capabilities and using them. If you give it a list of CLI tools with a one line description, it would probably call the tool's help page and find out everything it needs to know before using the tool. What benefit does MCP actually add?

by retrochameleon

3/9/2026 at 1:30:11 PM

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.

by doix

3/9/2026 at 2:32:53 PM

Correct.

Centralized MCP server over HTTP that enables standardized doc lookup across the org, standardized skills (as MCP prompt), MCP resources (these are virtual indexes of the docs that is similar to how Vercel formatted their `AGENTS.md`), and a small set of tools.

We emit OTEL from the server and build dashboards to see how the agents and devs are using context and tools and which documents are "high signal" meaning they get hit frequently so we know that tuning these docs will yield more consistent output.

OAuth lets us see the users because every call has identity attached.

by CharlieDigital

3/9/2026 at 4:29:48 PM

Sandboxing and auth is a problem solved at the agent ("harness") level. You don't need to reinvent OpenAPI badly.

by otabdeveloper4

3/9/2026 at 6:07:42 PM 

    > Sandboxing and auth is a problem solved at the agent ("harness") level
If you run a homogeneous set of harnesses/runtimes (we don't; some folks are on Cursor, some on Codex, some on Claude, some on OpenCode, some on VS Code GHCP). The only thing that works across all of them? MCP.

Everything about local CLIs and skill files works great as long as you are 1) running in your own env, 2) working on a small, isolated codebase, 3) working in a fully homogeneous environment, 4) each repo only needs to know about itself and not about a broader ecosystem of services and capabilities.

Beyond that, some kind of protocol is necessary to standardize how information is shared across contexts.

That's why my OP prefaced that MCP is critical for orgs and enterprises because it alleviates some of the friction points for standardizing behavior across a fleet of repos and tools.

    > You don't need to reinvent OpenAPI badly
You are only latching onto one aspect of MCP servers: tools. But MCP delivers two other critical features: prompts and resources and it is here where MCP provides contextual scaffold over otherwise generic OpenAPI. Tools is perhaps the least interesting of MCP features (though useful, still, in an enterprise context because centralized tools allows for telemetry)

For prompts and resources to work, industry would have to agree on defined endpoints, request/response types. That's what MCP is.

by CharlieDigital

3/9/2026 at 9:25:40 AM

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

by Charon77

3/9/2026 at 11:22:12 AM

No it’s more like - because AI can’t know every endpoint and what it does, so MCP allows for injecting the endpoints and a description into context so the ai can choose the right tool without additions steps

by edgyquant

3/9/2026 at 10:18:38 AM

Agents can't write bash correctly so... I wonder about your claim

by ekianjo

3/9/2026 at 7:09:58 PM

It can. Not sure what AI you're using, but Gemini outputs great bash. Of course you need to test it.

You do have to make sure to tell it what platform you're using, because things like MacOS have different CLIs than Linux.

by mannyv

3/9/2026 at 10:39:21 AM

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

by anonzzzies

3/9/2026 at 3:05:49 PM

[dead]

by jamiemallers

3/9/2026 at 7:44:47 AM

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?

by DieErde

3/9/2026 at 8:32:40 AM

A few things: in this case, you have to provide the tool list in your prompt for the AI to know it exists. But you probably want the AI agent to be able to act and choose tools without you micromanaging and reminding it in every prompt, so then you'd need a tool list... and then you're back to providing the tool list automatically ala MCP again.

MCP can provide validation & verification of the request before making the API call. Giving the model a /tool/forecast URL doesn't prevent the model from deciding to instead explore what other tools might be available on the remote server instead, like deciding to try running /tool/imagegenerator or /tool/globalthermonuclearwar. MCP can gatekeep what the AI does, check that parameters are valid, etc.

Also, MCP can be used to do local computation, work with local files etc, things that web access wouldn't give you. CLI will work for some of those use cases too, but there is a maximum command line length limit, so you might struggle to write more than 8kB to a file when using the command line, for example. It can be easier to get MCP to work with binary files as well.

I tend to think of local MCP servers like DLLs, except the function calls are over stdio and use tons of wasteful JSON instead of being a direct C-function call. But thinking of where you might use a DLL and where you might call out to a CLI can be a useful way of thinking about the difference.

by SyneRyder

3/9/2026 at 8:10:32 AM

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 agent can reach, but what operations it can perform, with the host controlling credentials and parameters. That brings us to an MCP-like solution.

by Phlogistique

3/9/2026 at 8:36:34 AM

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.

by rvz

3/9/2026 at 9:47:38 AM

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.

by acchow

3/9/2026 at 9:47:58 AM

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.

by regularfry

3/9/2026 at 10:07:57 AM

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 web content.

by fennecbutt

3/9/2026 at 7:54:07 AM

One thing that I currently find useful on MCPs is granular access control.

Not all services provide good token definition or access control, and often have API Key + CLI combo which can be quite dangerous in some cases.

With an MCP even these bad interfaces can be fixed up on my side.

by ewidar

3/9/2026 at 7:47:31 AM

The prophecy of the hypermedia web

by iddan

3/9/2026 at 8:25:21 AM

I feel like I haven’t read anything about this in combination with mcp and like I am taking crazy pills: does no one remember hateoas?

by Traubenfuchs

3/9/2026 at 8:18:31 AM

Proxying / gatekeeping

by jbverschoor

3/9/2026 at 8:08:11 AM

Nice project! I've been working on something very similar here https://github.com/max-hq/max

It works by schematising the upstream and making data locally synchronised + a common query language, so the longer term goals are more about avoiding API limits / escaping the confines of the MCP query feature set - i.e. token savings on reading data itself (in many cases, savings can be upwards of thousands of times fewer tokens)

Looking forward to trying this out!

by benvan

3/9/2026 at 7:15:43 AM

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.

by stephantul

3/9/2026 at 9:00:50 AM

Token counts alone tell you nothing about correctness, latency, or developer ergonomics. Run a deterministic test suite that exercises representative MCP calls against both native MCP and mcp2cli while recording token usage, wall time, error rate, and output fidelity.

Measure fidelity with exact diffs and embedding similarity, and include streaming behavior, schema-change resilience, and rate-limit fallbacks in the cases you care about. Check the repo for a runnable benchmark, archived fixtures captured with vcrpy or WireMock, and a clear test harness that reproduces the claimed 96 to 99 percent savings.

by hrmtst93837

3/9/2026 at 1:32:30 PM

Are you an llm? That would be so ironic

by stephantul

3/9/2026 at 2:38:50 PM

I found this comment because I was wondering the same thing on a completely unrelated thread. I strongly suspect this is a bot.

by danlitt

3/9/2026 at 2:52:16 PM

You can post this under every of my comments, that does not make it true. I can go to your account and do the same on your comments.

by hrmtst93837

3/9/2026 at 2:57:41 PM

ok, I'll stop. I am not the only person who suspected you!

by danlitt

3/9/2026 at 3:12:49 PM

I use LLMs to support in writing comments, like brainstorming and fixing grammar + spelling. But many people use that these days.

by hrmtst93837

3/9/2026 at 3:25:10 PM

This is such a funny interaction

by stephantul

3/9/2026 at 3:44:55 PM

Happens all the time nowadays here on HN. IMHO, The llm accusations go out of hand

by hrmtst93837

3/9/2026 at 2:53:06 PM

No, unless you ask danlitt who tries to suspect me of llm under every of my comments.

by hrmtst93837

3/9/2026 at 9:44:20 AM

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."

by rakag

3/9/2026 at 9:50:24 AM

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

by acchow

3/9/2026 at 10:15:24 AM

Absoultely.

I'll add to your comment that it isn't a bug of MCP itself. MCP doesn't specify what the LLM sees. It's a bug of the MCP client.

In my toy chatbot, I implement MCP as pseudo-python for the LLM, dropping typing info, and giving the tool infos as abruptly as possible, just a line - function_name(mandatory arg1 name, mandatory arg2 name): Description

(I don't recommend doing that, it's largely obsolete, my point is simply that you feed the LLM whatever you want, MCP doesn't mandate anything. tbh it doesn't even mandate that it feeds into a LLM, hence the MCP CLIs)

by phh

3/9/2026 at 10:05:22 AM

Yup, routing is key. Just like how we've had RAG so we don't have to add every biz doc to the context.

I agree with the general idea that models are better trained to use popular cli tools like directory navigation etc, but outside of ls and ps etc the difference isn't really there, new clis are just as confusing to the model as new mcps.

by fennecbutt

3/9/2026 at 12:19:30 PM

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

ANTHROP\C's Claudes manage/minimize/mitigate this reaonably.

by Terretta

3/9/2026 at 11:25:53 AM

That’s a trade off, now you need multiple model calls for every single request

by edgyquant

3/9/2026 at 10:19:28 AM

Yes we just RAG to be applied on tools. Very simple to implement.

by ekianjo

3/9/2026 at 11:26:43 AM

I don’t think so. Without a list of tools in context the ai can’t even know what options it has, so a RAG like search doesn’t feel like it would be anywhere near as accurate

by edgyquant

3/9/2026 at 12:15:34 PM

The RAG helps select the tool needed for the task at hand. Semantic search returns only the tools that match. Very efficient.

by ekianjo

3/9/2026 at 8:11:18 AM

How is this the 5th one of these I have seen this week, is everyone just trying to make the same thing?

by jofzar

3/9/2026 at 8:36:42 AM

Basically yes.

by hnlmorg

3/9/2026 at 2:22:22 PM

Since there is no friction and everyone is generating an idea to code using GitHub training data, this is basically the future

by sathish316

3/9/2026 at 2:30:48 PM

Not invented here (NIH) syndrome has always been a thing but I think what we are seeing at the moment is an artificial high vs new ideas because

1. People are looking for excuses to learn to use AI because they’re scared of being left behind.

2. People are looking for examples of AI projects to add to their LinkedIn profile so they appear a tech leader and thus more employable

by hnlmorg

3/9/2026 at 10:37:13 AM

This looks useful.

One pattern we've been seeing internally is that once teams standardize API interactions through a single interface (or agent layer), debugging becomes both easier and harder.

Easier because there's a central abstraction, harder because failures become more opaque.

In production incidents we often end up tracing through multiple abstraction layers before finding the real root cause.

Curious if you've built anything into the CLI to help with observability or tracing when something fails.

by devrimozcay

3/9/2026 at 3:22:28 PM

The lazy discovery pattern is clever. Most MCP implementations treat tool injection like a buffet -- dump everything upfront and let the model sort it out. The problem is you pay the context cost whether the model uses those tools or not, and at 120+ tools that cost compounds fast.

The analogy I'd draw is database query planning: you don't load the entire schema into memory before every query, you resolve references on demand. Same principle here. Does the CLI maintain a tool cache between invocations, or does it re-fetch schemas each time?

by ryanholtdev

3/9/2026 at 3:24:19 PM

It caches the spec with a default TTL of 1 hour

by knowsuchagency

3/9/2026 at 1:52:39 PM

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?

by alkh

3/9/2026 at 2:20:54 PM

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

by sathish316

3/9/2026 at 8:57:55 AM

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.

by Intermernet

3/9/2026 at 2:27:18 PM

If you intercept what an agent (client) sends to the LLM with multiple MCP servers and tools, the context or header is filled with available MCP servers and all tools as part of the conversation.

With a CLI, you avoid sending this context to the LLM and it progressively discovers only what is needed.

The input token costs come down because of using a CLI instead of MCP

by sathish316

3/9/2026 at 9:07:06 AM

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.

by mvc

3/9/2026 at 9:12:23 AM

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.

by Intermernet

3/9/2026 at 7:24:43 AM

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!

by philipp-gayret

3/9/2026 at 7:42:36 AM

How would the LLM exactly discover such unknown CLI commands?

by silverwind

3/9/2026 at 10:57:11 AM

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

by kristopolous

3/9/2026 at 7:50:23 AM

Skills or tell it the --list command would be my guess.

by Mashimo

3/9/2026 at 12:13:48 PM

Skills is the right abstraction.

by ramoz

3/9/2026 at 11:10:28 AM

the token math is compelling but I'm curious about the discovery step. with native MCP the host already knows what tools exist. with this, the agent has to run --list first, which means extra roundtrips. for 120 tools that might still be a net win, but the latency tradeoff seems worth calling out

by vicchenai

3/9/2026 at 2:05:14 PM

Interesting! is this exclusive for LLM usage?

by termwatch

3/9/2026 at 6:12:04 PM

it's also for humans!

by knowsuchagency

3/9/2026 at 8:01:07 AM

How is it different from 'mcporter', already included in eg. openclaw?

by jkisiel

3/9/2026 at 7:50:02 AM

I kind of feel like it might be better to go from CLI to MCP.

by Ozzie_osman

3/9/2026 at 7:53:32 AM

mcp just need to add dynamic tools discovery and lazy load them, that would solve this token problem right?

by tuananh

3/9/2026 at 11:30:09 AM

Time is a flat circle...

by andai

3/9/2026 at 10:22:26 AM

For a typical B2B SaaS usecase (non technical employees) -> MCP is working great since its allows people to work in Chat interfaces (ChatGPT, Claude). They will not move to terminal UX's anytime soon.

So, I dont see why a typical productivity app build CLI than MCP. Am I missing anything?

by rakamotog

3/9/2026 at 3:05:42 PM

It's about letting LLM Agents use the CLI, the end user still interfaces with the agent via chat.

by lagrange77

3/9/2026 at 11:04:50 AM

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.

by kristopolous

3/9/2026 at 12:23:50 PM

> 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).

by Terretta

3/9/2026 at 10:17:34 AM

Doubtful that a 16 tokens summary is the same as she JSON tool description that uses 10x more tokens. The JSON will describe parameters in a longer way and that has probably some positive impact on accuracy

by ekianjo

3/9/2026 at 7:51:52 AM

MCP itself is a flawed standard to being with as I said before [0] and its wraps around an API from the start.

You might as well directly create a CLI tool that works with the AI agents which does an API call to the service anyway.

[0] https://news.ycombinator.com/item?id=44479406

by rvz

3/9/2026 at 8:30:21 AM

[dead]

by techpulse_x

3/9/2026 at 9:14:03 AM

[dead]

by yogin16

3/9/2026 at 7:31:50 AM

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.

by liminal-dev

3/9/2026 at 4:24:34 PM

No

by knowsuchagency