Merge pull request modelcontextprotocol#1825 from ArcadeAI/elicitation/expect-server-flag

fix: Clearer language around new feature status of URL elicitation

Author: localden

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)).

docs/specification/draft/client/elicitation.mdx

@@ -324,8 +324,23 @@ Note that complex nested structures, arrays of objects (beyond enums), and other
 
 ### URL Mode Elicitation Requests
 
+<Note>
+
+**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.
+
+</Note>
+
 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.
+
 <Note>
   **Important**: URL mode elicitation is *not* for authorizing the MCP client's
   access to the MCP server (that's handled by [MCP
@@ -336,15 +351,6 @@ URL mode elicitation enables servers to direct users to external URLs for out-of
   elicitation URL the server wants them to open.
 </Note>
 
-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).
@@ -384,18 +390,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