What it does
The `notifications/elicitation/complete` notification fires exclusively in the URL-mode elicitation flow. When a server calls `elicitation/create` with `mode: "url"`, it must include an `elicitationId` in the request params. The client opens the target URL in a browser tab and enters a waiting state. Once the user finishes that out-of-band interaction — completing an OAuth grant, a payment page, or any trusted-browser flow — the client emits this notification to the server, carrying the same `elicitationId` and an `action` value of `accept`, `decline`, or `cancel`.\n\nThe direction is Client → Server: the client is the sender and the MCP server is the receiver. Upon receiving this notification the server should unblock any logic that was suspended waiting for the elicitation result, then branch on `action`. An `accept` means the external flow succeeded; `decline` means the user explicitly refused; `cancel` means the browser tab was closed or the flow was abandoned without a definitive outcome. None of these three paths returns form-field data — URL-mode completion carries only the action, so the server must derive outcome details from the external system (e.g., exchanging the OAuth code its callback endpoint already received).\n\nThis notification is only valid when the client has declared `elicitation.url` inside its `ClientCapabilities` during `initialize`. If the client omits that sub-capability the server MUST NOT issue a URL-mode `elicitation/create`, and no completion notification will ever arrive. Because JSON-RPC notifications are fire-and-forget with no acknowledgement, the server cannot confirm delivery; it should implement a timeout and treat silence as an implicit `cancel` after a reasonable interval.
When to use
On completion of a url-mode elicitation.
When NOT to use
For form-mode — that uses the request/response cycle.
Notes
Capability gating is mandatory
The client declares elicitation support in ClientCapabilities.elicitation during initialize, with separate sub-keys for form and url modes. A server that issues url-mode elicitations without first checking for the url sub-capability violates the protocol — well-behaved clients will ignore or error on an unexpected elicitation/create.
elicitationId must be present in url mode
Unlike form mode, url-mode elicitations require the server to include an elicitationId in the elicitation/create params. Without it the client has no stable identifier to echo back in this notification, making correlation impossible. Servers should generate a unique, opaque ID per request (e.g., a UUID) and store it locally while awaiting completion.
No payload beyond action — derive outcome externally
The completion notification intentionally carries only elicitationId and action. Sensitive tokens or redirected data from the external flow (an OAuth authorization code, a payment confirmation) should have been delivered to your server-side callback endpoint — never through the MCP channel. The notification is purely a signal that the user has finished; reconcile the result via your own backend state.
Silence and race conditions
Because notifications carry no acknowledgement, there is no built-in timeout or retry. A client crash, network drop, or user simply closing the app after opening the URL can leave the server hanging indefinitely. Servers must apply their own deadline: if no completion notification arrives within an expected window, treat the elicitation as cancelled and resume or abort accordingly. Similarly, a server restart between sending the request and receiving the notification must handle the orphaned elicitationId gracefully.
Parameters
| Name | Type | Purpose |
|---|---|---|
| elicitationId | string | Identifier from the original request. |
| action | 'accept' | 'decline' | 'cancel' | Outcome. |
Examples
OAuth accepted
{ "method": "notifications/elicitation/complete", "params": { "elicitationId": "e1", "action": "accept" } }