Comment by troupo

8 days ago

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.

7 comments

troupo

Reply
0xbadcafebee  8 days ago

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.

  • losvedir  8 days ago

    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.

    • 0xbadcafebee  7 days ago

      More than it needs? Buddy, HTTP is more than any web app needs. It has a lot of stuff in it because it's intended to solve a lot of problems. The fact that there is a bidirectional stateful mode for HTTP is horrifying, but it's there now, and it solves problems. MCP is here, it solves problems we have now, it's supported by industry. If there are pain points, we can fix them in the standard without throwing the baby out with the bathwater.

      1 reply →

  • troupo  7 days ago

    > 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

    • 0xbadcafebee  7 days ago

      1) MCP does more than just make an API call, 2) only the MCP server has to know about the lightbulb.

      Example: right now, I want to add web search to my local AI agent. Normally you'd have to add some custom logic to the agent to do this. But instead, I merely support MCP in the agent. Now I can connect to a SearXNG MCP server, and tell my agent to "use /web_search". Boom, I have web search, and the agent didn't need anything added to it. Similarly, SearXNG didn't need to know anything about my AI agent.

      If you "just used HTTP", you could not do that. You'd need to add extra code to SearXNG, or extra code to the AI agent, just to support this one use case.

      GraphQL does not have any of the AI-specific features in it, and is way more complex than MCP.

      1 reply →