The Model Context Protocol (MCP)

Tool use lets a model act on the world, but someone still has to wire each tool into each application. The Model Context Protocol (MCP) is an open standard for that wiring. Introduced by Anthropic in late 2024 and since adopted across many AI applications, it defines a common way for an AI app to discover and use tools, data and prompt templates provided by separate programs called servers. The specification is versioned and still evolving, so treat the details below as the durable shape of the protocol and check the current spec before building.

The integration problem

Imagine five AI applications (a chat app, two IDEs, a support bot, an internal agent) and twenty things they want to connect to (GitHub, a database, a calendar, a file system…). Without a standard, each pairing needs its own integration: potentially 100 bespoke connectors, each with its own quirks.

MCP turns that multiplication into addition. A service writes one MCP server; an application implements one MCP client; any compatible pair can work together. The designers explicitly cite the Language Server Protocol as inspiration: LSP let any editor support any programming language through one standard, and MCP aims to do the same for AI context and tools.

Hosts, clients and servers

MCP has three roles:

Host: the AI application the user interacts with, such as a desktop assistant, an IDE or a custom agent. It holds the conversation, talks to the LLM, decides which servers to connect, and enforces consent and security policy.
Client: a connector inside the host. Each client talks to exactly one server, so a host using three servers runs three clients.
Server: a program exposing focused capabilities, such as “files and git”, “our CRM” or “the weather API”. It can be a local process or a remote service.

One design principle deserves emphasis: servers should not see the whole conversation, nor see into other servers. The host keeps the full context and passes each server only what it needs. That isolation is what makes it reasonable to plug several independent servers into one application.

Messages between client and server use JSON-RPC 2.0, a simple request, response and notification format.

What servers expose: tools, resources and prompts

A server offers any combination of three core primitives, which differ mainly in who decides to use them:

Tools: model-controlled

Functions the model can call to take actions or fetch information, each with a name, description and input schema, exactly like the function calling you would define by hand. The host lists a server’s tools to the model; when the model requests one, the client sends the call and returns the result.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": { "name": "search_issues", "arguments": { "query": "login bug" } }
}

Resources: application-controlled

Data and context identified by URIs: a file, a database schema, a document. The host application decides whether and how to include them in the model’s context, for example by letting the user attach one.

Prompts: user-controlled

Reusable, parameterised message templates or workflows, typically surfaced for the user to pick, for instance as a slash command such as “summarise this pull request”.

The protocol also lets servers ask the client for things, such as asking the user for extra input, and offers optional extensions. These areas have changed between spec revisions, which is a good reason to rely on an official SDK rather than hand-rolling the wire format.

Local and remote servers

The spec defines two standard transports:

stdio: the client launches the server as a local subprocess and exchanges newline-delimited messages over standard input and output. Simple, no network, and a natural fit for tools that touch your local files or dev environment.
Streamable HTTP: the server lives at an HTTP endpoint, and responses come back as JSON or a stream. This suits remote servers shared by many users and maintained centrally.

The choice has security consequences. A local server is a program running on your machine with your privileges. A remote server needs proper authorization; for HTTP, the spec builds on OAuth, so users can grant scoped access without handing credentials to the AI app.

Security considerations

MCP makes powerful capabilities easy to connect, which also makes mistakes easy to connect. The specification is candid that the protocol cannot enforce safety by itself; hosts and servers have to build it in. Key points:

User consent and control. Users should explicitly approve data access and actions. Hosts must get consent before invoking tools and before exposing user data to servers.
Treat tools as code execution. Tool descriptions and annotations should be considered untrusted unless they come from a trusted server.
Prompt injection. Anything a server returns becomes text the model reads. A malicious description or a poisoned tool result can instruct the model to misuse other tools or leak data. Limit what each server can do and confirm risky actions.
Local server compromise. Installing a server means running its code. Clients offering one-click setup should show the exact command, require approval, and ideally sandbox the process.
Least privilege. Request narrow OAuth scopes and grant broader ones only when needed.
No token passthrough. A server must accept only tokens issued for itself, never forward a client’s token blindly to another API; doing so undermines audit trails and security controls.

A good mental model: every MCP server is a third-party plugin with access to your model’s attention. Install it with the same care you would give any software that can read your data and act for you.

Why it matters

MCP does not make agents smarter; it makes them easier to connect. Tool builders get one integration that reaches many applications, and application builders get an ecosystem of ready-made servers. The price is a new layer to understand and secure. Learn the roles, the three primitives and the transport trade-offs, and always check the current specification: the fundamentals are stable, but the details keep moving.