Merge branch 'aaronpk/ext-auth' of https://github.com/modelcontextprotocol/modelcontextprotocol into aaronpk/ext-auth

Author: localden

MAINTAINERS.md

@@ -95,6 +95,12 @@ This document lists current maintainers in the Model Context Protocol project.
 - [Adam Jones](https://github.com/domdomegg)
 - [Radoslav (Rado) Dimitrov](https://github.com/rdimitrov)
 
+### MCPB (Model Context Protocol Bundle)
+
+- [Alexander Sklar](https://github.com/asklar)
+- [Adam Jones](https://github.com/domdomegg)
+- [Joan Xie](https://github.com/joan-anthropic)
+
 ### Reference Servers
 
 - [Ola Hungerford](https://github.com/olaservo)

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/legacy/concepts/architecture.mdx

@@ -201,6 +201,9 @@ enum ErrorCode {
   MethodNotFound = -32601,
   InvalidParams = -32602,
   InternalError = -32603,
+
+  // MCP-specific error codes in the range [-32000, -32099]
+  UrlElicitationRequired = -32042,
 }
 ```
 

docs/specification/draft/basic/authorization.mdx

@@ -104,7 +104,7 @@ and instead retrieve credentials from the environment.
 Additionally, clients and servers **MAY** negotiate their own custom authentication and
 authorization strategies.
 
-For further discussions and contributions to the evolution of MCP’s auth mechanisms, join
+For further discussions and contributions to the evolution of MCP's auth mechanisms, join
 us in
 [GitHub Discussions](https://github.com/modelcontextprotocol/specification/discussions)
 to help shape the future of the protocol!
@@ -120,9 +120,61 @@ There is also a
 which is automatically generated from the TypeScript source of truth, for use with
 various automated tooling.
 
-### General fields
+## JSON Schema Usage
 
-#### `_meta`
+The Model Context Protocol uses JSON Schema for validation throughout the protocol. This section clarifies how JSON Schema should be used within MCP messages.
+
+### Schema Dialect
+
+MCP supports JSON Schema with the following rules:
+
+1. **Default dialect**: When a schema does not include a `$schema` field, it defaults to JSON Schema 2020-12 (`https://json-schema.org/draft/2020-12/schema`)
+1. **Explicit dialect**: Schemas MAY include a `$schema` field to specify a different dialect
+1. **Supported dialects**: Implementations MUST support at least 2020-12 and SHOULD document which additional dialects they support
+1. **Recommendation**: Implementors are RECOMMENDED to use JSON Schema 2020-12.
+
+### Example Usage
+
+#### Default dialect (2020-12):
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "name": { "type": "string" },
+    "age": { "type": "integer", "minimum": 0 }
+  },
+  "required": ["name"]
+}
+```
+
+#### Explicit dialect (draft-07):
+
+```json
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "type": "object",
+  "properties": {
+    "name": { "type": "string" },
+    "age": { "type": "integer", "minimum": 0 }
+  },
+  "required": ["name"]
+}
+```
+
+### Implementation Requirements
+
+- Clients and servers **MUST** support JSON Schema 2020-12 for schemas without an explicit `$schema` field
+- Clients and servers **MUST** validate schemas according to their declared or default dialect. They **MUST** handle unsupported dialects gracefully by returning an appropriate error indicating the dialect is not supported.
+- Clients and servers **SHOULD** document which schema dialects they support
+
+### Schema Validation
+
+- Schemas **MUST** be valid according to their declared or default dialect
+
+## General fields
+
+### `_meta`
 
 The `_meta` property/parameter is reserved by MCP to allow clients and servers
 to attach additional metadata to their interactions.

docs/specification/draft/basic/index.mdx

@@ -64,12 +64,26 @@ The client **MUST** initiate this phase by sending an `initialize` request conta
         "listChanged": true
       },
       "sampling": {},
-      "elicitation": {}
+      "elicitation": {
+        "form": {},
+        "url": {}
+      },
+      "tasks": {
+        "requests": {
+          "elicitation": {
+            "create": {}
+          },
+          "sampling": {
+            "createMessage": {}
+          }
+        }
+      }
     },
     "clientInfo": {
       "name": "ExampleClient",
       "title": "Example Client Display Name",
       "version": "1.0.0",
+      "description": "An example MCP client application",
       "icons": [
         {
           "src": "https://example.com/icon.png",
@@ -102,12 +116,22 @@ The server **MUST** respond with its own capabilities and information:
       },
       "tools": {
         "listChanged": true
+      },
+      "tasks": {
+        "list": {},
+        "cancel": {},
+        "requests": {
+          "tools": {
+            "call": {}
+          }
+        }
       }
     },
     "serverInfo": {
       "name": "ExampleServer",
       "title": "Example Server Display Name",
       "version": "1.0.0",
+      "description": "An example MCP server providing tools and resources",
       "icons": [
         {
           "src": "https://example.com/server-icon.svg",
@@ -166,18 +190,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/lifecycle.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/cancellation.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