SEP-1686: Tasks

[mikekistler]

Is your feature request related to a problem? Please describe.

Implement support for SEP-1686, which has been accepted for the next version of the MCP spec.

Note that some details of this SEP are still being finalized within the Core Maintainers.

Describe the solution you'd like

Compliance with the next version of the MCP spec within two weeks of its release.

[mikekistler]

I believe our initial support for this SEP should be to allow servers to support tasks if they choose. In other words, make it possible, but defer convenience features until there is clear signal that developers want them.

I think this means:

• Support sending and handling the new RPCs: tasks/list, tasks/get, tasks/result.
• Support sending notifications/tasks/created
• Allow taskId to be set in and read from requests (maybe no work here, as I think this is just a _meta field)
• Allow related-tasked to be set in requests, notifications, and responses (again, maybe no work)

[mikekistler]

For sending values in _meta of requests / notifications, I think we will want to update the "high-level" methods to accept a Meta to include in the message. Here's a list of methods I think should be updated:

• McpClient

  • CallToolAsync
  • GetPromptAsync
  • ListPromptsAsync
  • ListResourceTemplatesAsync
  • ListResourcesAsync
  • ListToolsAsync
  • PingAsync
  • ReadResourceAsync
  • SetLoggingLevel
  • SubscribeToResourceAsync
  • UnsubscribeFromResourceAsync
  • (whatever high-level method sends the initialize request)

• McpServer

  • ElicitAsync
  • RequestRootsAsync
  • SampleAsync
  • (ping is done with SendRequestAsync)

• McpSession

  • NotifyProgressAsync

[eiriktsarpalis]

@mikekistler @jeffhandley given the experimental status of the tasks feature, I would be inclined to remove the November milestone from the issue.

[stephentoub]

@mikekistler @jeffhandley given the experimental status of the tasks feature, I would be inclined to remove the November milestone from the issue.

I think we need clarification on what "experimental" means. If it means "this isn't actually part of the spec", then sure. If it means "this is part of the spec but we reserve the right to make breaking changes in future iterations of the spec", then we would still need to implement it to say we're compliant with the spec.

[eiriktsarpalis]

I asked that question on the spec PR. It appears that bare minimum it means that the design is subject to change, but let's see if we can get more clarification from the author.

[jeffhandley]

I also have an email out to @ihrpr and @pcarleton at @modelcontextprotocol, seeking their guidance on if experimental parts of the spec need to be in place for conformance.

[LucaButBoring]

Relaying here from #general-sdk-dev:

There doesn't seem to be a central ticket for all SDK implementations of a particular change, so sharing this here for SEP-1686 -- the following revisions have been merged on top of the base specification PR for tasks:

• Clarify request lifetimes in task diagrams: PR
• Fix capability phrasing in spec: PR
• Remove an incorrectly-added field from notifications/cancelled: PR
• Adjust schema to better-communicate where tasks are valid: PR
• Rename/move annotations.taskHint to execution.taskSupport, tweak its enum values, and change a SHOULD to a MUST for the behavior when this is declared:
  • PR 1
  • PR 2
• GetTask polling clarification: PR
• SSE stream management clarification: PR

The actual functional changes should be limited to taskHint, but the rest should help clarify some details around polling.

To save the trouble of going through each of the above PRs one by one, you can also go to the file on the "Files changed" tab here, searching for docs/specification/draft/basic/utilities/tasks.mdx, and then using the "Display the rich diff" button, as shown:

[LucaButBoring]

One very last change (we're doing a hard cutoff on additional changes here): adding a lastUpdatedAt to the Task object: modelcontextprotocol/modelcontextprotocol#1875