MCP is a USB port for models

Every few months something gets called a revolution in AI and it turns out to be a connector standard. MCP is the connector standard. The hype is annoying. The thing itself is actually useful.

Here’s the short version: before MCP, if you wanted an agent to talk to a database, a web search API, a code runner, and a file system, you wrote four different integrations. Each one had its own auth shape, its own error format, its own protocol quirks. You could copy-paste patterns but you were still writing glue code for every surface. The agent wasn’t composable. It was a star topology of one-offs with your code in the middle. Adding tool five meant writing tool five from scratch.

MCP is a wire format. JSON-RPC over STDIO or HTTP. The model talks to a server; the server exposes tools; the protocol is the same regardless of what the tools actually do. That’s it. USB port for models: one connector shape, many peripherals.

why a dumb protocol matters more than another model

The thing that makes this genuinely useful isn’t the spec. It’s the ecosystem effect. Once enough people implement the same interface, you stop writing integrations and start plugging things in. Anthropic shipped MCP in late 2024. By spring 2025 there were hundreds of community-built servers: Postgres, GitHub, browser automation, Slack, file systems, weather, Jira. Claude Code runs on MCP. The tooling in Cursor, in various agent frameworks. Most of the stuff that actually works in 2025 either uses MCP directly or stole its ideas.

The parallel to USB is intentional. USB didn’t do anything the protocols before it couldn’t do. It just standardized the connector so manufacturers stopped shipping proprietary cables. The product you actually wanted, a keyboard, a drive, a camera, was always the point. The standard was just the thing that let the market fill in without everyone coordinating. MCP is the same play. The agent capability you actually want is whatever the tool does. The protocol is the part that means you can use someone else’s server instead of building your own.

Before MCP reached critical mass, building a serious agent meant you were also in the business of writing and maintaining integrations. The integration tax was real, not in a metaphorical sense, but in a “this part of the codebase is three months of work that has nothing to do with the actual problem I was trying to solve” sense. That’s largely gone now if you’re building on models that support it natively, which Claude, GPT-4.1, Gemini 2.5, and Grok do.

what it’s actually like to wire it together

The developer experience is fine. Not magical, fine.

You pick up a community MCP server, drop it into your config, and the tools appear in the model’s context. The auth story varies: some servers handle it cleanly, some punt to you with environment variables and a shrug. Error handling is inconsistent because the spec leaves room for inconsistency. Debugging a misbehaving tool call means grepping logs across the model response, the MCP transport layer, and the server itself, which is three places your attention has to be simultaneously.

The STDIO path is the simplest. You spawn a local process, the model writes to its stdin, reads from its stdout, done. HTTP is useful when the server needs to live elsewhere or be shared across multiple clients. WebSockets make sense for real-time data. None of this is complicated. It’s just plumbing, and plumbing is what it is.

The part that surprised me is how much the composability actually pays off in practice. When you have ten MCP servers registered, the model can figure out which combination of tools to call without you routing it explicitly. That’s genuinely new. Before, you were either writing the orchestration yourself or hoping a framework handled it correctly. Now you drop in a server and the tool discovery works: the model reads the tool descriptions, decides what to call, and calls it. It’s not reliable enough to be unsupervised in production, but it’s reliable enough to get you somewhere fast.

Grok 4 just shipped a few days ago and it’s also MCP-native. At this point every frontier model treats MCP as table stakes. That’s how you know the standard won.

where it’s overhyped

Multi-agent coordination over MCP gets talked about like it’s solved. It’s not. You can run agents as MCP servers, one agent calling another through the protocol, and it works in demos. In practice, managing state across agent boundaries, handling failures without cascading, keeping context from exploding: all of that is still your problem. MCP standardized the wire. It didn’t solve the hard parts of agentic systems.

The “federated AI architectures” framing in some of the launch coverage made it sound like you’d plug servers together and they’d self-organize into something intelligent. That’s not what happens. What happens is the model calls the tools you told it about, in ways you probably didn’t anticipate, and you debug it. The protocol is a solved problem. The behavior is not.

None of that is a knock on MCP specifically. A connector standard can only be a connector standard. The revolution people wanted, reliable autonomous agents that don’t require babysitting, is still pending. MCP is part of the scaffolding you’d need to get there. It’s a good part. It’s just not the whole thing.

Worth having. Not a revolution. Stop calling things revolutions.