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.
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.
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.
> The fact that there is a bidirectional stateful mode for HTTP is horrifying,
Oh no, really? So why didn't the new vibe-coded hotness use WebSockets for bidirectional communication?
> MCP is here, it solves problems we have now,
Many other protocols save the exact same problem of client-server communication with well-defined ways of discovering available API calls.
> it's supported by industry.
It's supported by hype and people who have very little knowledge of what existis in the world.
Also, industry is notorious for supporting a lot of crazy and bad shit. Doesn't make it good.
> If there are pain points, we can fix them in the standard without throwing the baby out with the bathwater.
You have already thrown out a lot of babies by deciding that the vibe-coded MCP protocol is the only true way to set up two-way communication between a server and a client, and refuse to even entertain the thought that it might not be a good protocol to begin with.
> 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
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.
It literally does that. What MCP calls a "tool call" is literally an API call (well, technically an RPC call since it's just JSON-RPC underneath).
But that's beside the point. Your original claim was this:
--- start quote ---
The only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app).
--- end quote ---
1. The MCP doesn't solve that. Every MCP server you connect to will expose their own bespoke API (aka tools) incompatible with anything else, in data formats incompatible with anything else.
2. No idea what SearXNG is, but if you used Swagger/OpenAPI or GraphQL you could easily have provided a standard way to discover what your API offers, and ways of calling that API
> You'd need to add extra code to SearXNG
You literally added extra code to SearXNG to expose an MCP server.
> GraphQL does not have any of the AI-specific features in it
Neither does MCP. Just because they invented new cute terms for JSON-RPC doesn't make it any more suitable for AI than literally any other protocol. And don't forget the idiocy of using a one-way communication protocol for two-way communication.
MCP re-invented SOAP, badly, with none of the advantages, and most of the disadvantages
There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.