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

111–120 of 231 posts

Re: MCP is dead; long live MCP

#111

Post by tptacek »

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…

If the chief reason to use MCP is security, I'm sold: it's a dead letter, and we're not going to be using it a couple years from now.

Re: MCP is dead; long live MCP

#112

Post by 0xbadcafebee »

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

Earlier quoted context omitted.

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…

If the chief reason to use MCP is security, I'm sold: it's a dead letter, and we're not going to be using it a couple years from now.

Security is the chief reason in that it's the most important, since AI security is like nuclear waste. But the reason you should use it is it's a standard, and it's better to use one standard and be compatible with 10,000 apps, than have to write 10,000 custom integrations.

When I first used ChatGPT, I thought, "surely someone has written some kind of POP3 or IMAP plugin for ChatGPT so it can just connect to my mail server and download my mail." Nope; you needed to write a ChatGPT-specific integration for mail, which needed to be approved by ChatGPT, etc. Whereas if they supported any remote MCP server, I could just write an MCP server for mail, and have ChatGPT connect to it, ask it to "/search_mail_for_string" or whatever, and poof, You Have Mail(tm).

Re: MCP is dead; long live MCP

#113

Post by kasey_junk »

tptacek wrote: post #101
oneseventwonine wrote: post #100

Earlier quoted context omitted.

For the Agent to use CLI, don't we have to install CLI in the run-time environment first? Instead for the MCP over streamable HTTP we don't have to install anything and just specify the tool call in the context in't it?

This rolls up to my original point. I get that if you stipulate the agent can't run code, you need some kind of systems solution to the problem of "let the agent talk to an API". I just don't get why that's a network protocol coupling the agent to the API and attempting to capture the shape of every possible API. That seems... dumb.

Environments where it’s hard to install and configure cli tools and where you want oauth flows.

That is mcp for coding agents is dumb. For gui apps installed at non-cli using non-permissive endpoints it makes a lot of sense.

Re: MCP is dead; long live MCP

#114

Post by tptacek »

kasey_junk wrote: post #113
tptacek wrote: post #101

Earlier quoted context omitted.

This rolls up to my original point. I get that if you stipulate the agent can't run code, you need some kind of systems solution to the problem of "let the agent talk to an API". I just don't get why that's a network protocol coupling the agent to the API and attempting to capture the shape of every possible API. That seems... dumb.

Environments where it’s hard to install and configure cli tools and where you want oauth flows. That is mcp for coding agents is dumb. For gui apps installed at non-cli using non-permissive endpoints it makes a lot of sense.

Right, this is the part of the problem I get, but a universal meta-API seems like they're overshooting it by a lot.

Re: MCP is dead; long live MCP

#115

Post by avereveard »

superturkey650 wrote: post #83
avereveard wrote: post #65

Earlier quoted context omitted.

C each ai need context management per conversation this is something that would be very clunky to replicate on top of http or ftp (as in requiring side channel information due session and conversation management) Everyone looks at api and sure mcp seem redundant there but look at agent driving a browser the get dom method depends on all the action performed from when the window opened and it needs to be per agent per…

All MCP adds is a session token. How is that not already a solved problem?

P

It makes it part of the protocol so the llm doesn't have to handle it, which is brittle

And look at the patent post I've replied to choice of protocol, I'd like to see a session token over ftp where you need to track the current folder per conversation.

Re: MCP is dead; long live MCP

#116

Post by JeremyNT »

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

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.

Re: MCP is dead; long live MCP

#117

Post by SilverElfin »

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.

I’m not a technical person but I’ve seen people share various tips and tricks to get around the MCP context issues. There’s also this from Anthropic:

https://www.anthropic.com/engineering/code-execution-with-mc

Re: MCP is dead; long live MCP

#118

Post by algis-hn »

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.

Accurate for naive MCP client implementations, but a proxy layer with inference-time routing solves exactly this control problem. BM25 semantic matching on each incoming query exposes only 3-5 relevant tool schemas to the agent rather than loading everything upfront - the 44K token cold-start cost that the article cites mostly disappears because the routing layer is doing selection work. MCPProxy (https://github.com/smart-mcp-proxy/mcpproxy-go) implements this pattern: structured schemas stay for validation and security quarantine, but the agent only sees what's relevant per query rather than the full catalog. The tradeoff isn't MCP vs CLI - it's routing-aware MCP vs naive MCP, and the former competes with CLI on token efficiency while retaining the organizational benefits the article argues for.

Re: MCP is dead; long live MCP

#119

Post by gbro3n »

A lot of the best tooling around AI we're seeing is adding deterministic gates that the probabilistic AI agents work with. This is why I'm using MCP over http. I'm happy for the the agent to use it's intelligence and creativity to help me solve problems, but for a range of operations, I want a gate past which actions run with the certainty of normal software functions. NanoClaw sells itself on using deterministic filtering of your WhatsApp messages before the agent gets to see them, and proxies API keys so the agent bever gets them - this is a similar type of deterministic gate that allows for more confidence when working with AI.
Post reply on HN