Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

201–210 of 231 posts

Re: MCP is dead; long live MCP

#201
post #136

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…

MCP is literally "define a bespoke API using this vibe-coded protocol over JSON-RPC". There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.

No, this misunderstands what MCP is for and how it works.

Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house?

Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol your bulbs use, to be able to control them. Claude needs to support your specific lightbulb stack, and some kind of routing software would need to be added in your home to connect the external network to the internal devices.

But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs or have some custom routing thing for your home. You just need to run an MCP server that talks to the lightbulbs... which the lightbulb company should make and publish, so you don't have to do anything but download the lightbulb MCP server and run it. Now Claude can talk to your lightbulbs, and neither you nor Claude had to do any extra work.

In addition to the communication, there is also asynchronous task control features, AI-specific features, security features, etc that are all necessary for AI work. All this is baked into MCP.

This is the power of standardized communications abstractions. It's why everyone uses HTTP and doesn't have their own custom application-specific tcp-server-language. The world wide web would just be 10 websites.

Re: MCP is dead; long live MCP

#202

Earlier quoted context omitted.

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.

But the agent harness is still handling the session token for you either way. MCP might be an easy way for agent harness creators to abstract the issue away, but I don’t want to lose all REST conventions just to make it a little easier for them to write an agent harness. It makes it harder for the LLM to understand what’s going on, not easier.

again, not all services are rest or with nice api, if they were, you'd just have the agent write scripts.

Re: MCP is dead; long live MCP

#203

I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs f…

so now you have almost all the parts of an mcp:

1. the tools 2. the instructions

just add an auth mechanism to it and you get mcp OR use mcp because it's a nice self contained package that contains all of it.

Re: MCP is dead; long live MCP

#204
post #136

Earlier quoted context omitted.

MCP is literally "define a bespoke API using this vibe-coded protocol over JSON-RPC". There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.

No, this misunderstands what MCP is for and how it works. Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house? Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol you…

No, that's not MCP. That's a pleasant idea that MCP has been shoehorned into trying to solve. But MCP the spec is far more complicated than it needs to be to support that story. Streamable HTTP transport makes it much more workable, and I imagine was designed by real people rather than the version prior to that, but it's still much more than it needs.

Ultimately, 90% of use cases would be solved by a dramatically simpler spec which was simply an API discovery mechanism, maybe an OpenAPI spec at a .well-known location, and a simple public-client based OAuth approach for authentication and authorization. The full-on DCR approach and stateful connections specified in the spec is dramatically harder to implement.

Re: MCP is dead; long live MCP

#205

Earlier quoted context omitted.

But the agent harness is still handling the session token for you either way. MCP might be an easy way for agent harness creators to abstract the issue away, but I don’t want to lose all REST conventions just to make it a little easier for them to write an agent harness. It makes it harder for the LLM to understand what’s going on, not easier.

again, not all services are rest or with nice api, if they were, you'd just have the agent write scripts.

No, but MCPs aren’t free to build either. So if you need to build an API on top, why would you build an MCP instead of using one of the existing standards that both LLMs and humans already know how to work with?

Re: MCP is dead; long live MCP

#206
post #198

Earlier quoted context omitted.

[dead]

It seems like we're going back to expert systems in a kind of inverted sense with all of this chaining of deterministic steps. But now the "experts" are specialized and well-defined actions available to something smart enough to compose them to create new, more powerful actions. We've moved the determinism to the right spot, maybe? Just a half-thought. I'm just trying to learn this stuff now, so I don't the literatur…

I have wondered if we're going to end up investing so much in putting up guard rails around AI that we end up with systems of the same complexity as a non AI expert system that runs slower and at higher costs due just having injected models and tokens into the mix! I joke, but it seems like there's a pull towards that.

Re: MCP is dead; long live MCP

#208
post #136

Earlier quoted context omitted.

MCP is literally "define a bespoke API using this vibe-coded protocol over JSON-RPC". There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.

No, this misunderstands what MCP is for and how it works. Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house? Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol you…

> But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs

Except the fact that it has to "know" about that specific manufacturer's bespoke API aka "tool calls" for that specific lightbulb. If the manufacturer provides an API for the lightbulb.

MCP is a vibe-coded communications protocol. There's nothing more standard or re-usable in MCP than HTTP, or any protocols built over that. Hell, using GraphQL would be a more standardized, re-usable and discoverable way of doing things than MCP. Fielding ddescribed and architecture for machine-discoverable APIs in 2000

Re: MCP is dead; long live MCP

#209
post #198

Earlier quoted context omitted.

[dead]

It seems like we're going back to expert systems in a kind of inverted sense with all of this chaining of deterministic steps. But now the "experts" are specialized and well-defined actions available to something smart enough to compose them to create new, more powerful actions. We've moved the determinism to the right spot, maybe? Just a half-thought. I'm just trying to learn this stuff now, so I don't the literatur…

[dead]
Post reply on HN