Skip to content

feat(schema): add optional serverInfo response metadata and make clientInfo optional #3002

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kurtisvg merged 2 commits into from
Jul 16, 2026
Merged

feat(schema): add optional serverInfo response metadata and make clientInfo optional #3002

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
100679d
feat(schema): add optional serverInfo response metadata and make clie…
kurtisvg Jul 2, 2026
c734d64
feat(schema): recommend clientInfo/serverInfo via SHOULD and de-dupli…
kurtisvg Jul 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/specification/draft/architecture/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ title: Architecture

The Model Context Protocol (MCP) follows a client-host-server architecture where each
host can run multiple client instances. MCP is a stateless protocol: every request is
self-contained and carries its own protocol version, client identity, and capabilities.
self-contained and carries its own protocol version and capabilities.
This architecture enables users to integrate AI capabilities across applications while
maintaining clear security boundaries and isolating concerns. Built on JSON-RPC, MCP
provides a protocol focused on context exchange and sampling coordination between
Expand Down Expand Up @@ -141,7 +141,7 @@ sequenceDiagram

loop Client Requests
Host->>Client: User- or model-initiated action
Client->>Server: Request (with _meta: version, clientInfo, clientCapabilities)
Client->>Server: Request (with _meta: version, clientCapabilities)
alt Server requires client input
Server-->>Client: InputRequiredResult (e.g. sampling/createMessage)
Client->>Host: Forward to AI
Expand Down
30 changes: 26 additions & 4 deletions docs/specification/draft/basic/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -346,29 +346,51 @@ may reserve particular names for purpose-specific metadata, as declared in those

**Per-request protocol fields:**

Every client request **MUST** include the following `io.modelcontextprotocol/*` fields
in `_meta`. Servers use these to identify the client and the protocol version in use
without relying on any prior connection state. See
Client requests carry the following `io.modelcontextprotocol/*` fields in `_meta`;
fields marked as required **MUST** be included on every request. Servers use these
to identify the protocol version and capabilities in use without relying on any
prior connection state. See
[Versioning and Compatibility][lifecycle] for version negotiation rules.

| Key | Type | Required | Description |
| -------------------------------------------- | -------------------- | -------- | --------------------------------------------------------- |
| `io.modelcontextprotocol/protocolVersion` | `string` | Yes | Protocol version for this request (e.g., `"2026-07-28"`) |
| `io.modelcontextprotocol/clientInfo` | `Implementation` | Yes | Client name and version |
| `io.modelcontextprotocol/clientInfo` | `Implementation` | No | Client name and version |
| `io.modelcontextprotocol/clientCapabilities` | `ClientCapabilities` | Yes | Client capabilities relevant to this request |
| `io.modelcontextprotocol/logLevel` | `LoggingLevel` | No | Minimum log level the server should emit for this request |

A request missing any required field is malformed; the server **MUST** reject it with
JSON-RPC error code `-32602` (Invalid params). On HTTP, the response status **MUST** be
`400 Bad Request`.

Clients **SHOULD** include `io.modelcontextprotocol/clientInfo` on every request
unless specifically configured not to do so.

A server **MUST NOT** rely on capabilities the client has not declared. If
processing a request requires a capability the client did not include in
`io.modelcontextprotocol/clientCapabilities`, the server **MUST** return a
[`MissingRequiredClientCapabilityError`](/specification/draft/schema#missingrequiredclientcapabilityerror)
(`-32021`) whose `data.requiredCapabilities` lists the missing capabilities. On
HTTP, the response status **MUST** be `400 Bad Request`.

**Per-response protocol fields:**

Servers **SHOULD** include the following `io.modelcontextprotocol/*` field in
every result's `_meta`, unless specifically configured not to do so, to
identify themselves without relying on any prior connection state:

| Key | Type | Required | Description |
| ------------------------------------ | ---------------- | -------- | ----------------------- |
| `io.modelcontextprotocol/serverInfo` | `Implementation` | No | Server name and version |

<Note>
`io.modelcontextprotocol/clientInfo` and `io.modelcontextprotocol/serverInfo`
are self-reported by the sender and are not verified by the protocol. They are
intended for display, logging, and debugging. Implementations **SHOULD NOT**
use them to change the behavior of the client or server, and **SHOULD NOT**
rely on them for security decisions.
</Note>

On notifications delivered via a [`subscriptions/listen`][subscriptions-listen] stream,
the server **MUST** include `io.modelcontextprotocol/subscriptionId` in `_meta` so the
client can correlate the notification with the originating subscription request.
Expand Down
9 changes: 9 additions & 0 deletions docs/specification/draft/basic/patterns/mrtr.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,15 @@ title: Multi Round-Trip Requests
supported. This is a breaking change.
</Note>

<Note>
For brevity, the request examples on this page omit the `_meta` request
metadata (`io.modelcontextprotocol/protocolVersion`,
`io.modelcontextprotocol/clientInfo`, and
`io.modelcontextprotocol/clientCapabilities`). Every request **MUST** include
the required `_meta` fields; see
[`_meta`](/specification/draft/basic/index#meta).
</Note>

## Multi Round-Trip Requests

The Model Context Protocol (MCP) defines several ways for servers to request additional information
Expand Down
2 changes: 1 addition & 1 deletion docs/specification/draft/basic/transports/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ initiate JSON-RPC requests and clients do not send JSON-RPC responses.
## Request Metadata

All protocol metadata travels in the message body: every request carries its
protocol version, client identity, and client capabilities in
protocol version and client capabilities in
[`_meta.io.modelcontextprotocol/*`](/specification/draft/basic/index#meta)
fields.

Expand Down
4 changes: 2 additions & 2 deletions docs/specification/draft/basic/transports/stdio.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,8 +65,8 @@ Server-to-client interactions are carried in
## Request Metadata

All request metadata for the stdio transport is carried inline in the
JSON-RPC message body. The protocol version, client identity, and
per-request capabilities live in
JSON-RPC message body. The protocol version, per-request capabilities, and
optional client identity live in
[`_meta.io.modelcontextprotocol/*`][meta-fields];
the method name and arguments live where JSON-RPC puts them. There is no
header layer.
Expand Down
2 changes: 1 addition & 1 deletion docs/specification/draft/changelog.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ the previous revision, [2025-11-25](/specification/2025-11-25).

1. Remove protocol-level sessions and the `Mcp-Session-Id` header from the Streamable HTTP transport. List endpoints (`tools/list`, `resources/list`, `prompts/list`) no longer vary per-connection. Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments ([SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567)).

2. Make MCP stateless: remove the `initialize`/`notifications/initialized` handshake. Every request now carries its protocol version, client identity, and client capabilities in `_meta` (`io.modelcontextprotocol/protocolVersion`, `io.modelcontextprotocol/clientInfo`, `io.modelcontextprotocol/clientCapabilities`). Version mismatches return `UnsupportedProtocolVersionError` ([SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575)).
2. Make MCP stateless: remove the `initialize`/`notifications/initialized` handshake. Every request now carries its protocol version and client capabilities in `_meta` (`io.modelcontextprotocol/protocolVersion`, `io.modelcontextprotocol/clientCapabilities`). Clients SHOULD identify themselves on each request (`io.modelcontextprotocol/clientInfo`), and servers SHOULD identify themselves in each result's `_meta` (`io.modelcontextprotocol/serverInfo`). Version mismatches return `UnsupportedProtocolVersionError` ([SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575)).

3. Add `server/discover`: servers MUST implement this RPC to advertise their supported protocol versions, capabilities, and identity. Clients MAY call it before any other request for up-front version selection, or use it as a backward-compatibility probe on STDIO ([SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575)).

Expand Down
Loading
Loading