--- title: "Protocol surface — MCP glossary" description: "The primitives a server exposes, the shape of a result, and the error codes MCP defines." canonicalUrl: "https://zuplo.com/learn/mcp/glossary/protocol" pageType: "mcp-glossary-group" --- # Protocol surface The primitives a server exposes, the shape of a result, and the error codes MCP defines. One group of the [MCP glossary](/learn/mcp/glossary), which indexes every term A to Z. ## initialize handshake _Removed in 2026-07-28._ Deleted from this revision as a breaking change (SEP-2575), not deprecated first. SDKs may still expose an `initialize()` call, so check your SDK version before changing working code. The opening exchange of every MCP revision up to `2025-11-25`: the client sent an `initialize` request carrying its protocol version and capabilities, the server replied with its own, and the client confirmed with a `notifications/initialized`. The `2026-07-28` revision removed it. Version, identity, and capabilities now travel in the `_meta` field of every request. **Where you meet it.** This is why almost every MCP tutorial written before July 2026 no longer describes the wire. A modern-only server that receives `initialize` should name the protocol versions it supports in the error it returns, because a handshake-era client has no way to fall forward and that message may be the only diagnostic a user sees. **Also written:** initialize, notifications/initialized, initialize handshake, MCP handshake, initialize request **Source:** [MCP 2026-07-28: Versioning and Compatibility](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning#backward-compatibility-with-initialization-based-versions) **Read next:** [_meta](/learn/mcp/glossary/protocol#meta) · [server/discover](/learn/mcp/glossary/discovery#server-discover) · [Statelessness](/learn/mcp/glossary/transport#statelessness) ## `_meta` _Changed in 2026-07-28._ This revision made `_meta` load-bearing: it now carries per-request version and capability declarations, and extension identifiers follow its key naming rules. A reserved field on MCP requests, results, and notifications that carries metadata rather than payload. Since `2026-07-28` it is where each request declares what the removed handshake used to establish. Exactly two keys are required on every request — `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities` — while `io.modelcontextprotocol/clientInfo` on requests and `io.modelcontextprotocol/serverInfo` on results are both a SHOULD. **Where you meet it.** A request missing a required `_meta` field is malformed: the server must reject it with `-32602` and, on HTTP, `400 Bad Request`. Any prefix whose second label is `modelcontextprotocol` or `mcp` is reserved, so `com.mcp.tools/` is reserved and `com.example.mcp/` is not. The W3C trace-context keys `traceparent`, `tracestate`, and `baggage` are an explicit exception to the prefix rules. `clientInfo` and `serverInfo` are self-reported and unverified, and implementations should not base security decisions on them. **Also written:** _meta, io.modelcontextprotocol/protocolVersion, clientCapabilities, clientInfo, serverInfo, meta field **Source:** [MCP 2026-07-28: _meta](https://modelcontextprotocol.io/specification/2026-07-28/basic/index#meta) **Read next:** [initialize handshake](/learn/mcp/glossary/protocol#initialize) · [MCP-Protocol-Version](/learn/mcp/glossary/transport#mcp-protocol-version) · [MCP error codes](/learn/mcp/glossary/protocol#error-codes) · [Official extension](/learn/mcp/glossary/governance#official-extensions) ## Tool A named, schema-described capability a server exposes so that a language model can interact with an external system. Tools are listed with `tools/list` and invoked with `tools/call`. The specification describes them as model-controlled: the model can discover and invoke a tool on its own from context and the user's prompts. **Where you meet it.** Because invocation is the model's decision, the specification says there should always be a human in the loop able to deny a tool call. Tools are the primitive almost every MCP server ships, and the one authorization decisions are usually made against. **Also written:** tool, tools/call, tools/list, MCP tool, model-controlled **Source:** [MCP 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) **Read next:** [Resource indicators](/learn/mcp/glossary/authorization#resource) · [Prompt](/learn/mcp/glossary/protocol#prompt) · [x-mcp-header](/learn/mcp/glossary/transport#x-mcp-header) ## Resource Data a server exposes to give a language model context — files, database schemas, or application-specific information — each identified uniquely by a URI and read with `resources/read`. The specification describes resources as application-driven, with the host application deciding how to incorporate them. **Where you meet it.** The distinction that matters when reading the specification: a tool is invoked by the model, a resource is selected by the application. Custom URI schemes must conform to RFC 3986. **Also written:** resource, resources/read, resources/list, MCP resource, application-driven **Source:** [MCP 2026-07-28: Resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources) **Read next:** [Tool](/learn/mcp/glossary/protocol#tool) · [Prompt](/learn/mcp/glossary/protocol#prompt) · [subscriptions/listen](/learn/mcp/glossary/transport#subscriptions-listen) ## Prompt A server-defined, optionally parameterized template of structured messages and instructions for interacting with a language model, listed with `prompts/list` and resolved with `prompts/get`. The specification describes prompts as user-controlled, meaning the user explicitly selects one — that is about who decides when a prompt is used, not who writes it. The content is defined by the server. **Where you meet it.** Prompts complete the three-way split a reader keeps meeting in the specification: model-controlled tools, application-driven resources, user-controlled prompts. **Also written:** prompt, prompts/get, prompts/list, MCP prompt, user-controlled **Source:** [MCP 2026-07-28: Prompts](https://modelcontextprotocol.io/specification/2026-07-28/server/prompts) **Read next:** [Tool](/learn/mcp/glossary/protocol#tool) · [Resource](/learn/mcp/glossary/protocol#mcp-resource) ## Multi Round-Trip Requests (MRTR) _New in 2026-07-28._ Added in this revision (SEP-2322) as a breaking change: the previous pattern of server-initiated requests is no longer supported. The pattern that replaced server-initiated requests in `2026-07-28`. Instead of sending its own JSON-RPC request, a server that needs input answers the client's request with an `InputRequiredResult` — `resultType: "input_required"` plus an `inputRequests` map — and the client gathers the input and retries the original request with matching `inputResponses`. The retry must use a new JSON-RPC id. **Where you meet it.** Every result now carries a required `resultType` of either `"complete"` or `"input_required"`, and a client must treat an absent `resultType` from an earlier-revision server as `"complete"`. `InputRequiredResult` is only valid on `prompts/get`, `resources/read`, and `tools/call`. **Also written:** MRTR, multi round-trip requests, InputRequiredResult, resultType, input_required, inputRequests, inputResponses **Source:** [MCP 2026-07-28: Multi Round-Trip Requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr) **Read next:** [Elicitation](/learn/mcp/glossary/protocol#elicitation) · [Sampling](/learn/mcp/glossary/protocol#sampling) · [Roots](/learn/mcp/glossary/protocol#roots) · [Statelessness](/learn/mcp/glossary/transport#statelessness) ## Elicitation _Changed in 2026-07-28._ The feature remains, but its delivery moved to MRTR. URL mode dates from `2025-11-25`; the `notifications/elicitation/complete` message and `elicitationId` from that revision were removed. The mechanism by which a server asks for additional information from the user, through the client, while a request is in flight. It has two modes: form mode, where the client renders a schema-validated form and sees the answer, and URL mode, where the user is sent out of band so the data never passes through the client. **Where you meet it.** Since `2026-07-28` an elicitation arrives inside an `InputRequiredResult` rather than as a request the server pushes. Servers must not use form mode to ask for passwords, API keys, access tokens, or payment credentials. **Also written:** elicitation, elicitation/create, ElicitResult, form mode, url mode **Source:** [MCP 2026-07-28: Elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation) **Read next:** [MRTR](/learn/mcp/glossary/protocol#mrtr) · [Sampling](/learn/mcp/glossary/protocol#sampling) ## Sampling _Deprecated in 2026-07-28._ Deprecated in this revision (SEP-2577). It stays in the specification for at least twelve months, so the earliest removal is the first revision on or after 2027-07-28. The mechanism by which a server asks the client to run a language model completion on its behalf, so the client keeps control of model access, selection, and cost, and the server needs no model API key of its own. Deprecated as of `2026-07-28`. **Where you meet it.** Existing implementations should migrate to integrating with an LLM provider API directly. While it remains, a sampling request is delivered inside an `InputRequiredResult` like any other MRTR input request. **Also written:** sampling, sampling/createMessage, MCP sampling, server requests completion **Source:** [MCP 2026-07-28: Sampling](https://modelcontextprotocol.io/specification/2026-07-28/client/sampling) **Read next:** [MRTR](/learn/mcp/glossary/protocol#mrtr) · [Roots](/learn/mcp/glossary/protocol#roots) · [Deprecated, Removed, and Active](/learn/mcp/glossary/governance#deprecated-vs-removed) ## Roots _Deprecated in 2026-07-28._ Deprecated in this revision (SEP-2577), with the same twelve-month floor as sampling: earliest removal is the first revision on or after 2027-07-28. Filesystem locations a client tells a server it considers relevant, each identified by a `file://` URI. They are informational guidance and not an access-control mechanism: the protocol does not enforce that servers stay within them. Deprecated as of `2026-07-28`. **Where you meet it.** Anyone who read roots as a sandbox was reading them wrong, and the specification says so. Existing implementations should migrate to passing directories or files through tool parameters, resource URIs, or server configuration. **Also written:** roots, roots/list, MCP roots, filesystem roots, workspace roots **Source:** [MCP 2026-07-28: Roots](https://modelcontextprotocol.io/specification/2026-07-28/client/roots) **Read next:** [MRTR](/learn/mcp/glossary/protocol#mrtr) · [Sampling](/learn/mcp/glossary/protocol#sampling) · [Deprecated, Removed, and Active](/learn/mcp/glossary/governance#deprecated-vs-removed) ## MCP error codes _Changed in 2026-07-28._ This revision renumbered all three defined codes from the legacy range and retired `-32002` and `-32042`. MCP partitions the JSON-RPC implementation-defined error range: `-32000` to `-32019` is legacy, allocated by implementations before the policy existed, and `-32020` to `-32099` is reserved for the specification. Three codes are currently defined: `-32020` `HeaderMismatch`, `-32021` `MissingRequiredClientCapability`, and `-32022` `UnsupportedProtocolVersion`. **Where you meet it.** Two codes are retired. `-32002` (resource not found) is replaced by `-32602`, though clients should still accept `-32002` from older servers, and `-32042` (URL elicitation required) existed only in `2025-11-25`. Implementations of this revision must not emit either. Errors purely local to an implementation, such as an SDK request timeout, are not assigned codes by the specification at all — so a string like `MCP error -32001: Request timed out` is not a protocol error. **Also written:** MCP error codes, -32020, -32021, -32022, -32002, -32042, HeaderMismatch, MissingRequiredClientCapability, UnsupportedProtocolVersion **Source:** [MCP 2026-07-28: Error Codes](https://modelcontextprotocol.io/specification/2026-07-28/basic/index#error-codes) **On this site:** [MCP error reference](/learn/mcp/errors) **Read next:** [MCP-Protocol-Version](/learn/mcp/glossary/transport#mcp-protocol-version) · [Mcp-Method](/learn/mcp/glossary/transport#mcp-method) · [_meta](/learn/mcp/glossary/protocol#meta)