Elicitation changedspecification/draft/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+12added
Lines−12removed
From line
333
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 333, old and new numbered
/
from line 333
333333>
334334> **Important**: URL mode elicitation is *not* for authorizing the MCP client's
335335> access to the MCP server (that's handled by [MCP
336> authorization](../basic/authorization)). Instead, it's used when the MCP
336> authorization](/specification/draft/basic/authorization.md)). Instead, it's used when the MCP
337337> server needs to obtain sensitive information or third-party authorization on
338338> behalf of the user. The MCP client's bearer token remains unchanged. The
339339> client's only responsibility is to provide the user with context about the
from line 462
462462
463463### Statefulness
464464
465Elicitations do not require that the server maintain state about users with the [multi round-trip requests](/specification/draft/basic/patterns/mrtr#multi-round-trip-requests) mechanism.
465Elicitations do not require that the server maintain state about users with the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism.
466466
467However, if state is stored, servers implementing elicitation **MUST** securely associate this state with individual users following the guidelines in the [security best practices](/docs/draft/tutorials/security/security_best_practices) document. Specifically:
467However, if state is stored, servers implementing elicitation **MUST** securely associate this state with individual users following the guidelines in the [security best practices](/docs/draft/tutorials/security/security_best_practices.md) document. Specifically:
468468
469469* State storage **MUST** be protected against unauthorized access
470* For remote MCP servers, user identification **MUST** be derived from credentials acquired via [MCP authorization](../basic/authorization) when possible (e.g. `sub` claim)
470* For remote MCP servers, user identification **MUST** be derived from credentials acquired via [MCP authorization](/specification/draft/basic/authorization.md) when possible (e.g. `sub` claim)
471471
472472> [!NOTE]
473473>
from line 492
492492### URL Mode Elicitation for OAuth Flows
493493
494494URL mode elicitation enables a pattern where MCP servers act as OAuth clients to third-party resource servers.
495Authorization 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.
495Authorization with external APIs enabled by URL mode elicitation is separate from [MCP authorization](/specification/draft/basic/authorization.md). MCP servers **MUST NOT** rely on URL mode elicitation to authorize users for themselves.
496496
497497#### Understanding the Distinction
498498
499* **MCP Authorization**: Required OAuth flow between the MCP client and MCP server (covered in the [authorization specification](../basic/authorization))
499* **MCP Authorization**: Required OAuth flow between the MCP client and MCP server (covered in the [authorization specification](/specification/draft/basic/authorization.md))
500500* **External (third-party) Authorization**: Optional authorization between the MCP server and a third-party resource server, initiated via URL mode elicitation
501501
502502In external authorization, the server acts as both:
from line 513
513513The critical security requirements are:
514514
5155151. **The third-party credentials MUST NOT transit through the MCP client**: The client must never see third-party credentials to protect the security boundary
5162. **The MCP server MUST NOT use the client's credentials for the third-party service**: That would be [token passthrough](/docs/draft/tutorials/security/security_best_practices#token-passthrough), which is forbidden
5162. **The MCP server MUST NOT use the client's credentials for the third-party service**: That would be [token passthrough](/docs/draft/tutorials/security/security_best_practices.md#token-passthrough), which is forbidden
5175173. **The user MUST authorize the MCP server directly**: The interaction happens outside the MCP protocol, without involving the MCP client
5185184. **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).
519519
from line 522
522522> [!NOTE]
523523>
524524> For additional background, refer to the [token passthrough
525> section](/docs/draft/tutorials/security/security_best_practices#token-passthrough)
525> section](/docs/draft/tutorials/security/security_best_practices.md#token-passthrough)
526526> of the Security Best Practices document to understand why MCP servers cannot
527527> act as pass-through proxies.
528528
from line 617
617617### Identifying the User
618618
619619Servers **MUST NOT** rely on client-provided user identification without server verification, as this can be forged.
620Instead, servers **SHOULD** follow [security best practices](/docs/draft/tutorials/security/security_best_practices).
620Instead, servers **SHOULD** follow [security best practices](/docs/draft/tutorials/security/security_best_practices.md).
621621
622622Non-normative examples:
623623
624624* Incorrect: Treat user input like "I am [[email protected]](mailto:[email protected])" as authoritative
625* Correct: Rely on [authorization](../basic/authorization) to identify the user
625* Correct: Rely on [authorization](/specification/draft/basic/authorization.md) to identify the user
626626
627627### Form Mode Security
628628
from line 634
634634
635635URL 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.
636636
637Typically 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.
637Typically identity verification is done by leveraging the [MCP authorization server](/specification/draft/basic/authorization.md) to identify the user, through a session cookie or equivalent in the browser.
638638
639639For 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:
640640
No line in this hunk matches that.