datarekha
Frameworks May 20, 2026

MCP is the USB-C of AI tools, finally

Anthropic shipped the Model Context Protocol in late 2024 as a small, JSON-RPC-shaped spec for connecting LLM clients to tools and data sources. Eighteen months later, it's the most adopted open protocol in the AI space — and the hype is, for once, an undercount.

12 min read · by datarekha · mcpanthropicclaudeopenaitools

If you’d told an LLM tooling engineer in early 2024 that within eighteen months OpenAI, Anthropic, Microsoft, Google’s Gemini CLI, Cursor, Zed, Replit, and a long tail of open-source IDEs would all speak the same protocol for tool integration — and that the protocol would have been designed by Anthropic — they would have looked at you the way a network engineer looks at someone explaining VHS will win.

And yet. By mid-2026, Model Context Protocol (MCP) has crossed the threshold every open standard hopes for: it’s adopted broadly enough that not supporting it is the conspicuous choice. The major model vendors all ship MCP clients. The major IDEs ship MCP clients. Enterprise tooling vendors ship MCP servers because their customers asked.

This post is about why a small JSON-RPC-shaped spec turned out to be load-bearing for the entire agent ecosystem, and what it does (and doesn’t) actually solve.

The N×M problem MCP solved

Before MCP, every tool integration was bespoke. If you wanted Claude to browse GitHub, somebody wrote a GitHub tool for Claude’s specific function-calling format. If you wanted GPT to do the same, somebody wrote it again for OpenAI’s format. If you wanted Cursor to read your local filesystem, Cursor wrote its own filesystem adapter. If you wanted Zed to do that too, Zed wrote a separate one.

BEFORE MCP — N × MClaudeGPTCursorZedGitHubfilesystemPostgresSlack4 × 4 = 16 integrations to writeAFTER MCP — N + MClaudeGPTCursorZedMCPprotocolGitHubfspgslack4 + 4 = 8 integrations to write
The actual win is unspectacular: every client speaks MCP, every tool speaks MCP, and the cross product collapses. This is the USB-C of LLM tooling — boring, useful, ubiquitous.

This is the same pain ODBC solved for databases, the same pain Language Server Protocol (LSP) solved for editors. In every case, the shape of the win is the same: the matrix of integrations collapses from N×M to N+M, and the marginal cost of supporting a new client or a new tool drops to roughly zero.

Anthropic open-sourced MCP in November 2024. The spec was small — a JSON-RPC handshake, a tools/prompts/resources abstraction, a server/client architecture, a transport layer (stdio for local, SSE and now Streamable HTTP for remote). The fact that the spec was small is, in retrospect, the most important design choice.

The shape of the protocol

An MCP server exposes three kinds of things to a client:

  • Tools — callable functions the model can invoke. Each tool has a name, a JSON Schema for input, and a return shape.
  • Resources — readable content the model can pull into context. Files, database rows, web pages. Read-only.
  • Prompts — pre-built templated prompts the user can pick from. Less load-bearing than the other two; useful for “slash command” style UX.

An MCP client (typically an LLM client like Claude Desktop or Cursor) connects to one or more MCP servers, discovers what each server offers, and surfaces those capabilities to the model.

// client → server
{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}

// server → client
{
  "jsonrpc": "2.0", "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_repo",
        "description": "Search a GitHub repository by name.",
        "inputSchema": {
          "type": "object",
          "properties": {"query": {"type": "string"}},
          "required": ["query"]
        }
      }
    ]
  }
}

That’s the whole protocol’s flavour. JSON-RPC, discoverable, the shape of a hundred other protocols you’ve seen. The genius is not in the design — it’s in the restraint. Anthropic could have shipped a sprawling, opinionated spec with built-in authentication, schemas, and tool-call etiquette. Instead, they shipped the smallest possible useful thing.

Why it actually got adopted

Three things together explain MCP’s adoption curve, none of which is “Anthropic shipped it.”

One: the implementer doesn’t have to like Anthropic. OpenAI shipped MCP support in Agents SDK in 2025. Google’s Gemini CLI ships MCP support. The major IDEs ship MCP. The protocol is genuinely vendor-neutral. If you adopt MCP, you are not adopting a Claude tax — your servers work with everyone’s clients and vice versa. This is what made LSP succeed: Microsoft shipped it for VS Code, and then every other editor adopted it precisely because Microsoft didn’t try to lock it down.

Two: server-side is easy. Writing an MCP server is roughly as hard as writing a Flask app. The official SDKs (Python, TypeScript, Go, Java, C#) handle the JSON-RPC plumbing; you write your tool as a function and decorate it. A working server is fifty lines.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("filesystem")

@mcp.tool()
def read_file(path: str) -> str:
    """Read a file from disk."""
    return open(path).read()

if __name__ == "__main__":
    mcp.run()

The Anthropic team has been quietly shipping a lot of these as reference servers — GitHub, Slack, Postgres, GDrive, filesystem, web search. Every reference server is a working example of how to write one.

Three: client-side is also easy, but more importantly, invisible to the user. The Claude Desktop config file is a JSON listing the MCP servers to start. Cursor’s is similar. Zed’s is similar. The user does not care about the protocol; they care about “I can ask Claude to look at my Postgres database and it just works.” The protocol is the invisible thing that makes the thing work.

What MCP didn’t try to solve

The discipline of the spec shows most clearly in what it left out.

  • No authentication scheme baked in. MCP doesn’t say how a tool call to “Slack” should authenticate. It defers to the underlying transport — local servers use the user’s OS-level credentials, remote servers can require OAuth, but the protocol doesn’t take a position. This drew complaints early on, but it’s why the protocol works in environments with wildly different security models.
  • No opinion on prompt engineering. MCP describes tool calls; it doesn’t tell the model how to use them. That’s the client’s job. (This is exactly the right boundary, and the place every other “agent protocol” before MCP got wrong.)
  • No agent-to-agent semantics. MCP is client-tool, not agent-agent. A2A is Google’s competing proposal for the agent-agent direction; the two coexist.

This restraint is the reason MCP got adopted instead of fragmenting into competing standards. Every time someone proposed “let’s add X to MCP,” the working group’s answer was usually “X is out of scope; build a server that does X, or build a layer on top.” That answer preserves what makes the spec usable.

Who’s actually running it in production

A non-exhaustive list of public adopters as of mid-2026:

  • Anthropic’s Claude Desktop and Claude Code ship with MCP as the only tool-integration mechanism. There is no “Anthropic-proprietary” tool format. This is the strongest possible signal Anthropic could send.
  • Cursor ships MCP for IDE-level tool integrations, and the Cursor team has been one of the most active contributors to the spec.
  • Zed supports MCP for assistant tool integration.
  • Replit Agent uses MCP servers internally to wire database, filesystem, and deployment tools to its agent.
  • OpenAI’s Agents SDK added MCP client support in 2025, allowing GPT-driven agents to invoke any MCP server.
  • Microsoft Copilot Studio added MCP support for connecting copilots to external tools without bespoke connectors.
  • A growing list of enterprise SaaS vendors ship MCP servers as the way for AI agents to interact with their products — Notion, Linear, Vercel, Fly, and others.

The cumulative effect is that if you’re shipping an MCP server, your tool is one config-file edit away from being usable inside every major LLM client. That is the meaningful difference between a protocol that gets adopted and one that doesn’t.

Where MCP bites

Honest pain points to know about:

  • Remote MCP is newer than local MCP. The original spec assumed stdio-based local servers (you’d run a server as a subprocess of your client). The HTTP+SSE and Streamable HTTP transports for remote servers are well-specified now, but the ecosystem for operating remote MCP servers — authentication, multi-tenancy, rate-limiting — is still settling.
  • Schema discipline varies. Some MCP servers ship beautiful, tightly-typed input schemas. Others ship Record<string, any> and pray. The protocol can’t enforce taste.
  • The model has to be told a tool exists. MCP gets you to the point where a tool is available to the model; it doesn’t make the model good at using it. Prompt engineering and evals are still your problem.
  • The “every Claude Desktop user is an admin running arbitrary servers” model has security implications. Anthropic, Cursor, and others have all had to walk through trust-and-safety scenarios for malicious MCP servers. The community has converged on signed servers and explicit approval prompts, but it’s an active area.

What to take away

MCP is the boring infrastructure win we’ve been waiting for in the agent space. It is not the flashy paper, not the new model, not the agent framework with the cleanest DSL. It is the unsexy plumbing that means the next flashy thing can plug into the existing world without writing a new integration layer.

If you’re building an agent in 2026, two practical takeaways:

  • Your tools should be MCP servers by default. Not because of any model lock-in concern, but because future-you will be glad you can swap clients without rewriting tools.
  • Your client doesn’t need to invent its own tool format. If you’re writing the next IDE assistant, the next desktop agent, the next embedded copilot — be an MCP client. The reference implementations are good, the ecosystem of servers is large, and the user can bring their own tools without your help.

The hype around MCP has, for once, been an undercount. The protocol turned out to matter more than the loudest essays predicted, because the win is invisible by design. The best protocols always are.

Further reading: modelcontextprotocol.io is the spec home; the reference servers repository is the best place to learn by reading; Anthropic’s original launch announcement gives the motivation in the team’s own words.

Skip to content