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

MCP is dead; long live MCP

chrlschn.dev

Post reply on HN
Print view View original

121–130 of 231 posts

Re: MCP is dead; long live MCP

#121

Post by 0xbadcafebee »

ambicapter wrote: post #20
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

If AI is AI, why does it need a protocol to figure out how to interact with HTTP, FTP, etc.? MCP is a way to quickly get those integrations up and running, but purely because the underlying technology has not lived up to its hyped abilities so far. That's why people think of MCP as a band-aid fix.

You mean, why not ask the AI to "find a way to use FTP", including either using a tool, or writing its own code? Besides the security issues?

One simple reason is "determinism". If you ask the AI to "just figure it out", it will do that in different ways and you won't have a reliable experience. The protocol provides AI a way to do this without guessing or working in different ways, because the server does all the work, deterministically.

But the second reason is, all the other reasons. There is a lot in the specification, that the AI literally cannot figure out, because it would require custom integration with every application and system. MCP is also a client/server distributed system, which "calling a tool" is not, so it does stuff that is impossible to do on your existing system, without setting up a whole other system... a system like MCP. And all this applies to both the clients, and the servers.

Here's another way to think of it. The AI is a psychopath in prison. You want the psycho to pick up your laundry. Do you hand the psycho the keys to your car? Or do you hand him a phone, where he can call someone who is in charge of your car? Now the psycho doesn't need to know how to drive a car, and he can't drive it off a bridge. All he can do is talk to your driver and tell him where to go. And your driver will definitely not drive off a bridge or stab anyone. And this works for planes, trains, boats, etc, just by adding a phone in between.

Re: MCP is dead; long live MCP

#122

Post by clintonb »

JeremyNT wrote: post #116
harrall wrote: post #88

Earlier quoted context omitted.

CLI doesn’t work for your coworkers that aren’t technical. Have you tried to use a random API before? It’s a process of trial and error. With the MCP tools I use, it works the first time and every time. There is no “figuring out.”

This should be trivial if you have proper API documentation in something like swagger. You can generate a cli tool with no "figuring out" anything either.

Nothing is “trivial” when you combine humans and computers. I worked at the MIT Computing Help Desk during my undergraduate years. We joked that we received callas from Nobel laureates who could find subatomic particles but couldn’t find the Windows Start button.

My company is currently trying to rollout shared MCPs and skills throughout the company. The engineers who have been using AI tools for the past 1-2 years have few, if any, issues. The designers, product managers, and others have numerous issues.

Having a single MCP gateway with very clear instructions for connecting to Claude Desktop and authenticating with Google eliminates numerous problems that would arise from installing and authenticating a CLI.

The MCP is also available on mobile devices. I can jot down ideas and interact with real data with Claude iOS and the remote MCP. Can’t do that with a CLI.

Re: MCP is dead; long live MCP

#123

Post by spiderfarmer »

I use Claude Cowork to talk to my (remote) CMS over MCP to continually improve all content in my website. If I find a new nugget of interesting information, I tell it to improve my content with it. I created lots of tools to help it do things that would require multiple calls in a pure, basic REST api. Plus you can describe lots of guidelines right in the MCP instructions.

I hear everyone talking about skills, but I this something I should use skills for?

Re: MCP is dead; long live MCP

#124

Post by jabber86 »

jswny wrote: post #19
SilverElfin wrote: post #5

This came up in recent discussions about the Google apps CLI that was recently released. Google initially included an MCP server but then removed it silently - and some people believe this is because of how many different things the Google Workspace CLI exposes, which would flood the context. And it seemed like in social media, suddenly a lot of people were talking about how MCP is dead. But fundamentally that doesn’…

MCP loads all tools immediately. CLI does not because it’s not auto exposed to the agent, got have more control of how the context of which tools exist, and how to deliver that context.

It does not have to load all tools. As you are able to hide the details in CLI you can implement the same in MCP server and client.

Just follow the widely accepted pattern (all you need 3 tools in front): - listTools - List/search tools - getToolDetails - Get input arguments for the given tool name - execTool - Execute given tool name with input arguments

HasMCP - Remote MCP framework follows/allows this pattern.

Re: MCP is dead; long live MCP

#125

Post by DetroitThrow »

0xbadcafebee wrote: post #109
tptacek wrote: post #75

Earlier quoted context omitted.

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

A lot of the reasons to use MCP are contained in the architecture document ( https://modelcontextprotocol.io/specification/2025-11-25/arc... ) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools. For any…

>Among them, chief is security

Considering many popular MCPs have done auth incorrectly, this made me lol

Re: MCP is dead; long live MCP

#126

Post by mmis1000 »

ekropotin wrote: post #102
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

I mean, CLI tool is also “reusable communication abstraction”, innit?

Tell me how many ways that print help message for a command you have seen and say "reusable" again. Mcp is exactly exists to solve this. The rest is just json rpc with simple key value pairs.

You can probably let llm guess the help flag and try to parse help message. But the success rate is totally depends on model you are using.

Re: MCP is dead; long live MCP

#127

Post by mmis1000 »

jamesrom wrote: post #82

The problem with MCP isn't MCP. It's the way it's invoked by your agent. IMO, by default MCP tools should run in forked context. Only a compacted version of the tool response should be returned to the main context. This costs tokens yes, but doesn't blow out your entire context. If other information is required post-hoc, the full response can be explored on disk.

I think part of the problem is how these mcp service are designed. A lot of them just returns Mbs of text blob without filtering at all, and thus explodes the context.

And it's also affected by how model is trained. Gemini specifically like to read large amount of text data directly and explodes the context. But claude try to use tool for partial search or write a script to sample from a very large file. Gemini always fills the context way faster then claude when doing the same job.

But I guess in case of a bad designed mcp, there is no much model can do because the results are injected into context directly though (unless the runtime decided to redirect it to somewhere else)

Re: MCP is dead; long live MCP

#128

Post by AussieWog93 »

harrall wrote: post #88
tptacek wrote: post #75

Earlier quoted context omitted.

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

CLI doesn’t work for your coworkers that aren’t technical. Have you tried to use a random API before? It’s a process of trial and error. With the MCP tools I use, it works the first time and every time. There is no “figuring out.”

>CLI doesn’t work for your coworkers that aren’t technical.

This actually isn't true. I've written bespoke CLI tools for my small business and non-technical people run them without issue. They get intimidated at first but within a day or so they're completely used to it - it's basically just magic incantations on a black box.

Re: MCP is dead; long live MCP

#129

Post by troupo »

0xbadcafebee wrote: post #109
tptacek wrote: post #75

Earlier quoted context omitted.

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

A lot of the reasons to use MCP are contained in the architecture document ( https://modelcontextprotocol.io/specification/2025-11-25/arc... ) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools. For any…

> Among them, chief is security

The security is so chief that they had no security at all until several versions later when they hastily bolted on OAuth.

MCP is a vibe-codef protocol that rode one of the many AI hype waves where all "design documents" are post-hoc justifications.

Re: MCP is dead; long live MCP

#130

Post by gdorsi »

There is another differentiator between CLIs and MCP.

The CLI are executed by the coding assistants in the project directory, which means that they can get implicit information from there (e.g. git branch and commit)

With an MCP you would need a prepare step to gather that, making things slower.

Post reply on HN