mcp-20261022T203719Z / page 6 of 12 / documentation capture

extensions/skills/overview Changed · +9 / -9 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) is Final.

7(`io.modelcontextprotocol/skills`). [SEP-2640](/seps/2640-skills-extension.md) is Final.

88

9The [Skills Over MCP Working Group](/community/working-groups/skills-over-mcp)

9The [Skills Over MCP Working Group](/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) and

11see the [client support matrix](/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 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#_meta).

75> [request metadata](/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)

83and [caching](/specification/draft/server/utilities/caching).

82operation supports [pagination](/specification/draft/server/utilities/pagination.md)

83and [caching](/specification/draft/server/utilities/caching.md).

8484

8585**Request:**

8686

from line 428

428428

429429## Client Support

430430

431See the [client matrix](/extensions/client-matrix) for Skills support and links

431See the [client matrix](/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).

437Development is coordinated by the [Skills Over MCP Working Group](/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). Host

245> MCP Tasks is an extension to the [core MCP specification](/specification/latest.md). Host

246246> support varies by client.

247247

248See the [client matrix](/extensions/client-matrix) for extension support across

248See the [client matrix](/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#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](/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).

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](./package-types) 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](/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-aggregators) 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](/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](./authentication).

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).

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](./moderation-policy) for details on what content is removed.

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.

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](./authentication). 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](/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](./package-types).

280* Learn about [support for remote servers](./remote-servers).

281* Learn how to [use other authentication methods](./authentication), such as [DNS authentication](./authentication#dns-authentication) which enables custom domains for server name prefixes.

282* Learn how to [automate publishing with GitHub Actions](./github-actions).

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).

283283

seps/1036-url-mode-elicitation-for-secure-out-of-band-intera 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) and its changelog for authoritative

14> specification](/specification/latest.md) and its changelog for authoritative

1515> requirements.

1616

1717| Field | Value |

from line 36

3636The current MCP specification (2025-06-18) provides an elicitation mechanism for gathering non-sensitive information from users through structured, in-band requests (most commonly imagined as the MCP client rendering a form to collect data from the end-user). However, several critical use cases require interactions that must not pass through the MCP client:

3737

38381. Sensitive data collection: API keys, passwords, and other credentials must never transit through intermediary systems.

392. External authorization: MCP servers often need to access third-party APIs on behalf of users. The MCP authorization specification only covers client-to-server authorization, not server-to-third-party authorization. The [Security Best Practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) document explicitly forbids token passthrough, requiring a secure mechanism for external (3rd-party) OAuth flows. This was a particularly important motivating factor emerging from discussions in #234 and #284.

392. External authorization: MCP servers often need to access third-party APIs on behalf of users. The MCP authorization specification only covers client-to-server authorization, not server-to-third-party authorization. The [Security Best Practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices.md) document explicitly forbids token passthrough, requiring a secure mechanism for external (3rd-party) OAuth flows. This was a particularly important motivating factor emerging from discussions in #234 and #284.

40403. Payment and Subscription Flows: Financial transactions require PCI compliance and secure payment processing that cannot be achieved through in-band data collection.

4141

4242Without a standardized mechanism for these interactions, MCP servers must resort to non-standard workarounds or insecure practices like requesting API keys through in-band, form-style elicitation. This SEP addresses these gaps by introducing a URL elicitation mode that leverages established web security patterns to handle sensitive interactions securely.

4343

44URL elicitation is fundamentally different from [MCP authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization). URL elicitation is not for authorizing the MCP client's access to the MCP server (that's handled directly by MCP authorization). Instead, it's used when the MCP server needs to obtain sensitive information or third-party authorization on behalf of the user. The MCP client's bearer token remains unchanged, and the client's only responsibility is to provide the user with context about the elicitation URL the server wants them to open.

44URL elicitation is fundamentally different from [MCP authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization.md). URL elicitation is not for authorizing the MCP client's access to the MCP server (that's handled directly by MCP authorization). Instead, it's used when the MCP server needs to obtain sensitive information or third-party authorization on behalf of the user. The MCP client's bearer token remains unchanged, and the client's only responsibility is to provide the user with context about the elicitation URL the server wants them to open.

4545

4646## Specification

4747

from line 215

215215

216216It is tempting to suggest that the MCP client should perform the interaction itself, e.g. act as an OAuth client to a third-party authorization server. However, there are several reasons why this is not a good idea:

217217

218* If the MCP client obtains user tokens from a third-party authorization server, the MCP server becomes a [token passthrough](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices#token-passthrough) server, which is explicitly forbidden.

218* If the MCP client obtains user tokens from a third-party authorization server, the MCP server becomes a [token passthrough](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices.md#token-passthrough) server, which is explicitly forbidden.

219219* Similarly, for payment-type flows, the MCP client would need to perform PCI-compliant payment processing, which is not a desired requirement for MCP clients.

220220

221221**Why doesn't the server block (wait) on the elicitation to complete?**

seps/1303-input-validation-errors-as-tool-execution-errors Changed · +3 / -3 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) and its changelog for authoritative

14> specification](/specification/latest.md) and its changelog for authoritative

1515> requirements.

1616

1717| Field | Value |

from line 76

7676

7777### Current Behavior

7878

79The [tool errors specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools#error-handling) currently provides ambiguous guidance:

79The [tool errors specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools.md#error-handling) currently provides ambiguous guidance:

8080

8181* "Invalid arguments" should be treated as Protocol Error

8282* "Invalid input data" should be treated as Tool Execution Error

from line 194

194194

195195## References

196196

197* [MCP Tools Error Handling Specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools#error-handling)

197* [MCP Tools Error Handling Specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools.md#error-handling)

198198* [Better MCP tools/call Error Responses: Help Your AI Recover Gracefully](https://dev.to/alpic/better-mcp-toolscall-error-responses-help-your-ai-recover-gracefully-15c7)

199199* Related Issue: [https://github.com/modelcontextprotocol/typescript-sdk/pull/824](https://github.com/modelcontextprotocol/typescript-sdk/pull/824)

200200

seps/1577--sampling-with-tools Changed · +12 / -12 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) and its changelog for authoritative

14> specification](/specification/latest.md) and its changelog for authoritative

1515> requirements.

1616

1717| Field | Value |

from line 33

3333

3434## Motivation

3535

36* [Sampling](https://modelcontextprotocol.io/specification/2025-06-18/client/sampling) doesn't support tool calling, although it's a cornerstone of modern agentic behaviour. Without explicit support for it, MCP servers that use Sampling can either try and emulate tool calling w/ complex prompting / custom parsing of the outputs, or are limited to simpler, non-agentic requests. Adding support for tool calling could unlock many novel use cases in the MCP ecosystem.

36* [Sampling](https://modelcontextprotocol.io/specification/2025-06-18/client/sampling.md) doesn't support tool calling, although it's a cornerstone of modern agentic behaviour. Without explicit support for it, MCP servers that use Sampling can either try and emulate tool calling w/ complex prompting / custom parsing of the outputs, or are limited to simpler, non-agentic requests. Adding support for tool calling could unlock many novel use cases in the MCP ecosystem.

3737

38* Context inclusion is ambiguously defined (see [this doc](https://docs.google.com/document/d/1KUsloHpsjR4fdXdJuofb9jUuK0XWi88clbRm9sWE510/edit?tab=t.0#heading=h.edw7oyac2e87)): it makes it particularly tricky to fully implement sampling, which along with other precautions needed for sampling (unaffected by this SEP) may have contributed to [low adoption of the feature in clients](https://modelcontextprotocol.io/clients#feature-support-matrix) (feature was introduced in the MCP Nov 2024 spec).

38* Context inclusion is ambiguously defined (see [this doc](https://docs.google.com/document/d/1KUsloHpsjR4fdXdJuofb9jUuK0XWi88clbRm9sWE510/edit?tab=t.0#heading=h.edw7oyac2e87)): it makes it particularly tricky to fully implement sampling, which along with other precautions needed for sampling (unaffected by this SEP) may have contributed to [low adoption of the feature in clients](https://modelcontextprotocol.io/clients.md#feature-support-matrix) (feature was introduced in the MCP Nov 2024 spec).

3939

4040Please note some related work:

4141

from line 52

5252

5353### Overview

5454

55* Add traditional tool call support in [CreateMessageRequest](https://modelcontextprotocol.io/specification/2025-06-18/schema#createmessagerequest) w/ `tools` (w/ JSON schemas) & `toolChoice` params, requiring a server-side tool loop

55* Add traditional tool call support in [CreateMessageRequest](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#createmessagerequest) w/ `tools` (w/ JSON schemas) & `toolChoice` params, requiring a server-side tool loop

5656 * Sampling may now yield ToolCallBlock responses

5757 * Server needs to call tools by itself

5858 * Server calls sampling again with ToolResultParamBlock to inject tool results

5959 * `toolChoice.mode` can be `“auto" | "required" | "none"` to allow common structured outputs use case (see below for possible follow up improvements)

6060 * Fenced by new capability (`sampling { tools {} }`)

61* Fix/update underspecified strings in [CreateMessageResult](https://modelcontextprotocol.io/specification/2025-06-18/schema#createmessageresult):

61* Fix/update underspecified strings in [CreateMessageResult](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#createmessageresult):

6262 * `stopReason: “endTurn" | "stopSequence" | “toolUse" | “maxToken" | string` (explicit enums + open string for compat)

6363 * `role: “assistant”`

64* Soft-deprecate [CreateMessageRequest.params.includeContext](https://modelcontextprotocol.io/specification/2025-06-18/schema#createmessagerequest) != ‘none’ (now fenced by capability)

64* Soft-deprecate [CreateMessageRequest.params.includeContext](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#createmessagerequest) != ‘none’ (now fenced by capability)

6565 * Incentivize context-free sampling implementation

6666

6767### Protocol changes

from line 76

7676

7777### Schema changes

7878

79* [ClientCapabilities](https://modelcontextprotocol.io/specification/2025-06-18/schema#clientcapabilities)

79* [ClientCapabilities](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#clientcapabilities)

8080

8181 ```typescript theme={null}

8282 interface ClientCapabilities {

from line 88

8888 }

8989 ```

9090

91* [CreateMessageRequest](https://modelcontextprotocol.io/specification/2025-06-18/schema#createmessagerequest) (use existing [Tool](https://modelcontextprotocol.io/specification/2025-06-18/schema#tool))

91* [CreateMessageRequest](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#createmessagerequest) (use existing [Tool](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#tool))

9292

9393 ```typescript theme={null}

9494 interface CreateMessageRequest {

from line 122

122122 * Gemini API has no way to disable parallel tool calls atm (unlike OAI / Anthropic APIs). Removing this flag for now, to be reintroduced when Gemini has any way of supporting it. Otherwise clients would get unexpected multiple tool calls (or alternatively if implemented that way, unexpected failures / costly retry until a single tool call is emitted)

123123 * Gemini API's [Function calling modes](https://ai.google.dev/gemini-api/docs/function-calling?example=meeting#function_calling_modes) have an `ANY` value that should match the proposed `required`

124124

125* [SamplingMessage](https://modelcontextprotocol.io/specification/2025-06-18/schema#samplingmessage):

125* [SamplingMessage](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#samplingmessage):

126126

127127 ```typescript theme={null}

128128 /*

from line 240

240240 * `function` role (similar to OAI's `tool` role)

241241 * No tool call id concept ([function calling](https://ai.google.dev/gemini-api/docs/function-calling?example=meeting#parallel_function_calling): Gemini requires tool results to be provided in the exact same order as the tool use parts. An implementation could generate the tool call ids and use them to reorder the tool results if needed.

242242

243* [CreateMessageResult](https://modelcontextprotocol.io/specification/2025-06-18/schema#createmessageresult)

243* [CreateMessageResult](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#createmessageresult)

244244

245245 ```typescript theme={null}

246246 /*

from line 342

342342Pros:

343343

344344* Technically no spec change needed (if anything, mention this as a freedom clients have)

345* Possibly similar to what [CreateMessageRequest.params.includeContext](https://modelcontextprotocol.io/specification/2025-06-18/schema#createmessagerequest) = thisServer / allServers intended semantics may have meant

345* Possibly similar to what [CreateMessageRequest.params.includeContext](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#createmessagerequest) = thisServer / allServers intended semantics may have meant

346346 * `CreateMessageRequest.params.allowImplicitToolCalls = “none” | “thisServer” | “allServers”`

347347 (assuming we wanted to give the server any control over this)

348348

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) and its changelog for authoritative

14> specification](/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](./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)](./1865-mcp-apps-interactive-user-interfaces-for-mcp.md).

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).

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](./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](/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)](./1865-mcp-apps-interactive-user-interfaces-for-mcp.md)

192* [SEP-2133: Extensions](./2133-extensions.md)

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)

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/2133-extensions Changed · +7 / -7 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) and its changelog for authoritative

14> specification](/specification/latest.md) and its changelog for authoritative

1515> requirements.

1616

1717| Field | Value |

from line 43

4343

4444An MCP extension is an optional addition to the specification that defines 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).

4545

46Extensions are identified using a unique *extension identifier* with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials` or `com.example/websocket-transport`. The names follow the same rules as the [\_meta keys](https://modelcontextprotocol.io/specification/draft/basic/index#meta), except that the prefix is mandatory.

46Extensions are identified using a unique *extension identifier* with the format: `{vendor-prefix}/{extension-name}`, e.g. `io.modelcontextprotocol/oauth-client-credentials` or `com.example/websocket-transport`. The names follow the same rules as the [\_meta keys](https://modelcontextprotocol.io/specification/draft/basic/index.md#meta), except that the prefix is mandatory.

4747

4848To prevent identifier collisions, the vendor prefix SHOULD be a reversed domain name that the extension author owns or controls (similar to Java package naming conventions). For example, a company owning `example.com` would use `com.example/` as their prefix.

4949

from line 89

8989

9090Extensions MAY optionally begin as experimental extensions (see *Experimental Extensions* section) to facilitate prototyping and collaboration before formal submission. This incubation period is encouraged but not required.

9191

92To become an official extension, extensions are created via a SEP in the [main MCP repository](https://github.com/modelcontextprotocol/modelcontextprotocol/) using the [standard SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines) but with a new type: **Extensions Track**. This type follows the same review and acceptance process as Standards Track SEPs, but clearly indicates that the proposal is for an extension rather than a core protocol addition. The SEP must identify the Working Group and Extension Maintainers that will be responsible for the extension. See [SEP-2148](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2148) for how maintainers are appointed.

92To become an official extension, extensions are created via a SEP in the [main MCP repository](https://github.com/modelcontextprotocol/modelcontextprotocol/) using the [standard SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md) but with a new type: **Extensions Track**. This type follows the same review and acceptance process as Standards Track SEPs, but clearly indicates that the proposal is for an extension rather than a core protocol addition. The SEP must identify the Working Group and Extension Maintainers that will be responsible for the extension. See [SEP-2148](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2148) for how maintainers are appointed.

9393

9494Extension SEPs:

9595

from line 110

110110

111111### Spec Recommendation

112112

113Extensions will be referenced from a new page on the MCP website at [modelcontextprotocol.io/extensions](http://modelcontextprotocol.io/extensions) (to be created) with links to their specification.

113Extensions will be referenced from a new page on the MCP website at [modelcontextprotocol.io/extensions](https://modelcontextprotocol.io/extensions.md) (to be created) with links to their specification.

114114

115Links to relevant extensions MAY also be added to the core specification as appropriate (e.g. [https://modelcontextprotocol.io/specification/draft/basic/authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization) may link to ext-auth extensions), but they MUST be clearly advertised as optional extensions and SHOULD be links only (not copies of specification text).

115Links to relevant extensions MAY also be added to the core specification as appropriate (e.g. [https://modelcontextprotocol.io/specification/draft/basic/authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization.md) may link to ext-auth extensions), but they MUST be clearly advertised as optional extensions and SHOULD be links only (not copies of specification text).

116116

117117### SDK Implementation

118118

from line 132

132132

133133### Negotiation

134134

135Clients and servers advertise their support for extensions in the [ClientCapabilities](https://modelcontextprotocol.io/specification/2025-06-18/schema#clientcapabilities) and [ServerCapabilities](https://modelcontextprotocol.io/specification/2025-06-18/schema#servercapabilities) fields respectively, and in the [Server Card](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649) (currently in progress).

135Clients and servers advertise their support for extensions in the [ClientCapabilities](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#clientcapabilities) and [ServerCapabilities](https://modelcontextprotocol.io/specification/2025-06-18/schema.md#servercapabilities) fields respectively, and in the [Server Card](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649) (currently in progress).

136136

137137A new "extensions" field will be introduced to each that is a map of *extension identifiers* to per-extension settings objects. Each extension specifies the schema of its settings object; an empty object indicates no settings.

138138

seps/2148-contributor-ladder Changed · +7 / -7 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) and its changelog for authoritative

14> specification](/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](./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](/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 87

8787

8888**How to get started:**

8989

90* Review the [Contributing Guide](https://modelcontextprotocol.io/community/contributing)

90* Review the [Contributing Guide](https://modelcontextprotocol.io/community/contributing.md)

9191* Join community channels (Discord, GitHub Discussions)

9292* Look for issues tagged `good-first-issue` or `help-wanted`

9393* Attend working group meetings

from line 204

204204**Privileges:**

205205

206206* Final approval on breaking changes and major spec revisions

207* Voting rights on [SEPs](https://modelcontextprotocol.io/community/sep-guidelines) (Specification Enhancement Proposals)

207* Voting rights on [SEPs](https://modelcontextprotocol.io/community/sep-guidelines.md) (Specification Enhancement Proposals)

208208* Approval of Maintainers

209209* Governance voting rights / expectation of governance participation

210210* Administrative rights to all MCP GitHub repositories

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](./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](/seps/2149-working-group-charter-template.md).

280280

281281#### Escalation Matrix

282282

from line 310

310310#### Specification Work

311311

312312* Drafting or refining spec text

313* [SEP](https://modelcontextprotocol.io/community/sep-guidelines) authorship or co-authorship

313* [SEP](https://modelcontextprotocol.io/community/sep-guidelines.md) authorship or co-authorship

314314* Protocol design participation

315315* Compatibility analysis

316316

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](./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](/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) and its changelog for authoritative

14> specification](/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](./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](/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](./2148-contributor-ladder.md)

78* Hold at least Member status on the [MCP Contributor Ladder](/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 98

9898

9999**WG Leads are additionally responsible for:**

100100

101* Drive proposals through the [SEP](https://modelcontextprotocol.io/community/sep-guidelines) (Specification Enhancement Proposal) process to resolution

101* Drive proposals through the [SEP](https://modelcontextprotocol.io/community/sep-guidelines.md) (Specification Enhancement Proposal) process to resolution

102102* Triage SEPs in the WG's scope area, including closing SEPs that do not fit the roadmap (with documented rationale; authors may appeal to Core Maintainers)

103103* Escalate blocked decisions to Core Maintainers with clear context

104104* Maintain the working group's roadmap

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](./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](/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| - | - | - |

seps/2596-spec-feature-lifecycle-and-deprecation Changed · +18 / -18 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) and its changelog for authoritative

14> specification](/specification/latest.md) and its changelog for authoritative

1515> requirements.

1616

1717| Field | Value |

from line 229

229229As with all Core Maintainer decisions, Lead Maintainers retain veto authority over each of the

230230approvals above, per the [governance roles][governance-roles] definition.

231231

232[governance-roles]: https://modelcontextprotocol.io/community/governance#roles

232[governance-roles]: https://modelcontextprotocol.io/community/governance.md#roles

233233

234234### Transition

235235

from line 380

380380 deprecation field on responses, comparable to the Kubernetes `Warning` header) would close that

381381 gap but is a Standards Track change outside the scope of this Process SEP.

382382

383[transports-compat]: https://modelcontextprotocol.io/specification/draft/basic/transports#backwards-compatibility

383[transports-compat]: https://modelcontextprotocol.io/specification/draft/basic/transports.md#backwards-compatibility

384384

385[sampling-includecontext]: https://modelcontextprotocol.io/specification/draft/client/sampling

385[sampling-includecontext]: https://modelcontextprotocol.io/specification/draft/client/sampling.md

386386

387[versioning]: https://modelcontextprotocol.io/docs/learn/versioning

387[versioning]: https://modelcontextprotocol.io/docs/learn/versioning.md

388388

389[design-principles]: https://modelcontextprotocol.io/community/design-principles

389[design-principles]: https://modelcontextprotocol.io/community/design-principles.md

390390

391[sep-guidelines]: https://modelcontextprotocol.io/community/sep-guidelines

391[sep-guidelines]: https://modelcontextprotocol.io/community/sep-guidelines.md

392392

393[governance-decisions]: https://modelcontextprotocol.io/community/governance#decision-process

393[governance-decisions]: https://modelcontextprotocol.io/community/governance.md#decision-process

394394

395[sep-1730]: https://modelcontextprotocol.io/seps/1730-sdks-tiering-system

395[sep-1730]: https://modelcontextprotocol.io/seps/1730-sdks-tiering-system.md

396396

397[sep-1730-relegation]: https://modelcontextprotocol.io/seps/1730-sdks-tiering-system#tier-relegation-process

397[sep-1730-relegation]: https://modelcontextprotocol.io/seps/1730-sdks-tiering-system.md#tier-relegation-process

398398

399399[sep-1400]: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1400

400400

401401[issue-1540]: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1540

402402

403[sep-2577]: https://modelcontextprotocol.io/seps/2577-deprecate-roots-sampling-and-logging

403[sep-2577]: https://modelcontextprotocol.io/seps/2577-deprecate-roots-sampling-and-logging.md

404404

405405[nyc-2026-03-31]: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2547

406406

seps/2663-tasks-extension Changed · +21 / -21 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) and its changelog for authoritative

14> specification](/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) have been [formalized](./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](/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

36This proposal *removes* the version of [tasks](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks) 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:

36This 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](./2260-Require-Server-requests-to-be-associated-with-Client-requests.md)

39* [SEP-2322: Multi Round-Trip Requests](./2322-MRTR.md)

40* [SEP-2243: HTTP Header Standardization for Streamable HTTP Transport](./2243-http-standardization.md)

41* [SEP-2567: Sessionless MCP via Explicit State Handles](./2567-sessionless-mcp.md)

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)

4242* [SEP-2575: Make MCP Stateless](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575)

4343

4444## Motivation

4545

46The experimental [tasks](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks) feature served as an alternate execution mode for tool calls, elicitation, and sampling, allowing receivers to return a poll handle instead of blocking until a final result was ready. Implementation experience surfaced several challenges:

46The experimental [tasks](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks.md) feature served as an alternate execution mode for tool calls, elicitation, and sampling, allowing receivers to return a poll handle instead of blocking until a final result was ready. Implementation experience surfaced several challenges:

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](./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](/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](./1686-tasks.md) permitted clients to host tasks for elicitation and sampling, in part to avoid coupling tasks to tool calls. [SEP-2260](./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](/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.

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](./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](/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](./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](/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](./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](/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](./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](/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](./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](./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](/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).

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](./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](/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](./2322-MRTR.md), but the two are not coupled with one another.

925This happens to align with the proposed [SEP-2322](/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](./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](/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)).

7Each SEP is reachable by number at `/seps/<number>` (for example, [/seps/1850](/seps/1850.md)).

88

9> **[Submit a SEP](/community/sep-guidelines)**

9> **[Submit a SEP](/community/sep-guidelines.md)**

1010>

1111> Learn how to submit your own Specification Enhancement Proposal

1212

from line 18

1818

2020| - | - | - | - | - |

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)**

38> **[Lifecycle](/specification/2024-11-05/basic/lifecycle.md)**

3939

40> **[Resources](/specification/2024-11-05/server/resources)**

40> **[Resources](/specification/2024-11-05/server/resources.md)**

4141

42> **[Prompts](/specification/2024-11-05/server/prompts)**

42> **[Prompts](/specification/2024-11-05/server/prompts.md)**

4343

44> **[Tools](/specification/2024-11-05/server/tools)**

44> **[Tools](/specification/2024-11-05/server/tools.md)**

4545

46> **[Logging](/specification/2024-11-05/server/utilities/logging)**

46> **[Logging](/specification/2024-11-05/server/utilities/logging.md)**

4747

48> **[Sampling](/specification/2024-11-05/client/sampling)**

48> **[Sampling](/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) before the server

110 [pings](/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) and

114 [logging](/specification/2024-11-05/server/utilities/logging) before

113 [pings](/specification/2024-11-05/basic/utilities/ping.md) and

114 [logging](/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) |

139| Client | `sampling` | Support for LLM [sampling](/specification/2024-11-05/client/sampling) requests |

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 |

140140| Client | `experimental` | Describes support for non-standard experimental features |

141| Server | `prompts` | Offers [prompt templates](/specification/2024-11-05/server/prompts) |

142| Server | `resources` | Provides readable [resources](/specification/2024-11-05/server/resources) |

143| Server | `tools` | Exposes callable [tools](/specification/2024-11-05/server/tools) |

144| Server | `logging` | Emits structured [log messages](/specification/2024-11-05/server/utilities/logging) |

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) |

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), the

171For the stdio [transport](/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), shutdown

184For HTTP [transports](/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 · +4 / -4 lines

from line 116

116116

117117Explore the detailed specification for each protocol component:

118118

119> **[Architecture](/specification/2024-11-05/architecture)**

119> **[Architecture](/specification/2024-11-05/architecture.md)**

120120

121> **[Base Protocol](/specification/2024-11-05/basic)**

121> **[Base Protocol](/specification/2024-11-05/basic.md)**

122122

123> **[Server Features](/specification/2024-11-05/server)**

123> **[Server Features](/specification/2024-11-05/server.md)**

124124

125125> **[Client Features](/specification/2024-11-05/client)**

126126

127> **[Contributing](/community/contributing)**

127> **[Contributing](/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)**

23> **[Prompts](/specification/2024-11-05/server/prompts.md)**

2424

25> **[Resources](/specification/2024-11-05/server/resources)**

25> **[Resources](/specification/2024-11-05/server/resources.md)**

2626

27> **[Tools](/specification/2024-11-05/server/tools)**

27> **[Tools](/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#initialization):

27[initialization](/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).

48[pagination](/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).

91auto-completed through [the completion API](/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).

85[pagination](/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).

159auto-completed through [the completion API](/specification/2024-11-05/server/utilities/completion.md).

160160This operation supports

161[pagination](/specification/2024-11-05/server/utilities/pagination).

161[pagination](/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) before the server has responded to the

117 [pings](/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) and

121 [logging](/specification/2025-03-26/server/utilities/logging) before receiving the `initialized`

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`

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) |

146| Client | `sampling` | Support for LLM [sampling](/specification/2025-03-26/client/sampling) requests |

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 |

147147| Client | `experimental` | Describes support for non-standard experimental features |

148| Server | `prompts` | Offers [prompt templates](/specification/2025-03-26/server/prompts) |

149| Server | `resources` | Provides readable [resources](/specification/2025-03-26/server/resources) |

150| Server | `tools` | Exposes callable [tools](/specification/2025-03-26/server/tools) |

151| Server | `logging` | Emits structured [log messages](/specification/2025-03-26/server/utilities/logging) |

152| Server | `completions` | Supports argument [autocompletion](/specification/2025-03-26/server/utilities/completion) |

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) |

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), the client **SHOULD** initiate

179For the stdio [transport](/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), shutdown is indicated by closing the

192For HTTP [transports](/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) for that request and stop waiting for

200notification](/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) corresponding to the request, as this

207notification](/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#http-with-sse) from

53> transport](/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). To support

179server, beginning with the [initialization phase](/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#http-with-sse) (from

249transport](/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).

4the previous revision, [2024-11-05](/specification/2024-11-05.md).

55

66## Major changes

77

81. Added a comprehensive **[authorization framework](/specification/2025-03-26/basic/authorization)**

81. Added a comprehensive **[authorization framework](/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#streamable-http)** (PR

12 transport](/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 · +4 / -4 lines

from line 118

118118

119119Explore the detailed specification for each protocol component:

120120

121> **[Architecture](/specification/2025-03-26/architecture)**

121> **[Architecture](/specification/2025-03-26/architecture.md)**

122122

123> **[Base Protocol](/specification/2025-03-26/basic)**

123> **[Base Protocol](/specification/2025-03-26/basic.md)**

124124

125> **[Server Features](/specification/2025-03-26/server)**

125> **[Server Features](/specification/2025-03-26/server.md)**

126126

127127> **[Client Features](/specification/2025-03-26/client)**

128128

129> **[Contributing](/community/contributing)**

129> **[Contributing](/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)**

23> **[Prompts](/specification/2025-03-26/server/prompts.md)**

2424

25> **[Resources](/specification/2025-03-26/server/resources)**

25> **[Resources](/specification/2025-03-26/server/resources.md)**

2626

27> **[Tools](/specification/2025-03-26/server/tools)**

27> **[Tools](/specification/2025-03-26/server/tools.md)**

2828

One read of Model Context Protocolmcp-20261022T203719Z

What this read moved

extensions/skills/overview Changed · +9 / -9 lines

extensions/tasks/overview Changed · +3 / -3 lines

registry/about Changed · +4 / -4 lines

registry/quickstart Changed · +5 / -5 lines

seps/1036-url-mode-elicitation-for-secure-out-of-band-intera Changed · +4 / -4 lines

seps/1303-input-validation-errors-as-tool-execution-errors Changed · +3 / -3 lines

seps/1577--sampling-with-tools Changed · +12 / -12 lines

seps/2127-mcp-server-cards Changed · +5 / -5 lines

seps/2133-extensions Changed · +7 / -7 lines

seps/2148-contributor-ladder Changed · +7 / -7 lines

seps/2149-working-group-charter-template Changed · +5 / -5 lines

seps/2596-spec-feature-lifecycle-and-deprecation Changed · +18 / -18 lines

seps/2663-tasks-extension Changed · +21 / -21 lines

seps/index Changed · +45 / -45 lines

specification/2024-11-05/basic/index Changed · +6 / -6 lines

specification/2024-11-05/basic/lifecycle Changed · +11 / -11 lines

specification/2024-11-05/index Changed · +4 / -4 lines

specification/2024-11-05/server/index Changed · +3 / -3 lines

specification/2024-11-05/server/prompts Changed · +3 / -3 lines

specification/2024-11-05/server/resources Changed · +3 / -3 lines

specification/2025-03-26/basic/lifecycle Changed · +14 / -14 lines

specification/2025-03-26/basic/transports Changed · +3 / -3 lines

specification/2025-03-26/changelog Changed · +3 / -3 lines

specification/2025-03-26/index Changed · +4 / -4 lines

specification/2025-03-26/server/index Changed · +3 / -3 lines