Module request_meta 

The per-request _meta block SEP-2575 introduced at 2026-07-28.

Why the handshake moved into _meta

Through 2025-11-25 a client’s capabilities and revision arrive once, in initialize, and every request after that rides the session they opened. 2026-07-28 has no handshake: the schema makes RequestParams._meta required on every request, and requires two keys in it — io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. A stateless peer repeats them per request because there is no session to remember them on.

The spec is explicit that the server must not carry them forward:

Capabilities are declared per-request rather than once at initialization; Servers MUST NOT infer capabilities from prior requests.

That sentence is the reason this is a value object parsed from one body rather than a field on the session: reading a request against the previous request’s capabilities is exactly the inference the SEP forbids, and a design where that is reachable is a design where it will happen.

Why the parser lives beside initialize

initialize::read_offer reads the same two facts off a different member of a different message, and both go through the same client_capabilities table. A second copy of that table would be a second definition of what a client is allowed to say.

Structs

RequestMeta

What one request said about itself.

Enums

RequestMetaError

Why a _meta block could not be read.

Constants

CLIENT_CAPABILITIES_KEY

The key naming what the client supports, for this request.

CLIENT_INFO_KEY

The key naming the client software, which the SEP makes a SHOULD.

LOG_LEVEL_KEY

The key opting a request in to notifications/message at a level.

PROTOCOL_VERSION_KEY

The key naming the revision this request is written against.

Functions

declares_version

Whether this body is a SEP-2575 stateless request.

progress_token

The progress token a request opened, if it opened one.

version_text

The revision a request’s _meta names, exactly as the client wrote it.