Who’s on FirstChoose a flow

Flows / Human in the loop

Out-of-band authorization (MCP URL elicitation)

A tool needs the user to sign in somewhere else. It hands back a link, the user completes the flow in a browser, and the secret never touches the agent.

Based onMCP specification 2026-07-28, ElicitationFinal specGuide reviewedNovember 2026

Sources and review details
This page
Implementation guideAn explanation, not a specification
Primary specification
MCP URL-Mode ElicitationFinal spec · Introduced in 2025‑11‑25 and reworked in 2026‑07‑28
All 3 specifications
2 published, 1 draft
Flow maturity
EmergingWhat the rating means
Human involvement
Human present
Review
Checked against sources in November 2026How it was checked

An MCP server often sits in front of someone else’s API. The user has authorized their client to use the MCP server, but the server still needs the user’s permission at the third party: their code host, their CRM, their bank.

The wrong ways to get it are familiar. Ask the user to paste an API key into the chat, where the model and every log will see it. Or have the client forward its own token, which is token passthrough. URL-mode elicitation is the protocol’s answer: in the middle of a tool call the server replies “I need the user to visit this URL.” The client shows the link, the user opens it in a real browser, and the server completes an ordinary OAuth flow with the third party on its own. The credential is stored by the server and is never seen by the client or the model.

The same mechanism covers anything sensitive that should bypass the agent: entering a key, confirming a payment, approving a specific action on a page the server controls.

Step by step

12 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.

Sequence diagram4 participants, 12 steps
  • Direct call
  • Via the user’s browser or device
  • Response
  • Local action

Drag to see every party and step. Tap a step to jump to its explanation.

1tools/call +Bearer token2No third-party grant for user3Input required:open URL4Show full URL;ask to open5Open connect page6Redirect tothird-party sign-in7Sign in and consent8Redirect with code9Store tokens for this user10Retry tools/call+ requestState11API call withthird-party token12Tool result

  1. 1MCP clientMCP serverDirect call

    The agent calls a tool

    The client is already authorized to the MCP server. Its bearer token identifies the user to the server.

    Who holds what after this step

    MCP client
    newaccess token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  2. 2MCP serverLocal action

    The server finds it has no downstream credential

    The server looks up the user (from the sub of the MCP access token) and finds no stored token for the third-party service. It must not try the client’s token there.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  3. 3MCP serverMCP clientResponse

    The server answers with an elicitation

    Instead of a tool result, the server returns an InputRequiredResult containing a URL-mode elicitation. requestState is an opaque value the client will echo back; the server must treat it as attacker-controlled and protect its integrity.

    {
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "connect_tracker": {
        "method": "elicitation/create",
        "params": {
          "mode": "url",
          "url": "https://mcp.example.com/connect/tracker",
          "message": "Connect your issue tracker to continue."
        }
      }
    },
    "requestState": "v1.9f2c…"
  }
}

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  4. 4MCP clientUserDirect call

    The client asks the user, and stays out of the way

    The client must show the complete URL, must not fetch it itself, and must not open it without explicit consent. It opens the link in a browser context the model cannot read.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  5. 5UserMCP serverVia the user’s browser or device

    The user lands on a page the server controls

    The recommended design is a “connect” URL on the server’s own domain rather than a direct link to the third party. That page checks that the browser belongs to the same user who made the tool call, which blocks an attacker from sending their own link to a victim.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  6. 6MCP serverThird-party serviceVia the user’s browser or device

    The server starts its own OAuth flow

    Here the MCP server is an ordinary OAuth client of the third party, with its own client ID, redirect URI and PKCE.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  7. 7UserThird-party serviceVia the user’s browser or device

    The user authorizes the server directly

    The consent screen names the MCP server’s application, not the AI client. The user is granting access to the server.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  8. 8Third-party serviceMCP serverVia the user’s browser or device

    The third party returns a code to the server

    The browser is redirected back to the MCP server, which redeems the code at the third party’s token endpoint.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  9. 9MCP serverLocal action

    The server keeps the third-party tokens

    Stored server-side, keyed to the user. They never transit the MCP client and are never visible to the model.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)
    MCP server
    newthird-party tokens

    Parties not listed hold none of this flow’s credentials at this point.

  10. 10MCP clientMCP serverDirect call

    The client retries the original call

    There is no completion callback in the current revision. The client simply retries, echoing requestState and an inputResponses entry. An accept response means only that the user agreed to open the link, so the server checks for itself whether the connection now exists.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)
    MCP server
    third-party tokens

    Parties not listed hold none of this flow’s credentials at this point.

  11. 11MCP serverThird-party serviceDirect call

    The server calls the downstream API as itself

    Using the token it obtained, addressed to the third-party API.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)
    MCP server
    third-party tokens

    Parties not listed hold none of this flow’s credentials at this point.

  12. 12MCP serverMCP clientResponse

    The tool call completes

    From the agent’s point of view a tool call took a detour through the user. It holds exactly what it held before.

    Who holds what after this step

    MCP client
    access token (aud: MCP server)
    MCP server
    third-party tokens

    Parties not listed hold none of this flow’s credentials at this point.

Watch out for

  • This is not how a client gets authorized to the MCP server itself. That is MCP authorization; the specification says servers must not use elicitation for it.
  • Phishing in both directions. A malicious server can send a link to a lookalike sign-in page, so clients must show the full URL and never open it without consent. And the server must make sure the person who completes the flow is the user who started it.
  • The server becomes a holder of third-party tokens, with everything that implies for storage and revocation.
  • The feature is still marked as subject to change, and its wire format did change in 2026-07-28. Check client support before depending on it.

Standards in play

See the full tracker for status and links.

Final specMCP specification 2026-07-28, Elicitation

MCP URL-Mode Elicitation

Keeps downstream credentials out of the agent and the model.

Final specMCP specification 2026-07-28

MCP Authorization

The most widely implemented authorization profile written specifically for agents and tools.

WG draftdraft-ietf-oauth-v2-1

OAuth 2.1

The baseline MCP profiles. Worth knowing that the normative base of most agent authorization is still, formally, a draft.

MCP authorization

How an MCP client that has never seen a server before discovers where to sign in, identifies itself, and gets a token good for that server alone.

Human presentEmerging

Credential broker

The agent never holds the secret. A proxy outside the sandbox adds it to outgoing requests, and only for the hosts it was meant for.

With or without a humanEmerging

Backchannel approval (CIBA)

The agent asks the authorization server to go and find the user. Approval arrives as a push notification, not a redirect.

Human reachableStable standards

Step-up authorization

Start with a weak token. When the agent reaches something sensitive, the API says so and the user is asked for exactly that.

Human presentStable standards