Moving discussion from #2557 over here @CaitieM20 @markdroth @Randgalt @kurtisvg @localden @pja-ant @dsp-ant @maxisbey @maciej-kisiel @ylxlpl

(Tagged everyone who commented on #2557)

Thanks for putting this together, @LucaButBoring - I'll post the comment that I was typing earlier in #2557 and let you validate how much of this is still relevant.

Some notes beyond the other bits I called out in the review. There's a few places where I think the SEP is a little underspecified:

1. CreateTaskResult and GetTaskResult both carry resultType: "task" but have different shapes. In schema.ts, CreateTaskResult is { task: Task } (nested), while GetTaskResult is Result & DetailedTask (flat). So a client switching on resultType === "task" then has to also check whether it got result.task.taskId or result.taskId. Is the nesting on CreateTaskResult intentional, or a holdover from before GetTaskResult was flattened?
2. The inputRequests key contract stops at "SHOULD dedupe." The tasks spec says clients should dedupe by key, and the inputResponses JSDoc says keys match inputRequests keys. But it doesn't say whether a key is unique for the task's lifetime or can be reused after the server consumes the response.
3. Retry of tasks/get with inputResponses. What happens if a client sends tasks/get { inputResponses: { k: ... } }, network blips, and client retries? If the response was a sampling result the server feeds into a downstream API call, that call just ran twice. IMO the smallest fix is to say the server MUST treat inputResponses keyed on a request it has already consumed as a no-op. That makes the key the idempotency token, and it's almost what the key-matching contract says already.
4. "The same requests will be included" is ambiguous for partial responses. The Input Requests section says if the client polls again before providing all responses, the same requests reappear. Does "the same requests" mean the full original set (client must re-send what it already provided) or only the still-unfulfilled remainder? I'd read it as the remainder, but the text doesn't say so, and it interacts with the idempotency point above.
5. The cancel behavior has two stories. The spec says servers MAY ignore cancellation but MUST support tasks/cancel, which I read as: always return a valid CancelTaskResult, possibly with a non-cancelled status. But the "Cancellation Not Supported" example returns a -32603 JSON-RPC error instead. Those are different contracts. Can we formalize that the response carries the task's current status, which may not be cancelled, and drop the -32603 example.
6. ttl and pollInterval are now in different units. The schema still documents pollInterval in milliseconds while the SEP moves ttl to seconds. So { ttl: 60, pollInterval: 5000 } is 60 seconds next to 5000 milliseconds. @pja-ant raised this before and I don't see it landed yet. Both fields should match.
7. The Failed example might be the wrong status under the new rule. The Task Flow Change section says failed is for JSON-RPC errors and application faults go to completed with isError: true. The Failed example shows error: { code: -32603, message: "API rate limit exceeded" }. A downstream API rate-limiting the tool is an application fault (exactly the case the new rule routes to completed). If -32603 here means the MCP server itself fell over, the message should say that; otherwise the example is the case the rule says not to use failed for.
8. Is taskId alone always sufficient for tasks/get? requestState lets a server externalize lookup state to the client (a backend job ID, a serialized continuation) so it doesn't have to keep a mapping table - that makes sense. But in a fully stateless deployment a server could push that to the limit and put the entire task record in requestState, keeping nothing locally. At that point tasks/get { taskId } without requestState has nothing to look up, which runs into the "MUST NOT return CreateTaskResult until tasks/get would find it" guarantee. Should we be explicit about the taskId always being sufficient as a standalone index of a task?

A couple of schema regressions I noticed too:

• CallToolRequestParams, CreateMessageRequestParams, and the ElicitRequest*Params types no longer extend anything after TaskAugmentedRequestParams was removed, so they've lost the RequestParams base and _meta? with it.
• ServerRequest still includes GetTaskRequest and CancelTaskRequest even though client-hosted tasks are removed.

@localden Thanks for the feedback, going through this:

1. CreateTaskResult and GetTaskResult both carry resultType: "task" but have different shapes. In schema.ts, CreateTaskResult is { task: Task } (nested), while GetTaskResult is Result & DetailedTask (flat). So a client switching on resultType === "task" then has to also check whether it got result.task.taskId or result.taskId. Is the nesting on CreateTaskResult intentional, or a holdover from before GetTaskResult was flattened?

This revision limits resultType: "task" to CreateTaskResult to avoid any ambiguity, noticed that issue while rewriting this. GetTaskResult was always flat, the distinction was that we made CreateTaskResult nested at the last minute in 2025-11-25 to allow switching on it. That nesting is a holdover from before we had resultType, so we can actually flatten CreateTaskResult, too.

edit: updated

2. The inputRequests key contract stops at "SHOULD dedupe." The tasks spec says clients should dedupe by key, and the inputResponses JSDoc says keys match inputRequests keys. But it doesn't say whether a key is unique for the task's lifetime or can be reused after the server consumes the response.

This revision does require keys to be unique over the lifetime of a task, and not reused between distinct requests.

3. Retry of tasks/get with inputResponses. What happens if a client sends tasks/get { inputResponses: { k: ... } }, network blips, and client retries? If the response was a sampling result the server feeds into a downstream API call, that call just ran twice. IMO the smallest fix is to say the server MUST treat inputResponses keyed on a request it has already consumed as a no-op. That makes the key the idempotency token, and it's almost what the key-matching contract says already.

Yup, that's how tasks/update works in this revision.

4. "The same requests will be included" is ambiguous for partial responses. The Input Requests section says if the client polls again before providing all responses, the same requests reappear. Does "the same requests" mean the full original set (client must re-send what it already provided) or only the still-unfulfilled remainder? I'd read it as the remainder, but the text doesn't say so, and it interacts with the idempotency point above.

I struck out that phrasing in this revision, now it can actually be either, as tasks/update is eventually-consistent - but the new key uniqueness constraint means that this is fine from the client's perspective, now.

5. The cancel behavior has two stories. The spec says servers MAY ignore cancellation but MUST support tasks/cancel, which I read as: always return a valid CancelTaskResult, possibly with a non-cancelled status. But the "Cancellation Not Supported" example returns a -32603 JSON-RPC error instead. Those are different contracts. Can we formalize that the response carries the task's current status, which may not be cancelled, and drop the -32603 example.

To deal with that, in this revision, tasks/cancel no longer has any result (and is also eventually-consistent, like tasks/update).

6. ttl and pollInterval are now in different units. The schema still documents pollInterval in milliseconds while the SEP moves ttl to seconds. So { ttl: 60, pollInterval: 5000 } is 60 seconds next to 5000 milliseconds. @pja-ant raised this before and I don't see it landed yet. Both fields should match.

A TTL in integer seconds makes sense, but I'm not sure if a polling interval in integer seconds does - 500ms would be a reasonable polling interval for a relatively quick, but high-variance (1s-20s) task. A duration is probably better-expressed with units included in the value (e.g. "500ms"), but that would be nonstandard for us - I suppose I could name it pollIntervalMilliseconds, but that feels awkward and inconsistent in its own right, since nothing else includes units in the field name so far.

edit: updated to include units in the field names

7. The Failed example might be the wrong status under the new rule. The Task Flow Change section says failed is for JSON-RPC errors and application faults go to completed with isError: true. The Failed example shows error: { code: -32603, message: "API rate limit exceeded" }. A downstream API rate-limiting the tool is an application fault (exactly the case the new rule routes to completed). If -32603 here means the MCP server itself fell over, the message should say that; otherwise the example is the case the rule says not to use failed for.

Noted, I'll update the phrasing here - it actually doesn't really mean the MCP server fell over either, the literal intent is just that if the inner request returns a JSON-RPC error, that's failed, and in every other case (including a tool call with isError: true), that's completed.

edit: updated

8. Is taskId alone always sufficient for tasks/get? requestState lets a server externalize lookup state to the client (a backend job ID, a serialized continuation) so it doesn't have to keep a mapping table - that makes sense. But in a fully stateless deployment a server could push that to the limit and put the entire task record in requestState, keeping nothing locally. At that point tasks/get { taskId } without requestState has nothing to look up, which runs into the "MUST NOT return CreateTaskResult until tasks/get would find it" guarantee. Should we be explicit about the taskId always being sufficient as a standalone index of a task?

I don't think there's an inconsistency here? requestState is already on the request shape for tasks/get - the requirement is that the client echoes whatever the server gives it. So, in the case where the full task record is in requestState, the server would return the initial value in CreateTaskResult, the client would pick that up, and then it would echo it in tasks/get, maintaining the full record through that flow.

edit: updated, I misinterpreted this - noted here

A couple of schema regressions I noticed too:

• CallToolRequestParams, CreateMessageRequestParams, and the ElicitRequest*Params types no longer extend anything after TaskAugmentedRequestParams was removed, so they've lost the RequestParams base and _meta? with it.
• ServerRequest still includes GetTaskRequest and CancelTaskRequest even though client-hosted tasks are removed.

Ah, I missed that on #2557 - I'll make sure this is handled correctly when I write the schema changes here.

This is great, allows integration of various organizational extensions.

A TTL in integer seconds makes sense, but I'm not sure if a polling interval in integer seconds does - 500ms would be a reasonable polling interval for a relatively quick, but high-variance (1s-20s) task. A duration is probably better-expressed with units included in the value (e.g. "500ms"), but that would be nonstandard for us - I suppose I could name it pollIntervalMilliseconds, but that feels awkward and inconsistent in its own right, since nothing else includes units in the field name so far.

The option space is:

1. Have everything as seconds
2. Allow different units, but don't include it in the name or value
3. Allow different units, but use a string (e.g. "500ms")
4. Allow different units, and add it to the name

IMO:

1. Too limiting - seconds isn't appropriate for everything
2. Strongly prefer we don't do this. We know what happens: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
3. An option, but IMO having to parse is just annoying.
4. My strong preference. It's simple and avoids any confusion. It's a little more verbose.

I agree that (4) is non-standard, but IMO we just make it the standard starting now and make sure that TTL lists also adopts this standard.

Following further discussions, ttlSeconds is now ttlMs and pollIntervalMilliseconds is now pollIntervalMs - both represent integer milliseconds. #2549 will use ttlMs as well.

Pushed changes to remove tasks from the core specification and adjust remaining references to it now that #2322 is merged: 82fb2c4

Wanted to propose a non-normative "Migration Notes" appendix as an expansion to the Backward Compatibility section. The existing section already mentions hybrid mode in one sentence (Implementations that need to bridge legacy clients can shim at the SDK level...). This turns that into actionable host-side guidance with per-connection routing rules, a recommended timeline, and an observability note for safe sunset.

We could perhaps add this betweeen ## Backward Compatibility and ## Security Implications.

How does verbatim sound? HHappy to iterate on wording or scope, and if you'd prefer to keep this PR focused on the core extension definition, this could land as a sibling SEP or a separate follow-up PR instead.

## Migration Notes

This section provides non-normative guidance for implementations migrating from the experimental `2025-11-25` tasks feature to the extension defined in this proposal.

### Migration is gated on protocol version

A client and server negotiate a protocol version in `initialize`. The extension surfaces only on connections that negotiate `2026-06-30` or later. Connections that negotiate `2025-11-25` continue to use the experimental tasks feature unchanged.

This means a deployment can support both versions during transition without forcing simultaneous client and server upgrades. A v1 client connecting to a hybrid-capable server keeps working against the `2025-11-25` surface. A v2-aware client connecting to the same server negotiates `2026-06-30` and exercises the extension.

### Server migration

#### Hybrid pattern (recommended during transition)

A server **MAY** accept both `2025-11-25` and `2026-06-30` connections during transition. Per-connection behavior:

- On a `2025-11-25` connection, advertise `capabilities.tasks` in the initialize response and serve the experimental tasks methods.
- On a `2026-06-30` connection, advertise `capabilities.extensions["io.modelcontextprotocol/tasks"]` and serve the extension methods. **MUST NOT** advertise `capabilities.tasks` (per [Backward Compatibility](#backward-compatibility)).

The two surfaces share no per-task state and operate independently. A task created over the experimental surface is not visible from the extension surface and vice versa.

#### Post-migration

Once a server's `2025-11-25` traffic falls below an organization-defined threshold, the server **MAY** drop `2025-11-25` support entirely. After that point only `2026-06-30` (and later) connections succeed. Clients still pinned to `2025-11-25` receive a protocol-version negotiation failure on `initialize`, which is the explicit signal to upgrade.

### Client migration

A v1-only client requires code changes to use the extension. The wire-shape mapping is described in [Backward Compatibility](#backward-compatibility). In summary:

- `tasks/result` is removed. Replace with polling via `tasks/get`. The result is inlined on the `tasks/get` response when the task reaches a terminal status.
- The `task` parameter on `CallToolRequest` is removed. Replace with declaring the extension at session level (or per-request via SEP-2575) and handling the polymorphic `resultType` discriminator on the response.
- `tasks/cancel` returns an empty acknowledgement instead of a rich task envelope. Observe the resulting `cancelled` status via the next `tasks/get` call.
- The `tasks/list` method is removed. There is no replacement (per [Security Implications](#security-implications) below).

### Recommended migration timeline

The following is non-normative guidance.

- Servers **SHOULD** support the hybrid pattern for at least one specification release cycle after `2026-06-30` reaches general availability, to give clients time to upgrade.
- Servers **MAY** end hybrid support sooner if they have direct visibility into their client population and have confirmed `2025-11-25` traffic is zero.
- Clients **SHOULD** prioritize migrating to the extension before any given server stops advertising the experimental surface. A hybrid server that drops `2025-11-25` support is not visible to v1 clients.

### Observability for safe sunset

To support a deliberate sunset decision, both sides **SHOULD** instrument which surface is in use.

- Servers **SHOULD** log, per session, which protocol version was negotiated and which task surface (experimental or extension) the session exercised. Aggregate `2025-11-25` traffic counts inform the sunset decision.
- Clients **SHOULD** report which task surface they exercised against each server, via deployment-side telemetry or operator reporting channels. This helps server operators understand the migration pace from the client side.

The extension does not require these instrumentation patterns. They are listed here because the absence of a `tasks/list` method means servers cannot otherwise inspect cross-session client behavior, so structured logging is the only practical signal.

@panyam I think that's too detailed, and we'd be better off considering this a wholesale replacement for most purposes - we'd be better served by reducing it to just a couple of rules:

1. If the negotiated protocol version is 2025-11-25, we disallow capabilities.extensions["io.modelcontextprotocol/tasks"] and follow all of the v2 semantics.
2. If the negotiated protocol version is 2026-06-30, we disallow capabilities.tasks and follow all of the v1 semantics.

As for some immediate issues with the proposed guidance, servers that weren't already adopting v1 tasks will generally not want to do so during the migration period, and clients won't generally have any way of signaling simultaneous support for both versions to servers beyond their capability declarations. We also need to consider how things interact with #2575 - initialize doesn't exist in the new version and we signal on per-request client capabilities instead and use server/discover to communicate server capabilities. I think at this point, the harder we bifurcate this the better, otherwise we'll get stuck in a backwards-compatibility mire. I think this also follows suit with what e.g. #2322 and similar proposals are doing.