What is Model Context Protocol (MCP)?

The integration problem it addresses

Before MCP, connecting an AI application to a data source meant writing a custom integration for each pairing. Five assistants and ten systems (a file store, a CRM, an error tracker, a database) could mean fifty separate connectors. MCP turns that multiplication into addition: write an MCP server for a system once, and any application that speaks MCP can use it.

The official specification says it takes inspiration from the Language Server Protocol, which did the same thing for programming-language support across code editors. Its scope is deliberately narrow. MCP covers the exchange of context; it does not dictate how an application uses its language model or manages what it receives.

Hosts, clients and servers

• Host: the AI application the user works in, such as a desktop assistant, a code editor or a chat interface. It coordinates one or more clients.
• Client: a component inside the host that maintains a dedicated connection to one server. The host creates a separate client for each server it connects to.
• Server: a program that provides context and capabilities. It can run locally on the user's machine or remotely.

The specification defines two transports. Local servers usually communicate over standard input/output (stdio) as a process on the same machine. Remote servers use Streamable HTTP, which supports standard HTTP authentication such as bearer tokens and API keys, with OAuth recommended for obtaining tokens.

Tools, resources and prompts

Clients can offer capabilities back to servers as well. Through elicitation, for instance, a server can ask the user for more information or for confirmation. A client discovers a server's tools with tools/list and invokes one with tools/call. With the _meta block (protocol version and capabilities) left out for brevity, a call looks like this:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "find_order",
    "arguments": { "order_id": "UK-48213" }
  }
}

Each tool's inputSchema is a JSON Schema. In other words, MCP doesn't replace function calling; it standardises how the tools a model may call are discovered on independent servers and delivered to the host.

Versions and recent changes

The specification is versioned by date; when this page was checked, the latest was 2026-07-28. That version makes the protocol stateless: every request carries the protocol version and relevant capabilities in its own _meta field, and servers advertise supported versions through a server/discover request. Sampling, which let a server request a language-model completion through the client, is deprecated as of that version. Anyone building on MCP should check which specification version their SDK targets.

Security sits with the implementer

The specification is blunt that MCP opens paths to arbitrary data access and code execution, and that the protocol itself cannot enforce its security principles. Implementers are expected to make sure users explicitly consent to data access and operations, that the host obtains explicit consent before invoking any tool, and that tool descriptions are treated as untrusted unless they come from a trusted server.

• Install only servers whose origin you know. An MCP server is a program that runs with the access you give it.
• Scope the tokens you hand a server according to the principle of least privilege.
• Remember that documents and pages read as resources can smuggle instructions to the model: prompt injection.

Systems that combine several servers and use their tools step by step towards a goal are the typical plumbing of an AI agent.