The canonical no-op RequestContext: every member has a passive default (never cancelled, notifications dropped, server->client requests rejected, no capabilities, not stateless, no input responses / request state, no auth). A focused context — most of them test fakes — subclasses this and overrides only the one or two members it exercises, instead of re-stubbing the whole 12-method surface. Channel-less production contexts (NullContext, HttpNotifyContext) override only the server->client reject message.
A shared, mutable cancellation flag for one in-flight request. The server hands the same token to the request's RequestContext (so the handler can poll ctx.isCancelled) and to its in-flight registry (so an inbound notifications/cancelled for the matching request id can flip it). It is a class so the flag is observed across the two tasks that a Streamable HTTP transport runs the request and its cancellation on. See basic/utilities/cancellation: a receiver "SHOULD: Stop processing the cancelled request, Free associated resources, Not send a response".
A context with no client channel: notifications are dropped and server->client requests are rejected. Used by transports that do not (yet) support streaming, and as the default when none is supplied.
Wraps a transport-supplied RequestContext with the per-request protocol state the server determines only after parsing the message: whether the request is stateless (MRTR), and the input responses the client attached. The server installs this around the transport context before dispatching, so handlers observe correct isStateless/inputResponses and elicit/sample fail fast on stateless requests. Notifications and server->client requests delegate to the wrapped context unchanged.
A RequestContext for the stdio transport. The stdio transport is a single newline-delimited byte stream, and the MCP stdio spec permits the server to write any valid MCP message to stdout at any time — so server->client notifications (notifications/message logging and notifications/progress) are serialised and pushed to the transport's write sink as the handler emits them, out-of-band of the request's eventual reply.
Resolve the ConnectionState a context carries: the context's own state when it implements ConnectionScoped and resolved one, otherwise null. Centralised here (mirroring connectionTokenOf) so the server core has one place to decide per-session/per-request state vs. the single bound activeConnection fallback. A null result means "this context carries no scoped state" — the dispatcher then uses activeConnection.
Resolve the connection token for a context: the context's own token when it implements ConnectionScoped, otherwise the empty (shared) token. Centralised here so the server core has one place to derive the cancellation-registry scope.
The RFC 5424 severity ordering used by notifications/message logging (server/utilities/logging). Lower index == less severe; a message is emitted only when its severity is at or above the client's configured minimum (set via logging/setLevel). Returns -1 for an unrecognised level name.
Whether a log message at level should be emitted when the client's configured minimum is minLevel (RFC 5424 ordering). After logging/setLevel(error) only error and above pass. An unrecognised level is treated as always emitted (fail-open, so custom levels are not silently dropped); an unrecognised minLevel admits everything.
An optional capability a RequestContext may implement to report the connection / session it arrived on. The server core scopes its per-connection state (the in-flight cancellation registry) by this token so that two concurrent clients sharing one McpServer over Streamable HTTP cannot collide on a bare JSON-RPC id. A transport that multiplexes many sessions over one server SHOULD have its RequestContext implement this and return a per-session token (e.g. derived from Mcp-Session-Id, or a per-connection UUID), so a notifications/cancelled arriving on connection B only matches in-flight requests registered by connection B. A context that does not implement this interface is treated as the single shared connection (empty token), the behaviour for stdio, in-process, and any transport that does not distinguish connections.
Per-request context handed to tool handlers. It is the channel through which a handler emits server->client traffic while a request is in flight: progress + logging notifications, and (blocking) sampling / elicitation requests. Transports supply a concrete implementation; the in-process and stdio paths use NullContext (notifications are dropped, server->client requests are unsupported).