MCP (Model Context Protocol) is an open protocol that defines how an LLM-based client connects to an external server that exposes tools, resources, and prompt templates. It is the standardization attempt for the part of agent plumbing that every platform was reinventing on its own.

Why it exists

Before MCP, every chat product, every IDE assistant, and every agent runtime had its own way of letting the model call external capabilities. Some used JSON over HTTP. Some used gRPC. Some used a bespoke RPC. Tool definitions were formatted differently in every place. A tool that worked in Claude did not work in another product without rewriting.

The cost of this fragmentation was real. Tool authors wrote the same capability three times. Agent platforms could not share an ecosystem. Operators could not move a working integration between products.

MCP is the attempt to define one wire format and one discovery model, so a tool author writes the integration once and any MCP-speaking client can use it.

Basic shape

MCP has two sides.

Server. A server exposes three kinds of things:

  • Tools. Callable capabilities with typed inputs and outputs. The model can invoke these.
  • Resources. Read-only data the client can fetch — files, records, documents. The client surfaces these to the model as context.
  • Prompts. Named prompt templates the user can invoke with arguments. The model does not invoke these; the user does.

Client. A client speaks MCP to one or more servers. It discovers what each server offers, surfaces those offerings to the model, routes tool calls back to the right server, and returns results.

The wire format is JSON-RPC. Discovery happens at connection time — the server tells the client what it has. After that, calls are typed and bounded.

Who uses it

The protocol was introduced by Anthropic in late 2024 and has been adopted across the ecosystem at varying speeds. Anthropic's products speak MCP natively. OpenAI and Google have shipped MCP-compatible integrations in their platforms. The community has written servers for common systems: file systems, databases, Git, calendar, browser, IDEs.

Adoption is uneven. Some platforms treat MCP as a first-class citizen; others offer it as one transport among several. The direction is toward more MCP, not less.

What to read first

If you are building on top of an agent platform, the most useful question is whether your target platform speaks MCP. If yes, you write one integration and it works across clients. If no, you write one per client.

The deeper pattern is in the concept piece on tools, skills, and plugins. MCP is the protocol layer underneath the tool abstraction. The piece explains the higher-level shape; the protocol spec explains the wire format.

What MCP is not

  • Not an agent framework. MCP is a protocol for connecting clients to servers. It does not define the loop, the memory, or the planning.
  • Not a model API. MCP does not specify how the model is called. The client handles that.
  • Not a security boundary by itself. The protocol supports authentication, but the security model depends on the deployment. Treat any MCP server like any other remote system: scope, validate, audit. The piece on evaluation, safety, and governance covers what that means in practice.

The short version: if you are wiring tools to agents in 2026, you are probably writing or consuming an MCP server. The protocol is no longer the interesting question; the tool design is.