Elicitation changedspecification/2025-11-25/client/elicitation
Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 22 Oct 2026 20:37 UTC.
Upstream edited
Recorded here
Lines+11added
Lines−11removed
From line
43
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
The whole hunk
from line 43, old and new numbered
/
from line 43
4343## Capabilities
4444
4545Clients that support elicitation **MUST** declare the `elicitation` capability during
46[initialization](../basic/lifecycle#initialization):
46[initialization](/specification/2025-11-25/basic/lifecycle.md#initialization):
4747
4848```json theme={null}
4949{
from line 342
342342>
343343> **Important**: URL mode elicitation is *not* for authorizing the MCP client's
344344> access to the MCP server (that's handled by [MCP
345> authorization](../basic/authorization)). Instead, it's used when the MCP
345> authorization](/specification/2025-11-25/basic/authorization.md)). Instead, it's used when the MCP
346346> server needs to obtain sensitive information or third-party authorization on
347347> behalf of the user. The MCP client's bearer token remains unchanged. The
348348> client's only responsibility is to provide the user with context about the
from line 567
567567* Whether required information has been collected (e.g., the user's display name via form mode elicitation)
568568* Status of resource access (e.g., API keys or a payment flow via URL mode elicitation)
569569
570Servers implementing elicitation **MUST** securely associate this state with individual users following the guidelines in the [security best practices](../basic/security_best_practices) document. Specifically:
570Servers implementing elicitation **MUST** securely associate this state with individual users following the guidelines in the [security best practices](/specification/2025-11-25/basic/security_best_practices.md) document. Specifically:
571571
572572* State **MUST NOT** be associated with session IDs alone
573573* State storage **MUST** be protected against unauthorized access
574* For remote MCP servers, user identification **MUST** be derived from credentials acquired via [MCP authorization](../basic/authorization) when possible (e.g. `sub` claim)
574* For remote MCP servers, user identification **MUST** be derived from credentials acquired via [MCP authorization](/specification/2025-11-25/basic/authorization.md) when possible (e.g. `sub` claim)
575575
576576> [!NOTE]
577577>
from line 596
596596### URL Mode Elicitation for OAuth Flows
597597
598598URL mode elicitation enables a pattern where MCP servers act as OAuth clients to third-party resource servers.
599Authorization with external APIs enabled by URL mode elicitation is separate from [MCP authorization](../basic/authorization). MCP servers **MUST NOT** rely on URL mode elicitation to authorize users for themselves.
599Authorization with external APIs enabled by URL mode elicitation is separate from [MCP authorization](/specification/2025-11-25/basic/authorization.md). MCP servers **MUST NOT** rely on URL mode elicitation to authorize users for themselves.
600600
601601#### Understanding the Distinction
602602
603* **MCP Authorization**: Required OAuth flow between the MCP client and MCP server (covered in the [authorization specification](../basic/authorization))
603* **MCP Authorization**: Required OAuth flow between the MCP client and MCP server (covered in the [authorization specification](/specification/2025-11-25/basic/authorization.md))
604604* **External (third-party) Authorization**: Optional authorization between the MCP server and a third-party resource server, initiated via URL mode elicitation
605605
606606In external authorization, the server acts as both:
from line 617
617617The critical security requirements are:
618618
6196191. **The third-party credentials MUST NOT transit through the MCP client**: The client must never see third-party credentials to protect the security boundary
6202. **The MCP server MUST NOT use the client's credentials for the third-party service**: That would be [token passthrough](../basic/security_best_practices#token-passthrough), which is forbidden
6202. **The MCP server MUST NOT use the client's credentials for the third-party service**: That would be [token passthrough](/specification/2025-11-25/basic/security_best_practices.md#token-passthrough), which is forbidden
6216213. **The user MUST authorize the MCP server directly**: The interaction happens outside the MCP protocol, without involving the MCP client
6226224. **The MCP server is responsible for tokens**: The MCP server is responsible for storing and managing the third-party tokens obtained through the URL mode elicitation (in other words, the MCP server must be stateful).
623623
from line 626
626626> [!NOTE]
627627>
628628> For additional background, refer to the [token passthrough
629> section](../basic/security_best_practices#token-passthrough) of the Security
629> section](/specification/2025-11-25/basic/security_best_practices.md#token-passthrough) of the Security
630630> Best Practices document to understand why MCP servers cannot act as
631631> pass-through proxies.
632632
from line 727
727727### Identifying the User
728728
729729Servers **MUST NOT** rely on client-provided user identification without server verification, as this can be forged.
730Instead, servers **SHOULD** follow [security best practices](../basic/security_best_practices).
730Instead, servers **SHOULD** follow [security best practices](/specification/2025-11-25/basic/security_best_practices.md).
731731
732732Non-normative examples:
733733
734734* Incorrect: Treat user input like "I am [[email protected]](mailto:[email protected])" as authoritative
735* Correct: Rely on [authorization](../basic/authorization) to identify the user
735* Correct: Rely on [authorization](/specification/2025-11-25/basic/authorization.md) to identify the user
736736
737737### Form Mode Security
738738
from line 744
744744
745745URL mode elicitation returns a URL that an attacker can use to send to a victim. The MCP Server **MUST** verify the identity of the user who opens the URL before accepting information.
746746
747Typically identity verification is done by leveraging the [MCP authorization server](../basic/authorization) to identify the user, through a session cookie or equivalent in the browser.
747Typically identity verification is done by leveraging the [MCP authorization server](/specification/2025-11-25/basic/authorization.md) to identify the user, through a session cookie or equivalent in the browser.
748748
749749For example, URL mode elicitation may be used to perform OAuth flows where the server acts as an OAuth client of another resource server. Without proper mitigation, the following phishing attack is possible:
750750
No line in this hunk matches that.