Every AI application eventually needs to reach outside the model: read a database, search documents, call an internal API. Before there was a shared standard, each of those connections was custom glue code, written separately for every pairing of application and tool. The Model Context Protocol (MCP) is the open standard that replaces that pairwise work with one common interface.

This explainer follows the current MCP specification, which is the authoritative source for everything described here.

The problem: N applications times M tools

Suppose you build a tool that assistants should be able to use. Without a standard, you write an integration for each assistant, and each assistant's maker writes one for each tool. The work grows as the product of the two. The specification describes MCP as "a standardized way to connect LLMs with the context they need," and says it takes inspiration from the Language Server Protocol, which solved the same multiplication problem for programming-language support across editors.

The three roles

MCP uses JSON-RPC 2.0 messages between three kinds of participant:

  • Hosts are the LLM applications that start connections, such as a chat app or an AI-powered editor.
  • Clients are connectors that live inside a host. Each one manages the connection to a server.
  • Servers are services that provide context and capabilities.

If you build a tool, you build a server. If you build an AI application, you build (or adopt) the client side. Neither has to know about the other in advance.

What a server can offer

The specification lists three server-side features:

  • Tools are functions the AI model can execute, like "create a ticket" or "run a query."
  • Resources are context and data that the user or the model can use, like a file or a database record.
  • Prompts are templated messages and workflows meant for users to invoke.

The distinction matters. Tools are model-controlled actions, so they deserve the most scrutiny; resources are data; prompts are user-facing shortcuts. A client may also offer a feature back to servers: elicitation, where a server asks the user for additional information mid-task.

Recent design direction

The current spec describes the base protocol as built on stateless, self-contained requests with per-request capability negotiation, plus utilities for progress tracking, cancellation and error reporting. Beyond the core, it defines optional extensions that both client and server must opt into during initialization. Named examples include Tasks (asynchronous execution of long-running operations with polling and durable handles) and MCP Apps (interactive UI elements such as charts and forms, rendered inline in a conversation).

If you read older tutorials, check them against the current specification, because the protocol has continued to evolve.

The security section is the part to read

MCP gives models a path to arbitrary data access and code execution, and the specification says so plainly. Its key principles are worth treating as a checklist:

  1. User consent and control. Users must explicitly consent to data access and operations, and keep control over what is shared.
  2. Data privacy. Hosts must get explicit consent before exposing user data to servers, and must not pass resource data elsewhere without it.
  3. Tool safety. Tools represent arbitrary code execution. The spec says hosts must obtain explicit user consent before invoking any tool, and that descriptions of tool behaviour, such as annotations, should be considered untrusted unless they come from a trusted server.

That last point has a direct consequence: a tool description is text that ends up in your model's context, so a malicious or compromised server can try to steer the model through it. The protocol itself cannot enforce these principles; the spec says implementors should build the consent flows and access controls themselves.

Practical advice

My own suggestions, not the specification's:

  • Start with read-only tools. Prove the integration before giving a model the ability to change anything.
  • Treat third-party servers like third-party code. Review what they do, pin versions, and don't connect servers you don't trust to a model that has access to sensitive data.
  • Keep tool lists small and stable. Models choose better from a few well-described tools, and changing tool definitions between requests can also invalidate a provider's prompt cache. Our prompt-caching guide explains why.
  • Log tool calls. When an agent does something unexpected, you want the full record of which tool it called and with what arguments.

The takeaway

MCP's value is simple to state: build one server, and any compatible client can use it; build one client, and you can use any compatible server. Its risk is just as simple: it makes it easy to hand a model real power. Adopt it for the first reason, and design for the second. For the agent-building side, see Agentic Coding Assistants.

Sources

AI IntegrationAI ToolsDeveloper ToolsMCPModel Context Protocol