Scope
The Model Context Protocol includes the following projects:- MCP Specification: A specification of MCP that outlines the implementation requirements for clients and servers.
- MCP SDKs: SDKs for different programming languages that implement MCP.
- MCP Development Tools: Tools for developing MCP servers and clients, including the MCP Inspector
- MCP Reference Server Implementations: Reference implementations of MCP servers.
MCP focuses solely on the protocol for context exchange—it does not dictate
how AI applications use LLMs or manage the provided context.
Concepts of MCP
Participants
MCP follows a client-server architecture where an MCP host — an AI application like Claude Code or Claude Desktop — establishes connections to one or more MCP servers. The MCP host accomplishes this by creating one MCP client for each MCP server. Each MCP client maintains a dedicated connection with its corresponding MCP server. Local MCP servers that use the STDIO transport typically serve a single MCP client, whereas remote MCP servers that use the Streamable HTTP transport will typically serve many MCP clients. The key participants in the MCP architecture are:- MCP Host: The AI application that coordinates and manages one or multiple MCP clients
- MCP Client: A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use
- MCP Server: A program that provides context to MCP clients
Layers
MCP consists of two layers:- Data layer: Defines the JSON-RPC based protocol for client-server communication, including capability and version discovery, and core primitives, such as tools, resources, prompts and notifications.
- Transport layer: Defines the communication mechanisms and channels that enable data exchange between clients and servers, including transport-specific connection establishment, message framing, and authorization.
Data layer
The data layer implements a JSON-RPC 2.0 based exchange protocol that defines the message structure and semantics. This layer includes:- Discovery: Lets clients query a server’s supported protocol versions, capabilities, and identity through the
server/discoverrequest - Server features: Enables servers to provide core functionality including tools for AI actions, resources for context data, and prompts for interaction templates from and to the client
- Client features: Enables servers to elicit input from the user. Sampling is deprecated as of protocol version
2026-07-28. - Utility features: Supports additional capabilities like notifications for real-time updates and progress tracking for long-running operations
Transport layer
The transport layer manages communication channels and authentication between clients and servers. It handles connection establishment, message framing, and secure communication between MCP participants. MCP supports two transport mechanisms:- Stdio transport: Uses standard input/output streams for direct process communication between local processes on the same machine, providing optimal performance with no network overhead.
- Streamable HTTP transport: Uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming capabilities. This transport enables remote server communication and supports standard HTTP authentication methods including bearer tokens, API keys, and custom headers. MCP recommends using OAuth to obtain authentication tokens.
Data Layer Protocol
A core part of MCP is defining the schema and semantics between MCP clients and MCP servers. Developers will likely find the data layer — in particular, the set of primitives — to be the most interesting part of MCP. It is the part of MCP that defines the ways developers can share context from MCP servers to MCP clients. MCP uses JSON-RPC 2.0 as its underlying RPC protocol. Client and servers send requests to each other and respond accordingly. Notifications can be used when no response is required.Statelessness and discovery
MCP is a . Every request carries the protocol version and the relevant to that request in its_meta field, so the server can process each request on its own. Clients should also identify themselves in the same field unless configured not to. Servers advertise their supported versions and capabilities through the mandatory server/discover request, which clients may send before any other request. Detailed information can be found in the specification, and the example showcases the per-request metadata and the discovery sequence.
Primitives
MCP primitives are the most important concept within MCP. They define what clients and servers can offer each other. These primitives specify the types of contextual information that can be shared with AI applications and the range of actions that can be performed. MCP defines three core primitives that servers can expose:- Tools: Executable functions that AI applications can invoke to perform actions (e.g., file operations, API calls, database queries)
- Resources: Data sources that provide contextual information to AI applications (e.g., file contents, database records, API responses)
- Prompts: Reusable templates that help structure interactions with language models (e.g., system prompts, few-shot examples)
*/list), retrieval (*/get), and in some cases, execution (tools/call).
MCP clients will use the */list methods to discover available primitives. For example, a client can first list all available tools (tools/list) and then execute them. This design allows listings to be dynamic.
As a concrete example, consider an MCP server that provides context about a database. It can expose tools for querying the database, a resource that contains the schema of the database, and a prompt that includes few-shot examples for interacting with the tools.
For more details about server primitives see server concepts.
MCP also defines primitives that clients can expose. These primitives allow MCP server authors to build richer interactions.
- Elicitation: Allows servers to request additional information from users. This is useful when server authors want to get more information from the user, or ask for confirmation of an action. Servers request user input with the
elicitation/createmethod.
2026-07-28.
- Sampling: Allows servers to request language model completions from the client’s AI application. This is useful when server authors want access to a language model, but want to stay model-independent and not include a language model SDK in their MCP server. Servers request completions with the
sampling/createMessagemethod, also delivered through the Multi Round-Trip Requests pattern. New implementations should integrate directly with LLM provider APIs. - Logging: Enables servers to send log messages to clients for debugging and monitoring purposes. New implementations should log to
stderr(stdio transport) or use OpenTelemetry.
Notifications
The protocol supports real-time notifications to enable dynamic updates between servers and clients. For example, when a server’s available tools change (such as when new functionality becomes available or existing tools are modified), the server can send tool update notifications to inform connected clients about these changes. Notifications are sent as JSON-RPC 2.0 notification messages (without expecting a response). Change notifications are opt-in: the client opens a long-livedsubscriptions/listen stream naming the notification types it wants to receive, and the server delivers matching notifications on that stream.
Example
Data Layer
This section provides a step-by-step walkthrough of an MCP client-server interaction, focusing on the data layer protocol. We’ll demonstrate discovery, tool operations, and notifications using JSON-RPC 2.0 messages.1
Discovery
As described in the statelessness and discovery section, every MCP request carries the protocol version and client capabilities in its
_meta field, and clients should also include their identity there. A client that wants to learn what a server supports before issuing other requests sends a server/discover request, which every server must implement. The discovery response is typically cacheable, meaning it can be re-used so the discovery flow does not need to be performed for every request.Understanding the Discovery Exchange
The_meta fields and the discovery response together serve several purposes:-
Protocol Version Selection: The
io.modelcontextprotocol/protocolVersionfield declares the version the client is speaking on this request, andsupportedVersionsin the response lists the versions the server accepts. If a server does not support the requested version, it rejects the request with anUnsupportedProtocolVersionErrorlisting the versions it does support, and the client retries with a mutually supported version. -
Capability Discovery: The client declares its capabilities in
io.modelcontextprotocol/clientCapabilitieson every request, and the server returns its owncapabilitiesobject fromserver/discover. This tells each party which primitives the other can handle (tools, resources, prompts) and whether change notifications are available, so unsupported operations are never attempted. -
Identity Exchange: The
io.modelcontextprotocol/clientInfofield in the request’s_metaand theio.modelcontextprotocol/serverInfofield in the result’s_metaprovide identification and versioning information for debugging and compatibility purposes.
"elicitation": {}- The client declares it can gather additional input from the user when the server requests it
"tools": {"listChanged": true}- The server supports the tools primitive and can honor atoolsListChangedfilter insubscriptions/listen. Clients that request this filter receivenotifications/tools/list_changedwhen the tool list changes."resources": {}- The server also supports the resources primitive (can handleresources/listandresources/readmethods)
server/discover is optional. Because every request carries the same _meta fields, a client is free to send any request directly and handle a version error if one comes back. Discovery is a convenient way to fetch the server’s identity, capabilities, and supported versions in a single request.How This Works in AI Applications
The AI application’s MCP client manager connects to configured servers and stores their discovered capabilities for later use. The application uses this information to determine which servers can provide specific types of functionality (tools, resources, prompts) and whether they support real-time updates. In the Python SDK, discovery happens while the client connects. The results are then available on the client object.Pseudo-code for AI application discovery
2
Tool Discovery (Primitives)
The client can discover available tools by sending a
tools/list request. This request is fundamental to MCP’s tool discovery mechanism: it allows clients to understand what tools are available on the server before attempting to use them.