MCP Elicitation Explained: Form Mode, URL Mode, and Secure User Consent

MCP elicitation lets a server ask the user for information during a request instead of requiring every value up front. The protocol has two different interaction modes. Form mode collects structured, non-sensitive information through the MCP client. URL mode sends the user to an out-of-band web interaction for sensitive data, third-party authorization, or payment confirmation. The distinction is a privacy and trust boundary, not merely a user-interface preference.

This article is verified against the MCP elicitation specifications, SEP-1036, and the 2026-07-28 multi-round-trip design on September 12, 2026. The wire flow differs between 2025-era and modern protocol revisions, so a production implementation must test the exact client and SDK versions it supports.

Form mode

Form mode is an in-band structured request. The server sends a human-readable message and a requested schema. The client presents the fields, validates them according to its own policy, and returns accept, decline, or cancel with structured content when appropriate. The content is visible to the MCP client and can be passed back into the server request.

{
  "mode": "form",
  "message": "Choose a deployment region",
  "requestedSchema": {
    "type": "object",
    "properties": {
      "region": { "type": "string", "enum": ["us", "eu"] }
    },
    "required": ["region"]
  }
}

Good form-mode inputs include a non-sensitive preference, a date, a project name, or a confirmation that does not itself disclose a credential. The server must still validate the returned value. A client-rendered form is not a replacement for server-side validation or authorization.

URL mode

URL mode is for an interaction that should not pass sensitive data through the MCP client. The server provides a valid URL, an elicitationId, and a message explaining why the user needs to open it. The client gives the user context and asks for consent to open the URL. The browser flow then happens outside the MCP message exchange.

{
  "mode": "url",
  "elicitationId": "elicit-opaque-2048",
  "url": "https://mcp.example.com/connect?elicitationId=elicit-opaque-2048",
  "message": "Authorize access to the selected repository"
}

URL mode does not authorize the MCP client's access to the MCP server. The MCP bearer token remains the same. URL mode is for the server obtaining user input or authorization from another system on the user's behalf. Confusing those two flows can produce an incomplete security design.

Bind the browser flow to the right user

A URL can be copied, modified, opened by another person, or replayed. The server must bind the elicitation to the user who started it and verify that binding again when the browser callback arrives. A common design is a server-owned connect page that checks a user session before redirecting to a third-party authorization provider. The exact mechanism depends on the deployment, but it must resist an attacker changing the elicitation URL or substituting another user's session.

• Use a short-lived, unguessable elicitation identifier.
• Store the initiating user or authorization subject with the elicitation state.
• Do not put secrets or bearer tokens in the URL query string.
• Use an exact callback and state validation strategy for the third-party flow.
• Treat accept as consent to open the interaction, not proof that the external action completed.
• Expire completed, cancelled, and abandoned elicitations.

Accept, decline, cancel, and complete

An accepted form contains user-provided content. A declined or cancelled form should let the server stop safely without treating the result as an error caused by the user. In URL mode, accept means the user consented to the client opening the URL. It does not necessarily mean that the external OAuth, payment, or credential step succeeded. The server should communicate completion separately when the out-of-band action finishes.

The modern multi-round-trip flow

The 2026-07-28 revision removes the need for a server to send a separate server-to-client JSON-RPC request during a stateless call. Instead, a server can return an input_required result containing an elicitation request. The client fulfills it and retries the original operation with inputResponses and, when present, the opaque requestState. The retried request must use a fresh JSON-RPC ID.

{
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "region": {
        "method": "elicitation/create",
        "params": { "mode": "form", "message": "Choose a region" }
      }
    },
    "requestState": "opaque-server-state"
  }
}

Legacy 2025-era clients may use the older server-to-client request channel and capability negotiation. A server supporting both should keep the semantics aligned while using the wire pattern appropriate to the negotiated revision. Do not assume that a client supporting form mode also supports URL mode.

Elicitation and MCP authorization are different

MCP authorization protects access to the MCP server itself. Elicitation can be used after that connection exists when the server needs the user to authorize a third-party service or provide sensitive information through a browser. The two flows may be related in a product, but they have different tokens, endpoints, trust decisions, and completion signals.

Client compatibility tests

• Client declares form support and renders a valid non-sensitive schema.
• Client declines a form and the tool exits without a side effect.
• Client cancels a form and the server cleans up pending state.
• Client supports URL mode and shows the full URL with user consent.
• Client does not support URL mode and receives a safe, actionable fallback.
• The user opens the URL in a different browser session and the server rejects the mismatch.
• The browser flow completes after the original MCP request has timed out.
• A duplicate retry does not create two authorizations or two payments.

What TrackMCP can and cannot tell you

TrackMCP can report server-boundary evidence such as an elicitation request, the mode emitted by the application, a subsequent retry, a tool error, or an explicit workflow outcome. It can help a team see where server-side flows stop and which client metadata was available.

TrackMCP cannot see a private browser session, validate that a user read a consent screen, or know that a third-party OAuth provider completed unless the application emits a bounded completion event. URL contents and credential values should remain outside telemetry unless a deliberate, compliant data policy says otherwise.