Secure Out-of-Band MCP URL Elicitation

Secure interaction outside the MCP client

URL mode elicitation lets an MCP server direct a user to a browser flow for an interaction that must not pass through the MCP client. Credentials, payment details, and other secrets go directly to the external service; the client presents the destination and tracks the elicitation without inspecting what the user enters there.

The mode was added in the MCP specification dated November 25, 2025. The specification marks it as a new feature whose design and implementation may change in later protocol revisions.

The browser creates the security boundary

The November 2025 elicitation specification defines URL mode as an out-of-band interaction. The MCP server sends a URL through the protocol, but the sensitive part of the exchange happens after the user leaves the client-controlled interface and opens that URL in a secure browser context.

This boundary matters because a normal client-rendered input becomes visible to the client. It may also enter model context, application telemetry, debugging output, crash reports, or other client-side processing. URL elicitation keeps the submitted data out of that path. The client sees the URL and protocol state, but not the credentials or payment information entered on the external page.

Sensitive information must not be requested through form mode. That includes passwords, API keys, access tokens, payment credentials, and other secrets that grant access or authorize transactions. Non-secret structured responses can remain in MCP form elicitation, where the client intentionally receives and validates the submitted fields.

For URL mode, the MCP server sends an elicitation/create request containing:

• mode: "url", which identifies the out-of-band mode;
• message, which explains why the interaction is required;
• url, which identifies the browser destination;
• elicitationId, which uniquely identifies this elicitation.

The URL itself is exposed to the client because the client must show it to the user. Data entered after navigation is not returned as elicitation content. The browser page sends that data to the external service or to the MCP server handling the external workflow, without routing it back through the client.

A URL mode response therefore has no content field containing the submitted secret. The response action records what the user did with the client prompt, not what they typed on the external page.

What the MCP client presents and tracks

A client supporting URL elicitation declares elicitation.url in its capabilities during initialization. A server must not send URL elicitation to a client that did not declare support for it. If it does, the client returns JSON-RPC invalid parameters error -32602.

When a supported request arrives, the client is responsible for presenting the handoff clearly. It must identify which MCP server is asking for the interaction, explain the request, display the full target URL for examination, and obtain explicit consent before opening it. The client should emphasize the destination domain and warn about ambiguous or suspicious addresses, including addresses using Punycode.

The client must not open the page automatically. It must also not pre-fetch the URL or fetch page metadata for a preview. Either action would contact a server before the user has consented and could leak client or network information. The user must be able to decline the request or cancel without completing it.

After consent, the client must open the URL in a browser context that prevents both the client and the model from inspecting the page content or the user’s input. An embedded web view that exposes the document, form fields, cookies, or navigation state to the host application does not preserve this boundary. The requirement is not merely to display a web page; it is to display it without giving the MCP client an observation channel into the sensitive exchange.

The MCP maintainers’ November 25, 2025 release account describes the intended split plainly: the client provides an affordance for the URL, while the server receives and manages credentials from the browser flow. That separation leaves the client responsible for its own authorization to the MCP server, not for holding credentials belonging to downstream services.

The initial URL elicitation response uses one of three actions:

• accept means the user consented to open or continue with the external interaction;
• decline means the user explicitly refused it;
• cancel means the prompt or navigation was dismissed without an explicit decision, or the browser could not complete the handoff.

For URL mode, accept does not mean that authentication, payment, or credential submission succeeded. It records consent to the out-of-band interaction. The client cannot infer completion from that response because it does not observe the external page.

The server may later send notifications/elicitation/complete with the original elicitationId. This notification tells the initiating client that the external interaction finished. It does not disclose the information submitted or even carry a secret-bearing result. The client tracks correlation and completion, not page contents.

A completion notification must go only to the client that initiated the elicitation. Clients must ignore unknown identifiers and identifiers for elicitations already marked complete. Because completion notifications are optional, a client should also retain manual controls that let the user retry, cancel, or resume the original operation if no notification arrives.

When an operation cannot proceed until one or more URL interactions finish, a server may return URLElicitationRequiredError, JSON-RPC code -32042. The error contains the required URL elicitations and their identifiers. After receiving completion, the client may retry the blocked request. This gives the client enough state to continue the workflow without receiving the credentials that unblocked it.

OAuth without credential transit through the client

URL elicitation supports OAuth when an MCP server needs authorization to call a third-party resource server on the user’s behalf. The MCP server acts as an OAuth client of that third party. It creates an authorization URL, binds the elicitation to the user, sends the URL through the MCP client, and receives the third party’s callback after the user completes authorization in the browser.

The third-party authorization credentials must not transit through the MCP client. The user authorizes the MCP server directly, and the MCP server stores and manages the resulting third-party tokens. It must not send those tokens back to the client. Future tool calls can use the stored authorization at the server.

This is separate from authorization between the MCP client and the MCP server. URL elicitation does not authorize the client to access the MCP server, and it does not replace the normal MCP authorization flow. The client’s bearer token for the MCP server remains unchanged. The distinction is important when deciding how to handle OAuth and API-key authentication for an MCP server: URL elicitation concerns a sensitive downstream interaction, not the client’s original connection credentials.

Passing the client’s third-party token through the MCP server is not a substitute. MCP security guidance forbids token passthrough because the server would be accepting a token that was not properly issued to it and forwarding it downstream. URL elicitation instead makes the MCP server a real participant in the external authorization flow and assigns it responsibility for storing and managing the resulting tokens.

Payments and other secure browser interactions

The same boundary supports payments and other operations that require a secure browser context. The MCP server supplies a URL and a message appropriate to the operation; the browser page handles the sensitive fields and any service-specific checks. The MCP client receives only consent state and, when supplied, a completion notification.

This does not make the client a payment form or credential vault. It keeps the client outside those roles. Any compliance, validation, confirmation, or transaction handling remains the responsibility of the external page and the services behind it. URL elicitation only defines the handoff and protocol-level lifecycle.

Other credential-acquisition flows follow the same rule. A user may enter an API key or password on a trusted HTTPS page, but the value must not be copied into an MCP client dialog, an elicitation response, a model message, or a URL. The server can retain the credential for later requests only after binding it securely to the verified user.

URL mode is therefore not the right mechanism for ordinary non-sensitive questions that the server needs returned as structured data. It is also not a general-purpose way to open arbitrary links. Its purpose is an external interaction whose contents must remain outside the MCP client.

Server-side state and identity

Keeping secrets outside the client moves responsibility to the MCP server. The server needs protected state that associates the elicitation, the browser session, the initiating client, and the authenticated user. Session identifiers alone are not sufficient identity. For a remote MCP server, the specification says user identity should come from verified authorization credentials where possible, such as an authenticated subject claim.

The server must not accept an unverified identity supplied by the client or entered into the browser page. A malicious client could forge it. When the user opens an elicitation URL, the server must verify who opened it before accepting sensitive information. A browser session associated with the server’s authorization system is one stated way to perform that check.

For an external OAuth flow, the stored state connects the elicitation to the user before redirection. The external authorization server then redirects to the MCP server, which validates the return, stores the third-party tokens against that user, and can notify the initiating client that the elicitation completed. These tokens remain separate from the credentials the MCP client uses to access the MCP server.

This requirement makes URL elicitation stateful in practical deployments. The server needs a browser endpoint, secure state storage, user binding, callback handling where applicable, and a way to recover when a user abandons the flow. Whether the MCP server runs locally or remotely changes where those responsibilities live; the deployment boundary is covered in remote and local MCP server configurations.

Safe URL construction and opening

The URL crosses the MCP client even though the submitted data does not, so it must not become a secret carrier. A server must not place credentials, personally identifiable information, or other sensitive user data in the URL. It must not send a pre-authenticated URL that a malicious client could reuse to impersonate the user. Non-development deployments should use HTTPS.

Clients must treat the supplied destination as untrusted input. The MCP security best-practices guidance requires authorization URL validation because unsafe handling can turn a malicious URL into script or command execution. Production authorization destinations must use HTTPS. HTTP is allowed only for loopback addresses during local development. Clients must reject dangerous schemes such as javascript:, data:, file:, and vbscript:.

A client must not invoke a shell to open the URL. Passing an untrusted address through cmd.exe, PowerShell, sh, or a shell script gives shell metacharacters a chance to become commands. The client should use the operating system’s non-shell URL-opening mechanism and keep the browser isolated from client and model inspection.

Displaying the full URL before navigation is part of the consent boundary. A friendly message or button label is not enough because it can conceal an unrelated host. Highlighting the registrable domain helps the user evaluate where credentials or payment details will go, but it does not replace showing the complete address.

The server must also bind each request to the correct client and user. Otherwise, an attacker could forward an elicitation URL to a victim and attach the victim’s completed interaction to the attacker’s workflow. Completion routing alone does not solve that problem; the browser endpoint has to verify the user independently before accepting or storing sensitive data.

What to check next

Before implementing URL mode, confirm that the client advertises the capability during initialization, that the server can maintain identity-bound state, and that the browser handoff cannot be inspected by the client or model. Confirm separately that URL validation, explicit consent, decline and cancel controls, optional completion handling, and manual recovery are present.

Then audit where existing secrets are stored. Credentials already placed in client configuration remain a separate exposure surface even if new authorization uses URL elicitation; see credentials in MCP client configuration files for that boundary. URL elicitation protects the browser interaction it initiates. It does not retroactively protect secrets passed through another channel.