Understanding URL-mode elicitation in MCP

In the Model Context Protocol (MCP), elicitation is the mechanism a server uses to request additional input from a user while a session is in progress. An MCP server can pause execution, ask the user for information, and wait for a response before continuing. This allows workflows to be interactive rather than limited to one-shot tool calls.

Today, MCP elicitation primarily works by requesting structured data from the user. The server specifies what information it needs, optionally including a JSON Schema to validate the response. The MCP client collects the information from the user and returns the result to the server.

This approach works well for simple, non-sensitive input. However, it has clear limits.

Some user interactions cannot safely or practically be handled inside an MCP client. OAuth authorization flows, credential entry, and payment setup all require trusted external surfaces and must avoid passing sensitive data through the client or model context. Structured in-band elicitation does not provide a clean way to support these cases.

URL-mode elicitation addresses this gap.

With URL-mode elicitation, an MCP server can explicitly ask the client to send the user to an external URL to complete a required step. The interaction happens outside the MCP session, and the client’s role is limited to guiding the user to that URL and tracking whether the step was completed.

This makes out-of-band user interactions a first-class part of the MCP protocol, rather than an implicit workaround.

In this article, we will look at how URL-mode elicitation works at the protocol level, how it differs from form-based elicitation, and how it enables secure, real-world workflows.

What is elicitation in MCP and why URL-mode matters

At its core, elicitation allows an MCP server to pause a workflow and request additional input from a user. This is essential for workflows that depend on user choices, configuration, or approval before continuing. For example, a deployment assistant might need a user to choose between staging and production environments before running a script, or a data-cleaning tool might ask which columns to normalize before proceeding. In these cases, elicitation ensures that the model can gather the right parameters directly from the user rather than guessing or relying on defaults.

Early elicitation support focused on collecting structured data directly through the MCP client. This design keeps the interaction tightly coupled to the session and ensures responses can be validated and handled deterministically. It works well for simple, in-band decisions such as toggling options, confirming actions, or providing short text inputs.

However, as MCP has been applied to more real-world integrations, it has become clear that not all user interactions belong inside the client. For instance, when connecting to external APIs that require OAuth authorization, or when a workflow involves entering payment details or private credentials, the interaction must happen in a secure, trusted environment outside the MCP client. These are environments the client should not observe (such as a browser-based login page, a corporate single sign-on portal, or a PCI-compliant payment form) because they handle sensitive data that must never pass through the model context.

URL-mode elicitation exists to handle those cases explicitly.

How URL-mode elicitation works

A typical URL-mode elicitation flow looks like this:

1. The server sends a URL-mode elicitation request.
2. The client presents the message and directs the user to the URL.
3. The user completes the interaction outside the MCP client.
4. The server tracks completion through its own mechanisms and may notify the client when the step is complete.

The MCP client does not receive sensitive data and does not need to understand the details of the external interaction.

Client capability declaration

Before a server can use URL-mode elicitation, the MCP client must first indicate that it supports this feature during initialization. This is the setup phase where the client and server exchange information on the features they support.

Clients may support only form mode, only URL mode, or both.

A client that supports both structured (form) elicitation and URL-mode elicitation would advertise capabilities like this:

	
{
  "capabilities": {
    "elicitation": {
      "form": {},
      "url": {}
    }
  }
}
	

This declaration is not optional. If a client does not include "url" in its capabilities, the server must assume that URL-mode elicitation is unsupported and must not attempt to initiate it. In that case, the server should either fall back to form-based elicitation or fail the operation with an appropriate error.

This explicit capability check is important because URL-mode elicitation requires client behavior that goes beyond simple data collection. The client must be able to:

• Safely present external URLs to the user
• Clearly communicate why navigation is required
• Handle user cancellation or refusal
• Maintain session state while the user leaves the client context

By requiring clients to opt in via capabilities, MCP ensures that URL-mode elicitation is only used when both sides are prepared to support it correctly.

Elicitation request structure

Once the MCP server knows that the client supports elicitation it can proceed with its workflow and pause to request for information when needed.

For example, imagine a server that needs to connect to a user’s GitHub account to fetch private repositories. The server can’t safely ask for a personal access token inside the MCP client, so it needs a way to send the user to GitHub’s own authorization page. This is where URL-mode elicitation comes in.

In this case, the server pauses its workflow and sends a special request to the client, saying in effect: “Please show the user this message and open this URL so they can authorize access.” Once the user completes the action, the server can continue its work.

The server sends to the client a URL-mode elicitation request:

	
{
  "jsonrpc": "2.0",
  "id": "request-123",
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "message": "Authorize access to your GitHub account",
    "url": "https://auth.example.com/oauth",
    "elicitationId": "elicit-abc"
  }
}
	

Key fields include:

• mode: Must be set to "url".
• message: A human-readable explanation shown to the user.
• url: The external location where the interaction occurs.
• elicitationId: A server-generated identifier used to track the interaction lifecycle.

A typical client response looks like this:

	
{
  "jsonrpc": "2.0",
  "id": "request-123",
  "result": {
    "action": "accept" // or "decline" or "cancel"
  }
}
	

This means:

• The client accepted the elicitation request
• The client has presented the message to the user
• The client has initiated navigation to the provided URL (or otherwise enabled it)

It does not mean:

• The external interaction succeeded
• The user completed the flow
• Authorization was granted

Those outcomes are still determined out of band by the server.

Required URL-mode elicitation

In MCP, a server can indicate that an elicitation step is required in order to continue a workflow. This is important for cases where the server cannot proceed safely unless the user completes a specific interaction, such as OAuth authorization or credential setup. When URL-mode elicitation is marked as required:

• The server must pause the workflow until the elicitation completes.
• A client that supports URL-mode must present the request to the user.
• A client that does not support URL-mode must fail the request rather than attempting to continue.

In practice, this makes URL-mode elicitation a blocking control-flow step, not just a best-effort prompt. Servers should be prepared for both outcomes: successful completion, or a client error indicating that required elicitation is unsupported.

A simplified example of a required URL-mode elicitation request looks like this:

	
{
  "jsonrpc": "2.0",
  "id": "request-456",
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "required": true,
    "message": "Authorize access to your GitHub account",
    "url": "https://auth.example.com/oauth",
    "elicitationId": "elicit-required-1"
  }
}
	

If the client cannot perform this required elicitation, it should return an error rather than continuing the workflow. This ensures that sensitive or security-critical steps are never skipped or partially executed.

Elicitation request completion

In practice, the server’s tracking mechanism depends on the external system involved. For example, in a GitHub OAuth flow, the server might generate a unique state parameter and store it alongside the user’s session. When GitHub redirects back to the server’s callback endpoint, the server verifies the state value, exchanges the authorization code for an access token, and marks the elicitation as complete.

Once the external process finishes, the server can send a notification such as notifications/elicitation/complete to the client, including the elicitationId from the original request. This tells the client that the out‑of‑band step has finished and that the workflow can continue.

	
{
  "jsonrpc": "2.0",
  "method": "notifications/elicitation/complete",
  "params": {
    "elicitationId": "request-123"
  }
}
	

If the user cancels or the external service returns an error, the server can instead send a failure notification or simply let the client’s timeout logic handle it.

Form mode vs URL mode

Form mode and URL mode are two complementary ways for an MCP server to gather user input.

• Form mode keeps the interaction inside the client and is best for simple, structured data.
• URL mode sends the user outside the client for actions that require secure or external handling, such as authentication or payments.

The table below summarizes the main differences.

Both modes serve different purposes and are designed to coexist.

URL-mode elicitation in the broader MCP execution model

Recent updates to MCP also introduce bidirectional tool calling, where servers can suggest or initiate the next step in a workflow rather than acting as passive tool providers. This allows servers to encode more of their own planning and control logic, including when human input is required.

URL-mode elicitation fits naturally into this model. When a server determines that progress depends on a human completing a sensitive or external action (such as authenticating with a third-party service) it can pause execution, initiate a URL-mode elicitation, and resume only after the out-of-band step completes.

Together, bidirectional tool calling and URL-mode elicitation enable MCP workflows that combine automated reasoning, server-side orchestration, and explicit human interaction, without forcing sensitive data through the client or model context.

‍Security and implementation considerations

‍URL-mode elicitation introduces an explicit transition from the MCP client to an external system. Both servers and clients need to handle this transition carefully to avoid security and usability issues.

• Treat URL-mode elicitation as a trust boundary: Servers should assume that anything happening at the external URL occurs outside the MCP session and outside the client’s control. Completion, failure, or cancellation must be tracked and validated by the server, not inferred from client behavior.
• Make redirection explicit to the user: Clients should clearly explain why the user is being redirected and what action is expected. The destination URL should be visible so users can recognize where they are being sent and avoid spoofed or misleading links.
• Do not pass sensitive data through the client: Secrets, credentials, tokens, and payment details should never flow through the MCP client or model context. URL-mode elicitation exists specifically to keep these interactions out-of-band.
• Handle cancellation and timeouts explicitly: Servers should be prepared for users to abandon or decline the external step and should define clear failure or retry behavior when a URL-mode elicitation is not completed.
• Use URL-mode elicitation narrowly: Clients should not treat URL-mode elicitation as general navigation, and servers should only invoke it when structured, in-band elicitation is insufficient or unsafe.

These constraints help ensure that URL-mode elicitation strengthens MCP’s security model rather than weakening it.

Conclusion

URL-mode elicitation extends MCP’s interaction model to cover cases that structured, in-band elicitation cannot safely handle. By standardizing out-of-band user interactions, MCP enables secure, real-world workflows without sacrificing clarity or protocol consistency.

As MCP adoption grows, URL-mode elicitation will play a critical role in bridging conversational AI workflows with the broader ecosystem of authentication, security, and commerce systems.