One read of Model Context Protocolmcp-20261022T203719Z
295 pages moved out of 357 read.
Pages moved
295
significant first
Pages read
357
in this capture
Captured
20:37 UTC
Corpus hash
3ef457b31340
full-sweep
What this read moved
276-295 of 295, page 12 of 12This capture is too large to show at once. Changes 276-295 of 295 are below, significant first; the rest are on the following screens.
specification/2025-11-25/architecture/index Changed · +2 / -2 lines
from line 158
158158Each capability unlocks specific protocol features for use during the session. For
159159example:
160160
161* Implemented [server features](/specification/2025-11-25/server) must be advertised in the
161* Implemented [server features](/specification/2025-11-25/server.md) must be advertised in the
162162 server's capabilities
163163* Emitting resource subscription notifications requires the server to declare
164164 subscription support
165165* Tool invocation requires the server to declare tool capabilities
166* [Sampling](/specification/2025-11-25/client/sampling) requires the client to declare support in its
166* [Sampling](/specification/2025-11-25/client/sampling.md) requires the client to declare support in its
167167 capabilities
168168
169169This capability negotiation ensures clients and servers have a clear understanding of
specification/2025-11-25/basic/utilities/cancellation Changed · +1 / -1 lines
from line 29
2929 * Were previously issued in the same direction
3030 * Are believed to still be in-progress
31312. The `initialize` request **MUST NOT** be cancelled by clients
323. For [task-augmented requests](./tasks), the `tasks/cancel` request **MUST** be used instead of the `notifications/cancelled` notification. Tasks have their own dedicated cancellation mechanism that returns the final task state.
323. For [task-augmented requests](/specification/2025-11-25/basic/utilities/tasks.md), the `tasks/cancel` request **MUST** be used instead of the `notifications/cancelled` notification. Tasks have their own dedicated cancellation mechanism that returns the final task state.
33334. Receivers of cancellation notifications **SHOULD**:
3434 * Stop processing the cancelled request
3535 * Free associated resources
specification/2025-11-25/basic/utilities/progress Changed · +1 / -1 lines
from line 62
6262 * Send notifications at whatever frequency they deem appropriate
6363 * Omit the total value if unknown
6464
653. For [task-augmented requests](./tasks), the `progressToken` provided in the original request **MUST** continue to be used for progress notifications throughout the task's lifetime, even after the `CreateTaskResult` has been returned. The progress token remains valid and associated with the task until the task reaches a terminal status.
653. For [task-augmented requests](/specification/2025-11-25/basic/utilities/tasks.md), the `progressToken` provided in the original request **MUST** continue to be used for progress notifications throughout the task's lifetime, even after the `CreateTaskResult` has been returned. The progress token remains valid and associated with the task until the task reaches a terminal status.
6666 * Progress notifications for tasks **MUST** use the same `progressToken` that was provided in the initial task-augmented request
6767 * Progress notifications for tasks **MUST** stop after the task reaches a terminal status (`completed`, `failed`, or `cancelled`)
6868
specification/2025-11-25/client/roots Changed · +1 / -1 lines
from line 21
2121## Capabilities
2222
2323Clients that support roots **MUST** declare the `roots` capability during
24[initialization](/specification/2025-11-25/basic/lifecycle#initialization):
24[initialization](/specification/2025-11-25/basic/lifecycle.md#initialization):
2525
2626```json theme={null}
2727{
specification/2025-11-25/client/sampling Changed · +1 / -1 lines
from line 36
3636## Capabilities
3737
3838Clients that support sampling **MUST** declare the `sampling` capability during
39[initialization](/specification/2025-11-25/basic/lifecycle#initialization):
39[initialization](/specification/2025-11-25/basic/lifecycle.md#initialization):
4040
4141**Basic sampling:**
4242
specification/2025-11-25/server/resources Changed · +2 / -2 lines
from line 81
8181### Listing Resources
8282
8383To discover available resources, clients send a `resources/list` request. This operation
84supports [pagination](/specification/2025-11-25/server/utilities/pagination).
84supports [pagination](/specification/2025-11-25/server/utilities/pagination.md).
8585
8686**Request:**
8787
from line 163
163163
164164Resource templates allow servers to expose parameterized resources using
165165[URI templates](https://datatracker.ietf.org/doc/html/rfc6570). Arguments may be
166auto-completed through [the completion API](/specification/2025-11-25/server/utilities/completion).
166auto-completed through [the completion API](/specification/2025-11-25/server/utilities/completion.md).
167167
168168**Request:**
169169
specification/2026-07-28/architecture/index Changed · +2 / -2 lines
from line 159
159159
160160Each capability unlocks specific protocol features on a per-request basis. For example:
161161
162* Implemented [server features](/specification/2026-07-28/server) must be advertised in the
162* Implemented [server features](/specification/2026-07-28/server.md) must be advertised in the
163163 server's capabilities
164164* Receiving resource update notifications requires opening a
165165 [`subscriptions/listen`](/specification/2026-07-28/basic/patterns/subscriptions) stream
166166 with the desired resource URIs
167* [Tool](/specification/2026-07-28/server/tools) invocation requires the server to declare tool capabilities
167* [Tool](/specification/2026-07-28/server/tools.md) invocation requires the server to declare tool capabilities
168168
169169This capability negotiation ensures clients and servers have a clear understanding of
170170supported functionality while maintaining protocol extensibility.
specification/2026-07-28/basic/authorization/authorization-server-discovery Changed · +2 / -2 lines
from line 27
2727separate registration state (client credentials, tokens) per authorization server and
2828**MUST NOT** assume that credentials valid for one authorization server will be accepted by
2929another. See
30[Authorization Server Binding](/specification/2026-07-28/basic/authorization/client-registration#authorization-server-binding)
30[Authorization Server Binding](/specification/2026-07-28/basic/authorization/client-registration.md#authorization-server-binding)
3131for the requirements on associating client credentials with the authorization server that issued them.
3232
3333## Protected Resource Metadata Discovery Requirements
from line 46
4646
4747Servers can also include a `scope` parameter in the `WWW-Authenticate` challenge to indicate the
4848scopes required for accessing the resource; the scope semantics and the associated client behavior
49are defined in the [Scope Selection Strategy](/specification/2026-07-28/basic/authorization#scope-selection-strategy) section.
49are defined in the [Scope Selection Strategy](/specification/2026-07-28/basic/authorization.md#scope-selection-strategy) section.
5050
5151## Authorization Server Metadata Discovery
5252
specification/2026-07-28/basic/authorization/client-registration Changed · +2 / -2 lines
from line 44
4444* **SHOULD** cache metadata respecting HTTP cache headers
4545* **MUST** validate redirect URIs presented in an authorization request against those in the metadata document
4646* **MUST** validate the document structure is valid JSON and contains required fields
47* **SHOULD** follow the security considerations in [Section 6 of Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-00.html#section-6) and in [Client ID Metadata Document Security](/specification/2026-07-28/basic/authorization/security-considerations#client-id-metadata-document-security)
47* **SHOULD** follow the security considerations in [Section 6 of Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-00.html#section-6) and in [Client ID Metadata Document Security](/specification/2026-07-28/basic/authorization/security-considerations.md#client-id-metadata-document-security)
4848
4949### Example Metadata Document
5050
from line 181
181181credentials with the specific authorization server that issued them,
182182keyed by the authorization server's `issuer` identifier. When the
183183authorization server changes (detected via updated
184[protected resource metadata](/specification/2026-07-28/basic/authorization/authorization-server-discovery#authorization-server-location)),
184[protected resource metadata](/specification/2026-07-28/basic/authorization/authorization-server-discovery.md#authorization-server-location)),
185185clients **MUST NOT** reuse client credentials
186186from a different authorization server and **MUST** re-register
187187with the new authorization server.
specification/2026-07-28/basic/patterns/cancellation Changed · +2 / -2 lines
from line 54
5454per-request basis.
5555
5656Implementations **MAY** choose to reset the timeout clock when receiving a
57[progress notification](/specification/2026-07-28/basic/patterns/progress) corresponding to
57[progress notification](/specification/2026-07-28/basic/patterns/progress.md) corresponding to
5858the request, as this implies that work is actually happening. However, implementations
5959**SHOULD** always enforce a maximum timeout, regardless of progress notifications, to
6060limit the impact of a misbehaving client or server.
from line 115
115115This maintains the "fire and forget" nature of notifications while allowing for race
116116conditions in asynchronous communication.
117117
118[subscriptions]: /specification/2026-07-28/basic/patterns/subscriptions
118[subscriptions]: /specification/2026-07-28/basic/patterns/subscriptions.md
119119
specification/2026-07-28/basic/patterns/subscriptions Changed · +1 / -1 lines
from line 159
159159
160160See [Cancellation][cancellation] for the full rules.
161161
162[cancellation]: /specification/2026-07-28/basic/patterns/cancellation
162[cancellation]: /specification/2026-07-28/basic/patterns/cancellation.md
163163
specification/2026-07-28/client/roots Changed · +2 / -2 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), it remains
8> Under the [feature lifecycle policy](/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/2026-07-28/deprecated).
13> [deprecated features registry](/specification/2026-07-28/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
specification/2026-07-28/server/utilities/logging Changed · +2 / -2 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), it remains
8> Under the [feature lifecycle policy](/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/2026-07-28/deprecated).
14> registry](/specification/2026-07-28/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
specification/draft/architecture/index Changed · +2 / -2 lines
from line 159
159159
160160Each capability unlocks specific protocol features on a per-request basis. For example:
161161
162* Implemented [server features](/specification/draft/server) must be advertised in the
162* Implemented [server features](/specification/draft/server.md) must be advertised in the
163163 server's capabilities
164164* Receiving resource update notifications requires opening a
165165 [`subscriptions/listen`](/specification/draft/basic/patterns/subscriptions) stream
166166 with the desired resource URIs
167* [Tool](/specification/draft/server/tools) invocation requires the server to declare tool capabilities
167* [Tool](/specification/draft/server/tools.md) invocation requires the server to declare tool capabilities
168168
169169This capability negotiation ensures clients and servers have a clear understanding of
170170supported functionality while maintaining protocol extensibility.
specification/draft/basic/authorization/authorization-server-discovery Changed · +2 / -2 lines
from line 27
2727separate registration state (client credentials, tokens) per authorization server and
2828**MUST NOT** assume that credentials valid for one authorization server will be accepted by
2929another. See
30[Authorization Server Binding](/specification/draft/basic/authorization/client-registration#authorization-server-binding)
30[Authorization Server Binding](/specification/draft/basic/authorization/client-registration.md#authorization-server-binding)
3131for the requirements on associating client credentials with the authorization server that issued them.
3232
3333## Protected Resource Metadata Discovery Requirements
from line 46
4646
4747Servers can also include a `scope` parameter in the `WWW-Authenticate` challenge to indicate the
4848scopes required for accessing the resource; the scope semantics and the associated client behavior
49are defined in the [Scope Selection Strategy](/specification/draft/basic/authorization#scope-selection-strategy) section.
49are defined in the [Scope Selection Strategy](/specification/draft/basic/authorization.md#scope-selection-strategy) section.
5050
5151## Authorization Server Metadata Discovery
5252
specification/draft/basic/authorization/client-registration Changed · +2 / -2 lines
from line 44
4444* **SHOULD** cache metadata respecting HTTP cache headers
4545* **MUST** validate redirect URIs presented in an authorization request against those in the metadata document
4646* **MUST** validate the document structure is valid JSON and contains required fields
47* **SHOULD** follow the security considerations in [Section 6 of Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-00.html#section-6) and in [Client ID Metadata Document Security](/specification/draft/basic/authorization/security-considerations#client-id-metadata-document-security)
47* **SHOULD** follow the security considerations in [Section 6 of Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-00.html#section-6) and in [Client ID Metadata Document Security](/specification/draft/basic/authorization/security-considerations.md#client-id-metadata-document-security)
4848
4949### Example Metadata Document
5050
from line 181
181181credentials with the specific authorization server that issued them,
182182keyed by the authorization server's `issuer` identifier. When the
183183authorization server changes (detected via updated
184[protected resource metadata](/specification/draft/basic/authorization/authorization-server-discovery#authorization-server-location)),
184[protected resource metadata](/specification/draft/basic/authorization/authorization-server-discovery.md#authorization-server-location)),
185185clients **MUST NOT** reuse client credentials
186186from a different authorization server and **MUST** re-register
187187with the new authorization server.
specification/draft/basic/patterns/cancellation Changed · +2 / -2 lines
from line 54
5454per-request basis.
5555
5656Implementations **MAY** choose to reset the timeout clock when receiving a
57[progress notification](/specification/draft/basic/patterns/progress) corresponding to
57[progress notification](/specification/draft/basic/patterns/progress.md) corresponding to
5858the request, as this implies that work is actually happening. However, implementations
5959**SHOULD** always enforce a maximum timeout, regardless of progress notifications, to
6060limit the impact of a misbehaving client or server.
from line 115
115115This maintains the "fire and forget" nature of notifications while allowing for race
116116conditions in asynchronous communication.
117117
118[subscriptions]: /specification/draft/basic/patterns/subscriptions
118[subscriptions]: /specification/draft/basic/patterns/subscriptions.md
119119
specification/draft/basic/patterns/subscriptions Changed · +1 / -1 lines
from line 159
159159
160160See [Cancellation][cancellation] for the full rules.
161161
162[cancellation]: /specification/draft/basic/patterns/cancellation
162[cancellation]: /specification/draft/basic/patterns/cancellation.md
163163
specification/draft/client/roots Changed · +2 / -2 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), it remains
8> Under the [feature lifecycle policy](/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).
13> [deprecated features registry](/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
specification/draft/server/utilities/logging Changed · +2 / -2 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), it remains
8> Under the [feature lifecycle policy](/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).
14> registry](/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