feat(schema): add optional serverInfo response metadata and make clientInfo optional by kurtisvg · Pull Request #3002 · modelcontextprotocol/modelcontextprotocol · GitHub
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
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
Loading
Loading