“MCP is a fad.” I’ve seen this take floating around. Too complex. Security holes everywhere. Just another wrapper around function calls.

I disagree.

The Problem No One Solved

Every protocol we use today was designed with the same assumption: a human sits in the middle. REST. GraphQL. gRPC. A human reads the docs. A human writes the integration. A human debugs when things break.

Agents don’t work that way.

They can read documentation, sure. But they can’t interpret what’s missing from it. They need structured, machine-readable contracts. Capabilities they can discover at runtime. Error semantics they can actually parse.

This is what MCP actually solves. Not “a better way to call functions.” The first protocol that treats agents as first-class citizens.

A Different Mental Model

The obvious answer is “tools for AI.” That’s not it.

MCP is bidirectional. Servers can request LLM completions from the host. The tool asks the agent for help. This isn’t RPC. It’s a conversation. REST can’t express this pattern at all.

MCP is resource-aware. Instead of an agent repeatedly calling APIs and parsing responses (wasting tokens every time), it exposes structured data directly. Schemas, documentation, configs. Load once, work with it.

MCP is dynamic. Client and server negotiate capabilities when they connect. The agent doesn’t need prior knowledge of every tool. It discovers them.

These aren’t incremental improvements over REST. They’re a different way of thinking about how software talks to AI.

STDIO Was Never the Point

MCP launched with STDIO transport. Client spawns server as a subprocess. Communication happens through stdin and stdout. Dead simple.

Critics love pointing out the limitations. Single client. No authentication. Local only. Tightly coupled process lifecycles. All valid criticisms.

But they miss the point.

STDIO was the MVP. It proved one thing: Claude Desktop could call local tools through a standardized protocol. That’s all it needed to prove.

HTTP 0.9 had no headers, no status codes, no content types. The first version of any protocol exists to validate the idea. Evolution comes after.

OAuth Is Where It Gets Real

The introduction of Streamable HTTP and OAuth 2.1 transformed MCP from a local hack into genuine infrastructure.

Streamable HTTP unlocks what STDIO couldn’t. Multi-client servers. Session management. Disconnection recovery. An MCP server can now run as a proper service, deployed independently, serving multiple agents at once.

OAuth solves the trust problem that STDIO ignored entirely. When an agent reads your email or accesses your calendar, it’s acting on your behalf. That requires proper consent flows. Token binding to specific resources. Step-up authorization when the agent needs elevated permissions.

This is what an agent ecosystem actually needs. Not local script execution. Secure, authorized access to user data across services.

Evolution as Feature

Some criticize MCP for changing. For having limitations early on. For not shipping perfect on day one.

I see it differently.

A protocol’s value isn’t measured by its initial state. It’s measured by its capacity to evolve. MCP now has formal governance: Specification Enhancement Proposals, Working Groups, oversight from the Linux Foundation. The community is actively tackling real problems:

• Async tasks for operations that take minutes, not milliseconds
• Dynamic tool discovery so agents aren’t overwhelmed by large catalogs
• HTTP message signing for cryptographic authentication

The protocol keeps improving. That’s exactly the point.

Honest Tradeoffs

MCP isn’t universally necessary. I should be upfront about that.

For coding agents with direct filesystem and shell access, the value proposition gets murky. These agents write their own glue code. They’re often good at it.

But think about web-based assistants. ChatGPT. Claude.ai. They can’t spawn subprocesses or touch local files. They need a standardized way to connect to external services: your calendar, your email, your company’s internal tools.

Here, MCP provides genuine value. One integration that works across every AI platform.

For enterprises, this translates to real savings. Expose MCP as a connector layer on top of existing APIs. Write the integration once, support every AI client. Not technical elegance. Ecosystem efficiency.

The Bet

Will MCP become the standard? I don’t know.

But the protocols we have were built for humans. Agents need their own. Someone has to build it.

That’s why MCP matters.