A close read of the Model Context Protocol — how hosts discover and invoke external capabilities through a common protocol, and the wire format underneath each connection.
Without a shared protocol, every AI application needs a bespoke adapter for every data source. M apps × N tools creates an M×N integration problem.
Three roles, not two. The Host is the application you're using; it creates one Client per connection, and each Client speaks 1:1 to exactly one Server.
The primitives above are transport-agnostic — the same tools/call works whether the server is a subprocess or a website.
The client launches a subprocess and exchanges newline-delimited JSON-RPC over stdin/stdout. OS permissions and exposed environment variables still define what that process can reach.
A single endpoint accepts POST requests. A reply can be one JSON object or a request-scoped SSE stream; long-lived change events use a subscription stream.
Every MCP message is one of three JSON-RPC shapes — the transport changes, this doesn't.
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": { ... }
}
{
"jsonrpc": "2.0",
"method": "notifications/tools/list_changed"
}
// no "id" field at all
Legacy revisions establish a connection-scoped session: negotiate a protocol version and capabilities, then confirm readiness.
The most recent spec revision removes the handshake entirely — worth knowing about, still landing across the ecosystem.
An initialize handshake negotiates connection-scoped capabilities. Streamable HTTP may use an MCP-Session-Id for subsequent requests.
No handshake or protocol session ID. Every request carries its protocol version and capabilities in _meta. Servers implement server/discover; clients may call it upfront.
Modern MCP centers on three server features and one client feature. Roots and Sampling remain available temporarily, but are deprecated.
Model-controlled actions the LLM can invoke — tools/list, tools/call.
App-controlled readable data — files, records — addressed by URI.
User-controlled reusable templates the host can surface as slash commands.
A server requests model generation through the client. New implementations should integrate with a model provider directly.
Filesystem locations the client exposes as working context. They are context hints, not an enforceable authorization boundary.
A server can ask the client to collect a specific piece of missing input from the user mid-task.
SEP-2577 deprecates all three. They remain functional during the compatibility window, but new implementations should use the alternatives below.
| Deprecated feature | Recommended direction |
|---|---|
| Roots | Pass locations through tool parameters, resource URIs, or server configuration |
| Sampling | Integrate the server directly with the chosen model provider |
| Logging | Use stderr for stdio and OpenTelemetry for structured observability |
Modern MCP separates capability discovery from live change delivery: discover what exists, then explicitly subscribe to the changes you need.
Stable since the 2025-03-26 revision — four booleans a tool definition can carry to describe its own behavior.
Safe-looking calls a client might auto-approve more readily.
Deletion, overwrites — the kind of call worth a confirmation.
Repeating the same call does not create further effects beyond the first call.
Web search, external APIs — results a client can't fully predict.
For protected HTTP servers, the MCP server is an OAuth resource server, the MCP client is an OAuth client, and authorization may be handled by a separate authorization server.
Fetches metadata, performs the authorization flow with PKCE, obtains the token, and sends it to the protected MCP endpoint.
Advertises RFC 9728 metadata and validates that the presented access token was issued for this resource.
Publishes discovery metadata, authenticates or obtains consent, and issues a resource-bound access token.
| 1 · Discover | 2 · Authorize | 3 · Call |
|---|---|---|
| 401 points the client to protected-resource metadata, which identifies the authorization server. | The client uses PKCE and includes resource= in authorization and token requests. | The client calls the MCP server with the token; the server validates its audience. |
MCP standardizes what the client can request and what the server exposes. The host remains responsible for what the user permits: consent, credentials, isolation, and policy.