|
4 | 4 | 1. [Lifecycle](#lifecycle) |
5 | 5 | 1. [Discovery (`server/discover`)](#discovery-(server/discover)) |
6 | 6 | 1. [Per-request `_meta` keys](#per-request-meta-keys) |
| 7 | + 1. [Per-response `_meta` keys](#per-response-meta-keys) |
7 | 8 | 1. [Subscriptions (`subscriptions/listen`)](#subscriptions-(subscriptions/listen)) |
8 | 9 | 1. [Transports](#transports) |
9 | 10 | 1. [Stdio Transport](#stdio-transport) |
@@ -40,8 +41,10 @@ transparently based on the negotiated protocol version: |
40 | 41 | - A **stateless** model introduced in `2026-07-28` by |
41 | 42 | [SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575), |
42 | 43 | in which there is no `initialize`/`notifications/initialized` handshake, and |
43 | | - each request carries its protocol version, client identity, and client |
44 | | - capabilities in `_meta`. |
| 44 | + each request carries its protocol version and client capabilities in |
| 45 | + `_meta`. Clients SHOULD also include their identity (`clientInfo`) on every |
| 46 | + request, and servers SHOULD include their identity (`serverInfo`) on every |
| 47 | + response. |
45 | 48 |
|
46 | 49 | In both models, the SDK exposes the same API: |
47 | 50 |
|
@@ -130,17 +133,28 @@ When the negotiated protocol version is `2026-07-28` or later, every request |
130 | 133 | carries these keys inside its `_meta` map (constants live in |
131 | 134 | [`mcp/protocol.go`](https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#pkg-constants)): |
132 | 135 |
|
133 | | -| Constant | Wire key | Type | |
134 | | -|---|---|---| |
135 | | -| `MetaKeyProtocolVersion` | `io.modelcontextprotocol/protocolVersion` | `string` | |
136 | | -| `MetaKeyClientInfo` | `io.modelcontextprotocol/clientInfo` | `*Implementation` | |
137 | | -| `MetaKeyClientCapabilities` | `io.modelcontextprotocol/clientCapabilities` | `*ClientCapabilities` | |
138 | | -| `MetaKeyLogLevel` | `io.modelcontextprotocol/logLevel` | `LoggingLevel` (deprecated by SEP-2577) | |
139 | | - |
140 | | -The client populates these keys automatically on every outgoing request. |
141 | | -Server-side handlers can read them |
142 | | -through `ServerRequest[P].ProtocolVersion()`, `ServerRequest[P].ClientInfo()`, |
143 | | -and `ServerRequest[P].ClientCapabilities()`. |
| 136 | +| Constant | Wire key | Type | Required | |
| 137 | +|---|---|---|---| |
| 138 | +| `MetaKeyProtocolVersion` | `io.modelcontextprotocol/protocolVersion` | `string` | Yes | |
| 139 | +| `MetaKeyClientCapabilities` | `io.modelcontextprotocol/clientCapabilities` | `*ClientCapabilities` | Yes | |
| 140 | +| `MetaKeyClientInfo` | `io.modelcontextprotocol/clientInfo` | `*Implementation` | No | |
| 141 | +| `MetaKeyLogLevel` | `io.modelcontextprotocol/logLevel` | `LoggingLevel` (deprecated by SEP-2577) | No | |
| 142 | + |
| 143 | +The client populates the required keys automatically on every outgoing |
| 144 | +request, and populates `clientInfo` when configured with an `*Implementation` |
| 145 | +(the default). Server-side handlers can read them through |
| 146 | +`ServerRequest[P].ProtocolVersion()`, `ServerRequest[P].ClientInfo()`, and |
| 147 | +`ServerRequest[P].ClientCapabilities()`. |
| 148 | + |
| 149 | +### Per-response `_meta` keys |
| 150 | + |
| 151 | +Under the same protocol version, servers SHOULD identify themselves on every |
| 152 | +response. The SDK populates this |
| 153 | +key automatically on every outgoing response: |
| 154 | + |
| 155 | +| Constant | Wire key | Type | Required | |
| 156 | +|---|---|---|---| |
| 157 | +| `MetaKeyServerInfo` | `io.modelcontextprotocol/serverInfo` | `*Implementation` | No | |
144 | 158 |
|
145 | 159 | ### Subscriptions (`subscriptions/listen`) |
146 | 160 |
|
|
0 commit comments