Model Context Protocol (MCP)

Before MCP, connecting an AI application to external tools and data was an N-times-M problem: every application needed custom glue for every data source, and none of it was reusable. Anthropic introduced and open-sourced the Model Context Protocol in November 2024 to collapse that into N-plus-M. Build a server once for your data source, build a client once in your application, and any compliant client can talk to any compliant server. The official analogy is a USB-C port for AI: a single standardised connector rather than a drawer of proprietary cables. The protocol has since picked up support well beyond its origin, including clients from other vendors, which is what turns a good idea into a standard.

The architecture

MCP is a client-server protocol with three roles:

• Host: the AI application the user interacts with (Claude Desktop, an IDE, a chatbot). It runs one or more clients.
• Client: the connector inside the host that maintains a session with a single server.
• Server: a separate process that exposes a data source or tool through the protocol.

The separation matters: the server runs as its own process and the host never embeds the integration code, so a server written for Slack works unchanged in any MCP-aware host.

The three primitives

A server can expose three kinds of capability, and the distinction is worth internalising because it maps to who is in control:

1. Tools are model-controlled: functions the model may decide to call, the MCP form of function calling (see tool-use-function-calling).
2. Resources are application-controlled: data the host can load into context (a file, a database row, a document).
3. Prompts are user-controlled: reusable templated workflows a user can invoke deliberately.

Transport is typically stdio for a local server (the host launches the server as a subprocess) or HTTP for a remote one. The wire format is JSON-RPC, which keeps the protocol language-agnostic; SDKs exist across the common languages.

Why it caught on

The win is ecosystem leverage. An open protocol with ready-made servers for the systems people actually use (Google Drive, Slack, GitHub, Postgres were in the launch set) means an application gains a long tail of integrations for free, and a tool vendor reaches every MCP host by writing one server. Standards succeed when both sides of the market benefit, and MCP's split, easier for app builders and for tool builders simultaneously, is why it spread past its origin lab rather than staying a Claude-only feature.

When it falls down

• Servers are an attack surface. Tool results flow back into the model's context, so a malicious or compromised MCP server can mount a prompt-injection attack through the data it returns (see prompt-injection). Treat third-party servers as untrusted input, not as trusted plugins.
• Authorisation is the young part. The core protocol standardised tool-calling plumbing faster than it standardised auth and permission scoping; production deployments still wrap servers in their own authentication and least-privilege controls.
• It is a connector, not a brain. MCP standardises how a model reaches a tool; it does nothing for whether the model chooses the right tool or uses it well. Bad tool descriptions fail identically over MCP as over a bespoke integration.
• Local-server sprawl. Launching many stdio servers as subprocesses is convenient and easy to over-do, multiplying processes, credentials, and update surface on the host.

Further reading

• Model Context Protocol: Introduction - the official spec entry point; architecture, primitives, and SDKs.
• Introducing the Model Context Protocol - the November 2024 announcement and the N-times-M problem it set out to solve.