Merge pull request modelcontextprotocol#1732 from LucaButBoring/feat/tasks

SEP-1686: Tasks

Author: localden

docs/docs.json

@@ -231,7 +231,8 @@
                     "pages": [
                       "specification/draft/basic/utilities/cancellation",
                       "specification/draft/basic/utilities/ping",
-                      "specification/draft/basic/utilities/progress"
+                      "specification/draft/basic/utilities/progress",
+                      "specification/draft/basic/utilities/tasks"
                     ]
                   }
                 ]

docs/docs/learn/architecture.mdx

@@ -132,6 +132,10 @@ MCP also defines primitives that _clients_ can expose. These primitives allow MC
 
 For more details about client primitives see [client concepts](./client-concepts).
 
+Besides server and client primitives, the protocol offers cross-cutting utility primitives that augment how requests are executed:
+
+- **Tasks (Experimental)**: Durable execution wrappers that enable deferred result retrieval and status tracking for MCP requests (e.g., expensive computations, workflow automation, batch processing, multi-step operations)
+
 #### Notifications
 
 The protocol supports real-time notifications to enable dynamic updates between servers and clients. For example, when a server's available tools change—such as when new functionality becomes available or existing tools are modified—the server can send tool update notifications to inform connected clients about these changes. Notifications are sent as JSON-RPC 2.0 notification messages (without expecting a response) and enable MCP servers to provide real-time updates to connected clients.

docs/specification/draft/basic/lifecycle.mdx

@@ -67,6 +67,16 @@ The client **MUST** initiate this phase by sending an `initialize` request conta
       "elicitation": {
         "form": {},
         "url": {}
+      },
+      "tasks": {
+        "requests": {
+          "elicitation": {
+            "create": {}
+          },
+          "sampling": {
+            "createMessage": {}
+          }
+        }
       }
     },
     "clientInfo": {
@@ -105,6 +115,15 @@ The server **MUST** respond with its own capabilities and information:
       },
       "tools": {
         "listChanged": true
+      },
+      "tasks": {
+        "list": {},
+        "cancel": {},
+        "requests": {
+          "tools": {
+            "call": {}
+          }
+        }
       }
     },
     "serverInfo": {
@@ -169,18 +188,20 @@ available during the session.
 
 Key capabilities include:
 
-| Category | Capability     | Description                                                                          |
-| -------- | -------------- | ------------------------------------------------------------------------------------ |
-| Client   | `roots`        | Ability to provide filesystem [roots](/specification/draft/client/roots)             |
-| Client   | `sampling`     | Support for LLM [sampling](/specification/draft/client/sampling) requests            |
-| Client   | `elicitation`  | Support for server [elicitation](/specification/draft/client/elicitation) requests   |
-| Client   | `experimental` | Describes support for non-standard experimental features                             |
-| Server   | `prompts`      | Offers [prompt templates](/specification/draft/server/prompts)                       |
-| Server   | `resources`    | Provides readable [resources](/specification/draft/server/resources)                 |
-| Server   | `tools`        | Exposes callable [tools](/specification/draft/server/tools)                          |
-| Server   | `logging`      | Emits structured [log messages](/specification/draft/server/utilities/logging)       |
-| Server   | `completions`  | Supports argument [autocompletion](/specification/draft/server/utilities/completion) |
-| Server   | `experimental` | Describes support for non-standard experimental features                             |
+| Category | Capability     | Description                                                                              |
+| -------- | -------------- | ---------------------------------------------------------------------------------------- |
+| Client   | `roots`        | Ability to provide filesystem [roots](/specification/draft/client/roots)                 |
+| Client   | `sampling`     | Support for LLM [sampling](/specification/draft/client/sampling) requests                |
+| Client   | `elicitation`  | Support for server [elicitation](/specification/draft/client/elicitation) requests       |
+| Client   | `tasks`        | Support for [task-augmented](/specification/draft/basic/utilities/tasks) client requests |
+| Client   | `experimental` | Describes support for non-standard experimental features                                 |
+| Server   | `prompts`      | Offers [prompt templates](/specification/draft/server/prompts)                           |
+| Server   | `resources`    | Provides readable [resources](/specification/draft/server/resources)                     |
+| Server   | `tools`        | Exposes callable [tools](/specification/draft/server/tools)                              |
+| Server   | `logging`      | Emits structured [log messages](/specification/draft/server/utilities/logging)           |
+| Server   | `completions`  | Supports argument [autocompletion](/specification/draft/server/utilities/completion)     |
+| Server   | `tasks`        | Support for [task-augmented](/specification/draft/basic/utilities/tasks) server requests |
+| Server   | `experimental` | Describes support for non-standard experimental features                                 |
 
 Capability objects can describe sub-capabilities like:
 

docs/specification/draft/basic/utilities/cancellation.mdx

@@ -34,16 +34,17 @@ notification containing:
 1. Cancellation notifications **MUST** only reference requests that:
    - Were previously issued in the same direction
    - Are believed to still be in-progress
-2. The `initialize` request **MUST NOT** be cancelled by clients
-3. Receivers of cancellation notifications **SHOULD**:
+1. The `initialize` request **MUST NOT** be cancelled by clients
+1. For [task-augmented requests](./tasks), the `tasks/cancel` request **MUST** be used instead of the `notifications/cancelled` notification. Tasks have their own dedicated cancellation mechanism that returns the final task state.
+1. Receivers of cancellation notifications **SHOULD**:
    - Stop processing the cancelled request
    - Free associated resources
    - Not send a response for the cancelled request
-4. Receivers **MAY** ignore cancellation notifications if:
+1. Receivers **MAY** ignore cancellation notifications if:
    - The referenced request is unknown
    - Processing has already completed
    - The request cannot be cancelled
-5. The sender of the cancellation notification **SHOULD** ignore any response to the
+1. The sender of the cancellation notification **SHOULD** ignore any response to the
    request that arrives afterward
 
 ## Timing Considerations

docs/specification/draft/basic/utilities/progress.mdx

@@ -68,6 +68,10 @@ The receiver **MAY** then send progress notifications containing:
    - Send notifications at whatever frequency they deem appropriate
    - Omit the total value if unknown
 
+3. For [task-augmented requests](./tasks), the `progressToken` provided in the original request **MUST** continue to be used for progress notifications throughout the task's lifetime, even after the `CreateTaskResult` has been returned. The progress token remains valid and associated with the task until the task reaches a terminal status.
+   - Progress notifications for tasks **MUST** use the same `progressToken` that was provided in the initial task-augmented request
+   - Progress notifications for tasks **MUST** stop after the task reaches a terminal status (`completed`, `failed`, or `cancelled`)
+
 ```mermaid
 sequenceDiagram
     participant Sender