What Is Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools, data, and prompts. You write an integration once as an MCP server. Any MCP-capable app can then use it.

Before MCP, every AI app needed its own custom connector for every system. MCP replaces that grid of one-off integrations with one protocol.

Where it came from

Anthropic announced MCP on 25 November 2024. The launch included the specification, SDKs, local MCP server support in the Claude Desktop apps, and an open-source repository of servers. The first reference servers covered Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Early adopters named at launch included Block, Apollo, Zed, Replit, Codeium, and Sourcegraph.

On 9 December 2025, the Linux Foundation announced the Agentic AI Foundation. MCP, Block’s goose, and OpenAI’s AGENTS.md were contributed as anchor projects. That moves MCP toward neutral governance rather than a single vendor.

How it works

The specification (version 2025-11-25) defines three roles:

Hosts are the AI applications that start connections.
Clients are connectors inside the host.
Servers provide context and capabilities.

Messages use JSON-RPC. Connections are stateful, and the client and server negotiate which capabilities each supports.

A server can offer three kinds of features:

Tools. Functions the model can call.
Resources. Data the app or model can read.
Prompts. Templated messages and workflows the user can pick.

Clients can offer features back to servers, including sampling (a server asks the host’s model for a completion), roots, and elicitation (a server asks the user for more input).

How it relates to tool calling

Tool calling is what the model does: it emits a structured request to run a function. MCP is how the tools are described, discovered, and served. In the spec’s words, tools are model-controlled, meaning the model can discover and invoke them based on context and the user’s prompts. A client lists tools with tools/list and runs one with tools/call.

For the full comparison with a plain REST integration, see MCP vs API integration. For a broader primer, see what is MCP.

Security rules in the spec

The spec is direct about risk. It lists four principles: user consent and control, data privacy, tool safety, and controls on LLM sampling. On tools it says they represent arbitrary code execution and must be treated with caution. It also says tool descriptions should be treated as untrusted unless they come from a trusted server, and that hosts must get explicit user consent before invoking any tool.

That last point connects to prompt injection. A tool description is text the model reads. A malicious or compromised server can put instructions in it. In the tools section the spec says there should always be a human in the loop who can deny tool calls, and that clients should show tool inputs before sending them to the server.

The spec also tells servers to validate inputs, apply access controls, rate limit calls, and sanitize outputs. Clients should log tool usage for audit purposes.

Why it matters for production agents

MCP lowers the cost of connecting an agent to a new system. That is good for speed. It also lowers the cost of connecting an agent to something it should not touch. My rule: every MCP server is a new trust boundary. Review it like you would review any third-party dependency that can run code and read your data.

A short example

Say a team builds one MCP server that exposes read-only ticket search for their help desk. Their internal assistant, their coding tool, and a reporting agent can all use it without new integration work. When the help desk changes its API, they fix one server.

Common mistakes

Installing community servers without reading the code.
Giving a server write access when the use case only needs read.
Skipping per-user authorization and sharing one broad credential.
Forgetting that tool output is untrusted text too.
Treating MCP as a security layer. It is a connection standard. Security is your job.

Questions to ask before connecting a server

Who wrote it, and can we read the code?
What credentials does it hold, and what can they do?
Does it run locally or remotely, and who operates the remote host?
Which tools does it expose, and are any of them write or delete actions?
What does it send back to the model, and could that include untrusted text?
Does it log calls, and where do the logs go?
How do we remove it, and revoke its access, if we need to?

If a team cannot answer these, it is not ready to connect the server to an agent that touches real data.

An MCP server is the piece you build or install. Tool calling is the model-side mechanism. For permission design on connected tools, see AI agent permissions and least privilege.