One read of Model Context Protocolmcp-20261024T110706Z
303 pages moved out of 357 read.
Pages moved
303
significant first
Pages read
357
in this capture
Captured
11:07 UTC
Corpus hash
0c1129ea4604
full-sweep
What this read moved
201-225 of 303, page 9 of 13This capture is too large to show at once. Changes 201-225 of 303 are below, significant first; the rest are on the following screens.
specification/draft/basic/transports/index Changed · +10 / -10 lines
from line 7
77**binding**: it defines how messages are framed and delivered, how request
88metadata is carried, and how cancellation and termination are signaled. It
99does not define what the messages mean: the
10[message patterns](/specification/draft/basic/patterns.md) are part of the core
10[message patterns](https://modelcontextprotocol.io/specification/draft/basic/patterns.md) are part of the core
1111protocol and are the same on every binding. The binding pages specify the
1212standard transports:
1313
141. [stdio](/specification/draft/basic/transports/stdio.md): newline-delimited
141. [stdio](https://modelcontextprotocol.io/specification/draft/basic/transports/stdio.md): newline-delimited
1515 messages over the standard streams of a client-launched subprocess.
162. [Streamable HTTP](/specification/draft/basic/transports/streamable-http.md):
162. [Streamable HTTP](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md):
1717 each message is an HTTP POST to a single MCP endpoint; replies arrive as
1818 a JSON object or a request-scoped SSE stream.
1919
from line 28
2828A binding **MUST** deliver client-sent *requests* and *notifications* to the
2929server, and server-sent *responses* and *notifications* to the client. No
3030other message direction exists: per the
31[message patterns](/specification/draft/basic/patterns.md), servers do not
31[message patterns](https://modelcontextprotocol.io/specification/draft/basic/patterns.md), servers do not
3232initiate JSON-RPC requests and clients do not send JSON-RPC responses.
3333
3434## Request Metadata
from line 35
3535
3636All protocol metadata travels in the message body: every request carries its
3737protocol version and client capabilities in
38[`_meta.io.modelcontextprotocol/*`](/specification/draft/basic/index#meta)
38[`_meta.io.modelcontextprotocol/*`](https://modelcontextprotocol.io/specification/draft/basic/index#meta)
3939fields.
4040
4141A binding **MAY** additionally mirror selected body fields into envelope
4242metadata. The Streamable HTTP transport mirrors them into
43[HTTP headers](/specification/draft/basic/transports/streamable-http.md#request-metadata)
43[HTTP headers](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md#request-metadata)
4444so that intermediaries can route and inspect requests without parsing the
4545body. The body remains the source of truth; bindings that mirror metadata
4646define how mismatches are rejected.
from line 51
5151the client sends a `notifications/cancelled` notification; on Streamable
5252HTTP it closes the request's response stream. The protocol-level rules are
5353the same everywhere; see
54[Cancellation](/specification/draft/basic/patterns/cancellation.md).
54[Cancellation](https://modelcontextprotocol.io/specification/draft/basic/patterns/cancellation.md).
5555
5656## Custom Transports
5757
from line 62
6262
6363Implementers who choose to support custom transports **MUST** preserve the
6464JSON-RPC message format, the
65[message patterns](/specification/draft/basic/patterns.md), and the per-request
65[message patterns](https://modelcontextprotocol.io/specification/draft/basic/patterns.md), and the per-request
6666metadata model. Custom transports **SHOULD** document their connection
6767establishment, message framing, and cancellation patterns to aid
6868interoperability.
from line 69
6969
7070Custom transports that run over a reliable bidirectional byte stream (e.g.,
7171Unix domain sockets or TCP) **SHOULD** reuse the
72[stdio framing](/specification/draft/basic/transports/stdio.md) rather than
72[stdio framing](https://modelcontextprotocol.io/specification/draft/basic/transports/stdio.md) rather than
7373defining a new one: the stdio binding is just newline-delimited JSON-RPC
7474over a byte stream, and only its process-lifecycle rules are specific to
7575standard streams.
from line 80
8080`initialize` handshake and allowed servers to initiate JSON-RPC requests.
8181Clients and servers that interoperate with those revisions detect the
8282counterpart's era and fall back as described in
83[Versioning: Backward Compatibility](/specification/draft/basic/versioning.md#backward-compatibility-with-initialization-based-versions),
83[Versioning: Backward Compatibility](https://modelcontextprotocol.io/specification/draft/basic/versioning.md#backward-compatibility-with-initialization-based-versions),
8484which includes a compatibility matrix for implementors. Each binding page
8585describes its transport-specific detection mechanics.
8686
specification/draft/basic/transports/stdio Changed · +10 / -10 lines
from line 21
2121newline-delimited JSON-RPC message per line over a reliable bidirectional
2222byte stream) works unchanged over Unix domain sockets, TCP connections, or
2323any similar channel.
24[Custom transports](/specification/draft/basic/transports.md#custom-transports)
24[Custom transports](https://modelcontextprotocol.io/specification/draft/basic/transports.md#custom-transports)
2525built on such streams **SHOULD** reuse this framing and the message rules on
2626this page; only the subprocess-specific aspects (launch, `stderr`, shutdown
2727by closing the stream, process restart) need channel-specific equivalents.
from line 53
5353[`InputRequiredResult`][mrtr-input-required] replies; see
5454[Multi Round-Trip Requests][mrtr].
5555
56[mrtr]: /specification/draft/basic/patterns/mrtr.md
56[mrtr]: https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md
5757
58[mrtr-input-required]: /specification/draft/basic/patterns/mrtr.md#inputrequiredresult
58[mrtr-input-required]: https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md#inputrequiredresult
5959
60[subscriptions-listen]: /specification/draft/basic/patterns/subscriptions.md
60[subscriptions-listen]: https://modelcontextprotocol.io/specification/draft/basic/patterns/subscriptions.md
6161
62[subscriptions-listen-request]: /specification/draft/schema.md#subscriptionslistenrequest
62[subscriptions-listen-request]: https://modelcontextprotocol.io/specification/draft/schema.md#subscriptionslistenrequest
6363
6464## Request Metadata
6565
from line 70
7070the method name and arguments live where JSON-RPC puts them. There is no
7171header layer.
7272
73[meta-fields]: /specification/draft/basic/index.md#meta
73[meta-fields]: https://modelcontextprotocol.io/specification/draft/basic/index.md#meta
7474
7575## Cancellation
7676
from line 81
8181practical and **MUST NOT** send any further messages for it. See
8282[Cancellation][cancellation] for the full rules.
8383
84[cancellation]: /specification/draft/basic/patterns/cancellation.md
84[cancellation]: https://modelcontextprotocol.io/specification/draft/basic/patterns/cancellation.md
8585
8686## Shutdown
8787
from line 150
150150See [Versioning: Backward Compatibility][lifecycle-compat] for the era model
151151and a compatibility matrix for implementors.
152152
153[server-discover]: /specification/draft/schema.md#discoverrequest
153[server-discover]: https://modelcontextprotocol.io/specification/draft/schema.md#discoverrequest
154154
155[unsupported-version]: /specification/draft/schema.md#unsupportedprotocolversionerror
155[unsupported-version]: https://modelcontextprotocol.io/specification/draft/schema.md#unsupportedprotocolversionerror
156156
157[lifecycle-compat]: /specification/draft/basic/versioning.md#backward-compatibility-with-initialization-based-versions
157[lifecycle-compat]: https://modelcontextprotocol.io/specification/draft/basic/versioning.md#backward-compatibility-with-initialization-based-versions
158158
specification/draft/basic/transports/streamable-http Changed · +27 / -27 lines
from line 13
1313> * Removal of the GET stream endpoint.
1414> * Removal of protocol-level sessions.
1515>
16> See the [changelog](/specification/draft/changelog.md) and
16> See the [changelog](https://modelcontextprotocol.io/specification/draft/changelog.md) and
1717> [Backward Compatibility](#backward-compatibility) below.
1818
1919In the **Streamable HTTP** transport, the server operates as an independent
from line 40
4040as the **MCP endpoint**) that supports POST. For example, this could be a URL
4141like `https://example.com/mcp`.
4242
43[http-sse]: /specification/2024-11-05/basic/transports.md#http-with-sse
43[http-sse]: https://modelcontextprotocol.io/specification/2024-11-05/basic/transports.md#http-with-sse
4444
4545[sse]: https://en.wikipedia.org/wiki/Server-sent_events
4646
from line 88
8888> This revision of the core protocol defines no client-to-server
8989> *notifications* over Streamable HTTP. The only client-sent notification in
9090> the core protocol, `notifications/cancelled`, is used only on the
91> [stdio](/specification/draft/basic/transports/stdio.md) transport; on
91> [stdio](https://modelcontextprotocol.io/specification/draft/basic/transports/stdio.md) transport; on
9292> Streamable HTTP, closing the SSE response stream is itself the cancellation
9393> signal and no `notifications/cancelled` message is expected (see
9494> \[Cancellation]\[cancellation]). The notification rules above describe the
from line 145
145145
146146Resumable SSE streams via `Last-Event-ID` are not supported.
147147
148[notifications-progress]: /specification/draft/basic/patterns/progress.md
148[notifications-progress]: https://modelcontextprotocol.io/specification/draft/basic/patterns/progress.md
149149
150[notifications-message]: /specification/draft/server/utilities/logging.md
150[notifications-message]: https://modelcontextprotocol.io/specification/draft/server/utilities/logging.md
151151
152[input-required-result]: /specification/draft/schema.md#inputrequiredresult
152[input-required-result]: https://modelcontextprotocol.io/specification/draft/schema.md#inputrequiredresult
153153
154[mrtr]: /specification/draft/basic/patterns/mrtr.md
154[mrtr]: https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md
155155
156[sep-2322]: /seps/2322-MRTR.md
156[sep-2322]: https://modelcontextprotocol.io/seps/2322-MRTR.md
157157
158[subscriptions-listen]: /specification/draft/basic/patterns/subscriptions.md
158[subscriptions-listen]: https://modelcontextprotocol.io/specification/draft/basic/patterns/subscriptions.md
159159
160160## Message Flow
161161
from line 233
233233any further messages for it. See
234234[Cancellation][cancellation] for the full rules.
235235
236[cancellation]: /specification/draft/basic/patterns/cancellation.md
236[cancellation]: https://modelcontextprotocol.io/specification/draft/basic/patterns/cancellation.md
237237
238238## Request Metadata
239239
from line 274
274274server that does not support such clients **MUST** reject a request without
275275the header per [Server Validation](#server-validation).
276276
277[unsupported-version]: /specification/draft/schema.md#unsupportedprotocolversionerror
277[unsupported-version]: https://modelcontextprotocol.io/specification/draft/schema.md#unsupportedprotocolversionerror
278278
279[lifecycle-version]: /specification/draft/basic/versioning.md#protocol-version-negotiation
279[lifecycle-version]: https://modelcontextprotocol.io/specification/draft/basic/versioning.md#protocol-version-negotiation
280280
281281### Standard Request Headers
282282
from line 361
361361`x-mcp-header` annotations, conforming clients **MUST** mirror the
362362designated parameter values into HTTP headers.
363363
364[tool-definitions]: /specification/draft/server/tools.md#x-mcp-header
364[tool-definitions]: https://modelcontextprotocol.io/specification/draft/server/tools.md#x-mcp-header
365365
366366#### Schema Extension
367367
from line 594
594594
595595| Code | Name | Description |
596596| - | - | - |
597| `-32020` | [`HeaderMismatch`](/specification/draft/schema#headermismatcherror) | The HTTP headers do not match the corresponding values in the request body, or required headers are missing/malformed. |
597| `-32020` | [`HeaderMismatch`](https://modelcontextprotocol.io/specification/draft/schema#headermismatcherror) | The HTTP headers do not match the corresponding values in the request body, or required headers are missing/malformed. |
598598
599599This error code is allocated from the sub-range the MCP specification
600600reserves for protocol-defined errors. See
601[Error Codes](/specification/draft/basic/index.md#error-codes).
601[Error Codes](https://modelcontextprotocol.io/specification/draft/basic/index.md#error-codes).
602602
603603**Example error response:**
604604
from line 659
659659
660660### Earlier Streamable HTTP Revisions
661661
662Protocol versions `2025-03-26` through [`2025-11-25`](/specification/2025-11-25/basic/transports)
662Protocol versions `2025-03-26` through [`2025-11-25`](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports)
663663also used the Streamable HTTP transport, but in a different shape: servers could assign a session via
664664the `Mcp-Session-Id` header (terminated with HTTP DELETE), clients could open
665665a standalone SSE stream with HTTP GET to receive server-initiated messages,
from line 679
679679Servers and clients that need to interoperate with counterparts speaking
680680those protocol versions implement the behavior described in the corresponding
681681revision (for example,
682[2025-11-25: Streamable HTTP](/specification/2025-11-25/basic/transports.md#streamable-http)),
682[2025-11-25: Streamable HTTP](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports.md#streamable-http)),
683683in addition to the version-negotiation fallback described above.
684684
685685### HTTP+SSE Transport (2024-11-05)
from line 689
689689> **Deprecated**: The \[HTTP+SSE transport]\[http-sse] from protocol version
690690> 2024-11-05 has been deprecated since protocol version `2025-03-26` and is
691691> classified as Deprecated under the [feature lifecycle
692> policy](/community/feature-lifecycle.md#deprecating-a-feature)
692> policy](https://modelcontextprotocol.io/community/feature-lifecycle.md#deprecating-a-feature)
693693> ([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596)).
694694> New implementations **SHOULD NOT** adopt it; existing implementations
695695> **SHOULD** migrate to [Streamable
696> HTTP](/specification/draft/basic/transports/streamable-http.md). It is eligible
696> HTTP](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md). It is eligible
697697> for removal in a future revision; see the [deprecated features
698> registry](/specification/draft/deprecated.md).
698> registry](https://modelcontextprotocol.io/specification/draft/deprecated.md).
699699
700700Clients and servers can maintain backward compatibility with the
701701deprecated [HTTP+SSE transport][http-sse] (from
from line 726
726726 server running the old HTTP+SSE transport, and should use that
727727 transport for all subsequent communication.
728728
729[lifecycle-compat]: /specification/draft/basic/versioning.md#backward-compatibility-with-initialization-based-versions
729[lifecycle-compat]: https://modelcontextprotocol.io/specification/draft/basic/versioning.md#backward-compatibility-with-initialization-based-versions
730730
specification/draft/basic/versioning Changed · +12 / -12 lines
from line 37
3737## Protocol Version Negotiation
3838
3939Every request declares the protocol version it is using in its
40[`_meta`](/specification/draft/basic/index#meta) field. On HTTP, this is
40[`_meta`](https://modelcontextprotocol.io/specification/draft/basic/index#meta) field. On HTTP, this is
4141also carried in the
42[`MCP-Protocol-Version` header](/specification/draft/basic/transports/streamable-http#protocol-version-header).
42[`MCP-Protocol-Version` header](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http#protocol-version-header).
4343
4444If the server does not implement the requested version (whether the version
4545is unknown to the server, or is a known version the server has chosen not to
4646support), it **MUST** respond with an
47[`UnsupportedProtocolVersionError`](/specification/draft/schema#unsupportedprotocolversionerror)
47[`UnsupportedProtocolVersionError`](https://modelcontextprotocol.io/specification/draft/schema#unsupportedprotocolversionerror)
4848listing the versions it does support:
4949
5050```json theme={null}
from line 67
6767version exists.
6868
6969Servers **MUST** implement
70[`server/discover`](/specification/draft/server/discover). Clients
70[`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover). Clients
7171**MAY** call it before sending any other requests to learn the server's
7272supported versions up front, but are not required to: a client is free to
7373invoke any RPC inline and handle `UnsupportedProtocolVersionError` if its
from line 76
7676## Extension Negotiation
7777
7878Clients and servers can negotiate support for optional
79[extensions](/docs/extensions/overview.md) beyond the core protocol. Extensions
79[extensions](https://modelcontextprotocol.io/docs/extensions/overview.md) beyond the core protocol. Extensions
8080are advertised in the `extensions` field of capabilities, which is a map of
8181extension identifiers to per-extension settings objects. Extension identifiers
82**MUST** follow the [`_meta` key naming rules](/specification/draft/basic/index#meta),
82**MUST** follow the [`_meta` key naming rules](https://modelcontextprotocol.io/specification/draft/basic/index#meta),
8383with a mandatory prefix.
8484
8585The following is an example of a client that advertises the
86[MCP Apps extension](/extensions/apps/overview.md) identified as `io.modelcontextprotocol/ui`:
86[MCP Apps extension](https://modelcontextprotocol.io/extensions/apps/overview.md) identified as `io.modelcontextprotocol/ui`:
8787
8888```json theme={null}
8989{
from line 98
9898}
9999```
100100
101An example of [Tasks extension](/extensions/tasks/overview.md) identified as `io.modelcontextprotocol/tasks`:
101An example of [Tasks extension](https://modelcontextprotocol.io/extensions/tasks/overview.md) identified as `io.modelcontextprotocol/tasks`:
102102
103103```json theme={null}
104104{
from line 129
129129server's era with transport-specific mechanics, specified in the binding
130130pages:
131131
132* [stdio](/specification/draft/basic/transports/stdio.md#backward-compatibility):
132* [stdio](https://modelcontextprotocol.io/specification/draft/basic/transports/stdio.md#backward-compatibility):
133133 probe with `server/discover` and fall back on any error that is not a
134134 recognized modern error.
135* [Streamable HTTP](/specification/draft/basic/transports/streamable-http.md#backward-compatibility):
135* [Streamable HTTP](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md#backward-compatibility):
136136 attempt a modern request and inspect the body of a `400 Bad Request`
137137 before falling back.
138138
139139In both cases, a recognized modern JSON-RPC error (such as
140[`UnsupportedProtocolVersionError`](/specification/draft/schema#unsupportedprotocolversionerror))
140[`UnsupportedProtocolVersionError`](https://modelcontextprotocol.io/specification/draft/schema#unsupportedprotocolversionerror))
141141identifies a modern server: the client retries with a supported version
142142rather than falling back. Anything else identifies a legacy server.
143143
from line 163
163163| Modern | Legacy | Fails. The server may reject the request with an implementation-defined error, stay silent, or even process an era-ambiguous method under legacy semantics. On stdio, clients **SHOULD** send `server/discover` first to fail deterministically; the client then surfaces an actionable error to the user. |
164164| Dual-era | Modern | Works. The stdio probe returns a `DiscoverResult` (or `UnsupportedProtocolVersionError`); on HTTP, the first modern request succeeds or returns a modern error. The client stays modern. |
165165| Dual-era | Legacy | Works. stdio: the probe returns a non-modern error or times out, and the client falls back to `initialize`. HTTP: the modern request returns a `4xx` without a recognized modern error body, and the client falls back to `initialize` (and possibly further to the deprecated HTTP+SSE transport). |
166| Legacy | Modern | Fails. stdio: the server rejects `initialize` with a JSON-RPC error; the exact code is implementation-defined (`initialize` is an unknown method and the request also lacks the required `_meta` fields). HTTP: the request is missing the required headers and is rejected per [server validation](/specification/draft/basic/transports/streamable-http.md#server-validation) with `400 Bad Request` (a client on the deprecated HTTP+SSE transport fails at its opening `GET` instead). Legacy clients have no fall-forward mechanism. |
166| Legacy | Modern | Fails. stdio: the server rejects `initialize` with a JSON-RPC error; the exact code is implementation-defined (`initialize` is an unknown method and the request also lacks the required `_meta` fields). HTTP: the request is missing the required headers and is rejected per [server validation](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md#server-validation) with `400 Bad Request` (a client on the deprecated HTTP+SSE transport fails at its opening `GET` instead). Legacy clients have no fall-forward mechanism. |
167167| Legacy | Dual-era | Works. The server answers `initialize` and serves the client according to the negotiated legacy revision. |
168168| Legacy | Legacy | Works according to the legacy revision; out of scope for this document. |
169169
specification/draft/client/elicitation Changed · +14 / -14 lines
from line 78
7878
7979### Elicitation Requests
8080
81Servers **MAY** request information from a user during the processing of a client request, by sending an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult)
81Servers **MAY** request information from a user during the processing of a client request, by sending an [`InputRequiredResult`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequiredresult)
8282containing an `elicitation/create` request.
8383
8484All elicitation requests **MUST** include the following parameters:
from line 234
234234
235235#### Example: Simple Text Request
236236
237**Input request (delivered inside [`InputRequiredResult.inputRequests`](/specification/draft/basic/patterns/mrtr#inputrequests)):**
237**Input request (delivered inside [`InputRequiredResult.inputRequests`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequests)):**
238238
239239```json theme={null}
240240{
from line 333
333333>
334334> **Important**: URL mode elicitation is *not* for authorizing the MCP client's
335335> access to the MCP server (that's handled by [MCP
336> authorization](/specification/draft/basic/authorization.md)). Instead, it's used when the MCP
336> authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization.md)). Instead, it's used when the MCP
337337> server needs to obtain sensitive information or third-party authorization on
338338> behalf of the user. The MCP client's bearer token remains unchanged. The
339339> client's only responsibility is to provide the user with context about the
from line 462
462462
463463### Statefulness
464464
465Elicitations do not require that the server maintain state about users with the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism.
465Elicitations do not require that the server maintain state about users with the [multi round-trip requests](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism.
466466
467However, if state is stored, servers implementing elicitation **MUST** securely associate this state with individual users following the guidelines in the [security best practices](/docs/draft/tutorials/security/security_best_practices.md) document. Specifically:
467However, if state is stored, servers implementing elicitation **MUST** securely associate this state with individual users following the guidelines in the [security best practices](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices.md) document. Specifically:
468468
469469* State storage **MUST** be protected against unauthorized access
470* For remote MCP servers, user identification **MUST** be derived from credentials acquired via [MCP authorization](/specification/draft/basic/authorization.md) when possible (e.g. `sub` claim)
470* For remote MCP servers, user identification **MUST** be derived from credentials acquired via [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization.md) when possible (e.g. `sub` claim)
471471
472472> [!NOTE]
473473>
from line 492
492492### URL Mode Elicitation for OAuth Flows
493493
494494URL mode elicitation enables a pattern where MCP servers act as OAuth clients to third-party resource servers.
495Authorization with external APIs enabled by URL mode elicitation is separate from [MCP authorization](/specification/draft/basic/authorization.md). MCP servers **MUST NOT** rely on URL mode elicitation to authorize users for themselves.
495Authorization with external APIs enabled by URL mode elicitation is separate from [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization.md). MCP servers **MUST NOT** rely on URL mode elicitation to authorize users for themselves.
496496
497497#### Understanding the Distinction
498498
499* **MCP Authorization**: Required OAuth flow between the MCP client and MCP server (covered in the [authorization specification](/specification/draft/basic/authorization.md))
499* **MCP Authorization**: Required OAuth flow between the MCP client and MCP server (covered in the [authorization specification](https://modelcontextprotocol.io/specification/draft/basic/authorization.md))
500500* **External (third-party) Authorization**: Optional authorization between the MCP server and a third-party resource server, initiated via URL mode elicitation
501501
502502In external authorization, the server acts as both:
from line 513
513513The critical security requirements are:
514514
5155151. **The third-party credentials MUST NOT transit through the MCP client**: The client must never see third-party credentials to protect the security boundary
5162. **The MCP server MUST NOT use the client's credentials for the third-party service**: That would be [token passthrough](/docs/draft/tutorials/security/security_best_practices.md#token-passthrough), which is forbidden
5162. **The MCP server MUST NOT use the client's credentials for the third-party service**: That would be [token passthrough](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices.md#token-passthrough), which is forbidden
5175173. **The user MUST authorize the MCP server directly**: The interaction happens outside the MCP protocol, without involving the MCP client
5185184. **The MCP server is responsible for tokens**: The MCP server is responsible for storing and managing the third-party tokens obtained through the URL mode elicitation (in other words, the MCP server must be stateful).
519519
from line 522
522522> [!NOTE]
523523>
524524> For additional background, refer to the [token passthrough
525> section](/docs/draft/tutorials/security/security_best_practices.md#token-passthrough)
525> section](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices.md#token-passthrough)
526526> of the Security Best Practices document to understand why MCP servers cannot
527527> act as pass-through proxies.
528528
from line 617
617617### Identifying the User
618618
619619Servers **MUST NOT** rely on client-provided user identification without server verification, as this can be forged.
620Instead, servers **SHOULD** follow [security best practices](/docs/draft/tutorials/security/security_best_practices.md).
620Instead, servers **SHOULD** follow [security best practices](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices.md).
621621
622622Non-normative examples:
623623
624624* Incorrect: Treat user input like "I am [[email protected]](mailto:[email protected])" as authoritative
625* Correct: Rely on [authorization](/specification/draft/basic/authorization.md) to identify the user
625* Correct: Rely on [authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization.md) to identify the user
626626
627627### Form Mode Security
628628
from line 634
634634
635635URL mode elicitation returns a URL that an attacker can use to send to a victim. The MCP Server **MUST** verify the identity of the user who opens the URL before accepting information.
636636
637Typically identity verification is done by leveraging the [MCP authorization server](/specification/draft/basic/authorization.md) to identify the user, through a session cookie or equivalent in the browser.
637Typically identity verification is done by leveraging the [MCP authorization server](https://modelcontextprotocol.io/specification/draft/basic/authorization.md) to identify the user, through a session cookie or equivalent in the browser.
638638
639639For example, URL mode elicitation may be used to perform OAuth flows where the server acts as an OAuth client of another resource server. Without proper mitigation, the following phishing attack is possible:
640640
specification/draft/client/roots Changed · +3 / -3 lines
from line 5
55> **Deprecated**: The Roots feature is deprecated as of protocol version
66> `2026-07-28`
77> ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)).
8> Under the [feature lifecycle policy](/community/feature-lifecycle.md), it remains
8> Under the [feature lifecycle policy](https://modelcontextprotocol.io/community/feature-lifecycle.md), it remains
99> in the specification for at least twelve months after this revision's release
1010> before it becomes eligible for removal. New implementations **SHOULD NOT**
1111> adopt it; existing implementations **SHOULD** migrate to passing directories
1212> or files via tool parameters, resource URIs, or server configuration. See the
13> [deprecated features registry](/specification/draft/deprecated.md).
13> [deprecated features registry](https://modelcontextprotocol.io/specification/draft/deprecated.md).
1414
1515The Model Context Protocol (MCP) provides a standardized way for clients to expose
1616filesystem "roots" to servers. Roots inform servers about the directories and files the
from line 53
5353To retrieve roots during the processing of a client request, servers send an `InputRequiredResult`
5454containing a `roots/list` request:
5555
56**Input request (delivered inside [`InputRequiredResult.inputRequests`](/specification/draft/basic/patterns/mrtr#inputrequests)):**
56**Input request (delivered inside [`InputRequiredResult.inputRequests`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequests)):**
5757
5858```json theme={null}
5959{
specification/draft/client/sampling Changed · +5 / -5 lines
from line 5
55> **Deprecated**: The Sampling feature is deprecated as of protocol version
66> `2026-07-28`
77> ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)).
8> Under the [feature lifecycle policy](/community/feature-lifecycle.md), it remains
8> Under the [feature lifecycle policy](https://modelcontextprotocol.io/community/feature-lifecycle.md), it remains
99> in the specification for at least twelve months after this revision's release
1010> before it becomes eligible for removal. New implementations **SHOULD NOT**
1111> adopt it; existing implementations **SHOULD** migrate to integrating directly
1212> with LLM provider APIs. See the [deprecated features
13> registry](/specification/draft/deprecated.md).
13> registry](https://modelcontextprotocol.io/specification/draft/deprecated.md).
1414
1515The Model Context Protocol (MCP) provides a standardized way for servers to request LLM
1616sampling ("completions" or "generations") from language models via clients. This flow
from line 94
9494>
9595> The `includeContext` parameter values `"thisServer"` and `"allServers"` are
9696> deprecated under the [feature lifecycle
97> policy](/community/feature-lifecycle.md#deprecating-a-feature)
97> policy](https://modelcontextprotocol.io/community/feature-lifecycle.md#deprecating-a-feature)
9898> ([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596));
9999> they will be removed no later than the Sampling feature itself. Servers
100100> **SHOULD** avoid using these values (e.g. can just omit `includeContext` since
101101> it defaults to `"none"`), and **SHOULD NOT** use them unless the client
102102> declares `sampling.context` capability. See the [deprecated features
103> registry](/specification/draft/deprecated.md).
103> registry](https://modelcontextprotocol.io/specification/draft/deprecated.md).
104104
105105## Protocol Messages
106106
from line 108
108108
109109To request a language model generation during the processing of a client request, servers send an `InputRequiredResult` containing a `sampling/createMessage` request:
110110
111**Input request (delivered inside [`InputRequiredResult.inputRequests`](/specification/draft/basic/patterns/mrtr#inputrequests)):**
111**Input request (delivered inside [`InputRequiredResult.inputRequests`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequests)):**
112112
113113```json theme={null}
114114{
specification/draft/deprecated Changed · +8 / -8 lines
from line 2
22
33This page is the registry of specification features that are currently in the
44**Deprecated** state under the
5[feature lifecycle and deprecation policy](/community/feature-lifecycle.md)
5[feature lifecycle and deprecation policy](https://modelcontextprotocol.io/community/feature-lifecycle.md)
66([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596)).
77
88A Deprecated feature remains part of the specification but is scheduled for
from line 19
1919
2020| Feature | Deprecation SEP | Deprecated in | Migration path | Earliest removal |
2121| - | - | - | - | - |
22| [Roots](/specification/draft/client/roots.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Pass directories or files via tool parameters, resource URIs, or server configuration | First revision released on or after 2027-07-28 |
23| [Sampling](/specification/draft/client/sampling.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Integrate directly with LLM provider APIs | First revision released on or after 2027-07-28 |
24| [Logging](/specification/draft/server/utilities/logging.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Log to `stderr` for stdio transports; use [OpenTelemetry](https://opentelemetry.io/) for observability | First revision released on or after 2027-07-28 |
25| [Dynamic Client Registration](/specification/draft/basic/authorization/client-registration.md#dynamic-client-registration) | [PR #2858](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2858) | `2026-07-28` | [Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents) | First revision released on or after 2027-07-28 |
26| `includeContext: "thisServer"` / `"allServers"` ([Sampling](/specification/draft/client/sampling.md#capabilities)) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-11-25` | Omit the field or use `"none"` | Follows Sampling ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)) |
27| [HTTP+SSE transport](/specification/2024-11-05/basic/transports.md#http-with-sse) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-03-26` | [Streamable HTTP](/specification/draft/basic/transports/streamable-http.md) | Three months after SEP-2596 reaches Final |
22| [Roots](https://modelcontextprotocol.io/specification/draft/client/roots.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Pass directories or files via tool parameters, resource URIs, or server configuration | First revision released on or after 2027-07-28 |
23| [Sampling](https://modelcontextprotocol.io/specification/draft/client/sampling.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Integrate directly with LLM provider APIs | First revision released on or after 2027-07-28 |
24| [Logging](https://modelcontextprotocol.io/specification/draft/server/utilities/logging.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Log to `stderr` for stdio transports; use [OpenTelemetry](https://opentelemetry.io/) for observability | First revision released on or after 2027-07-28 |
25| [Dynamic Client Registration](https://modelcontextprotocol.io/specification/draft/basic/authorization/client-registration.md#dynamic-client-registration) | [PR #2858](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2858) | `2026-07-28` | [Client ID Metadata Documents](https://modelcontextprotocol.io/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents) | First revision released on or after 2027-07-28 |
26| `includeContext: "thisServer"` / `"allServers"` ([Sampling](https://modelcontextprotocol.io/specification/draft/client/sampling.md#capabilities)) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-11-25` | Omit the field or use `"none"` | Follows Sampling ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)) |
27| [HTTP+SSE transport](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports.md#http-with-sse) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-03-26` | [Streamable HTTP](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md) | Three months after SEP-2596 reaches Final |
2828
2929The HTTP+SSE transport and the `includeContext` values were already described
3030as deprecated before the lifecycle policy existed; SEP-2596 reclassifies them
31as Deprecated under its [transition provisions](/community/feature-lifecycle.md).
31as Deprecated under its [transition provisions](https://modelcontextprotocol.io/community/feature-lifecycle.md).
3232
3333## Removed
3434
specification/draft/index Changed · +9 / -9 lines
from line 70
7070
7171### Extensions
7272
73Beyond the core protocol, MCP defines optional [extensions](/extensions/overview.md)
73Beyond the core protocol, MCP defines optional [extensions](https://modelcontextprotocol.io/extensions/overview.md)
7474that add modular, specialized, or experimental functionality. Extensions
7575are always opt-in and require explicit support from both client and server, negotiated
7676during initialization. Notable extensions include:
7777
78* **[Tasks](/extensions/tasks/overview.md)**: Asynchronous execution of long-running
78* **[Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md)**: Asynchronous execution of long-running
7979 operations, with polling, mid-flight input, and durable handles
80* **[Skills over MCP](/community/working-groups/skills-over-mcp.md)**: Rich, structured
80* **[Skills over MCP](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md)**: Rich, structured
8181 instructions for agent workflows, discovered and consumed through MCP
82* **[MCP Apps](/extensions/apps/overview.md)**: Interactive UI elements (charts, forms,
82* **[MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md)**: Interactive UI elements (charts, forms,
8383 video players) rendered inline within conversations
8484
8585## Security and Trust & Safety
from line 123
123123
124124Explore the detailed specification for each protocol component:
125125
126> **[Architecture](/specification/draft/architecture.md)**
126> **[Architecture](https://modelcontextprotocol.io/specification/draft/architecture.md)**
127127
128> **[Base Protocol](/specification/draft/basic.md)**
128> **[Base Protocol](https://modelcontextprotocol.io/specification/draft/basic.md)**
129129
130> **[Server Features](/specification/draft/server.md)**
130> **[Server Features](https://modelcontextprotocol.io/specification/draft/server.md)**
131131
132> **[Client Features](/specification/draft/client)**
132> **[Client Features](https://modelcontextprotocol.io/specification/draft/client)**
133133
134> **[Contributing](/community/contributing.md)**
134> **[Contributing](https://modelcontextprotocol.io/community/contributing.md)**
135135
specification/draft/server/discover Changed · +5 / -5 lines
from line 29
2929## Response
3030
3131The server replies with its supported protocol versions, capabilities, and
32identity. This operation supports [caching](/specification/draft/server/utilities/caching.md).
32identity. This operation supports [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
3333
3434```json theme={null}
3535{
from line 59
5959
6060Calling `server/discover` is optional for clients — a client may invoke any
6161RPC inline and handle
62[`UnsupportedProtocolVersionError`](/specification/draft/schema#unsupportedprotocolversionerror)
62[`UnsupportedProtocolVersionError`](https://modelcontextprotocol.io/specification/draft/schema#unsupportedprotocolversionerror)
6363if the server does not support the requested version. However, `server/discover`
6464is useful in two scenarios:
6565
from line 73
7373 HTTP status code to drive fallback. A client that supports both modern
7474 (per-request `_meta`) and legacy (`initialize` handshake) servers **SHOULD**
7575 send `server/discover` first; see
76 [stdio: Backward Compatibility](/specification/draft/basic/transports/stdio.md#backward-compatibility)
76 [stdio: Backward Compatibility](https://modelcontextprotocol.io/specification/draft/basic/transports/stdio.md#backward-compatibility)
7777 for the fallback rules.
7878
79See [Protocol Version Negotiation](/specification/draft/basic/versioning.md#protocol-version-negotiation)
79See [Protocol Version Negotiation](https://modelcontextprotocol.io/specification/draft/basic/versioning.md#protocol-version-negotiation)
8080for the full version-selection flow. For HTTP-specific status codes returned for
81unknown methods, see the [Protocol Version Header](/specification/draft/basic/transports/streamable-http.md#protocol-version-header)
81unknown methods, see the [Protocol Version Header](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md#protocol-version-header)
8282section in Transports.
8383
8484## Data Types
specification/draft/server/index Changed · +3 / -3 lines
from line 20
2020
2121Explore these key primitives in more detail below:
2222
23> **[Prompts](/specification/draft/server/prompts.md)**
23> **[Prompts](https://modelcontextprotocol.io/specification/draft/server/prompts.md)**
2424
25> **[Resources](/specification/draft/server/resources.md)**
25> **[Resources](https://modelcontextprotocol.io/specification/draft/server/resources.md)**
2626
27> **[Tools](/specification/draft/server/tools.md)**
27> **[Tools](https://modelcontextprotocol.io/specification/draft/server/tools.md)**
2828
specification/draft/server/prompts Changed · +9 / -9 lines
from line 12
1212> `io.modelcontextprotocol/clientInfo`, and
1313> `io.modelcontextprotocol/clientCapabilities`). Every request **MUST** include
1414> the required `_meta` fields; see
15> [`_meta`](/specification/draft/basic/index#meta).
15> [`_meta`](https://modelcontextprotocol.io/specification/draft/basic/index#meta).
1616
1717## User Interaction Model
1818
from line 35
3535## Capabilities
3636
3737Servers that support prompts **MUST** declare the `prompts` capability in their
38[`DiscoverResult`](/specification/draft/schema#discoverresult):
38[`DiscoverResult`](https://modelcontextprotocol.io/specification/draft/schema#discoverresult):
3939
4040```json theme={null}
4141{
from line 64
6464### Listing Prompts
6565
6666To retrieve available prompts, clients send a `prompts/list` request. This operation
67supports [pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
67supports [pagination](https://modelcontextprotocol.io/specification/draft/server/utilities/pagination.md) and [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
6868
6969**Request:**
7070
from line 118
118118### Getting a Prompt
119119
120120To retrieve a specific prompt, clients send a `prompts/get` request. Arguments may be
121auto-completed through [the completion API](/specification/draft/server/utilities/completion.md).
121auto-completed through [the completion API](https://modelcontextprotocol.io/specification/draft/server/utilities/completion.md).
122122
123123**Request:**
124124
from line 158
158158}
159159```
160160
161Servers **MAY** also respond to `prompts/get` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the prompt can be resolved. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
161Servers **MAY** also respond to `prompts/get` with an [`InputRequiredResult`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the prompt can be resolved. This follows the [multi round-trip requests](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
162162
163163### List Changed Notification
164164
165165When the list of available prompts changes, servers that declared the `listChanged`
166166capability **SHOULD** send a notification to clients that have opened a
167[`subscriptions/listen`](/specification/draft/basic/patterns/subscriptions) stream with
167[`subscriptions/listen`](https://modelcontextprotocol.io/specification/draft/basic/patterns/subscriptions) stream with
168168`promptsListChanged: true`:
169169
170170```json theme={null}
from line 221
221221> [!NOTE]
222222>
223223> All content types in prompt messages support optional
224> [annotations](/specification/draft/server/resources.md#annotations) for metadata
224> [annotations](https://modelcontextprotocol.io/specification/draft/server/resources.md#annotations) for metadata
225225> about audience, priority, and modification times.
226226
227227#### Text Content
from line 270
270270#### Resource Links
271271
272272Prompt messages **MAY** include links to
273[Resources](/specification/draft/server/resources.md), to provide additional context or
273[Resources](https://modelcontextprotocol.io/specification/draft/server/resources.md), to provide additional context or
274274data without embedding the resource contents directly. In this case, the prompt message
275275returns a URI that can be fetched by the client:
276276
from line 284
284284}
285285```
286286
287Resource links support the same [Resource annotations](/specification/draft/server/resources.md#annotations)
287Resource links support the same [Resource annotations](https://modelcontextprotocol.io/specification/draft/server/resources.md#annotations)
288288as regular resources to help clients understand how to use them.
289289
290290#### Embedded Resources
specification/draft/server/resources Changed · +9 / -9 lines
from line 13
1313> `io.modelcontextprotocol/clientInfo`, and
1414> `io.modelcontextprotocol/clientCapabilities`). Every request **MUST** include
1515> the required `_meta` fields; see
16> [`_meta`](/specification/draft/basic/index#meta).
16> [`_meta`](https://modelcontextprotocol.io/specification/draft/basic/index#meta).
1717
1818## User Interaction Model
1919
from line 81
8181### Listing Resources
8282
8383To discover available resources, clients send a `resources/list` request. This operation
84supports [pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
84supports [pagination](https://modelcontextprotocol.io/specification/draft/server/utilities/pagination.md) and [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
8585
8686**Request:**
8787
from line 130
130130### Reading Resources
131131
132132To retrieve resource contents, clients send a `resources/read` request. This operation
133supports [caching](/specification/draft/server/utilities/caching.md).
133supports [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
134134
135135**Request:**
136136
from line 170
170170`resources/read` request. For example, a server could return the contents of
171171several files when a directory resource is read.
172172
173Servers **MAY** also respond to `resources/read` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the resource can be read. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
173Servers **MAY** also respond to `resources/read` with an [`InputRequiredResult`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the resource can be read. This follows the [multi round-trip requests](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
174174
175175Alternatively, if the scheme of `uri` is `https://`, clients may fetch the resource directly from the web. See the [Common URI Schemes section](#https%3A%2F%2F) for more information.
176176
from line 178
178178
179179Resource templates allow servers to expose parameterized resources using
180180[URI templates](https://datatracker.ietf.org/doc/html/rfc6570). Arguments may be
181auto-completed through [the completion API](/specification/draft/server/utilities/completion.md).
182This operation supports [pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
181auto-completed through [the completion API](https://modelcontextprotocol.io/specification/draft/server/utilities/completion.md).
182This operation supports [pagination](https://modelcontextprotocol.io/specification/draft/server/utilities/pagination.md) and [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
183183
184184**Request:**
185185
from line 259
259259See [Subscriptions][subscriptions] for the full protocol mechanics (acknowledgment,
260260`subscriptionId` correlation, and cancellation).
261261
262[subscriptions-listen]: /specification/draft/schema.md#subscriptionslistenrequest
262[subscriptions-listen]: https://modelcontextprotocol.io/specification/draft/schema.md#subscriptionslistenrequest
263263
264[subscriptions]: /specification/draft/basic/patterns/subscriptions.md
264[subscriptions]: https://modelcontextprotocol.io/specification/draft/basic/patterns/subscriptions.md
265265
266266## Message Flow
267267
specification/draft/server/tools Changed · +16 / -16 lines
from line 12
1212> `io.modelcontextprotocol/clientInfo`, and
1313> `io.modelcontextprotocol/clientCapabilities`). Every request **MUST** include
1414> the required `_meta` fields; see
15> [`_meta`](/specification/draft/basic/index#meta).
15> [`_meta`](https://modelcontextprotocol.io/specification/draft/basic/index#meta).
1616
1717## User Interaction Model
1818
from line 72
7272### Listing Tools
7373
7474To discover available tools, clients send a `tools/list` request. This operation supports
75[pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
75[pagination](https://modelcontextprotocol.io/specification/draft/server/utilities/pagination.md) and [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
7676
7777**Request:**
7878
from line 167
167167
168168### Input Required Tool Results
169169
170Servers **MAY** respond to `tools/call` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the tool call can be completed. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism.
170Servers **MAY** respond to `tools/call` with an [`InputRequiredResult`](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the tool call can be completed. This follows the [multi round-trip requests](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism.
171171
172172When retrying the request with input responses, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters:
173173
from line 231
231231
232232When the list of available tools changes, servers that declared the `listChanged`
233233capability **SHOULD** send a notification to clients that have opened a
234[`subscriptions/listen`](/specification/draft/basic/patterns/subscriptions) stream with
234[`subscriptions/listen`](https://modelcontextprotocol.io/specification/draft/basic/patterns/subscriptions) stream with
235235`toolsListChanged: true`:
236236
237237```json theme={null}
from line 282
282282* `description`: Human-readable description of functionality
283283* `icons`: Optional array of icons for display in user interfaces
284284* `inputSchema`: JSON Schema defining expected parameters
285 * Follows the [JSON Schema usage guidelines](/specification/draft/basic.md#json-schema-usage)
285 * Follows the [JSON Schema usage guidelines](https://modelcontextprotocol.io/specification/draft/basic.md#json-schema-usage)
286286 * Defaults to 2020-12 if no `$schema` field is present
287287 * **MUST** be a valid JSON Schema object (not `null`)
288288 * For tools with no parameters, use one of these valid approaches:
from line 291
291291 * Properties **MAY** include an [`x-mcp-header`](#x-mcp-header) annotation to expose
292292 parameter values as HTTP headers
293293* `outputSchema`: Optional JSON Schema defining expected output structure
294 * Follows the [JSON Schema usage guidelines](/specification/draft/basic.md#json-schema-usage)
294 * Follows the [JSON Schema usage guidelines](https://modelcontextprotocol.io/specification/draft/basic.md#json-schema-usage)
295295 * Defaults to 2020-12 if no `$schema` field is present
296296* `annotations`: Optional properties describing tool behavior
297297
from line 327
327327
328328The `x-mcp-header` extension property allows servers to designate specific tool
329329parameters to be mirrored into HTTP headers when using the
330[Streamable HTTP transport](/specification/draft/basic/transports/streamable-http.md#custom-headers-from-tool-parameters).
330[Streamable HTTP transport](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md#custom-headers-from-tool-parameters).
331331This enables network intermediaries (load balancers, proxies, WAFs) to route and process
332332requests based on parameter values without parsing the request body.
333333
from line 348
348348 safe range for integers represented using IEEE754 double-precision floating point numbers (−2<sup>53</sup>+1 to 2<sup>53</sup>−1)
349349* **MUST** only be applied to properties that are *statically reachable* from the schema
350350 root, as defined in
351 [Custom Headers from Tool Parameters](/specification/draft/basic/transports/streamable-http.md#custom-headers-from-tool-parameters),
351 [Custom Headers from Tool Parameters](https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http.md#custom-headers-from-tool-parameters),
352352 which also defines how header values are extracted from call arguments
353353
354354Clients using the Streamable HTTP transport **MUST** reject tool definitions where any
from line 401
401401>
402402> All content types (text, image, audio, resource links, and embedded resources)
403403> support optional
404> [annotations](/specification/draft/server/resources.md#annotations) that provide
404> [annotations](https://modelcontextprotocol.io/specification/draft/server/resources.md#annotations) that provide
405405> metadata about audience, priority, and modification times. This is the same
406406> annotation format used by resources and prompts.
407407
from line 440
440440
441441#### Resource Links
442442
443A tool **MAY** return links to [Resources](/specification/draft/server/resources.md), to provide additional context
443A tool **MAY** return links to [Resources](https://modelcontextprotocol.io/specification/draft/server/resources.md), to provide additional context
444444or data. In this case, the tool will return a URI that can be subscribed to or fetched by the client:
445445
446446```json theme={null}
from line 453
453453}
454454```
455455
456Resource links support the same [Resource annotations](/specification/draft/server/resources.md#annotations) as regular resources to help clients understand how to use them.
456Resource links support the same [Resource annotations](https://modelcontextprotocol.io/specification/draft/server/resources.md#annotations) as regular resources to help clients understand how to use them.
457457
458458> [!NOTE]
459459>
from line 462
462462
463463#### Embedded Resources
464464
465[Resources](/specification/draft/server/resources.md) **MAY** be embedded to provide additional context
466or data using a suitable [URI scheme](/specification/draft/server/resources.md#common-uri-schemes). Servers that use embedded resources **SHOULD** implement the `resources` capability:
465[Resources](https://modelcontextprotocol.io/specification/draft/server/resources.md) **MAY** be embedded to provide additional context
466or data using a suitable [URI scheme](https://modelcontextprotocol.io/specification/draft/server/resources.md#common-uri-schemes). Servers that use embedded resources **SHOULD** implement the `resources` capability:
467467
468468```json theme={null}
469469{
from line 481
481481}
482482```
483483
484Embedded resources support the same [Resource annotations](/specification/draft/server/resources.md#annotations) as regular resources to help clients understand how to use them.
484Embedded resources support the same [Resource annotations](https://modelcontextprotocol.io/specification/draft/server/resources.md#annotations) as regular resources to help clients understand how to use them.
485485
486486#### Structured Content
487487
from line 728
7287281. **Protocol Errors** indicate issues with the request structure itself that models are less likely to be able to fix:
729729
730730 * Unknown tool
731 * Malformed requests (requests that fail to satisfy [CallToolRequest schema](/specification/draft/schema.md#calltoolrequest))
731 * Malformed requests (requests that fail to satisfy [CallToolRequest schema](https://modelcontextprotocol.io/specification/draft/schema.md#calltoolrequest))
732732 * Server errors
733733
734734 They are returned as standard JSON-RPC errors:
from line 785
785785 * Show tool inputs to the user before calling the server, to avoid malicious or
786786 accidental data exfiltration
787787 * Validate tool results before passing to LLM
788 * Follow the [`$ref` resolution requirements](/specification/draft/basic/index#ref-resolution)
788 * Follow the [`$ref` resolution requirements](https://modelcontextprotocol.io/specification/draft/basic/index#ref-resolution)
789789 when validating tool inputs and outputs against `inputSchema` and `outputSchema`
790790 * Implement timeouts for tool calls
791791 * Log tool usage for audit purposes
specification/draft/server/utilities/caching Changed · +3 / -3 lines
from line 17
1717* `resources/read`
1818
1919Interim results with `resultType: "input_required"` (see
20[multi round-trip requests](/specification/draft/basic/patterns/mrtr.md)) are not cacheable
20[multi round-trip requests](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md)) are not cacheable
2121and carry no caching hints.
2222
2323## Cache Key
from line 28
2828a request whose method or parameters differ from the request that produced it.
2929
3030Results produced by retrying a request through the
31[multi round-trip requests](/specification/draft/basic/patterns/mrtr.md) mechanism—that
31[multi round-trip requests](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr.md) mechanism—that
3232is, requests carrying `inputResponses` or `requestState`—**MUST NOT** be cached,
3333as they depend on inputs that are not part of the cache key.
3434
from line 142
142142
143143## Interaction with Pagination
144144
145When a list result is [paginated](/specification/draft/server/utilities/pagination.md), each
145When a list result is [paginated](https://modelcontextprotocol.io/specification/draft/server/utilities/pagination.md), each
146146page is an independently cacheable response—consistent with how HTTP
147147`Cache-Control` treats paginated resources.
148148
specification/draft/server/utilities/logging Changed · +3 / -3 lines
from line 5
55> **Deprecated**: The Logging feature is deprecated as of protocol version
66> `2026-07-28`
77> ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)).
8> Under the [feature lifecycle policy](/community/feature-lifecycle.md), it remains
8> Under the [feature lifecycle policy](https://modelcontextprotocol.io/community/feature-lifecycle.md), it remains
99> in the specification for at least twelve months after this revision's release
1010> before it becomes eligible for removal. New implementations **SHOULD NOT**
1111> adopt it; existing implementations **SHOULD** migrate to logging to `stderr`
1212> for stdio transports, or to [OpenTelemetry](https://opentelemetry.io/) for
1313> structured observability. See the [deprecated features
14> registry](/specification/draft/deprecated.md).
14> registry](https://modelcontextprotocol.io/specification/draft/deprecated.md).
1515
1616The Model Context Protocol (MCP) provides a standardized way for servers to send
1717structured log messages to clients. Clients control logging verbosity per-request via
from line 63
6363notifications at or above the requested level on the response stream of that
6464request, before the final response. `notifications/message` is request-scoped:
6565the server **MUST NOT** deliver it on a
66[`subscriptions/listen`](/specification/draft/basic/patterns/subscriptions)
66[`subscriptions/listen`](https://modelcontextprotocol.io/specification/draft/basic/patterns/subscriptions)
6767stream or on any stream other than the one carrying the response to the request
6868that set the log level.
6969
community/charter-template Changed · +1 / -1 lines
from line 4
44
55Every MCP Working Group and Interest Group must maintain a charter document following this structure. Charters are stored at `docs/community/working-groups/<group-name>.mdx` or `docs/community/interest-groups/<group-name>.mdx` in the [modelcontextprotocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol) and added to `docs/docs.json`.
66
7The charter captures information specific to your group. Governance rules — leadership requirements, decision-making process, meeting requirements, escalation paths — are defined in the [Working and Interest Groups](/community/working-interest-groups.md) documentation and apply automatically. Do not repeat them here.
7The charter captures information specific to your group. Governance rules — leadership requirements, decision-making process, meeting requirements, escalation paths — are defined in the [Working and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md) documentation and apply automatically. Do not repeat them here.
88
99Sections marked **(WG only)** are required for Working Groups and optional for Interest Groups.
1010
community/interest-groups/agents Changed · +2 / -2 lines
from line 48
4848
4949### Related Groups
5050
51* **[Transports WG](/community/working-groups/transports.md)** -
51* **[Transports WG](https://modelcontextprotocol.io/community/working-groups/transports.md)** -
5252 Task polling, multi-round-trip requests, stateless operation, and request
5353 association depend on transport and message-flow semantics.
54* **[Tasks and Events WG](/community/working-groups/tasks-events.md)** -
54* **[Tasks and Events WG](https://modelcontextprotocol.io/community/working-groups/tasks-events.md)** -
5555 Tasks and proactive task-status and completion notifications are owned by that
5656 group. The IG provides use cases and requirements as input.
5757
community/interest-groups/tool-annotations Changed · +1 / -1 lines
from line 30
3030### Related Groups
3131
3232* **Security IG** - Trust and sensitivity annotations ([SEP-1913](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)) span both groups' interests
33* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp.md)** - Skill-level metadata may interact with tool annotations for discovery and filtering
33* **[Skills Over MCP WG](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md)** - Skill-level metadata may interact with tool annotations for discovery and filtering
3434
3535## Leadership
3636
community/security Changed · +1 / -1 lines
from line 61
6161
6262## Security Interest Group
6363
64The [Security Interest Group](/community/interest-groups/security.md) is the venue for
64The [Security Interest Group](https://modelcontextprotocol.io/community/interest-groups/security.md) is the venue for
6565discussing MCP-specific threats, reviewing security-relevant proposals, and routing
6666disclosure questions that don't fit a single repository.
6767
community/working-groups/infrastructure Changed · +1 / -1 lines
from line 76
7676
7777Coordination starts in the Infrastructure Working Group discussion on MCP's Discord. Links to the Infrastructure WG channel and meeting notes will be added once confirmed. Meetings will be published at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io).
7878
79The [Working and Interest Groups governance rules](/community/working-interest-groups.md) apply.
79The [Working and Interest Groups governance rules](https://modelcontextprotocol.io/community/working-interest-groups.md) apply.
8080
8181## Deliverables & Success Metrics
8282
community/working-groups/interceptors Changed · +1 / -1 lines
from line 27
2727
2828### Related Groups
2929
30* **[Transports WG](/community/working-groups/transports.md)** — interceptors operate on MCP message flows whose delivery behavior depends on the transport; coordination needed on transport-level interception points.
30* **[Transports WG](https://modelcontextprotocol.io/community/working-groups/transports.md)** — interceptors operate on MCP message flows whose delivery behavior depends on the transport; coordination needed on transport-level interception points.
3131* **Gateways IG** — gateways are a key deployment model for interceptors; coordination needed on gateway-based interceptor patterns and shared concerns around routing, policy, and observability.
3232
3333## Leadership
docs/2024-11-05/develop/build-client Changed · +2 / -2 lines
from line 4
44
55In this tutorial, you'll learn how to build an LLM-powered chatbot client that connects to MCP servers.
66
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2024-11-05/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
7Before you begin, it helps to have gone through our [Build an MCP Server](https://modelcontextprotocol.io/docs/2024-11-05/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
88
99**Python**
1010
from line 2489
24892489
24902490## Next steps
24912491
2492> **[Example servers](/examples.md)**
2492> **[Example servers](https://modelcontextprotocol.io/examples.md)**
24932493>
24942494> Check out our gallery of official MCP servers and implementations
24952495
docs/2025-03-26/develop/build-client Changed · +2 / -2 lines
from line 4
44
55In this tutorial, you'll learn how to build an LLM-powered chatbot client that connects to MCP servers.
66
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2025-03-26/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
7Before you begin, it helps to have gone through our [Build an MCP Server](https://modelcontextprotocol.io/docs/2025-03-26/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
88
99**Python**
1010
from line 2489
24892489
24902490## Next steps
24912491
2492> **[Example servers](/examples.md)**
2492> **[Example servers](https://modelcontextprotocol.io/examples.md)**
24932493>
24942494> Check out our gallery of official MCP servers and implementations
24952495
docs/2025-06-18/develop/build-client Changed · +2 / -2 lines
from line 4
44
55In this tutorial, you'll learn how to build an LLM-powered chatbot client that connects to MCP servers.
66
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2025-06-18/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
7Before you begin, it helps to have gone through our [Build an MCP Server](https://modelcontextprotocol.io/docs/2025-06-18/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
88
99**Python**
1010
from line 2489
24892489
24902490## Next steps
24912491
2492> **[Example servers](/examples.md)**
2492> **[Example servers](https://modelcontextprotocol.io/examples.md)**
24932493>
24942494> Check out our gallery of official MCP servers and implementations
24952495