Merge branch 'main' into fix_elicitation_multiselect_example

Author: cliffhall

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/develop/build-client.mdx

@@ -881,7 +881,7 @@ Before starting, ensure your system meets these requirements:
 
    ```bash
    git clone https://github.com/spring-projects/spring-ai-examples.git
-   cd model-context-protocol/brave-chatbot
+   cd model-context-protocol/web-search/brave-chatbot
    ```
 
 3. Set up your API keys:

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/2025-06-18/schema.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/authorization.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/index.mdx

@@ -103,16 +103,26 @@ MCP endpoint.
    `Content-Type: application/json`, to return one JSON object. The client **MUST**
    support both these cases.
 6. If the server initiates an SSE stream:
-   - The SSE stream **SHOULD** eventually include JSON-RPC _response_ for the
+   - The server **SHOULD** immediately send an SSE event consisting of an event
+     ID and an empty `data` field in order to prime the client to reconnect
+     (using that event ID as `Last-Event-ID`).
+   - After the server has sent an SSE event with an event ID to the client, the
+     server **MAY** close the _connection_ (without terminating the _SSE stream_)
+     at any time in order to avoid holding a long-lived connection. The client
+     **SHOULD** then "poll" the SSE stream by attempting to reconnect.
+   - If the server does close the _connection_ prior to terminating the _SSE stream_,
+     it **SHOULD** send an SSE event with a standard `retry` field before
+     closing the connection. The client **MUST** respect the `retry` field,
+     waiting the given number of milliseconds before attempting to reconnect.
+   - The SSE stream **SHOULD** eventually include a JSON-RPC _response_ for the
      JSON-RPC _request_ sent in the POST body.
    - The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending the
      JSON-RPC _response_. These messages **SHOULD** relate to the originating client
      _request_.
-   - The server **SHOULD NOT** close the SSE stream before sending the JSON-RPC _response_
-     for the received JSON-RPC _request_, unless the [session](#session-management)
+   - The server **MAY** terminate the SSE stream if the [session](#session-management)
      expires.
-   - After the JSON-RPC _response_ has been sent, the server **SHOULD** close the SSE
-     stream.
+   - After the JSON-RPC _response_ has been sent, the server **SHOULD** terminate the
+     SSE stream.
    - Disconnection **MAY** occur at any time (e.g., due to network conditions).
      Therefore:
      - Disconnection **SHOULD NOT** be interpreted as the client cancelling its request.