The Model Context Protocol: USB-C for Tools
Anthropic has open-sourced the Model Context Protocol: a JSON-RPC standard that connects AI applications to data sources through servers, clients, tools, resources, and prompts. We explain the architecture, the stdio transport, what the protocol deliberately leaves unsolved, and why one integration surface could replace N-by-M custom connectors.
One Interface Instead of N Times M
Every AI assistant that should do more than chat needs access to external systems: ticket databases, wikis, repositories, internal APIs. Today each of these connections is a custom build. An application that talks to GitHub, Postgres, and Slack carries three bespoke connectors. A second application needs three more. With M applications and N systems, the industry maintains M times N integrations — each with its own authentication, its own error handling, and its own update cycle.
A shared protocol collapses that product into a sum. Each application implements the protocol once as a client; each system exposes it once as a server; M times N becomes M plus N. The analogy that gives this post its title is USB-C: one standardized port instead of one proprietary cable per peripheral. On November 25, 2024, Anthropic published exactly this kind of port for AI tooling.
What Anthropic Released on November 25
The release, named the Model Context Protocol (MCP), consists of three parts: an open specification with SDKs for TypeScript and Python, local MCP server support in the Claude Desktop apps, and an open-source repository of reference servers. Prebuilt servers exist for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. The specification carries revision 2024-11-05 and is developed publicly on GitHub.
Technically, MCP is JSON-RPC 2.0 over a stateful connection. Client and server negotiate capabilities during an initialize handshake: the client announces its protocol version and features such as sampling; the server replies with what it offers — tools, resources, prompts, logging. Nothing about the protocol is specific to Claude; any application can implement either side.
Hosts Clients and Servers
The specification names three roles. A host is an LLM application that initiates connections — Claude Desktop is the first shipping example. A client is the connector object inside the host; it maintains exactly one connection to exactly one server. A server is a usually small program that exposes context and capabilities. A host may run many clients in parallel, one per server.
Connections are two-way. Servers answer requests for data and execute tools, but they can also request work in the reverse direction: the sampling feature lets a server ask the client for an LLM completion. The specification requires that users explicitly approve such requests. This inversion is what distinguishes MCP from a plain plugin API.
Tools Resources and Prompts
A server offers up to three primitives, and the specification is precise about who controls each. Tools are model-controlled: functions with a JSON Schema inputSchema that the model discovers via tools/list and invokes via tools/call. Resources are application-controlled: data behind URIs that the client attaches as context. Prompts are user-controlled: templates the user invokes deliberately, for example as slash commands.
This separation is the design decision worth copying. A tool call is a decision by the model; a resource attachment is a decision by the client software; a prompt invocation is a decision by the human. Systems that blur these three lines end up either with unusable approval dialogs or with models that act without oversight.
Stdio as the Default Transport
The 2024-11-05 revision defines two transports. The primary one is stdio: the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages over stdin and stdout; stderr is reserved for logging. The specification says clients should support stdio whenever possible. The second transport, HTTP with Server-Sent Events, targets servers that run as standalone processes and serve multiple clients.
Stdio has practical consequences. Servers run on the user's machine, so credentials for the upstream system never leave it and no network endpoint needs securing. It also means MCP today is a local protocol: Anthropic has announced developer toolkits for remote production servers but has not shipped them yet.
What MCP Does Not Solve
MCP standardizes plumbing, not intelligence. Whether a model picks the right tool with the right arguments remains a property of the model and of the tool descriptions — the protocol only guarantees that the call is transported and answered in a defined format. Badly described tools stay badly used, over any protocol.
Other gaps are explicit. The specification defines no authentication or authorization scheme toward the upstream system; each server manages its own credentials, typically via environment variables. There is no registry: discovering servers means reading a GitHub repository. And the N-by-M argument holds only if M grows beyond one — at launch, Anthropic's own applications are the only shipping hosts.
The Early Ecosystem
The launch is not bare. Block and Apollo have already integrated MCP into their systems; Zed, Replit, Codeium, and Sourcegraph are building support into their development tools. The open-source repository contains reference servers beyond the six named above, and Anthropic notes that Claude 3.5 Sonnet is adept at writing new server implementations from a description of the target API.
That last point matters economically. If wrapping an internal system takes an afternoon rather than a sprint, the long tail of niche systems becomes reachable. We at Blue IT Systems wrapped a read-only view of an internal Postgres database as a stdio server during launch week; the code fits in one file.
| Primitive | Controlled by | Typical example |
|---|---|---|
| Tools | Model | Query a database or call an API |
| Resources | Application | File contents or a database schema |
| Prompts | User | A reusable review template as a slash command |
Outlook from Launch Week
Our forecast from launch week: MCP's fate depends on hosts, not servers. Servers are cheap to write; the protocol wins the moment a second and third major application speaks it as a client. The Language Server Protocol followed exactly this trajectory after 2016 — first one editor, then all of them, and language tooling stopped being an M-times-N problem.
For 2025 we expect three developments: a hardened remote transport with a real authentication story, some form of server registry, and adoption by at least one model vendor outside Anthropic — the specification contains nothing Claude-specific to prevent it. Until then we treat MCP servers as the default shape for new integrations: the worst case is a thin JSON-RPC wrapper we would have written anyway.