Model Context Protocol (MCP)

Elicitation is MCP's way for a server to ask the human user for structured input while it is handling a request — a missing parameter, a confirmation, a choice between accounts. The client shows the ask and returns the user's answer.

The host is the AI application the user runs. Inside it, one client per server speaks the protocol. Each server exposes one integration's tools, resources and prompts. Clients never talk to each other.

MCP restricts an elicitation/create requestedSchema to a single flat object whose properties are primitives only — string, number, integer, boolean, or an enum. No nested objects, no arrays. That keeps the form renderable by any client.

Roots are data the client sends, not a permission the protocol applies. MCP has no mechanism to intercept a server's file access, so a server keeps every byte its operating-system user can reach whether it honours the roots or ignores them.

Revision 2026-07-28 made MCP stateless: every request is self-contained and carries its own protocol version and capabilities. A connection, including a live stdio process, is only a transport channel, so a server must not build context from earlier requests on it.

Every MCP request must put io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities inside params._meta. An empty capabilities object is legal, but the key itself is not optional. clientInfo is optional and SHOULD be sent.

server/discover returns a DiscoverResult holding supportedVersions, the server's capabilities, optional instructions, and the required cache hints ttlMs and cacheScope, with serverInfo in _meta. Servers MUST implement it; clients MAY call it.

MCP protocol versions are dates in YYYY-MM-DD form naming the day of the last backwards-incompatible change to the specification. The current revision is 2026-07-28. Backwards-compatible additions do not bump the version.

Modern means the per-request metadata model of MCP 2026-07-28 and later; legacy means the initialize handshake of 2025-11-25 and earlier; dual-era supports both. Era is a property of the server, and only a dual-era server serves clients of both eras.

UnsupportedProtocolVersionError, JSON-RPC code -32022, is how an MCP server rejects one request whose declared protocol version it will not serve. Its data carries supported and requested, so the client retries with a listed version rather than disconnecting.

prompts/list returns the server's prompt templates with their names, descriptions and declared arguments. prompts/get takes one name plus argument values and returns the filled-in, role-tagged messages. Prompts are user-controlled: a person picks one, the model does not.

A resource is identified by its URI. resources/list returns descriptors — uri, name, optional description and mimeType — while resources/read takes one uri and returns a contents array carrying the data itself. Both results carry the required resultType field in MCP 2026-07-28.

inputSchema is the JSON Schema object in a tool's tools/list entry that describes the arguments the tool accepts. The host uses it to shape and check the arguments object sent in tools/call, and the server validates against it again.

Each entry in a prompt's arguments array is a PromptArgument with a name, an optional title and description, and an optional required boolean. Callers pass values as a flat name-to-string map on prompts/get; omitting a required argument earns a -32602 invalid-params error.

Failures of the tool's own work — an upstream 500, a missing file, a rejected input value — come back as a successful result with isError set to true, so the model can read them. Protocol-level failures such as an unknown tool or invalid params are JSON-RPC error objects.

Multi Round-Trip Requests. A server can no longer send its own JSON-RPC request; it answers the client's call with a result whose resultType is "input_required", listing what it needs, and the client re-sends the original call carrying the answers.

The client re-sends the original method and arguments as a brand-new JSON-RPC request with a new id, adding an inputResponses map keyed exactly like the server's inputRequests and echoing the opaque requestState byte for byte.

subscriptions/listen is one long-lived request whose response stream carries server-to-client change notifications. The client names what it wants in a SubscriptionFilter: toolsListChanged, promptsListChanged, resourcesListChanged, and resourceSubscriptions (a list of resource URIs). Nothing is pushed unless the client opted in.

Only tools/call, prompts/get and resources/read may answer with an input_required result. Each entry in its inputRequests map is one of three request types: a sampling createMessage request, a roots list request, or an elicitation request.

The server MUST send notifications/subscriptions/acknowledged before any change notification. It confirms the stream is live and the filter accepted. Every notification the server then sends on that stream carries io.modelcontextprotocol/subscriptionId in its _meta so the client can tell its streams apart.

MCP stdio framing is newline-delimited JSON: each JSON-RPC message is one line of UTF-8 text ending in a newline, contains no embedded newlines, and stdout carries nothing except MCP messages.

MCP's Streamable HTTP transport exposes a single endpoint that accepts POST only. The client POSTs one JSON-RPC message with an Accept header listing both application/json and text/event-stream, and the server answers with either a JSON body or an SSE stream.

Nothing replaced them. MCP revision 2026-07-28 removed protocol sessions entirely: every request is self-contained and carries its own protocol version and capabilities, so a server must not rely on anything an earlier request on the same connection established.

Inside the message itself. Stdio has no header layer, so every request carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in its params._meta object, on every single call.

An MCP Streamable HTTP request must carry MCP-Protocol-Version, Mcp-Method, and Mcp-Name for tools/call, resources/read and prompts/get. If MCP-Protocol-Version disagrees with the value in params._meta, the server returns HTTP 400 with JSON-RPC error -32020, HeaderMismatchError.

sampling/createMessage lets an MCP server ask the connecting client to run an LLM completion for it, so the server needs no model credentials of its own. The client picks the model and runs the call. MCP revision 2026-07-28 deprecates the feature.

Only messages and maxTokens are required. messages is an array of role-tagged user and assistant content blocks; maxTokens caps the completion. systemPrompt, modelPreferences, stopSequences, temperature and, for tool-enabled sampling, tools and toolChoice are optional.

Nothing at all. In MCP revision 2026-07-28 a refusal is expressed by simply not retrying the original request. There is no decline message, no error code and no reason string for the server to read.

Two review points. Before the model runs, the client should show the user the prompt the server supplied and let them approve, edit or reject it. After it runs, the user should be able to see and edit the completion before it goes back to the server.

Revision 2026-07-28 deprecates sampling and tells servers to integrate directly with an LLM provider API instead. Deprecated features stay in the spec at least twelve months, so the earliest removal is the first revision released on or after 2027-07-28.

The host application enforces consent. MCP is a JSON-RPC wire protocol: it can require fields and reject malformed messages, but it cannot verify that a human approved anything, so the specification states its principles as guidance the host must carry out.

A remote MCP server is an OAuth 2.1 resource server, never an authorization server. It issues no tokens and runs no login screen: it validates the bearer token presented on every HTTP request and rejects one not issued for itself.

ToolAnnotations are self-reported labels written by the same server whose behaviour they describe. MCP revision 2026-07-28 requires clients to treat them as untrusted unless the server itself is trusted out of band, so they may shape the UI but never gate a call.

A Client ID Metadata Document lets an MCP client use an HTTPS URL with a path as its client_id. The authorization server dereferences that URL to read the client's metadata — client_name, redirect_uris — with no prior registration.

User Consent and Control, Data Privacy, and Tool Safety. Revision 2026-07-28 deleted the former fourth principle, LLM Sampling Controls, when Sampling was deprecated. MCP states these principles but cannot enforce any of them at the protocol level.

Each side lists supported extensions in the extensions field of its capabilities: a map from a prefixed identifier to a settings object. An empty object means supported with no settings, not unsupported. An extension is live only if both sides list it.

The server answers immediately with a CreateTaskResult: resultType "task" plus a taskId. The work keeps running server-side, and the client polls tasks/get with that taskId until the task reaches a terminal status and yields its result.

The extension simply does not apply. Under MCP revision 2026-07-28 the other side MUST either revert to core protocol behaviour or reject the request outright. Proceeding as though the extension were in effect is not an option.

An MCP extension is an optional feature layered on top of the core protocol and used only when both peers declare it. Revision 2026-07-28 names two official ones: io.modelcontextprotocol/tasks (Tasks) and io.modelcontextprotocol/ui (MCP Apps).

A task is working, input_required, completed, failed or cancelled. The first two are live states the client keeps polling; completed, failed and cancelled are terminal. Cancellation is cooperative — tasks/cancel requests it, the server decides when the task actually stops.