diff --git a/docs/specification/draft/changelog.mdx b/docs/specification/draft/changelog.mdx
index 1cee8aa3a..d95c3655e 100644
--- a/docs/specification/draft/changelog.mdx
+++ b/docs/specification/draft/changelog.mdx
@@ -14,7 +14,7 @@ the previous revision, [2025-06-18](/specification/2025-06-18).
3. Enhance authorization flows with incremental scope consent via `WWW-Authenticate` ([SEP-835](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/835))
4. Provide guidance on tool names ([SEP-986](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1603))
5. Update `ElicitResult` and `EnumSchema` to use a more standards-based approach and support titled, untitled, single-select, and multi-select enums ([SEP-1330](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1330)).
-6. Added support for [URL mode elicitation](/specification/draft/client/elicitation#url-elicitation-requests)([SEP-1036](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/887))
+6. Added support for [URL mode elicitation](/specification/draft/client/elicitation#url-elicitation-requests) ([SEP-1036](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/887))
7. Add tool calling support to sampling via `tools` and `toolChoice` parameters ([SEP-1577](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1577))
8. Add support for OAuth Client ID Metadata Documents as a recommended client registration mechanism ([SEP-991](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/991), PR [#1296](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1296))
9. Add experimental support for [tasks](/specification/draft/basic/utilities/tasks) to enable tracking durable requests with polling and deferred result retrieval ([SEP-1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686)).
diff --git a/docs/specification/draft/client/elicitation.mdx b/docs/specification/draft/client/elicitation.mdx
index 3d269383e..9cd9b961c 100644
--- a/docs/specification/draft/client/elicitation.mdx
+++ b/docs/specification/draft/client/elicitation.mdx
@@ -322,8 +322,23 @@ Note that complex nested structures, arrays of objects (beyond enums), and other
### URL Mode Elicitation Requests
+
+
+**New feature:** URL mode elicitation is introduced in the `2025-11-25` version of the MCP specification. Its design and implementation may change in future protocol revisions.
+
+
+
URL mode elicitation enables servers to direct users to external URLs for out-of-band interactions that must not pass through the MCP client. This is essential for auth flows, payment processing, and other sensitive or secure operations.
+URL mode elicitation requests **MUST** specify `mode: "url"`, a `message`, and include these additional parameters:
+
+| Name | Type | Description |
+| --------------- | ------ | ----------------------------------------- |
+| `url` | string | The URL that the user should navigate to. |
+| `elicitationId` | string | A unique identifier for the elicitation. |
+
+The `url` parameter **MUST** contain a valid URL.
+
**Important**: URL mode elicitation is *not* for authorizing the MCP client's
access to the MCP server (that's handled by [MCP
@@ -334,15 +349,6 @@ URL mode elicitation enables servers to direct users to external URLs for out-of
elicitation URL the server wants them to open.
-URL mode elicitation requests **MUST** specify `mode: "url"` and include these additional parameters:
-
-| Name | Type | Description |
-| --------------- | ------ | ----------------------------------------- |
-| `url` | string | The URL that the user should navigate to. |
-| `elicitationId` | string | A unique identifier for the elicitation. |
-
-The `url` parameter **MUST** contain a valid URL. The `message` parameter **MUST NOT** contain a URL.
-
#### Example: Request Sensitive Data
This example shows a URL mode elicitation request directing the user to a secure URL where they can provide sensitive information (an API key, for example).
@@ -382,18 +388,19 @@ of band and the client is not aware of the outcome until and unless the server s
### Completion Notifications for URL Mode Elicitation
-Servers **SHOULD** send a `notifications/elicitation/complete` notification when an
+Servers **MAY** send a `notifications/elicitation/complete` notification when an
out-of-band interaction started by URL mode elicitation is completed. This allows clients to react programmatically if appropriate.
-- The notification **MUST** only be sent to the client that initiated the elicitation request.
-- The notification **MUST** include the `elicitationId` established in the original
- `elicitation/create` request.
-- Clients **MUST** ignore notifications referencing unknown or already-completed IDs.
-- If a completion notification never arrives, clients **SHOULD** provide a manual
- way for the user to continue the interaction.
+Servers sending notifications:
+
+- **MUST** only send the notification to the client that initiated the elicitation request.
+- **MUST** include the `elicitationId` established in the original `elicitation/create` request.
+
+Clients:
-Clients **MAY** use the notification to automatically retry requests that received a [URLElicitationRequiredError](#error-handling), update the user interface, or otherwise continue an interaction.
-However, because delivery of the notification is not guaranteed, clients must not wait indefinitely for a notification from the server.
+- **MUST** ignore notifications referencing unknown or already-completed IDs.
+- **MAY** wait for this notification to automatically retry requests that received a [URLElicitationRequiredError](#error-handling), update the user interface, or otherwise continue an interaction.
+- **SHOULD** still provide manual controls that let the user retry or cancel the original request (or otherwise resume interacting with the client) if the notification never arrives.
#### Example