Skip to main content

Elicitation

Some tool calls can't finish without asking the human on the other end of the agent something first: a missing field, a confirmation, an out-of-band login. MCP models this as elicitation, an elicitation/create request an upstream server sends mid-call, addressed to whichever client is ultimately connected. MCP Gateway relays it, and the client's eventual answer, without unwrapping or interpreting either one.

How It Works

An upstream MCP server can send an elicitation/create request at any point while handling a tools/call. MCP Gateway forwards it back through the pipeline unchanged, mcp · client → mcp · proxy → mcp · server, to the client that opened the session. The client resolves it however it resolves any elicitation, form UI, browser redirect, approval prompt, and the response flows back the same path in reverse.

Nothing about this relay is specific to any one upstream, tool, or guard. It's a property of the mcp · server, mcp · proxy, and mcp · client bindings passing every JSON-RPC message through as-is, the same pipeline documented in How It Works.

Form Mode

Form-mode elicitation is the general case: an upstream tool needs a piece of information it doesn't have, and asks for it through whatever prompt the client renders. No guard or auth flow is involved, any upstream MCP server can send one from any tool. The client must advertise elicitation support at initialize for the upstream's request to be worth sending in the first place.

URL Mode

URL-mode elicitation (SEP-1036) covers the case where the response can't come back through the same JSON-RPC round trip, commonly an OAuth consent screen or another page the user has to open in a browser. The upstream sends an elicitation/create request with mode: "url" and a link; once the user completes that out-of-band step, the upstream sends a follow-up notifications/elicitation/complete notification. MCP Gateway relays both, the initial request and the completion notification, the same way it relays a form-mode request.

URL-mode elicitation only reaches a client that advertised it. A client capable of form-mode elicitation but not URL-mode never receives the URL-mode request at all; the upstream is expected to fall back or fail the call instead.

{
  "method": "initialize",
  "params": {
    "capabilities": {
      "elicitation": { "url": {} }
    }
  }
}

When to Use It

Reach for an upstream MCP server that issues elicitation requests when a tool call needs information or a confirmation the caller didn't already supply, or needs the user to complete a step (like an OAuth grant) outside the MCP session entirely. MCP Gateway doesn't require any configuration to relay either mode: as long as the client and upstream both speak the relevant part of the MCP spec, the gateway carries it between them.

Tips

The mcp · server binding's own options.elicitation (callback, timeout) is a separate, narrower mechanism: it's specifically for an OAuth authorization flow the gateway itself drives, not the general elicitation relay described here. See Bearer Auth.

Get Started

Try the example

The mcp.proxy example includes two elicitation walkthroughs: a form-mode round trip against the everything reference server's demo tool, and a URL-mode round trip against a minimal urlelicit server built for the purpose.