Hacker News Reader

Comment by jimbokun | Hacker News Reader

You failed to describe what value the MCP protocol provides.

If all of these companies spent equivalent time writing a CLI for agents to consume as they spend on MCP servers, would they be any worse off in terms of agents being able to interact with their products?

View on HN

One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.

i mean you can surface an openapi schema too.

MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two.

Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.

MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.

[0] https://modelcontextprotocol.info/docs/concepts/prompts/

[1] https://modelcontextprotocol.info/docs/concepts/resources/

[2] https://modelcontextprotocol.io/specification/2025-11-25/cli...

[3] https://modelcontextprotocol.io/specification/2025-11-25/ser...

can these not be surfaced in an api and accessed using curl, with instructions in a SKILLS.md?

Sure. It would be great if they were portable as well.

To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.

If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.

MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.

Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?

this is bad. Anyone doing any cursory work with agents will realize how brittle <<just managing your own prompts>> can be. Adding an extra layer of indirection isn’t helpful, it’s a gigantic hindrance that gives you a moving eval target. Being an MCP developer means you have a moving target of model optimization. It is a win for nobody.

The tools we need to solve this problem exist and they are boring. Types, jsonschema, openapi, all of it is a better integration point than MCP.

It keeps people employed, yes?

And with people I guess I might actually mean not people but tokens everybody has to spend on keeping their environment self-adapting...

That's because you're not thinking about how teams and enterprises work. You're thinking about how individuals work.

An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OAuth cred.

I want to add access to internal and external services from one entry point without developers across hundred of teams having to sync or update their workspace. Put it behind one MCP interface.

I have enterprise skills and resources that I want to standardize and deliver to every team. But it has to vary in 10-15% of the skill body. Think same heuristics, but different specifics. MCP delivered prompts and resources can do that by dynamically templating them.

I want telemetry and data on how skills and tools are being used and I want to capture them using standard tooling like OTEL regardless of agent harness because I don't want to have to rebuild a solution on hooks if I charge vendors. MCP does that because I can capture all of the telemetry there.

    > jsonschema, openapi, all of it is a better integration point than MCP.

MCP is schema + interaction model. If MCP were built on OpenAPI, it would still need another layer to describe interaction. It is effectively JSON schema + interaction flow + standard surface area.

Your argument feels like asking why do we need OAuth and OIDC when we already have usernames and passwords. They solve different problems. A simple service can just use a secret key or username + password. But more complex enterprise scenarios need the structure and flow of OAuth, SAML, and SCIM.

You’re not talking about how teams and enterprises work, you’re talking about how teams and enterprises don’t work.

Teams and enterprises had problems maintaining API keys long before there was MCP and they will have the same problems afterwards. The better teams and enterprises have had solutions for a long time.

I wish you would explain more of how you infered the handlers' KPIs here

From my point of view their purpose in life is 1) hacker news highlights or 2) to restrain some patients (me) from getting off the (Freudian) couch and mouthing off at "the folks in the waiting room"

For those of us who lived this wild arc from the advent of normative protocols widely adopted, standards, open source, and the variety of “paradigm shifts” over the last several decades it’s not surprising to see a profusion of attempts at standards with poor adherence across tooling, and fits and starts along the way. Those using the modern web, but not old enough to have built it, which has largely calmed down, probably look about them at the relative order of things and sigh in contentment then squint at the AI agent standards and huff at the confusion. Those few other gray heads who went through the various fits and starts look about at what’s going and recognize it quite clearly as “this is how things look at the beginning.”

We are really only a few years into all this stuff, and the real taking it very seriously has only been about 8 months. Web standards took 8 years to be barely usable. That was built on 30 years of internet standards that were barely usable.

Relax padwan and enjoy the ride.

Isn’t that basically just a —help flag though?

Still easily doable with CLI

> Isn’t that basically just a --help flag though?

mostly, but not enough — i have been experimenting with this, and what i found to help is:

  - help menu is the default, not an error message to stderr. ex: `gh pr` and `gh pr --help` are byte identical
  - if the subcommand, or the options passed are wrong, present suggestions. ex: `gh gists` -> "Did you meant this? gist"
  - the help menu should provide examples like `tldr`. sprites.dev tool `sprite` does this well, `gh` is in the training set so theirs is shorter
  - can you append the docs url to the bottom of the help menu?
  - you're serving llms.txt, right?

Then give the CLI a man page.

> One advantage is the MCP advertises itself to the agent with its schema and api shape.

So, OpenAPI/Swagger for REST? GraphQL? SOAP schemas? All of these (and more) exist. What does MCP add that these don't have?

I’m confused by the question. You listed a bunch of standards over time, all of which reach to solve a similar problem (you left off XDR/RPC, CORBA, and about 10000 others), and unironically ask why is there a n+1 standard? Are you genuinely confused?

https://xkcd.com/927

You wouldn't be confused if you actually tried to understand what I was saying. .

Your claim was: "One advantage is the MCP advertises itself to the agent with its schema and api shape".

This "advantage" has already existed, as you correctly pointed out, in about 10000 other standards and protocols. MCP is not special, and doesnmt have some advantage. It's a vibe-coded hype-driven n+1 standard that is busy ignoring anything that came before it, for no reason.

Yes, in the same way a programming language would be worse off if they focused all of their effort on building an implementation instead of a language specification.

You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.

But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.

So the permissions model h is a the main advantage MCP has over CLIs?

Is that so surprising? I thought that was a given. And as soon as remote resources are involved, the old "it's in a docker" peace of mind does not apply.

You prevent the LLM from deleting your instances by not granting its AWS user that permission. Whatever tool you let it use to talk to AWS is irrelevant.

Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant fine-grained OS-level permissions to add such things back, except perhaps `sudo` and similar tools.

MCPs are impossible to combine this way: everything you feed or get from them goes though the model and consumes tokens.

>to manipulate or combine the data into a more useful format

why not build this directly into MCPs?

Hmm, indeed, so maybe I could have all this as an MCP, so I can just easily pass any imaginable data manipulation inside it, and then also have it support calling other MCPs, all inside that one MCP, to avoid filling context with intermediate data..

Sounds a lot like a shell to me.

Go idea. We will call this new MCP “bash”. It will allow you to stream the output of one command to the input of another incrementally as the data is generated.

Can an MCP provide prompts for your model to download and use CLIs (and ensure they have the right versions of those tools) in such a way that the data flows through the client side tools?

The more I read this thread the more I'm convinced that the main value of MCP is to provide a server managed release process. This is the same advantage that SaaS has over client side apps.

However MCPs couples with a client willing to run tools locally can provide the best of both worlds

As far as I know, the only way an MCP can provide you data that doesn't go into the context is by providing URLs to the data, and then the model uses e.g. curl to access that data for data manipulation purposes. You could also return result set ids and provide accessors to such data, but ultimately you'd need to provide powerful accessors to that result set to avoid polluting context. Things like shell with all its power already provides.

It seems like there's little point in MCP in that case. Maybe more point if it was a standard mechanism for MCP to provide additional data, in a completely compatible fashion with all other tools? You could perhaps even pass such URLs to other MCPs. You could have an MCP for jq for doing stream processing. Starts to look a lot like a shell, though.

Seems like MCPs could also be extended to store auxiliary data to your memory (or filesystem..), and then an additional extension to provide that kind of data as auxiliary data in the calls to MCP.

Well, even as is, MCP still provides a standard method of using OAuth for accessing such services. And you must use MCP if you wish to add something to the ChatGPT.com web service, so it's easy to see why OpenAI folks are seeing companies going that way.

You’re right that having a shell is the ultimate tool, and an agent with a shell seems to perform better than one without one. But, making shells safe is really damn hard; e.g. in the context of running an agent on behalf of a SaaS customer in your AWS environment. For now some companies are accepting the performance/security tradeoff of disabling the shell and focusing on specialized tools.

Remember: jq can always be a tool (MCP or otherwise). In this way you can allowlist specific CLI programs and give them to the agent via tools. Making python a tool is more difficult; that would have all of the same RCE injection issues that the shell would have.

There are isolation stacks that help make “running an agent with a shell on behalf of a customer in the cloud” possible. It’s just very risky. There’s a thousand attack vectors, and to a very real degree companies that are getting to this point are re-thinking their cloud infrastructure and architecture from first principals.

jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data.

I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files. Maybe even Python if it can be made safe. If not, then there are a lot of languages can be.

jq can 100% be an MCP tool. Remember: Agent tools do not have to involve a network boundary. They can be natively implemented inside the agent harness, and/or they can be provided via a local MCP server. The point of making it a tool is to tightly allowlist what the agent is capable of executing; it can only execute jq, not any shell program, and moreover it isn't allowed to do things like redirection, pipes, etc; all it has at its disposal is `jq (filters) (data)`.

People seem to think that MCP exists to give agents more capability. That could not be further from the truth, which is actually the opposite: MCP exists to take capability away from agents. It exists to control them.

Let's say you have a jq MCP. How do you pass data in and out to/from it without the data also being processed as tokens?

That's really my only issue with MCPs.

With shell you can pass data from one component to another directly, not only being cheaper, faster, but also preserving complete integrity. While models nowadays seem to do data echoing well, there's always the chance they might not do it exactly.

There's no reason why a shell would not be able to limit abilities of a party using it as well, by virtue of just implementing only the desired functionality. What makes it more advanced in this context is the (standard) ability to express how to connect multiple components to each other, or to/from local storage. MCP does not have this.

Providing that does not have any inherent danger any more than jq's functions have an inherent danger. Actual execution of processes or real files does not need to be involved.

> Let's say you have a jq MCP. How do you pass data in and out to/from it without the data also being processed as tokens?

Provide a meta-tool which handles piping data in and out of any other tool, and make specific tools which can read/write data sources directly, bypassing context. Or you could go full code mode, but I'm not sure it's worth the lift unless you have Cloudflare numbers of APIs which would need tools.

I work on an internal model/vendor-independent chat app where the agent runs in the browser - every chat gets its own virtual origin private filesystem (OPFS) [1] directory where user attachments get written to and tools can read from/write to, and users can also provide read/write access to a real directory with window.showDirectoryPicker() [2] (both use the same API, so tools can route to/from either).

It can push and pull MBs of data through tools, e.g. pulling huge spreadsheets directly from SharePoint in 50,000 row chunks using a tool which calls the Excel Services REST API, passing those all into a code execution tool to join them together and process them, which generates an Excel output file using SheetJS, none of which goes into context.

People used to drag their multi-MB documents in and complain either it didn't work or the agent couldn't do anything useful with it. Now it just works.

[1] https://developer.mozilla.org/en-US/docs/Web/API/File_System...

[2] https://developer.mozilla.org/en-US/docs/Web/API/Window/show...

So are you using MCP to do this?

I'm not saying MCP or the ways we use it cannot be extended to cover this use case, but my understanding is that nobody does it. But shell/code does, and more.

This is the first sensible thing I’ve read in defense of MCP.

However, wouldn’t a shell where all permissions are off by default, then you can enable read and write privileges to certain files and directories and executable privileges to certain binaries accomplish the same thing using UNIX permissions? Isn’t this still reinventing the wheel?

> Maybe even Python if it can be made safe.

https://github.com/pydantic/monty

Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such.

The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.

> The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution.

Is this an advantage? Phrased differently, every MCP that could have been a CLI call is a new opportunity for sandbox escape.

I don’t follow. It’s the other way around. Would you rather run an arbitrary binary blob (aka: a random cli) or `curl`?

Edit: Maybe to clarify, I’m talking about remote MCP. Local MCP is obviously nonsensical. Remote MCP is very much thriving aggressively.

If the random blob is running inside of a real sandbox (Landlock/Bubblewrap, VM, ...Docker) then I would take the blob, because I can reason about its capabilities without inspecting its internals. The LLM can run curl as much as it wants if I've `unshare()`d its network access. MCP is an instant obligatory sandbox escape unless I also manage to deploy all the MCP servers inside the sandbox.

And yes, sorry, I was talking about local MCP. I should have made that clear. I do see people using local MCP quite a bit (Ghidra MCP, Playwright MCP, etc), but maybe this is more of a hobbyist thing.

The security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code.

They have different tradeoffs.

You nailed it! There are established tools that handle the security model. MCP is the 5th leg.

Yes they would be.

MCP servers on the side of the consuming organizations fit into the existing IT landscape, with centralized safeguard on who can access what a lot better and are easier to administer than letting their employees run arbitrary agents against arbitrary sources and destinations and cause chaos.

I have a couple MCP servers connected to my Claude web & mobile clients. How would your clis work there?

The value is that many companies like building MCP servers much more than CLIs. For whatever reason.

Here's some companies that offer MCP servers but don't seem to offer an equally featured CLI:

   - Asana
   - Square
   - Linear
   - Dropbox 
   - Canva
   - Slack (sorta)
   - Figma (sorta)

and many more that offer both, but support their MCP more.

Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.

There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.

The mcp support gets more support because there is no cli.

A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.

That kind of code is easily portable in C or Rust or Go or Java or Python so long as it is a CLI and not GUI.

Again, tangential, relevant only in that CLI "portability coolness" captures only some of the meaningfulness

Having slept on the poorly made point I was trying to stick. I'm aware its still all tell no show )-:

  A comment worthy of hacker news highlights, Amish-made, fully earnest!

Would appeal to people with money, all manner of handlers, enbies born to embrace struggle, not to mention portability porn addicts. All things to all people but without the messianic contingent

  An Amish who might well have built a Space Lasers Platform  at Bell Labs!

Should perhaps be the character to learn how to play. This same Amish character would only use CLIs, on a wooden nonelectronic keyboard

I credit the obvious (to you) people here (incl you again) for this concept of an idea. Molon labe

Update: backrooms is getting serious traction in Indonesia. Ask me in a year if it was only meta-interest

The language barely matters, the issue is packaging, distribution, platform permissions, pushing updates, keeping client/server versions in sync, shell support, etc.

Where-as if you just expose HTTP endpoints, all that doesn't matter, you just need cURL or any app, like the chatGPT mobile app, can just call into your endpoint.

Reply on news.ycombinator.com