MCP is an open standard that lets AI applications connect to tools, data, and services through one consistent interface — instead of a bespoke integration for every pairing. Think USB-C, but for models.
Before MCP, wiring an AI agent to an external system meant a custom integration per source. N models × M tools = an N×M mess. MCP collapses that into N+M: build once on each side, connect anything to anything.
USB-C standardized how devices talk to peripherals. You don't need a unique cable per gadget. MCP does the same for LLMs and the outside world — a single shape every integration can rely on.
A server exposes capabilities (tools, data, prompt templates). A client speaks a shared JSON-RPC protocol to discover and call them. The model gets context and the ability to act, safely and uniformly.
Every MCP setup is a conversation between a host, its clients, and one or more servers. Underneath, the protocol cleanly separates what is said (data layer) from how it travels (transport layer).
Claude, an IDE, a chat UI. Manages the model and orchestrates connections.
Lives inside the host. Maintains a 1:1 session with a single server.
Exposes tools, resources & prompts. Local subprocess or remote service.
A JSON-RPC 2.0 protocol defining lifecycle, capability negotiation, and the core primitives — tools, resources, prompts, and notifications. Transport-independent.
The channel that moves messages: connection setup, framing, and authorization. The same data layer rides over any transport unchanged.
These three are what a server offers. Each has standard list and get/call methods, so any client can discover and use them without prior knowledge. Server concepts
Executable functions the model can invoke — run a query, send an email, create a file. Defined with a JSON Schema for their inputs.
Read-only data the server makes available — files, records, API responses. Context for the model, with no side effects.
Reusable, parameterized instruction templates the server defines — surfaced as slash-commands or menu actions in the host.
A server asks the host to run an LLM completion (sampling/createMessage) — enabling recursive, agentic server logic without bundling its own model.
The client tells the server which filesystem locations or URIs it's allowed to operate within — a scoping boundary for safe access.
A server requests structured input from the user mid-operation — confirmations, missing fields, choices — using schema-defined forms.
One-way messages with no reply: lifecycle signals like initialized and dynamic updates like tools/list_changed.
A connection follows a defined lifecycle so client and server agree on versions and capabilities before any real work happens — enabling backward and forward compatibility. Versioning
The client opens with its protocol version and what it supports. The server replies with its own. Both sides learn what's possible.
The client sends a notification confirming setup is complete. The session is now live.
Normal exchange: list tools/resources/prompts, call them, stream results, fire notifications when lists change.
The transport closes the connection. For stdio the client closes the subprocess; for HTTP the session simply ends.
Not three, not five — two. This intentional minimalism keeps the ecosystem interoperable. The same JSON-RPC data layer rides over both. Architecture & transports
/mcp) accepts both POST and GET/sse channel) was retired in March 2025 and replaced by Streamable HTTP's single-endpoint design. If you see SSE-only servers, they're on the old model.Remote servers are treated as OAuth 2.1 resource servers. The hard part has always been registering an unbounded number of clients with an unbounded number of servers — and the latest spec finally fixes it. Authorization guide
Dynamic Client Registration let clients self-register, but only worked if the auth server supported it. Otherwise developers had to build a fragile OAuth proxy, or push every user through IT to mint their own registration.
Client ID Metadata Documents (SEP-991): a client's ID is a URL pointing to a JSON document it controls describing itself. No pre-registration dance — the server fetches and trusts the metadata.
WWW-Authenticate, and a formal Cross-App Access authorization extension for enterprise identity.Shipped on MCP's first birthday — a batch of production-driven features that make the protocol more scalable and reliable. The headliners:
A new abstraction for long-running work. Any request can return a task handle — "call now, fetch later." Clients poll status and retrieve results within a server-defined window. Built for deep research, code migrations, multi-agent runs.
URL-based client registration that finally untangles OAuth at ecosystem scale — no more building proxies or per-user IT registrations.
Sampling requests can now pass tools and toolChoice — letting servers drive genuinely agentic LLM calls through the host.
Servers can hand off to a secure out-of-band web interaction (e.g. a hosted form or payment page) instead of cramming everything into inline fields.
A standards-based EnumSchema supporting titled, untitled, single-select, and multi-select enums — far better structured user prompts.
Tools, resources, templates, and prompts can expose icons — so hosts can render connectors and capabilities with proper visual identity.
A formal extension mechanism (including authorization extensions like Cross-App Access), plus OIDC discovery and tool-naming guidance — the protocol maturing for enterprise.
Pulled from the first-anniversary release notes. Browse the index yourself in the MCP Registry.