--- title: "MCP glossary" description: "Definitions for the terms in MCP authentication and the protocol itself: PRM, CIMD, DCR, PKCE, resource indicators, Streamable HTTP, statelessness, and the MCP error codes. Every entry cites its RFC or specification section." canonicalUrl: "https://zuplo.com/learn/mcp/glossary" sourceUrl: "https://zuplo.com/learn/mcp/glossary" pageType: "other" generatedAt: "2026-09-23" --- # MCP glossary > 39 terms from MCP authentication and the protocol itself, each defined against > the RFC or specification section it comes from, and marked where the > 2026-07-28 revision changed it. Current as of MCP 2026-07-28. Each term below links to its full definition on its group page (`/learn/mcp/glossary/#`). ## Index (A-Z) - **Audience** (aka: aud claim · aud · token audience · audience validation failed) — Authorization and tokens The party a token is intended for. → [/learn/mcp/glossary/authorization#aud](/learn/mcp/glossary/authorization#aud) - **Authorization server metadata** (ASM; aka: RFC 8414 · oauth-authorization-server · AS metadata) — Discovery A JSON document, published by an authorization server, that lists its endpoints and capabilities: issuer, authorization_endpoint, token_endpoint, scopes_supported, and which registration mechanisms it supports. → [/learn/mcp/glossary/discovery#authorization-server-metadata](/learn/mcp/glossary/discovery#authorization-server-metadata) - **Client ID Metadata Documents** (CIMD; aka: client ID metadata document · client_id_metadata_document_supported · URL client_id · DCR replacement) — Credentials and registration A registration mechanism in which the client's `client_id` is an HTTPS URL that resolves to a JSON document of its own metadata, so the authorization server fetches the client's details on demand instead of storing a registration. → [/learn/mcp/glossary/credentials#cimd](/learn/mcp/glossary/credentials#cimd) - **Deprecated, Removed, and Active** (aka: deprecated · removed · feature lifecycle · deprecation policy · deprecated features registry · SEP-2596) — Versions and governance The feature lifecycle policy puts every specification feature in exactly one of three states. → [/learn/mcp/glossary/governance#deprecated-vs-removed](/learn/mcp/glossary/governance#deprecated-vs-removed) - **Dynamic Client Registration** (DCR; aka: RFC 7591 · registration_endpoint · dynamic client registration not supported) — Credentials and registration A protocol, defined by RFC 7591, that lets a client register itself with an authorization server over HTTP and receive a `client_id` back, with no human in the loop. → [/learn/mcp/glossary/credentials#dcr](/learn/mcp/glossary/credentials#dcr) - **Elicitation** (aka: elicitation/create · ElicitResult · form mode · url mode) — Protocol surface The mechanism by which a server asks for additional information from the user, through the client, while a request is in flight. → [/learn/mcp/glossary/protocol#elicitation](/learn/mcp/glossary/protocol#elicitation) - **HTTP+SSE transport** (aka: HTTP+SSE · HTTP with SSE · SSE transport · old MCP transport · 2024-11-05 transport) — Transport and headers The original two-endpoint HTTP transport from the `2024-11-05` revision: the client opened an SSE stream with GET and posted messages to a separate endpoint the stream advertised. → [/learn/mcp/glossary/transport#http-sse](/learn/mcp/glossary/transport#http-sse) - **Identity Assertion JWT Authorization Grant** (ID-JAG; aka: Cross-App Access · XAA · urn:ietf:params:oauth:token-type:id-jag · identity chaining) — Credentials and registration An IETF draft profile of the JWT authorization grant that gives a client delegated access to a resource in another trust domain on behalf of a user, without a separate user-approval step at that domain's authorization server. → [/learn/mcp/glossary/credentials#id-jag](/learn/mcp/glossary/credentials#id-jag) - **initialize handshake** (aka: initialize · notifications/initialized · MCP handshake · initialize request) — Protocol surface 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`. → [/learn/mcp/glossary/protocol#initialize](/learn/mcp/glossary/protocol#initialize) - **Issuer identification** (aka: iss · iss parameter · RFC 9207 · authorization_response_iss_parameter_supported · mix-up attack) — Authorization and tokens RFC 9207 adds an `iss` parameter to the OAuth authorization response so a client can tell which authorization server issued the code it just received, and an `authorization_response_iss_parameter_supported` metadata flag to advertise it. → [/learn/mcp/glossary/authorization#iss](/learn/mcp/glossary/authorization#iss) - **MCP error codes** (aka: -32020 · -32021 · -32022 · -32002 · -32042 · HeaderMismatch · MissingRequiredClientCapability · UnsupportedProtocolVersion) — Protocol surface 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. → [/learn/mcp/glossary/protocol#error-codes](/learn/mcp/glossary/protocol#error-codes) - **Mcp-Method** (`Mcp-Method`; aka: mcp method header · mirrored headers) — Transport and headers An HTTP header mirroring the JSON-RPC `method` field of the request body, required on all Streamable HTTP POST requests. → [/learn/mcp/glossary/transport#mcp-method](/learn/mcp/glossary/transport#mcp-method) - **Mcp-Name** (`Mcp-Name`; aka: mcp name header · tool name header) — Transport and headers An HTTP header mirroring `params.name` or `params.uri` from the request body, required on `tools/call`, `resources/read`, and `prompts/get` requests. → [/learn/mcp/glossary/transport#mcp-name](/learn/mcp/glossary/transport#mcp-name) - **Mcp-Session-Id** (`Mcp-Session-Id`; aka: mcp session id header · MCP session · no valid session ID provided) — Transport and headers The HTTP header that carried a protocol-level session identifier in the `2025-03-26` through `2025-11-25` revisions. → [/learn/mcp/glossary/transport#mcp-session-id](/learn/mcp/glossary/transport#mcp-session-id) - **MCP-Protocol-Version** (`MCP-Protocol-Version`; aka: protocol version header · mcp protocol version · unsupported protocol version) — Transport and headers The HTTP header that carries the protocol version on every Streamable HTTP POST, for example `MCP-Protocol-Version: 2026-07-28`. → [/learn/mcp/glossary/transport#mcp-protocol-version](/learn/mcp/glossary/transport#mcp-protocol-version) - **Multi Round-Trip Requests** (MRTR; aka: InputRequiredResult · resultType · input_required · inputRequests · inputResponses) — Protocol surface The pattern that replaced server-initiated requests in `2026-07-28`. → [/learn/mcp/glossary/protocol#mrtr](/learn/mcp/glossary/protocol#mrtr) - **\_meta** (`_meta`; aka: io.modelcontextprotocol/protocolVersion · clientCapabilities · clientInfo · serverInfo · meta field) — Protocol surface A reserved field on MCP requests, results, and notifications that carries metadata rather than payload. → [/learn/mcp/glossary/protocol#meta](/learn/mcp/glossary/protocol#meta) - **Official extension** (aka: MCP extensions · io.modelcontextprotocol/ui · io.modelcontextprotocol/tasks · io.modelcontextprotocol/oauth-client-credentials · io.modelcontextprotocol/enterprise-managed-authorization · MCP Apps · extensions capability) — Versions and governance An optional addition to the specification that defines capability beyond the core protocol, identified as `{vendor-prefix}/{extension-name}`. → [/learn/mcp/glossary/governance#official-extensions](/learn/mcp/glossary/governance#official-extensions) - **OPTIONAL authorization** (aka: authorization is optional · MCP API key auth · custom header auth MCP · is API key authentication allowed in MCP · out of scope) — Authorization and tokens The MCP specification states that authorization is OPTIONAL for implementations, and that HTTP-based implementations SHOULD — not MUST — conform to its OAuth profile when they do support it. → [/learn/mcp/glossary/authorization#optional-authorization](/learn/mcp/glossary/authorization#optional-authorization) - **Prompt** (aka: prompts/get · prompts/list · MCP prompt · user-controlled) — Protocol surface 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`. → [/learn/mcp/glossary/protocol#prompt](/learn/mcp/glossary/protocol#prompt) - **Protected resource metadata** (PRM; aka: RFC 9728 · oauth-protected-resource · resource metadata) — Discovery A JSON document, published by a protected resource, that names the authorization servers able to issue tokens for it. → [/learn/mcp/glossary/discovery#protected-resource-metadata](/learn/mcp/glossary/discovery#protected-resource-metadata) - **Protocol revision** (aka: MCP version · 2026-07-28 · protocol version · Draft Current Final) — Versions and governance MCP versions are dates in `YYYY-MM-DD` form, naming the last date on which backward-incompatible changes were made. → [/learn/mcp/glossary/governance#protocol-revision](/learn/mcp/glossary/governance#protocol-revision) - **Proof Key for Code Exchange** (PKCE; aka: RFC 7636 · code_challenge · code_verifier · S256) — Credentials and registration An extension to the OAuth authorization code flow that stops a stolen authorization code from being redeemed by anyone else. → [/learn/mcp/glossary/credentials#pkce](/learn/mcp/glossary/credentials#pkce) - **Resource** (aka: resources/read · resources/list · MCP resource · application-driven) — Protocol surface 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`. → [/learn/mcp/glossary/protocol#mcp-resource](/learn/mcp/glossary/protocol#mcp-resource) - **Resource indicators** (aka: RFC 8707 · resource parameter · resource indicator missing or unknown · canonical server URI) — Authorization and tokens RFC 8707 defines a `resource` request parameter that names the target service a token is being requested for, so the authorization server can audience-restrict the token it issues. → [/learn/mcp/glossary/authorization#resource](/learn/mcp/glossary/authorization#resource) - **Roots** (aka: roots/list · MCP roots · filesystem roots · workspace roots) — Protocol surface Filesystem locations a client tells a server it considers relevant, each identified by a `file://` URI. → [/learn/mcp/glossary/protocol#roots](/learn/mcp/glossary/protocol#roots) - **Sampling** (aka: sampling/createMessage · MCP sampling · server requests completion) — Protocol surface 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. → [/learn/mcp/glossary/protocol#sampling](/learn/mcp/glossary/protocol#sampling) - **Scope** (aka: scopes_supported · insufficient_scope · 403 insufficient scope · step-up authorization) — Authorization and tokens The OAuth mechanism for expressing what an access token is allowed to do. → [/learn/mcp/glossary/authorization#scope](/learn/mcp/glossary/authorization#scope) - **server/discover** (`server/discover`; aka: DiscoverResult · mcp discover method · supportedVersions) — Discovery A method that returns a server's supported protocol versions, capabilities, and identity in a single request. → [/learn/mcp/glossary/discovery#server-discover](/learn/mcp/glossary/discovery#server-discover) - **Specification Enhancement Proposal** (SEP; aka: SEP-2575 · SEP-2322) — Versions and governance A SEP is a design document that describes a new feature for MCP or for its processes, and it is the mechanism required for any protocol change, breaking change, or governance change. → [/learn/mcp/glossary/governance#sep](/learn/mcp/glossary/governance#sep) - **Statelessness** (aka: stateless · stateless MCP · sessions removed · MCP is stateless) — Transport and headers MCP is a stateless protocol as of the `2026-07-28` revision. → [/learn/mcp/glossary/transport#statelessness](/learn/mcp/glossary/transport#statelessness) - **stdio** (`stdio`; aka: standard input output transport · local MCP server) — Transport and headers The transport in which the client launches the MCP server as a subprocess and the two exchange newline-delimited JSON-RPC messages over the subprocess's standard input and output. → [/learn/mcp/glossary/transport#stdio](/learn/mcp/glossary/transport#stdio) - **Streamable HTTP** (aka: streamable http transport · MCP endpoint · remote MCP transport) — Transport and headers The HTTP transport for MCP, introduced in the `2025-03-26` revision. → [/learn/mcp/glossary/transport#streamable-http](/learn/mcp/glossary/transport#streamable-http) - **subscriptions/listen** (`subscriptions/listen`; aka: resources/subscribe · MCP notifications stream · subscriptionId) — Transport and headers A long-lived request that opens a server-to-client notification stream filtered to the event types the client names. → [/learn/mcp/glossary/transport#subscriptions-listen](/learn/mcp/glossary/transport#subscriptions-listen) - **Token exchange** (aka: RFC 8693 · urn:ietf:params:oauth:grant-type:token-exchange · subject_token · delegation · impersonation) — Authorization and tokens An OAuth grant, defined by RFC 8693, in which a client presents one token and receives a different one with a different audience, subject, or scope. → [/learn/mcp/glossary/authorization#token-exchange](/learn/mcp/glossary/authorization#token-exchange) - **Token passthrough** (aka: forwarding access tokens · confused deputy) — Authorization and tokens The anti-pattern in which an MCP server accepts a token from a client without validating that it was issued to the MCP server, then passes it through to a downstream API. → [/learn/mcp/glossary/authorization#token-passthrough](/learn/mcp/glossary/authorization#token-passthrough) - **Tool** (aka: tools/call · tools/list · MCP tool · model-controlled) — Protocol surface A named, schema-described capability a server exposes so that a language model can interact with an external system. → [/learn/mcp/glossary/protocol#tool](/learn/mcp/glossary/protocol#tool) - **WWW-Authenticate** (`WWW-Authenticate`; aka: www authenticate header · 401 challenge · resource_metadata · Bearer challenge) — Discovery The HTTP response header field a server uses to challenge a client for credentials, defined by RFC 9110 and given its Bearer-scheme parameters by RFC 6750. → [/learn/mcp/glossary/discovery#www-authenticate](/learn/mcp/glossary/discovery#www-authenticate) - **x-mcp-header** (`x-mcp-header`; aka: Mcp-Param · custom headers from tool parameters · tool parameter header) — Transport and headers An extension property a server puts on a parameter inside a tool's `inputSchema` to have the client mirror that parameter's value into an HTTP header named `Mcp-Param-{Name}`. → [/learn/mcp/glossary/transport#x-mcp-header](/learn/mcp/glossary/transport#x-mcp-header) No match for a search string? The page suggests trying the acronym on its own, the RFC number, or the header name, and offers two exits: the [MCP error reference](/learn/mcp/errors) or [Ask us about it](/support). ## Pairs that get mixed up Each of these is two things, and knowing which one you have is usually the whole diagnosis. - **PRM versus ASM** — Two different documents, published by two different parties. The resource says which authorization servers can issue tokens for it; the authorization server says where its own endpoints are. - **DCR versus CIMD** — Both get a client an identity with no human involved. DCR stores a registration at the authorization server; CIMD uses an HTTPS URL as the client ID and is fetched on demand, so nothing is stored and the ID is portable. - **Resource indicators versus Audience** — The `resource` parameter is what the client asks for; the audience is what the issued token carries and what the server checks. An identity provider that ignores `resource` still issues a token — with the wrong audience. - **Mcp-Session-Id versus Statelessness** — Not a rename. Protocol-level sessions were deleted, so state that has to outlive a request is now an explicit handle passed in tool arguments rather than a header the transport tracks. ## Browse a whole area These read in the order a request does: find the authorization server, pick a transport, get a credential, have it checked, then the surface that credential buys, then the process that changes all of it. - **[Discovery](/learn/mcp/glossary/discovery)** (4 terms) — How a client finds out where to authenticate, starting from a 401 it did not expect. - **[Transport and headers](/learn/mcp/glossary/transport)** (10 terms) — How MCP messages travel, and the headers the 2026-07-28 revision added, changed, or dropped. - **[Credentials and registration](/learn/mcp/glossary/credentials)** (4 terms) — How a client obtains a client identity and an access token before it calls anything. - **[Authorization and tokens](/learn/mcp/glossary/authorization)** (7 terms) — What a server checks on the token it receives, and what it must refuse to do with it. - **[Protocol surface](/learn/mcp/glossary/protocol)** (10 terms) — The primitives a server exposes, the shape of a result, and the error codes MCP defines. - **[Versions and governance](/learn/mcp/glossary/governance)** (4 terms) — How revisions are numbered, how features are retired, and how any of it changes. ## Next steps - Start a free account: https://portal.zuplo.com/signup - Read the docs: https://zuplo.com/docs/mcp-gateway/code-config/overview - Back to [Learn MCP](/learn/mcp)