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
126-150 of 303, page 6 of 13This capture is too large to show at once. Changes 126-150 of 303 are below, significant first; the rest are on the following screens.
extensions/auth/enterprise-managed-authorization Changed · +3 / -3 lines
from line 135
135135>
136136> Support for this extension varies by client. Extensions are opt-in and never active by default.
137137
138Check the [client matrix](/extensions/client-matrix.md) for current implementation status across MCP clients. Enterprise-Managed Authorization typically requires client-level support from the organization's IT team in addition to the MCP client application.
138Check the [client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for current implementation status across MCP clients. Enterprise-Managed Authorization typically requires client-level support from the organization's IT team in addition to the MCP client application.
139139
140140## Related resources
141141
from line 147
147147>
148148> Technical specification with normative requirements
149149
150> **[SEP-990](/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o.md)**
150> **[SEP-990](https://modelcontextprotocol.io/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o.md)**
151151>
152152> Original proposal: Enable Enterprise IdP Policy Controls
153153
154> **[MCP Authorization](/specification/latest/basic/authorization.md)**
154> **[MCP Authorization](https://modelcontextprotocol.io/specification/latest/basic/authorization.md)**
155155>
156156> Core MCP authorization specification
157157
extensions/auth/overview Changed · +10 / -10 lines
from line 11
1111
1212## Why authorization extensions?
1313
14The core MCP specification includes a robust [authorization framework](/specification/latest/basic/authorization.md) built on OAuth 2.0. That framework handles the common case well: a user interactively grants an MCP client permission to access a server on their behalf.
14The core MCP specification includes a robust [authorization framework](https://modelcontextprotocol.io/specification/latest/basic/authorization.md) built on OAuth 2.0. That framework handles the common case well: a user interactively grants an MCP client permission to access a server on their behalf.
1515
1616But not every MCP deployment fits this pattern:
1717
from line 22
2222
2323## Available extensions
2424
25> **[OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md)**
25> **[OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md)**
2626>
2727> Machine-to-machine authentication using the OAuth 2.0 client credentials
2828> flow. No user interaction required.
2929
30> **[Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md)**
30> **[Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md)**
3131>
3232> Centralized access control via enterprise identity providers. Employees
3333> access MCP servers through their organization's IdP.
from line 36
3636
3737| Scenario | Recommended extension |
3838| - | - |
39| Background service or daemon accessing an MCP server | [OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md) |
40| CI/CD pipeline calling MCP tools | [OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md) |
41| Server-to-server API integration | [OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md) |
42| Enterprise employees accessing MCP servers at work | [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md) |
43| Organization-wide MCP access policy enforcement | [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md) |
39| Background service or daemon accessing an MCP server | [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) |
40| CI/CD pipeline calling MCP tools | [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) |
41| Server-to-server API integration | [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) |
42| Enterprise employees accessing MCP servers at work | [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) |
43| Organization-wide MCP access policy enforcement | [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) |
4444| Standard interactive user authorization | Core MCP spec (no extension needed) |
4545
4646## Client support
4747
48Authorization extension support varies by client. See the [client matrix](/extensions/client-matrix.md) for a full breakdown. Both extensions require explicit support from the MCP client — they are never active by default.
48Authorization extension support varies by client. See the [client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for a full breakdown. Both extensions require explicit support from the MCP client — they are never active by default.
4949
5050## Specification
5151
52Both extensions are specified in the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth/tree/main/specification/draft). They use the standard MCP [extension negotiation](/extensions/overview.md#negotiation) mechanism: clients declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` they send in each request's `_meta`, and servers advertise theirs in the capabilities returned by [`server/discover`](/specification/draft/server/discover).
52Both extensions are specified in the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth/tree/main/specification/draft). They use the standard MCP [extension negotiation](https://modelcontextprotocol.io/extensions/overview.md#negotiation) mechanism: clients declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` they send in each request's `_meta`, and servers advertise theirs in the capabilities returned by [`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover).
5353
extensions/client-matrix Changed · +8 / -8 lines
from line 2
22
33> Which MCP clients implement which official extensions
44
5This matrix shows which MCP clients support each [official extension](/extensions/overview.md). Extensions are always opt-in: a client only uses an extension if both client and server declare support in the `extensions` field of their [capabilities](/extensions/overview.md#negotiation).
5This matrix shows which MCP clients support each [official extension](https://modelcontextprotocol.io/extensions/overview.md). Extensions are always opt-in: a client only uses an extension if both client and server declare support in the `extensions` field of their [capabilities](https://modelcontextprotocol.io/extensions/overview.md#negotiation).
66
77> [!NOTE]
88>
from line 12
1212
1313| Extension | Identifier | Description |
1414| - | - | - |
15| [MCP Apps](/extensions/apps/overview.md) | `io.modelcontextprotocol/ui` | Interactive HTML interfaces rendered inline in the conversation |
16| [OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md) | `io.modelcontextprotocol/oauth-client-credentials` | Machine-to-machine auth without interactive user login |
17| [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md) | `io.modelcontextprotocol/enterprise-managed-authorization` | Centralized access control via enterprise IdP |
18| [Skills over MCP](/extensions/skills/overview.md) | `io.modelcontextprotocol/skills` | Discover skills and read their instructions and supporting files |
15| [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) | `io.modelcontextprotocol/ui` | Interactive HTML interfaces rendered inline in the conversation |
16| [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) | `io.modelcontextprotocol/oauth-client-credentials` | Machine-to-machine auth without interactive user login |
17| [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) | `io.modelcontextprotocol/enterprise-managed-authorization` | Centralized access control via enterprise IdP |
18| [Skills over MCP](https://modelcontextprotocol.io/extensions/skills/overview.md) | `io.modelcontextprotocol/skills` | Discover skills and read their instructions and supporting files |
1919
2020## Support matrix
2121
22| Client | [MCP Apps](/extensions/apps/overview.md) | [OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md) | [Enterprise Auth](/extensions/auth/enterprise-managed-authorization.md) | [Skills](/extensions/skills/overview.md) |
22| Client | [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) | [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) | [Enterprise Auth](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) | [Skills](https://modelcontextprotocol.io/extensions/skills/overview.md) |
2323| - | :-: | :-: | :-: | :-: |
2424| [Claude (web)](https://claude.ai) | | | | |
2525| [Claude Desktop](https://claude.ai/download) | | | | |
from line 45
4545If you're building an MCP client and want to implement extension support:
4646
47471. Review the extension specification (e.g., in the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) or [ext-apps](https://github.com/modelcontextprotocol/ext-apps) repository)
482. Declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` your client sends in each request's `_meta`, and read the server's `extensions` from its [`server/discover`](/specification/draft/server/discover) response
482. Declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` your client sends in each request's `_meta`, and read the server's `extensions` from its [`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover) response
49493. Implement the extension's protocol requirements
50504. Submit a pull request to update this matrix
5151
52See [Extensions Overview](/extensions/overview.md#negotiation) for details on the capability negotiation mechanism.
52See [Extensions Overview](https://modelcontextprotocol.io/extensions/overview.md#negotiation) for details on the capability negotiation mechanism.
5353
extensions/overview Changed · +14 / -14 lines
from line 6
66
77MCP extensions are optional additions to the specification that define capabilities beyond the core protocol. Extensions enable functionality that may be modular (e.g., distinct features like authentication), specialized (e.g., industry-specific logic), or experimental (e.g., features being incubated for potential core inclusion).
88
9Extensions are identified using a unique *extension identifier* with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials`. Identifiers follow the same rules as [`_meta` keys](/specification/draft/basic/index#meta), with a mandatory prefix. Official extensions use the `io.modelcontextprotocol` vendor prefix.
9Extensions are identified using a unique *extension identifier* with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials`. Identifiers follow the same rules as [`_meta` keys](https://modelcontextprotocol.io/specification/draft/basic/index#meta), with a mandatory prefix. Official extensions use the `io.modelcontextprotocol` vendor prefix.
1010
1111> [!TIP]
1212>
from line 25
2525
2626| Extension | Description |
2727| - | - |
28| [OAuth Client Credentials](/extensions/auth/oauth-client-credentials.md) | OAuth 2.0 client credentials flow for machine-to-machine authentication. |
29| [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md) | Framework for enterprise environments requiring centralized access control. |
28| [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) | OAuth 2.0 client credentials flow for machine-to-machine authentication. |
29| [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) | Framework for enterprise environments requiring centralized access control. |
3030
3131### MCP Apps
3232
from line 36
3636
3737| Extension | Description |
3838| - | - |
39| [MCP Apps](/extensions/apps/overview.md) | Allows MCP Servers to display interactive UI elements (charts, forms, video players) inline within conversations |
39| [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) | Allows MCP Servers to display interactive UI elements (charts, forms, video players) inline within conversations |
4040
41To get started building MCP Apps, see the [quickstart guide](/extensions/apps/build.md#getting-started) or read the full [MCP Apps documentation](https://apps.extensions.modelcontextprotocol.io/api/documents/Quickstart.html).
41To get started building MCP Apps, see the [quickstart guide](https://modelcontextprotocol.io/extensions/apps/build.md#getting-started) or read the full [MCP Apps documentation](https://apps.extensions.modelcontextprotocol.io/api/documents/Quickstart.html).
4242
4343### MCP Tasks
4444
4545| Extension | Description |
4646| - | - |
47| [MCP Tasks](/extensions/tasks/overview.md) | Asynchronous task execution for long-running operations, with polling, mid-flight input, and durable handles. |
47| [MCP Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) | Asynchronous task execution for long-running operations, with polling, mid-flight input, and durable handles. |
4848
4949### Skills over MCP
5050
from line 54
5454
5555| Extension | Description |
5656| - | - |
57| [Skills over MCP](/extensions/skills/overview.md) | Discover workflow instructions and read supporting files through MCP resources. |
57| [Skills over MCP](https://modelcontextprotocol.io/extensions/skills/overview.md) | Discover workflow instructions and read supporting files through MCP resources. |
5858
59See the [Skills overview](/extensions/skills/overview.md) to get started and the
60[client matrix](/extensions/client-matrix.md) for implementation support.
59See the [Skills overview](https://modelcontextprotocol.io/extensions/skills/overview.md) to get started and the
60[client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for implementation support.
6161
6262## Experimental Extensions
6363
64Experimental extensions provide an incubation pathway for [Working Groups and Interest Groups](/community/working-interest-groups.md) to prototype ideas and collaborate on extension concepts before formal SEP submission.
64Experimental extensions provide an incubation pathway for [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md) to prototype ideas and collaborate on extension concepts before formal SEP submission.
6565
6666Experimental extension repositories live within the MCP GitHub organization with the `experimental-ext-` prefix (e.g., `experimental-ext-interceptors`).
6767
from line 69
6969
7070* Every experimental extension needs to be associated with a Working Group or Interest Group
7171* Repositories and published packages need to clearly indicate their experimental status (e.g., in the README and package name)
72* [Core Maintainers](/community/contributor-ladder.md#core-maintainer) retain oversight of experimental extension repositories, including the ability to archive or remove them
72* [Core Maintainers](https://modelcontextprotocol.io/community/contributor-ladder.md#core-maintainer) retain oversight of experimental extension repositories, including the ability to archive or remove them
7373
7474### Graduation to Official Status
7575
from line 77
7777
7878## Creating Extensions
7979
80The lifecycle for official extensions follows a SEP-based process. For full details, see [SEP-2133: Extensions](/seps/2133-extensions.md).
80The lifecycle for official extensions follows a SEP-based process. For full details, see [SEP-2133: Extensions](https://modelcontextprotocol.io/seps/2133-extensions.md).
8181
821. **Propose**: Create a SEP in the main MCP repository using the [standard SEP guidelines](/community/sep-guidelines.md) with type **Extensions Track**.
821. **Propose**: Create a SEP in the main MCP repository using the [standard SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md) with type **Extensions Track**.
83832. **Implement**: Build at least one reference implementation in an official SDK — this is required before the SEP can be reviewed.
843. **Review**: [Core Maintainers](/community/contributor-ladder.md#core-maintainer) review the SEP and have final authority over inclusion.
843. **Review**: [Core Maintainers](https://modelcontextprotocol.io/community/contributor-ladder.md#core-maintainer) review the SEP and have final authority over inclusion.
85854. **Publish**: Once approved, open a PR to add the extension to the extension repository.
86865. **Adopt**: After that, other clients, servers, and SDKs can implement the extension too.
8787
extensions/skills/overview Changed · +11 / -11 lines
from line 4
44
55The [ext-skills repository](https://github.com/modelcontextprotocol/ext-skills)
66contains the published specification for the official Skills extension
7(`io.modelcontextprotocol/skills`). [SEP-2640](/seps/2640-skills-extension.md) is Final.
7(`io.modelcontextprotocol/skills`). [SEP-2640](https://modelcontextprotocol.io/seps/2640-skills-extension.md) is Final.
88
9The [Skills Over MCP Working Group](/community/working-groups/skills-over-mcp.md)
9The [Skills Over MCP Working Group](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md)
1010maintains the extension. SDK and host support is still being implemented;
11see the [client support matrix](/extensions/client-matrix.md) and
11see the [client support matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) and
1212[implementations list](https://github.com/modelcontextprotocol/ext-skills/blob/main/docs/implementations.md)
1313for current coverage.
1414
from line 45
4545
4646Servers that support Skills **MUST** declare both the `resources` capability and
4747the `io.modelcontextprotocol/skills` extension in
48[`server/discover`](/specification/draft/server/discover):
48[`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover):
4949
5050```json theme={null}
5151{
from line 72
7272>
7373> These examples use protocol revision `2026-07-28` or later. For brevity, the
7474> request examples omit `_meta`. Every request **MUST** include the required
75> [request metadata](/specification/draft/basic/index.md#_meta).
75> [request metadata](https://modelcontextprotocol.io/specification/draft/basic/index.md#_meta).
7676
7777## Protocol Messages
7878
from line 79
7979### Listing Skills
8080
8181To discover available skills, clients send a `skills/list` request. This
82operation supports [pagination](/specification/draft/server/utilities/pagination.md)
83and [caching](/specification/draft/server/utilities/caching.md).
82operation supports [pagination](https://modelcontextprotocol.io/specification/draft/server/utilities/pagination.md)
83and [caching](https://modelcontextprotocol.io/specification/draft/server/utilities/caching.md).
8484
8585**Request:**
8686
from line 180
180180### Reading Skill Content
181181
182182To retrieve skill instructions or supporting files, clients send a
183[`resources/read`](/specification/draft/server/resources#reading-resources)
183[`resources/read`](https://modelcontextprotocol.io/specification/draft/server/resources#reading-resources)
184184request. This example retrieves the `SKILL.md` from the listing above.
185185
186186**Request:**
from line 428
428428
429429## Client Support
430430
431See the [client matrix](/extensions/client-matrix.md) for Skills support and links
431See the [client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for Skills support and links
432432to implementation documentation.
433433
434434## Specification
435435
436436The full specification is in the [ext-skills repository](https://github.com/modelcontextprotocol/ext-skills/blob/main/specification/stable/skills.mdx).
437Development is coordinated by the [Skills Over MCP Working Group](/community/working-groups/skills-over-mcp.md).
437Development is coordinated by the [Skills Over MCP Working Group](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md).
438438
extensions/tasks/overview Changed · +3 / -3 lines
from line 242
242242
243243> [!NOTE]
244244>
245> MCP Tasks is an extension to the [core MCP specification](/specification/latest.md). Host
245> MCP Tasks is an extension to the [core MCP specification](https://modelcontextprotocol.io/specification/latest.md). Host
246246> support varies by client.
247247
248See the [client matrix](/extensions/client-matrix.md) for extension support across
248See the [client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for extension support across
249249clients. Task support requires explicit opt-in from both client and server.
250250
251251## Specification
252252
253The Tasks extension is specified in the [ext-tasks repository](https://github.com/modelcontextprotocol/ext-tasks). It uses the standard MCP [extension negotiation](/extensions/overview.md#negotiation) mechanism: clients declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` they send in each request's `_meta`, and servers advertise theirs in the capabilities returned by [`server/discover`](/specification/draft/server/discover).
253The Tasks extension is specified in the [ext-tasks repository](https://github.com/modelcontextprotocol/ext-tasks). It uses the standard MCP [extension negotiation](https://modelcontextprotocol.io/extensions/overview.md#negotiation) mechanism: clients declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` they send in each request's `_meta`, and servers advertise theirs in the capabilities returned by [`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover).
254254
registry/about Changed · +4 / -4 lines
from line 34
3434
3535For example, a `weather-mcp` package could be hosted on npm, and metadata in the MCP Registry could map the "weather v1.2.0" server to `npm:weather-mcp`.
3636
37The [Package Types guide](/registry/package-types.md) lists the supported package types and registries. More package registries may be supported in the future based on community demand. If you are interested in building support for a package registry, please [open an issue](https://github.com/modelcontextprotocol/registry).
37The [Package Types guide](https://modelcontextprotocol.io/registry/package-types.md) lists the supported package types and registries. More package registries may be supported in the future based on community demand. If you are interested in building support for a package registry, please [open an issue](https://github.com/modelcontextprotocol/registry).
3838
3939### Relationship with Server Developers
4040
from line 48
4848
4949The metadata hosted by the MCP Registry is deliberately unopinionated. Downstream aggregators can provide curation or additional metadata such as community ratings.
5050
51We expect that downstream aggregators will use the MCP Registry API to pull new metadata on a regular but infrequent basis (for example, once per hour). See the [MCP Registry Aggregators guide](/registry/registry-aggregators.md) for more information.
51We expect that downstream aggregators will use the MCP Registry API to pull new metadata on a regular but infrequent basis (for example, once per hour). See the [MCP Registry Aggregators guide](https://modelcontextprotocol.io/registry/registry-aggregators.md) for more information.
5252
5353### Relationship with Other MCP Registries
5454
from line 68
6868
6969The MCP Registry uses namespace authentication to ensure that servers come from their claimed sources. Server names follow a reverse DNS format (like `io.github.username/server` or `com.example/server`) that ties them to verified GitHub accounts or domains.
7070
71This namespace system ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace, providing trust and accountability in the ecosystem. For details on authentication methods, see the [Authentication guide](/registry/authentication.md).
71This namespace system ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace, providing trust and accountability in the ecosystem. For details on authentication methods, see the [Authentication guide](https://modelcontextprotocol.io/registry/authentication.md).
7272
7373### Security Scanning
7474
from line 85
8585
8686* **Namespace authentication requirements** — Publishers must verify ownership of their namespace through GitHub, DNS, or HTTP challenges, preventing arbitrary spam submissions.
8787* **Character limits and validation** — Free-form fields have strict character limits and regex validation to prevent abuse.
88* **Manual takedown** — The registry maintainers can manually remove spam or malicious servers. See the [Moderation Policy](/registry/moderation-policy.md) for details on what content is removed.
88* **Manual takedown** — The registry maintainers can manually remove spam or malicious servers. See the [Moderation Policy](https://modelcontextprotocol.io/registry/moderation-policy.md) for details on what content is removed.
8989
9090Future spam prevention measures under consideration include stricter rate limiting, AI-based spam detection, and community reporting capabilities.
9191
registry/quickstart Changed · +5 / -5 lines
from line 10
1010
1111* **Node.js** — This tutorial assumes the MCP server is written in TypeScript.
1212* **npm account** — The MCP Registry only hosts metadata, not artifacts. Before publishing to the MCP Registry, we will publish the MCP server's package to npm, so you will need an [npm](https://www.npmjs.com) account.
13* **GitHub account** — The MCP Registry supports [multiple authentication methods](/registry/authentication.md). For simplicity, this tutorial will use GitHub-based authentication, so you will need a [GitHub](https://github.com/) account.
13* **GitHub account** — The MCP Registry supports [multiple authentication methods](https://modelcontextprotocol.io/registry/authentication.md). For simplicity, this tutorial will use GitHub-based authentication, so you will need a [GitHub](https://github.com/) account.
1414
1515If you do not have an MCP server written in TypeScript, you can copy the `weather-server-typescript` server from the [`modelcontextprotocol/quickstart-resources` repository](https://github.com/modelcontextprotocol/quickstart-resources) to follow along with this tutorial:
1616
from line 276
276276
277277## Next Steps
278278
279* Learn about [support for other package types](/registry/package-types.md).
280* Learn about [support for remote servers](/registry/remote-servers.md).
281* Learn how to [use other authentication methods](/registry/authentication.md), such as [DNS authentication](/registry/authentication.md#dns-authentication) which enables custom domains for server name prefixes.
282* Learn how to [automate publishing with GitHub Actions](/registry/github-actions.md).
279* Learn about [support for other package types](https://modelcontextprotocol.io/registry/package-types.md).
280* Learn about [support for remote servers](https://modelcontextprotocol.io/registry/remote-servers.md).
281* Learn how to [use other authentication methods](https://modelcontextprotocol.io/registry/authentication.md), such as [DNS authentication](https://modelcontextprotocol.io/registry/authentication.md#dns-authentication) which enables custom domains for server name prefixes.
282* Learn how to [automate publishing with GitHub Actions](https://modelcontextprotocol.io/registry/github-actions.md).
283283
seps/2127-mcp-server-cards Changed · +5 / -5 lines
from line 11
1111> This SEP has reached Final status and is preserved as a historical record of
1212> the design as accepted. Changes made to the protocol after finalization are
1313> not reflected here. Refer to the [current
14> specification](/specification/latest.md) and its changelog for authoritative
14> specification](https://modelcontextprotocol.io/specification/latest.md) and its changelog for authoritative
1515> requirements.
1616
1717| Field | Value |
from line 31
3131
3232This SEP proposes adding a standardized, self-contained format to describe MCP servers for pre-connection discovery. This enables clients to automatically discover available transports, protocol versions, and connection guidance before establishing a connection.
3333
34As an Extensions Track SEP (per [SEP-2133](/seps/2133-extensions.md)), this document charters the **Server Card** extension and names its Working Group and maintainers. The detailed, normative wire format — the Server Card schema, field definitions, the discovery mechanics, and the full security analysis — is maintained in the [experimental-ext-server-card](https://github.com/modelcontextprotocol/experimental-ext-server-card) repository rather than inline here, following the precedent set by [SEP-1865 (MCP Apps)](/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md).
34As an Extensions Track SEP (per [SEP-2133](https://modelcontextprotocol.io/seps/2133-extensions.md)), this document charters the **Server Card** extension and names its Working Group and maintainers. The detailed, normative wire format — the Server Card schema, field definitions, the discovery mechanics, and the full security analysis — is maintained in the [experimental-ext-server-card](https://github.com/modelcontextprotocol/experimental-ext-server-card) repository rather than inline here, following the precedent set by [SEP-1865 (MCP Apps)](https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md).
3535
3636## Motivation
3737
from line 92
9292and the discovery mechanics in [`docs/discovery.md`](https://github.com/modelcontextprotocol/experimental-ext-server-card/blob/main/docs/discovery.md)
9393are derived from it.
9494
95For purposes of SEP review, [extension repository snapshot `526201bb`](https://github.com/modelcontextprotocol/experimental-ext-server-card/tree/526201bbc80231daa40ffcdecfc9da4e54e5dc93) captures the contract considered by this proposal. After acceptance, implementers should follow the current, versioned extension specification rather than this historical snapshot. As defined by [SEP-2133](/seps/2133-extensions.md#iteration), extension maintainers may evolve the specification independently while preserving backward compatibility; breaking changes require a new extension identifier.
95For purposes of SEP review, [extension repository snapshot `526201bb`](https://github.com/modelcontextprotocol/experimental-ext-server-card/tree/526201bbc80231daa40ffcdecfc9da4e54e5dc93) captures the contract considered by this proposal. After acceptance, implementers should follow the current, versioned extension specification rather than this historical snapshot. As defined by [SEP-2133](https://modelcontextprotocol.io/seps/2133-extensions.md#iteration), extension maintainers may evolve the specification independently while preserving backward compatibility; breaking changes require a new extension identifier.
9696
9797At a high level, the Server Card extension introduces:
9898
from line 188
188188
189189## References
190190
191* [SEP-1865: MCP Apps (Extensions Track precedent)](/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md)
192* [SEP-2133: Extensions](/seps/2133-extensions.md)
191* [SEP-1865: MCP Apps (Extensions Track precedent)](https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md)
192* [SEP-2133: Extensions](https://modelcontextprotocol.io/seps/2133-extensions.md)
193193* [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414)
194194* [RFC 8615: Well-Known URIs](https://datatracker.ietf.org/doc/html/rfc8615)
195195* [MCP Protocol Specification](https://modelcontextprotocol.io/specification)
seps/2148-contributor-ladder Changed · +4 / -4 lines
from line 11
1111> This SEP has reached Final status and is preserved as a historical record of
1212> the design as accepted. Changes made to the protocol after finalization are
1313> not reflected here. Refer to the [current
14> specification](/specification/latest.md) and its changelog for authoritative
14> specification](https://modelcontextprotocol.io/specification/latest.md) and its changelog for authoritative
1515> requirements.
1616
1717| Field | Value |
from line 31
3131
3232This SEP establishes a formal contributor ladder for the Model Context Protocol project, defining clear roles, responsibilities, and advancement criteria from first-time contributor through Core Maintainer. The ladder provides transparent pathways for community members to understand how they can grow their involvement and influence within the project.
3333
34This SEP is a companion to [SEP-2149: MCP Group Governance and Charter Template](/seps/2149-working-group-charter-template.md), which defines how Working Groups and Interest Groups operate. The two SEPs intersect: WG/IG leadership requires Member status on this ladder, and group participation is a recognized pathway to ladder advancement.
34This SEP is a companion to [SEP-2149: MCP Group Governance and Charter Template](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md), which defines how Working Groups and Interest Groups operate. The two SEPs intersect: WG/IG leadership requires Member status on this ladder, and group participation is a recognized pathway to ladder advancement.
3535
3636## Motivation
3737
from line 276
276276
277277When in doubt, make the decision at your level and document it. Escalate only when blocked, when the decision has project-wide implications, or when explicitly required by process.
278278
279The detailed escalation procedure for Working Group and Interest Group disputes — including the designation of a Core Maintainer without shared organizational affiliation to resolve the issue — is defined in [SEP-2149 §1.5](/seps/2149-working-group-charter-template.md).
279The detailed escalation procedure for Working Group and Interest Group disputes — including the designation of a Core Maintainer without shared organizational affiliation to resolve the issue — is defined in [SEP-2149 §1.5](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md).
280280
281281#### Escalation Matrix
282282
from line 337
337337
338338### Working Group and Interest Group Leadership
339339
340Working Group (WG) Leads and Interest Group (IG) Facilitators are a special form of community leadership that doesn't require Maintainer status. WG/IG leadership focuses on facilitation and coordination rather than merge authority. The full governance rules for WGs and IGs — including participation tiers, decision-making process, meeting requirements, and lifecycle — are defined in [SEP-2149: MCP Group Governance and Charter Template](/seps/2149-working-group-charter-template.md).
340Working Group (WG) Leads and Interest Group (IG) Facilitators are a special form of community leadership that doesn't require Maintainer status. WG/IG leadership focuses on facilitation and coordination rather than merge authority. The full governance rules for WGs and IGs — including participation tiers, decision-making process, meeting requirements, and lifecycle — are defined in [SEP-2149: MCP Group Governance and Charter Template](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md).
341341
342342**Requirements:**
343343
seps/2149-working-group-charter-template Changed · +5 / -5 lines
from line 11
1111> This SEP has reached Final status and is preserved as a historical record of
1212> the design as accepted. Changes made to the protocol after finalization are
1313> not reflected here. Refer to the [current
14> specification](/specification/latest.md) and its changelog for authoritative
14> specification](https://modelcontextprotocol.io/specification/latest.md) and its changelog for authoritative
1515> requirements.
1616
1717| Field | Value |
from line 31
3131
3232This SEP establishes governance rules and a standardized charter template for MCP's two collaborative group types: **Working Groups (WGs)** and **Interest Groups (IGs)**. Working Groups produce concrete deliverables — SEPs, implementations, and code. Interest Groups facilitate discussion and knowledge-sharing to identify problems and gather requirements. The governance rules define the requirements that all groups must follow, with lighter expectations for IGs where appropriate. The charter template defines the structure each group uses to document its specific mission, scope, leadership, and work. Together they address community feedback about unclear authority delegation and inconsistent processes across groups.
3333
34This SEP is a companion to [SEP-2148: MCP Contributor Ladder](/seps/2148-contributor-ladder.md), which defines the org-wide contributor roles (Member, Maintainer, Core Maintainer, Lead Maintainer) referenced throughout this document. Group leadership roles intersect with the contributor ladder: WG Leads and IG Facilitators must hold at least Member status on the ladder, and group participation is a recognized pathway to ladder advancement.
34This SEP is a companion to [SEP-2148: MCP Contributor Ladder](https://modelcontextprotocol.io/seps/2148-contributor-ladder.md), which defines the org-wide contributor roles (Member, Maintainer, Core Maintainer, Lead Maintainer) referenced throughout this document. Group leadership roles intersect with the contributor ladder: WG Leads and IG Facilitators must hold at least Member status on the ladder, and group participation is a recognized pathway to ladder advancement.
3535
3636## Motivation
3737
from line 75
7575
7676**Requirements for all Leads and Facilitators:**
7777
78* Hold at least Member status on the [MCP Contributor Ladder](/seps/2148-contributor-ladder.md)
78* Hold at least Member status on the [MCP Contributor Ladder](https://modelcontextprotocol.io/seps/2148-contributor-ladder.md)
7979* Demonstrated sustained engagement with the group's scope area
8080* Ability to facilitate across organizational boundaries
8181* Commitment to running the group's operations
from line 107
107107
108108#### 1.3 Participation Levels
109109
110All groups use the following participation tiers. Note that **WG Member** is a group-specific participation level distinct from the org-wide **Member** role defined in the [Contributor Ladder](/seps/2148-contributor-ladder.md) — an individual may be a WG Member in a specific group without holding org-wide Member status, and vice versa.
110All groups use the following participation tiers. Note that **WG Member** is a group-specific participation level distinct from the org-wide **Member** role defined in the [Contributor Ladder](https://modelcontextprotocol.io/seps/2148-contributor-ladder.md) — an individual may be a WG Member in a specific group without holding org-wide Member status, and vice versa.
111111
112112| Level | Description | Privileges |
113113| - | - | - |
from line 255
255255
256256### Part 2: Charter Template
257257
258Every MCP Working Group and Interest Group must maintain a charter document following this template structure. Charters are stored as MDX files at `docs/community/<group-name>/charter.mdx` in the modelcontextprotocol repository and added to the `docs/docs.json` file. A copyable version of this template is published at [`docs/community/charter-template.mdx`](/community/charter-template).
258Every MCP Working Group and Interest Group must maintain a charter document following this template structure. Charters are stored as MDX files at `docs/community/<group-name>/charter.mdx` in the modelcontextprotocol repository and added to the `docs/docs.json` file. A copyable version of this template is published at [`docs/community/charter-template.mdx`](https://modelcontextprotocol.io/community/charter-template).
259259
260260The charter captures information specific to each group. Governance rules from Part 1 apply automatically and do not need to be repeated in the charter. Sections marked **(WG only)** are required for Working Groups but optional for Interest Groups.
261261
seps/2663-tasks-extension Changed · +17 / -17 lines
from line 11
1111> This SEP has reached Final status and is preserved as a historical record of
1212> the design as accepted. Changes made to the protocol after finalization are
1313> not reflected here. Refer to the [current
14> specification](/specification/latest.md) and its changelog for authoritative
14> specification](https://modelcontextprotocol.io/specification/latest.md) and its changelog for authoritative
1515> requirements.
1616
1717| Field | Value |
from line 31
3131
3232This SEP defines an extension that allows a server to respond to a `tools/call` request with an asynchronous *task handle* instead of a final result, allowing the client to retrieve the eventual result by polling. The extension introduces three methods: `tasks/get`, `tasks/update`, and `tasks/cancel`; a polymorphic-result discriminator (`resultType: "task"`); and a `Task` shape that carries a task status, in-progress server-to-client requests, and a final result or error. Task creation is server-directed: the client signals support by including the extension in its per-request capabilities, and the server decides on a per-request basis whether to materialize a task.
3333
34Tasks will become a foundational building block of MCP and are expected to be supported in future protocol versions. The experimental `tasks` feature in the `2025-11-25` specification served as a stopgap until the protocol's extension mechanism was available. Now that [extensions](https://modelcontextprotocol.io/extensions/overview.md) have been [formalized](/seps/2133-extensions.md), moving tasks to an official extension gives the feature time to incubate and evolve based on additional real-world implementation feedback, without being constrained by the core specification's release cadence. Once the extension has stabilized and achieved broad adoption, it is intended to be promoted into the core protocol.
34Tasks will become a foundational building block of MCP and are expected to be supported in future protocol versions. The experimental `tasks` feature in the `2025-11-25` specification served as a stopgap until the protocol's extension mechanism was available. Now that [extensions](https://modelcontextprotocol.io/extensions/overview.md) have been [formalized](https://modelcontextprotocol.io/seps/2133-extensions.md), moving tasks to an official extension gives the feature time to incubate and evolve based on additional real-world implementation feedback, without being constrained by the core specification's release cadence. Once the extension has stabilized and achieved broad adoption, it is intended to be promoted into the core protocol.
3535
3636This proposal *removes* the version of [tasks](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks.md) specified in the `2025-11-25` release from the core protocol and moves it to an Extension. It also proposes updates to Tasks shaped by implementation feedback since that release, and by several changes to the base protocol included in the `2026-06-30` specification:
3737
38* [SEP-2260: Require Server requests to be associated with a Client request](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md)
39* [SEP-2322: Multi Round-Trip Requests](/seps/2322-MRTR.md)
40* [SEP-2243: HTTP Header Standardization for Streamable HTTP Transport](/seps/2243-http-standardization.md)
41* [SEP-2567: Sessionless MCP via Explicit State Handles](/seps/2567-sessionless-mcp.md)
38* [SEP-2260: Require Server requests to be associated with a Client request](https://modelcontextprotocol.io/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md)
39* [SEP-2322: Multi Round-Trip Requests](https://modelcontextprotocol.io/seps/2322-MRTR.md)
40* [SEP-2243: HTTP Header Standardization for Streamable HTTP Transport](https://modelcontextprotocol.io/seps/2243-http-standardization.md)
41* [SEP-2567: Sessionless MCP via Explicit State Handles](https://modelcontextprotocol.io/seps/2567-sessionless-mcp.md)
4242* [SEP-2575: Make MCP Stateless](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575)
4343
4444## Motivation
from line 47
4747
48481. **The handshake is fragile.** Tasks today expose method-level capabilities (`tasks.requests.tools.call` declares that `tools/call` **MAY** be task-augmented) alongside a tool-level `execution.taskSupport` field that declares whether a particular tool will accept the augmentation. Clients express their own support for tasks by passing a `task` parameter on their requests, but **MUST NOT** include it if the method/tool does not support tasks. A client that wants to opt into tasks must therefore prime its state with a `tools/list` call before issuing any task-augmented request, and cannot blindly attach a `task` parameter to every request to handle tools isomorphically. This is confusing, implicit, and easy to get wrong.
4949
502. **`tasks/result` is a blocking trap.** In the current flow, a client that observes `input_required` is required to call `tasks/result` prematurely so that the server has an SSE stream on which to side-channel elicitation or sampling requests. `tasks/result` then blocks until the entire operation completes. This forces long-lived persistent connections that many clients and servers do not want to implement, and it conflicts with [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md), which disallows unsolicited server-to-client requests outright. Under SEP-2260, the SSE semantics that justified the blocking behavior no longer apply.
502. **`tasks/result` is a blocking trap.** In the current flow, a client that observes `input_required` is required to call `tasks/result` prematurely so that the server has an SSE stream on which to side-channel elicitation or sampling requests. `tasks/result` then blocks until the entire operation completes. This forces long-lived persistent connections that many clients and servers do not want to implement, and it conflicts with [SEP-2260](https://modelcontextprotocol.io/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md), which disallows unsolicited server-to-client requests outright. Under SEP-2260, the SSE semantics that justified the blocking behavior no longer apply.
5151
52523. **`tasks/list` scoping cannot be defined.** To avoid clients cancelling or retrieving results for tasks they shouldn't have access to, all tasks should be bound to some sort of "authorization context," the implementation of which is left to individual servers according to their existing bespoke permission models. However, in many cases, it is not possible to perform this binding, in which case the task ID becomes the only line of defense against contamination. In this scenario, it is unsafe for a server to support `tasks/list` at all. While it was possible for tasks to instead be bound to a session, [SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567) removes sessions from the protocol. There is no other natural scope a server can define unilaterally — task IDs can be unguessable handles that a server can recognize one at a time, but servers cannot reliably correlate two unrelated handles to the same caller without additional state.
5353
54Beyond implementation challenges, tasks face another structural issue: **Client-hosted tasks are no longer expressible.** [SEP-1686](/seps/1686-tasks.md) permitted clients to host tasks for elicitation and sampling, in part to avoid coupling tasks to tool calls. [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md) makes any unsolicited server-to-client request invalid; every server-to-client polling request under client-hosted tasks would be unsolicited by definition.
54Beyond implementation challenges, tasks face another structural issue: **Client-hosted tasks are no longer expressible.** [SEP-1686](https://modelcontextprotocol.io/seps/1686-tasks.md) permitted clients to host tasks for elicitation and sampling, in part to avoid coupling tasks to tool calls. [SEP-2260](https://modelcontextprotocol.io/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md) makes any unsolicited server-to-client request invalid; every server-to-client polling request under client-hosted tasks would be unsolicited by definition.
5555
56This proposal intends to solve the above issues by redesigning certain aspects of the feature and moving tasks out to an official extension. Redefining tasks as an official extension gives the feature more time to incubate and evolve independently of the core specification, promoting adoption. As part of the redesign, this proposal consolidates the polling lifecycle into `tasks/get` and a new `tasks/update` to remove the blocking `tasks/result` method. The redesign allows servers to return tasks unsolicited (in response to ordinary, non-`task`-flagged requests) to eliminate the per-request opt-in and the `tools/list` warmup, relying instead on the extension capability as the single handshake point. Finally, this proposal removes client-hosted elicitation and sampling tasks in compliance with [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md).
56This proposal intends to solve the above issues by redesigning certain aspects of the feature and moving tasks out to an official extension. Redefining tasks as an official extension gives the feature more time to incubate and evolve independently of the core specification, promoting adoption. As part of the redesign, this proposal consolidates the polling lifecycle into `tasks/get` and a new `tasks/update` to remove the blocking `tasks/result` method. The redesign allows servers to return tasks unsolicited (in response to ordinary, non-`task`-flagged requests) to eliminate the per-request opt-in and the `tools/list` warmup, relying instead on the extension capability as the single handshake point. Finally, this proposal removes client-hosted elicitation and sampling tasks in compliance with [SEP-2260](https://modelcontextprotocol.io/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md).
5757
5858## Specification
5959
from line 137
137137
138138### Polymorphic Results
139139
140A request that is eligible for task-augmentation may return one of two distinct result shapes — the request's standard result, or a `CreateTaskResult`. The discriminator is the `resultType` field on the result object, introduced by [SEP-2322](/seps/2322-MRTR.md):
140A request that is eligible for task-augmentation may return one of two distinct result shapes — the request's standard result, or a `CreateTaskResult`. The discriminator is the `resultType` field on the result object, introduced by [SEP-2322](https://modelcontextprotocol.io/seps/2322-MRTR.md):
141141
142142```typescript theme={null}
143143// "task" is introduced by this extension.
from line 347
347347Upon receiving a `tasks/get` request, the server **MUST** check the status of the task and respond accordingly:
348348
3493491. If the status is `working`, the server **MUST** return a a `Task` object with status `working`.
3502. If the status is `input_required`, the server **MUST** return a `Task` object with status `input_required` and an `inputRequests` field defined in [Multi Round-Trip Requests](/seps/2322-MRTR.md). The `inputRequests` field **MUST** contain all outstanding requests from the server to the client that need to be fulfilled before the task can proceed.
3502. If the status is `input_required`, the server **MUST** return a `Task` object with status `input_required` and an `inputRequests` field defined in [Multi Round-Trip Requests](https://modelcontextprotocol.io/seps/2322-MRTR.md). The `inputRequests` field **MUST** contain all outstanding requests from the server to the client that need to be fulfilled before the task can proceed.
3513513. If the status is `completed`, the server **MUST** return a `Task` object with status `completed` and a `result` field containing the final result of the task.
3523524. If the status is `cancelled`, the server **MUST** return a `Task` object with status `cancelled`.
3533535. If the status is `failed`, the server **MUST** return a `Task` object with status `failed` and the error that occurred during execution.
from line 362
362362
363363### Task Update Requests
364364
365When a task requires input from the client (indicated by the `input_required` status), the server includes outstanding requests in the `inputRequests` field of the `tasks/get` response (see [Multi Round-Trip Requests](/seps/2322-MRTR.md)). The client provides responses via the `inputResponses` field in one or more subsequent `tasks/update` requests.
365When a task requires input from the client (indicated by the `input_required` status), the server includes outstanding requests in the `inputRequests` field of the `tasks/get` response (see [Multi Round-Trip Requests](https://modelcontextprotocol.io/seps/2322-MRTR.md)). The client provides responses via the `inputResponses` field in one or more subsequent `tasks/update` requests.
366366
367367When a client observes a `tasks/get` response (or `notifications/tasks` notification) with `status: "input_required"`, the client **SHOULD** fulfill the outstanding requests in `inputRequests` by sending one or more `tasks/update` requests with corresponding `inputResponses`. After sending a `tasks/update`, the client **SHOULD** continue observing the task's status via polling (`tasks/get`) or notifications (`notifications/tasks`) until it reaches a terminal state.
368368
from line 531
531531
532532### Streamable HTTP: Routing Headers
533533
534When `tasks/get`, `tasks/update`, or `tasks/cancel` is sent over the Streamable HTTP transport, the client **MUST** set the `Mcp-Name` header (defined by [SEP-2243](/seps/2243-http-standardization.md)) to the value of `params.taskId`. This allows transport intermediaries and load balancers to route subsequent requests for the same task to the server instance holding its state, which is typically required for correctness. The `Mcp-Method` header is set to the JSON-RPC method name per [SEP-2243](/seps/2243-http-standardization.md).
534When `tasks/get`, `tasks/update`, or `tasks/cancel` is sent over the Streamable HTTP transport, the client **MUST** set the `Mcp-Name` header (defined by [SEP-2243](https://modelcontextprotocol.io/seps/2243-http-standardization.md)) to the value of `params.taskId`. This allows transport intermediaries and load balancers to route subsequent requests for the same task to the server instance holding its state, which is typically required for correctness. The `Mcp-Method` header is set to the JSON-RPC method name per [SEP-2243](https://modelcontextprotocol.io/seps/2243-http-standardization.md).
535535
536536### Example Message Flow
537537
from line 608
608608}
609609```
610610
611Eventually, the server reaches the point at which it needs to send an elicitation to the user. It sets the task status to `"input_required"` to signal this. On the next `tasks/get` request from the client, the server sends the elicitation payload via the `inputRequests` field. Note that while task `inputRequests` share structural similarities with [SEP-2322](/seps/2322-MRTR.md) multi round-trip requests, they are a distinct mechanism: task `inputRequests` are surfaced via `tasks/get` and fulfilled via `tasks/update`, not via retries of the original method. A server that needs client input *before* returning a `CreateTaskResult` (e.g. to decide whether to proceed) uses the multi round-trip request flow on the original request; a server that needs client input *during* task execution uses the `inputRequests`/`inputResponses` mechanism described here.
611Eventually, the server reaches the point at which it needs to send an elicitation to the user. It sets the task status to `"input_required"` to signal this. On the next `tasks/get` request from the client, the server sends the elicitation payload via the `inputRequests` field. Note that while task `inputRequests` share structural similarities with [SEP-2322](https://modelcontextprotocol.io/seps/2322-MRTR.md) multi round-trip requests, they are a distinct mechanism: task `inputRequests` are surfaced via `tasks/get` and fulfilled via `tasks/update`, not via retries of the original method. A server that needs client input *before* returning a `CreateTaskResult` (e.g. to decide whether to proceed) uses the multi round-trip request flow on the original request; a server that needs client input *during* task execution uses the `inputRequests`/`inputResponses` mechanism described here.
612612
613613```json theme={null}
614614{
from line 922
922922
923923However, as we look to [move away](https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future/) from stateful protocol interactions and given the current experimental state of tasks in general, it seems worth proposing a somewhat more radical change that reduces the complexity of the overall specification and makes tasks more "native" to MCP at this time. In particular, the choice to allow unsolicited tasks (in *addition* to immediate results) means promoting tasks to a first-class concept intended for all persistent operations, as opposed to being a parallel and somewhat specialized concept.
924924
925This happens to align with the proposed [SEP-2322](/seps/2322-MRTR.md), but the two are not coupled with one another.
925This happens to align with the proposed [SEP-2322](https://modelcontextprotocol.io/seps/2322-MRTR.md), but the two are not coupled with one another.
926926
927927### Splitting Reads (`tasks/get`) and Writes (`tasks/update`)
928928
from line 954
954954
955955> Server implementations that use multi round-trip requests in conjunction with task creation (for example, a tool that requires elicitation over `InputRequiredResult` before creating a task) **SHOULD** resolve all MRTR exchanges *synchronously* before responding with a `CreateTaskResult`.
956956
957A `tools/call` that supports both MRTR ([SEP-2322](/seps/2322-MRTR.md)) and this extension may use them sequentially by sending one or more `InputRequiredResult` exchanges to gather input synchronously, followed by a `CreateTaskResult` to hand off to asynchronous execution. This composition is a consequence of the `resultType` discriminator — each response is independently typed and the client switches behavior based on the value it receives, *without* maintaining any state between the two modes. Prohibiting this would require imposing an artificial constraint with no protocol-level mechanism to enforce it, since the client is unaware that the server will create a task ahead of time.
957A `tools/call` that supports both MRTR ([SEP-2322](https://modelcontextprotocol.io/seps/2322-MRTR.md)) and this extension may use them sequentially by sending one or more `InputRequiredResult` exchanges to gather input synchronously, followed by a `CreateTaskResult` to hand off to asynchronous execution. This composition is a consequence of the `resultType` discriminator — each response is independently typed and the client switches behavior based on the value it receives, *without* maintaining any state between the two modes. Prohibiting this would require imposing an artificial constraint with no protocol-level mechanism to enforce it, since the client is unaware that the server will create a task ahead of time.
958958
959959The two flows maintain separate state despite sharing field names. The MRTR phase ends when the server returns any non-`"input_required"` `resultType`, at which point its `inputRequests` keys are consumed. The task phase begins with `CreateTaskResult` and maintains *its own* `inputRequests` keys independently. Key uniqueness for task `inputRequests` is scoped to the lifetime of the task and does not extend to keys from the preceding MRTR phase. Clients do not need to deduplicate across the two flows.
960960
seps/index Changed · +45 / -45 lines
from line 4
44
55Specification Enhancement Proposals (SEPs) are the primary mechanism for proposing major changes to the Model Context Protocol. Each SEP provides a concise technical specification and rationale for proposed features.
66
7Each SEP is reachable by number at `/seps/<number>` (for example, [/seps/1850](/seps/1850.md)).
7Each SEP is reachable by number at `/seps/<number>` (for example, [/seps/1850](https://modelcontextprotocol.io/seps/1850.md)).
88
9> **[Submit a SEP](/community/sep-guidelines.md)**
9> **[Submit a SEP](https://modelcontextprotocol.io/community/sep-guidelines.md)**
1010>
1111> Learn how to submit your own Specification Enhancement Proposal
1212
from line 18
1818
1919| SEP | Title | Status | Type | Created |
2020| - | - | - | - | - |
21| [SEP-2663](/seps/2663-tasks-extension.md) | Tasks Extension | Final | Extensions Track | 2026-04-27 |
22| [SEP-2640](/seps/2640-skills-extension.md) | Skills Extension | Final | Extensions Track | 2026-04-23 |
23| [SEP-2596](/seps/2596-spec-feature-lifecycle-and-deprecation.md) | Specification Feature Lifecycle and Deprecation Policy | Final | Process | 2026-04-17 |
24| [SEP-2577](/seps/2577-deprecate-roots-sampling-and-logging.md) | Deprecate Roots, Sampling, and Logging | Final | Standards Track | 2026-04-14 |
25| [SEP-2575](/seps/2575-stateless-mcp.md) | Make MCP Stateless | Final | Standards Track | 2025-06-18 |
26| [SEP-2567](/seps/2567-sessionless-mcp.md) | Sessionless MCP via Explicit State Handles | Final | Standards Track | 2026-03-11 |
27| [SEP-2549](/seps/2549-TTL-for-list-results.md) | TTL for List Results | Final | Standards Track | 2026-04-09 |
28| [SEP-2484](/seps/2484-conformance-tests-required-for-final-seps.md) | Require Conformance Tests for Standards Track SEPs to Reach Final Status | Final | Process | 2026-03-27 |
29| [SEP-2468](/seps/2468-recommend-issuer-claim-for-auth.md) | Recommend Issuer (iss) Parameter in MCP Auth Responses | Final | Standards Track | 2026-03-25 |
30| [SEP-2322](/seps/2322-MRTR.md) | Multi Round-Trip Requests | Final | Standards Track | 2026-02-03 |
31| [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md) | Require Server requests to be associated with a Client request. | Final | Standards Track | 2026-02-16 |
32| [SEP-2243](/seps/2243-http-standardization.md) | HTTP Header Standardization for Streamable HTTP Transport | Final | Standards Track | 2026-02-04 |
33| [SEP-2207](/seps/2207-oidc-refresh-token-guidance.md) | OIDC-Flavored Refresh Token Guidance | Final | Standards Track | 2026-02-04 |
34| [SEP-2164](/seps/2164-resource-not-found-error.md) | Standardize Resource Not Found Error Code | Final | Standards Track | 2026-01-28 |
35| [SEP-2149](/seps/2149-working-group-charter-template.md) | MCP Group Governance and Charter Template | Final | Process | 2025-01-15 |
36| [SEP-2148](/seps/2148-contributor-ladder.md) | MCP Contributor Ladder | Final | Process | 2026-01-15 |
37| [SEP-2133](/seps/2133-extensions.md) | Extensions | Final | Standards Track | 2025-01-21 |
38| [SEP-2127](/seps/2127-mcp-server-cards.md) | MCP Server Cards - HTTP Server Discovery | Final | Extensions Track | 2026-01-21 |
39| [SEP-2106](/seps/2106-json-schema-2020-12.md) | Tools `inputSchema` & `outputSchema` Conform to JSON Schema 2020-12 | Final | Standards Track | 2026-01-06 |
40| [SEP-2085](/seps/2085-governance-succession-and-amendment.md) | Governance Succession and Amendment Procedures | Final | Process | 2025-12-05 |
41| [SEP-1865](/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md) | MCP Apps - Interactive User Interfaces for MCP | Final | Extensions Track | 2025-11-21 |
42| [SEP-1850](/seps/1850-pr-based-sep-workflow.md) | PR-Based SEP Workflow | Final | Process | 2025-11-20 |
43| [SEP-1730](/seps/1730-sdks-tiering-system.md) | SDKs Tiering System | Final | Standards Track | 2025-10-29 |
44| [SEP-1699](/seps/1699-support-sse-polling-via-server-side-disconnect.md) | Support SSE polling via server-side disconnect | Final | Standards Track | 2025-10-22 |
45| [SEP-1686](/seps/1686-tasks.md) | Tasks | Final | Standards Track | 2025-10-20 |
46| [SEP-1613](/seps/1613-establish-json-schema-2020-12-as-default-dialect-f.md) | Establish JSON Schema 2020-12 as Default Dialect for MCP | Final | Standards Track | 2025-10-06 |
47| [SEP-1577](/seps/1577--sampling-with-tools.md) | Sampling With Tools | Final | Standards Track | 2025-09-30 |
48| [SEP-1330](/seps/1330-elicitation-enum-schema-improvements-and-standards.md) | Elicitation Enum Schema Improvements and Standards Compliance | Final | Standards Track | 2025-08-11 |
49| [SEP-1319](/seps/1319-decouple-request-payload-from-rpc-methods-definiti.md) | Decouple Request Payload from RPC Methods Definition | Final | Standards Track | 2025-08-08 |
50| [SEP-1303](/seps/1303-input-validation-errors-as-tool-execution-errors.md) | Input Validation Errors as Tool Execution Errors | Final | Standards Track | 2025-08-05 |
51| [SEP-1302](/seps/1302-formalize-working-groups-and-interest-groups-in-mc.md) | Formalize Working Groups and Interest Groups in MCP Governance | Final | Standards Track | 2025-08-05 |
52| [SEP-1046](/seps/1046-support-oauth-client-credentials-flow-in-authoriza.md) | Support OAuth client credentials flow in authorization | Final | Standards Track | 2025-07-23 |
53| [SEP-1036](/seps/1036-url-mode-elicitation-for-secure-out-of-band-intera.md) | URL Mode Elicitation for secure out-of-band interactions | Final | Standards Track | 2025-07-22 |
54| [SEP-1034](/seps/1034--support-default-values-for-all-primitive-types-in.md) | Support default values for all primitive types in elicitation schemas | Final | Standards Track | 2025-07-22 |
55| [SEP-1024](/seps/1024-mcp-client-security-requirements-for-local-server-.md) | MCP Client Security Requirements for Local Server Installation | Final | Standards Track | 2025-07-22 |
56| [SEP-994](/seps/994-shared-communication-practicesguidelines.md) | Shared Communication Practices/Guidelines | Final | Process | 2025-07-17 |
57| [SEP-991](/seps/991-enable-url-based-client-registration-using-oauth-c.md) | Enable URL-based Client Registration using OAuth Client ID Metadata Documents | Final | Standards Track | 2025-07-07 |
58| [SEP-990](/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o.md) | Enable enterprise IdP policy controls during MCP OAuth flows | Final | Standards Track | 2025-06-04 |
59| [SEP-986](/seps/986-specify-format-for-tool-names.md) | Specify Format for Tool Names | Final | Standards Track | 2025-07-16 |
60| [SEP-985](/seps/985-align-oauth-20-protected-resource-metadata-with-rf.md) | Align OAuth 2.0 Protected Resource Metadata with RFC 9728 | Final | Standards Track | 2025-07-16 |
61| [SEP-973](/seps/973-expose-additional-metadata-for-implementations-res.md) | Expose additional metadata for Implementations, Resources, Tools and Prompts | Final | Standards Track | 2025-07-15 |
62| [SEP-932](/seps/932-model-context-protocol-governance.md) | Model Context Protocol Governance | Final | Process | 2025-07-08 |
63| [SEP-414](/seps/414-request-meta.md) | Document OpenTelemetry Trace Context Propagation Conventions | Final | Standards Track | 2025-04-25 |
21| [SEP-2663](https://modelcontextprotocol.io/seps/2663-tasks-extension.md) | Tasks Extension | Final | Extensions Track | 2026-04-27 |
22| [SEP-2640](https://modelcontextprotocol.io/seps/2640-skills-extension.md) | Skills Extension | Final | Extensions Track | 2026-04-23 |
23| [SEP-2596](https://modelcontextprotocol.io/seps/2596-spec-feature-lifecycle-and-deprecation.md) | Specification Feature Lifecycle and Deprecation Policy | Final | Process | 2026-04-17 |
24| [SEP-2577](https://modelcontextprotocol.io/seps/2577-deprecate-roots-sampling-and-logging.md) | Deprecate Roots, Sampling, and Logging | Final | Standards Track | 2026-04-14 |
25| [SEP-2575](https://modelcontextprotocol.io/seps/2575-stateless-mcp.md) | Make MCP Stateless | Final | Standards Track | 2025-06-18 |
26| [SEP-2567](https://modelcontextprotocol.io/seps/2567-sessionless-mcp.md) | Sessionless MCP via Explicit State Handles | Final | Standards Track | 2026-03-11 |
27| [SEP-2549](https://modelcontextprotocol.io/seps/2549-TTL-for-list-results.md) | TTL for List Results | Final | Standards Track | 2026-04-09 |
28| [SEP-2484](https://modelcontextprotocol.io/seps/2484-conformance-tests-required-for-final-seps.md) | Require Conformance Tests for Standards Track SEPs to Reach Final Status | Final | Process | 2026-03-27 |
29| [SEP-2468](https://modelcontextprotocol.io/seps/2468-recommend-issuer-claim-for-auth.md) | Recommend Issuer (iss) Parameter in MCP Auth Responses | Final | Standards Track | 2026-03-25 |
30| [SEP-2322](https://modelcontextprotocol.io/seps/2322-MRTR.md) | Multi Round-Trip Requests | Final | Standards Track | 2026-02-03 |
31| [SEP-2260](https://modelcontextprotocol.io/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md) | Require Server requests to be associated with a Client request. | Final | Standards Track | 2026-02-16 |
32| [SEP-2243](https://modelcontextprotocol.io/seps/2243-http-standardization.md) | HTTP Header Standardization for Streamable HTTP Transport | Final | Standards Track | 2026-02-04 |
33| [SEP-2207](https://modelcontextprotocol.io/seps/2207-oidc-refresh-token-guidance.md) | OIDC-Flavored Refresh Token Guidance | Final | Standards Track | 2026-02-04 |
34| [SEP-2164](https://modelcontextprotocol.io/seps/2164-resource-not-found-error.md) | Standardize Resource Not Found Error Code | Final | Standards Track | 2026-01-28 |
35| [SEP-2149](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md) | MCP Group Governance and Charter Template | Final | Process | 2025-01-15 |
36| [SEP-2148](https://modelcontextprotocol.io/seps/2148-contributor-ladder.md) | MCP Contributor Ladder | Final | Process | 2026-01-15 |
37| [SEP-2133](https://modelcontextprotocol.io/seps/2133-extensions.md) | Extensions | Final | Standards Track | 2025-01-21 |
38| [SEP-2127](https://modelcontextprotocol.io/seps/2127-mcp-server-cards.md) | MCP Server Cards - HTTP Server Discovery | Final | Extensions Track | 2026-01-21 |
39| [SEP-2106](https://modelcontextprotocol.io/seps/2106-json-schema-2020-12.md) | Tools `inputSchema` & `outputSchema` Conform to JSON Schema 2020-12 | Final | Standards Track | 2026-01-06 |
40| [SEP-2085](https://modelcontextprotocol.io/seps/2085-governance-succession-and-amendment.md) | Governance Succession and Amendment Procedures | Final | Process | 2025-12-05 |
41| [SEP-1865](https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md) | MCP Apps - Interactive User Interfaces for MCP | Final | Extensions Track | 2025-11-21 |
42| [SEP-1850](https://modelcontextprotocol.io/seps/1850-pr-based-sep-workflow.md) | PR-Based SEP Workflow | Final | Process | 2025-11-20 |
43| [SEP-1730](https://modelcontextprotocol.io/seps/1730-sdks-tiering-system.md) | SDKs Tiering System | Final | Standards Track | 2025-10-29 |
44| [SEP-1699](https://modelcontextprotocol.io/seps/1699-support-sse-polling-via-server-side-disconnect.md) | Support SSE polling via server-side disconnect | Final | Standards Track | 2025-10-22 |
45| [SEP-1686](https://modelcontextprotocol.io/seps/1686-tasks.md) | Tasks | Final | Standards Track | 2025-10-20 |
46| [SEP-1613](https://modelcontextprotocol.io/seps/1613-establish-json-schema-2020-12-as-default-dialect-f.md) | Establish JSON Schema 2020-12 as Default Dialect for MCP | Final | Standards Track | 2025-10-06 |
47| [SEP-1577](https://modelcontextprotocol.io/seps/1577--sampling-with-tools.md) | Sampling With Tools | Final | Standards Track | 2025-09-30 |
48| [SEP-1330](https://modelcontextprotocol.io/seps/1330-elicitation-enum-schema-improvements-and-standards.md) | Elicitation Enum Schema Improvements and Standards Compliance | Final | Standards Track | 2025-08-11 |
49| [SEP-1319](https://modelcontextprotocol.io/seps/1319-decouple-request-payload-from-rpc-methods-definiti.md) | Decouple Request Payload from RPC Methods Definition | Final | Standards Track | 2025-08-08 |
50| [SEP-1303](https://modelcontextprotocol.io/seps/1303-input-validation-errors-as-tool-execution-errors.md) | Input Validation Errors as Tool Execution Errors | Final | Standards Track | 2025-08-05 |
51| [SEP-1302](https://modelcontextprotocol.io/seps/1302-formalize-working-groups-and-interest-groups-in-mc.md) | Formalize Working Groups and Interest Groups in MCP Governance | Final | Standards Track | 2025-08-05 |
52| [SEP-1046](https://modelcontextprotocol.io/seps/1046-support-oauth-client-credentials-flow-in-authoriza.md) | Support OAuth client credentials flow in authorization | Final | Standards Track | 2025-07-23 |
53| [SEP-1036](https://modelcontextprotocol.io/seps/1036-url-mode-elicitation-for-secure-out-of-band-intera.md) | URL Mode Elicitation for secure out-of-band interactions | Final | Standards Track | 2025-07-22 |
54| [SEP-1034](https://modelcontextprotocol.io/seps/1034--support-default-values-for-all-primitive-types-in.md) | Support default values for all primitive types in elicitation schemas | Final | Standards Track | 2025-07-22 |
55| [SEP-1024](https://modelcontextprotocol.io/seps/1024-mcp-client-security-requirements-for-local-server-.md) | MCP Client Security Requirements for Local Server Installation | Final | Standards Track | 2025-07-22 |
56| [SEP-994](https://modelcontextprotocol.io/seps/994-shared-communication-practicesguidelines.md) | Shared Communication Practices/Guidelines | Final | Process | 2025-07-17 |
57| [SEP-991](https://modelcontextprotocol.io/seps/991-enable-url-based-client-registration-using-oauth-c.md) | Enable URL-based Client Registration using OAuth Client ID Metadata Documents | Final | Standards Track | 2025-07-07 |
58| [SEP-990](https://modelcontextprotocol.io/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o.md) | Enable enterprise IdP policy controls during MCP OAuth flows | Final | Standards Track | 2025-06-04 |
59| [SEP-986](https://modelcontextprotocol.io/seps/986-specify-format-for-tool-names.md) | Specify Format for Tool Names | Final | Standards Track | 2025-07-16 |
60| [SEP-985](https://modelcontextprotocol.io/seps/985-align-oauth-20-protected-resource-metadata-with-rf.md) | Align OAuth 2.0 Protected Resource Metadata with RFC 9728 | Final | Standards Track | 2025-07-16 |
61| [SEP-973](https://modelcontextprotocol.io/seps/973-expose-additional-metadata-for-implementations-res.md) | Expose additional metadata for Implementations, Resources, Tools and Prompts | Final | Standards Track | 2025-07-15 |
62| [SEP-932](https://modelcontextprotocol.io/seps/932-model-context-protocol-governance.md) | Model Context Protocol Governance | Final | Process | 2025-07-08 |
63| [SEP-414](https://modelcontextprotocol.io/seps/414-request-meta.md) | Document OpenTelemetry Trace Context Propagation Conventions | Final | Standards Track | 2025-04-25 |
6464
6565## SEP Status Definitions
6666
specification/2024-11-05/basic/index Changed · +6 / -6 lines
from line 35
3535
3636See the following pages for more details on the different components:
3737
38> **[Lifecycle](/specification/2024-11-05/basic/lifecycle.md)**
38> **[Lifecycle](https://modelcontextprotocol.io/specification/2024-11-05/basic/lifecycle.md)**
3939
40> **[Resources](/specification/2024-11-05/server/resources.md)**
40> **[Resources](https://modelcontextprotocol.io/specification/2024-11-05/server/resources.md)**
4141
42> **[Prompts](/specification/2024-11-05/server/prompts.md)**
42> **[Prompts](https://modelcontextprotocol.io/specification/2024-11-05/server/prompts.md)**
4343
44> **[Tools](/specification/2024-11-05/server/tools.md)**
44> **[Tools](https://modelcontextprotocol.io/specification/2024-11-05/server/tools.md)**
4545
46> **[Logging](/specification/2024-11-05/server/utilities/logging.md)**
46> **[Logging](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/logging.md)**
4747
48> **[Sampling](/specification/2024-11-05/client/sampling.md)**
48> **[Sampling](https://modelcontextprotocol.io/specification/2024-11-05/client/sampling.md)**
4949
5050## Auth
5151
specification/2024-11-05/basic/lifecycle Changed · +11 / -11 lines
from line 107
107107```
108108
109109* The client **SHOULD NOT** send requests other than
110 [pings](/specification/2024-11-05/basic/utilities/ping.md) before the server
110 [pings](https://modelcontextprotocol.io/specification/2024-11-05/basic/utilities/ping.md) before the server
111111 has responded to the `initialize` request.
112112* The server **SHOULD NOT** send requests other than
113 [pings](/specification/2024-11-05/basic/utilities/ping.md) and
114 [logging](/specification/2024-11-05/server/utilities/logging.md) before
113 [pings](https://modelcontextprotocol.io/specification/2024-11-05/basic/utilities/ping.md) and
114 [logging](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/logging.md) before
115115 receiving the `initialized` notification.
116116
117117#### Version Negotiation
from line 135
135135
136136| Category | Capability | Description |
137137| - | - | - |
138| Client | `roots` | Ability to provide filesystem [roots](/specification/2024-11-05/client/roots.md) |
139| Client | `sampling` | Support for LLM [sampling](/specification/2024-11-05/client/sampling.md) requests |
138| Client | `roots` | Ability to provide filesystem [roots](https://modelcontextprotocol.io/specification/2024-11-05/client/roots.md) |
139| Client | `sampling` | Support for LLM [sampling](https://modelcontextprotocol.io/specification/2024-11-05/client/sampling.md) requests |
140140| Client | `experimental` | Describes support for non-standard experimental features |
141| Server | `prompts` | Offers [prompt templates](/specification/2024-11-05/server/prompts.md) |
142| Server | `resources` | Provides readable [resources](/specification/2024-11-05/server/resources.md) |
143| Server | `tools` | Exposes callable [tools](/specification/2024-11-05/server/tools.md) |
144| Server | `logging` | Emits structured [log messages](/specification/2024-11-05/server/utilities/logging.md) |
141| Server | `prompts` | Offers [prompt templates](https://modelcontextprotocol.io/specification/2024-11-05/server/prompts.md) |
142| Server | `resources` | Provides readable [resources](https://modelcontextprotocol.io/specification/2024-11-05/server/resources.md) |
143| Server | `tools` | Exposes callable [tools](https://modelcontextprotocol.io/specification/2024-11-05/server/tools.md) |
144| Server | `logging` | Emits structured [log messages](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/logging.md) |
145145| Server | `experimental` | Describes support for non-standard experimental features |
146146
147147Capability objects can describe sub-capabilities like:
from line 168
168168
169169#### stdio
170170
171For the stdio [transport](/specification/2024-11-05/basic/transports.md), the
171For the stdio [transport](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports.md), the
172172client **SHOULD** initiate shutdown by:
173173
1741741. First, closing the input stream to the child process (the server)
from line 181
181181
182182#### HTTP
183183
184For HTTP [transports](/specification/2024-11-05/basic/transports.md), shutdown
184For HTTP [transports](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports.md), shutdown
185185is indicated by closing the associated HTTP connection(s).
186186
187187## Error Handling
specification/2024-11-05/index Changed · +5 / -5 lines
from line 116
116116
117117Explore the detailed specification for each protocol component:
118118
119> **[Architecture](/specification/2024-11-05/architecture.md)**
119> **[Architecture](https://modelcontextprotocol.io/specification/2024-11-05/architecture.md)**
120120
121> **[Base Protocol](/specification/2024-11-05/basic.md)**
121> **[Base Protocol](https://modelcontextprotocol.io/specification/2024-11-05/basic.md)**
122122
123> **[Server Features](/specification/2024-11-05/server.md)**
123> **[Server Features](https://modelcontextprotocol.io/specification/2024-11-05/server.md)**
124124
125> **[Client Features](/specification/2024-11-05/client)**
125> **[Client Features](https://modelcontextprotocol.io/specification/2024-11-05/client)**
126126
127> **[Contributing](/community/contributing.md)**
127> **[Contributing](https://modelcontextprotocol.io/community/contributing.md)**
128128
specification/2024-11-05/server/index Changed · +3 / -3 lines
from line 20
2020
2121Explore these key primitives in more detail below:
2222
23> **[Prompts](/specification/2024-11-05/server/prompts.md)**
23> **[Prompts](https://modelcontextprotocol.io/specification/2024-11-05/server/prompts.md)**
2424
25> **[Resources](/specification/2024-11-05/server/resources.md)**
25> **[Resources](https://modelcontextprotocol.io/specification/2024-11-05/server/resources.md)**
2626
27> **[Tools](/specification/2024-11-05/server/tools.md)**
27> **[Tools](https://modelcontextprotocol.io/specification/2024-11-05/server/tools.md)**
2828
specification/2024-11-05/server/prompts Changed · +3 / -3 lines
from line 24
2424## Capabilities
2525
2626Servers that support prompts **MUST** declare the `prompts` capability during
27[initialization](/specification/2024-11-05/basic/lifecycle.md#initialization):
27[initialization](https://modelcontextprotocol.io/specification/2024-11-05/basic/lifecycle.md#initialization):
2828
2929```json theme={null}
3030{
from line 45
4545
4646To retrieve available prompts, clients send a `prompts/list` request. This operation
4747supports
48[pagination](/specification/2024-11-05/server/utilities/pagination.md).
48[pagination](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/pagination.md).
4949
5050**Request:**
5151
from line 88
8888### Getting a Prompt
8989
9090To retrieve a specific prompt, clients send a `prompts/get` request. Arguments may be
91auto-completed through [the completion API](/specification/2024-11-05/server/utilities/completion.md).
91auto-completed through [the completion API](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/completion.md).
9292
9393**Request:**
9494
specification/2024-11-05/server/resources Changed · +3 / -3 lines
from line 82
8282
8383To discover available resources, clients send a `resources/list` request. This operation
8484supports
85[pagination](/specification/2024-11-05/server/utilities/pagination.md).
85[pagination](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/pagination.md).
8686
8787**Request:**
8888
from line 156
156156
157157Resource templates allow servers to expose parameterized resources using
158158[URI templates](https://datatracker.ietf.org/doc/html/rfc6570). Arguments may be
159auto-completed through [the completion API](/specification/2024-11-05/server/utilities/completion.md).
159auto-completed through [the completion API](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/completion.md).
160160This operation supports
161[pagination](/specification/2024-11-05/server/utilities/pagination.md).
161[pagination](https://modelcontextprotocol.io/specification/2024-11-05/server/utilities/pagination.md).
162162
163163**Request:**
164164
specification/2025-03-26/basic/lifecycle Changed · +14 / -14 lines
from line 114
114114```
115115
116116* The client **SHOULD NOT** send requests other than
117 [pings](/specification/2025-03-26/basic/utilities/ping.md) before the server has responded to the
117 [pings](https://modelcontextprotocol.io/specification/2025-03-26/basic/utilities/ping.md) before the server has responded to the
118118 `initialize` request.
119119* The server **SHOULD NOT** send requests other than
120 [pings](/specification/2025-03-26/basic/utilities/ping.md) and
121 [logging](/specification/2025-03-26/server/utilities/logging.md) before receiving the `initialized`
120 [pings](https://modelcontextprotocol.io/specification/2025-03-26/basic/utilities/ping.md) and
121 [logging](https://modelcontextprotocol.io/specification/2025-03-26/server/utilities/logging.md) before receiving the `initialized`
122122 notification.
123123
124124#### Version Negotiation
from line 142
142142
143143| Category | Capability | Description |
144144| - | - | - |
145| Client | `roots` | Ability to provide filesystem [roots](/specification/2025-03-26/client/roots.md) |
146| Client | `sampling` | Support for LLM [sampling](/specification/2025-03-26/client/sampling.md) requests |
145| Client | `roots` | Ability to provide filesystem [roots](https://modelcontextprotocol.io/specification/2025-03-26/client/roots.md) |
146| Client | `sampling` | Support for LLM [sampling](https://modelcontextprotocol.io/specification/2025-03-26/client/sampling.md) requests |
147147| Client | `experimental` | Describes support for non-standard experimental features |
148| Server | `prompts` | Offers [prompt templates](/specification/2025-03-26/server/prompts.md) |
149| Server | `resources` | Provides readable [resources](/specification/2025-03-26/server/resources.md) |
150| Server | `tools` | Exposes callable [tools](/specification/2025-03-26/server/tools.md) |
151| Server | `logging` | Emits structured [log messages](/specification/2025-03-26/server/utilities/logging.md) |
152| Server | `completions` | Supports argument [autocompletion](/specification/2025-03-26/server/utilities/completion.md) |
148| Server | `prompts` | Offers [prompt templates](https://modelcontextprotocol.io/specification/2025-03-26/server/prompts.md) |
149| Server | `resources` | Provides readable [resources](https://modelcontextprotocol.io/specification/2025-03-26/server/resources.md) |
150| Server | `tools` | Exposes callable [tools](https://modelcontextprotocol.io/specification/2025-03-26/server/tools.md) |
151| Server | `logging` | Emits structured [log messages](https://modelcontextprotocol.io/specification/2025-03-26/server/utilities/logging.md) |
152| Server | `completions` | Supports argument [autocompletion](https://modelcontextprotocol.io/specification/2025-03-26/server/utilities/completion.md) |
153153| Server | `experimental` | Describes support for non-standard experimental features |
154154
155155Capability objects can describe sub-capabilities like:
from line 176
176176
177177#### stdio
178178
179For the stdio [transport](/specification/2025-03-26/basic/transports.md), the client **SHOULD** initiate
179For the stdio [transport](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports.md), the client **SHOULD** initiate
180180shutdown by:
181181
1821821. First, closing the input stream to the child process (the server)
from line 189
189189
190190#### HTTP
191191
192For HTTP [transports](/specification/2025-03-26/basic/transports.md), shutdown is indicated by closing the
192For HTTP [transports](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports.md), shutdown is indicated by closing the
193193associated HTTP connection(s).
194194
195195## Timeouts
from line 197
197197Implementations **SHOULD** establish timeouts for all sent requests, to prevent hung
198198connections and resource exhaustion. When the request has not received a success or error
199199response within the timeout period, the sender **SHOULD** issue a [cancellation
200notification](/specification/2025-03-26/basic/utilities/cancellation.md) for that request and stop waiting for
200notification](https://modelcontextprotocol.io/specification/2025-03-26/basic/utilities/cancellation.md) for that request and stop waiting for
201201a response.
202202
203203SDKs and other middleware **SHOULD** allow these timeouts to be configured on a
from line 204
204204per-request basis.
205205
206206Implementations **MAY** choose to reset the timeout clock when receiving a [progress
207notification](/specification/2025-03-26/basic/utilities/progress.md) corresponding to the request, as this
207notification](https://modelcontextprotocol.io/specification/2025-03-26/basic/utilities/progress.md) corresponding to the request, as this
208208implies that work is actually happening. However, implementations **SHOULD** always
209209enforce a maximum timeout, regardless of progress notifications, to limit the impact of a
210210misbehaving client or server.
specification/2025-03-26/basic/transports Changed · +3 / -3 lines
from line 50
5050> [!NOTE]
5151>
5252> This replaces the [HTTP+SSE
53> transport](/specification/2024-11-05/basic/transports.md#http-with-sse) from
53> transport](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports.md#http-with-sse) from
5454> protocol version 2024-11-05. See the [backwards compatibility](#backwards-compatibility)
5555> guide below.
5656
from line 176
176176### Session Management
177177
178178An MCP "session" consists of logically related interactions between a client and a
179server, beginning with the [initialization phase](/specification/2025-03-26/basic/lifecycle.md). To support
179server, beginning with the [initialization phase](https://modelcontextprotocol.io/specification/2025-03-26/basic/lifecycle.md). To support
180180servers which want to establish stateful sessions:
181181
1821821. A server using the Streamable HTTP transport **MAY** assign a session ID at
from line 246
246246### Backwards Compatibility
247247
248248Clients and servers can maintain backwards compatibility with the deprecated [HTTP+SSE
249transport](/specification/2024-11-05/basic/transports.md#http-with-sse) (from
249transport](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports.md#http-with-sse) (from
250250protocol version 2024-11-05) as follows:
251251
252252**Servers** wanting to support older clients should:
specification/2025-03-26/changelog Changed · +3 / -3 lines
from line 1
11# Key Changes
22
33This document lists changes made to the Model Context Protocol (MCP) specification since
4the previous revision, [2024-11-05](/specification/2024-11-05.md).
4the previous revision, [2024-11-05](https://modelcontextprotocol.io/specification/2024-11-05.md).
55
66## Major changes
77
81. Added a comprehensive **[authorization framework](/specification/2025-03-26/basic/authorization.md)**
81. Added a comprehensive **[authorization framework](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization.md)**
99 based on OAuth 2.1 (PR
1010 [#133](https://github.com/modelcontextprotocol/specification/pull/133))
11112. Replaced the previous HTTP+SSE transport with a more flexible **[Streamable HTTP
12 transport](/specification/2025-03-26/basic/transports.md#streamable-http)** (PR
12 transport](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports.md#streamable-http)** (PR
1313 [#206](https://github.com/modelcontextprotocol/specification/pull/206))
14143. Added support for JSON-RPC **[batching](https://www.jsonrpc.org/specification#batch)**
1515 (PR [#228](https://github.com/modelcontextprotocol/specification/pull/228))
specification/2025-03-26/index Changed · +5 / -5 lines
from line 118
118118
119119Explore the detailed specification for each protocol component:
120120
121> **[Architecture](/specification/2025-03-26/architecture.md)**
121> **[Architecture](https://modelcontextprotocol.io/specification/2025-03-26/architecture.md)**
122122
123> **[Base Protocol](/specification/2025-03-26/basic.md)**
123> **[Base Protocol](https://modelcontextprotocol.io/specification/2025-03-26/basic.md)**
124124
125> **[Server Features](/specification/2025-03-26/server.md)**
125> **[Server Features](https://modelcontextprotocol.io/specification/2025-03-26/server.md)**
126126
127> **[Client Features](/specification/2025-03-26/client)**
127> **[Client Features](https://modelcontextprotocol.io/specification/2025-03-26/client)**
128128
129> **[Contributing](/community/contributing.md)**
129> **[Contributing](https://modelcontextprotocol.io/community/contributing.md)**
130130
specification/2025-03-26/server/index Changed · +3 / -3 lines
from line 20
2020
2121Explore these key primitives in more detail below:
2222
23> **[Prompts](/specification/2025-03-26/server/prompts.md)**
23> **[Prompts](https://modelcontextprotocol.io/specification/2025-03-26/server/prompts.md)**
2424
25> **[Resources](/specification/2025-03-26/server/resources.md)**
25> **[Resources](https://modelcontextprotocol.io/specification/2025-03-26/server/resources.md)**
2626
27> **[Tools](/specification/2025-03-26/server/tools.md)**
27> **[Tools](https://modelcontextprotocol.io/specification/2025-03-26/server/tools.md)**
2828
specification/2025-03-26/server/prompts Changed · +3 / -3 lines
from line 24
2424## Capabilities
2525
2626Servers that support prompts **MUST** declare the `prompts` capability during
27[initialization](/specification/2025-03-26/basic/lifecycle.md#initialization):
27[initialization](https://modelcontextprotocol.io/specification/2025-03-26/basic/lifecycle.md#initialization):
2828
2929```json theme={null}
3030{
from line 44
4444### Listing Prompts
4545
4646To retrieve available prompts, clients send a `prompts/list` request. This operation
47supports [pagination](/specification/2025-03-26/server/utilities/pagination.md).
47supports [pagination](https://modelcontextprotocol.io/specification/2025-03-26/server/utilities/pagination.md).
4848
4949**Request:**
5050
from line 87
8787### Getting a Prompt
8888
8989To retrieve a specific prompt, clients send a `prompts/get` request. Arguments may be
90auto-completed through [the completion API](/specification/2025-03-26/server/utilities/completion.md).
90auto-completed through [the completion API](https://modelcontextprotocol.io/specification/2025-03-26/server/utilities/completion.md).
9191
9292**Request:**
9393