Any AI application that wants to reach beyond its own chat window runs into the same chore: wiring itself to each tool and data source by hand, one bespoke integration at a time. MCP replaces that wiring with a single standard socket. The common shorthand for it is a USB-C port for AI applications, one shared connector that anything can plug into. What sits behind the analogy is a real protocol with defined roles and message formats, and that is where the useful detail lives.
The Model Context Protocol is an open standard for connecting an AI application to external tools and data. A host application runs clients, each client holds a session with a server, and the server exposes capabilities the application can use. It standardises the connection, not the model.
What the protocol connects
MCP describes a client-host-server architecture, and each of the three plays a fixed part. The specification names them plainly (MCP specification, 2025-11-25).
- Host is the AI application itself, the coordinator. It owns security and user consent, and it holds the integration with the language model.
- Client is a connector the host creates. Each client keeps a one-to-one relationship with a single server, so a host that needs three servers runs three clients.
- Server is a separate process that exposes capabilities to whatever connects to it. A server might wrap a calendar or a code repository.
The one-to-one rule between client and server matters more than it first looks. It keeps each connection isolated, so a host can hold sessions with many servers at once without letting one bleed into another.
What a server offers
A server does not hand over raw access to a system. It exposes a fixed set of building blocks, and the specification defines exactly three (MCP specification, 2025-11-25):
- Tools are functions the model can call to take an action, such as sending a message or querying a record.
- Resources are read-only data the application can pull into context, such as a file or a database row.
- Prompts are reusable templates a server can offer for common tasks.
Because the shape of these building blocks is fixed by the standard, a host does not need to learn each server’s private conventions. It already knows how to list the tools a server offers and how to call one. This is the part that makes an AI agent portable across integrations: the agent reaches for a tool the same way whether the server behind it wraps email or a spreadsheet.
How the two sides talk
Every message in MCP travels over JSON-RPC 2.0, a general-purpose remote procedure call format that predates MCP by more than a decade (JSON-RPC 2.0 specification, 2013). MCP did not invent its own wire format; it builds on an existing, transport-agnostic one and adds the meaning on top.
The connection is a stateful session rather than a one-off request. When a client and server first connect, they negotiate capabilities: both sides declare what they support before any real work begins (MCP specification, 2025-11-25). From then on the session stays open, so the host can call tools and read resources over the same channel without reintroducing itself each time.
Who controls the standard
MCP is an open standard. It originated at Anthropic in late 2024 and is now developed under an open governance model, operated as a Series of LF Projects, LLC, with a public specification-change process (MCP governance and stewardship page, modelcontextprotocol.io). No single vendor owns the protocol, which is part of why a server written by one company can be consumed by an application built by another.
The line the standard draws
The point that most short definitions skip is where the standard stops. MCP says nothing about which language model runs inside the host or how good it is. It fixes only the connection between an application and the outside capabilities it reaches for. Swap the model behind the host and every server it talks to keeps working; swap a server and every compliant host can still use it.
That is the whole return on the standard. A tool built once against MCP becomes reachable by any application that speaks the protocol, and an application built once can reach any tool that does, without either side knowing about the other in advance. Whether MCP is the right layer for a given integration, or whether a direct API call is the better fit, is a separate question covered in MCP vs API.
Sources
- Model Context Protocol. Specification: Architecture. Version 2025-11-25.
- JSON-RPC. JSON-RPC 2.0 Specification. Version 2.0, 4 Jan 2013.
- Model Context Protocol. Governance and Stewardship.
Questions, answered
What does MCP stand for?
Model Context Protocol. It is an open standard that defines how an AI application connects to external tools, data, and context.
What are the three MCP primitives?
Tools (functions the model can call), resources (read-only data the application can pull in), and prompts (reusable templates). An MCP server exposes some combination of these to whatever connects to it.
What is the difference between an MCP host, client, and server?
The host is the AI application that coordinates everything and owns security and consent. It runs one or more clients, and each client holds a single dedicated session with one server. The server is the process that exposes tools, resources, and prompts.
Does MCP replace APIs?
No. MCP is a standard layer that sits above APIs rather than a substitute for them. The connection between the two is worth reading on its own; see the MCP vs API comparison.
Brief is a team of AI associates you direct in plain language. Opening to a small group at a time.
Request access