MCP Elicitation: Form vs URL Mode for Production

MCP elicitation lets a server ask a user for information that is missing during a workflow. The Model Context Protocol defines form mode for structured input through the client and URL mode for interactions outside the client, including sensitive credentials and third-party authorization. The distinction matters when an agent needs help without turning a conversation into a password form. MCP elicitation specification

A production implementation needs more than a dialog box. It must know which client capabilities are available, who is answering, whether the answer is valid and whether an external step actually finished. This guide explains those boundaries and proposes a release checklist. Examples and recommendations are our synthesis, not claims about a Codesprint deployment.

Start with the missing decision, not a generic prompt

Elicitation is an input mechanism, not a universal permission shortcut. The specification lets implementations choose their user interface, but requires clients to identify the requesting server, support clear decline and cancel choices, and let users review and change form responses before sending. That context helps users understand why an unfamiliar server wants information. MCP elicitation specification

Our recommendation is to ask for one bounded piece of information at the point it is needed. A report workflow might need a date range. A support workflow might need a choice between two known projects. Do not ask a broad question that invites the user to paste credentials, unrelated customer records or instructions that expand the workflow.

Keep the requested input separate from the action it will enable. Choosing a project does not necessarily approve publishing a report to that project's members. If an answer will lead to a consequential action, our recommendation is to make the recipient, resource and effect clear in the application's own approval design.

Use form mode for supported structured input

Form mode collects data in-band, meaning the client sees the response. The specification uses a restricted JSON Schema subset, with flat objects and primitive properties, plus supported choice patterns. It intentionally excludes complex nested structures and arrays of objects. Clients can use the schema to build an input interface; this is not a promise that every arbitrary schema can become a form. MCP elicitation specification

A useful form request might ask for a report label, an agreed date or a choice from an allowed list. Our design rule is to request the smallest amount of data the operation needs, explain the purpose and validate it again on the server. A dropdown does not replace checking that the selected project exists and that the authenticated user may access it.

The specification prohibits using form mode for passwords, API keys, access tokens and payment credentials. It does not categorically prohibit general contact or profile data such as a name or email address, but leaves that request subject to user review and decline. Do not flatten these different data classes into either "all personal data is forbidden" or "anything the user types is safe." MCP elicitation specification

Use URL mode when the client must not see the data

URL mode directs the user to an external interaction. The specification requires it for sensitive information that must not pass through the MCP client. It is also clear about what URL mode is not: it does not authorize the client's access to the MCP server. MCP authorization and a server obtaining separate access to a third-party service are different relationships. MCP elicitation specification

For example, a server may need the user's authorization to read a third-party account. The external flow can handle that authorization while the server stores and manages the resulting third-party tokens. Those credentials must not be sent back through the MCP client, and the server must not pass the client's MCP credentials through to the third party. MCP elicitation specification

Our implementation checklist keeps credentials out of model-visible messages, tool results and ordinary analytics. Review the callback handler, error reporting and success screen as well as the initial URL. Moving the first credential field into a browser is not enough if a later response copies the token into the conversation.

Treat URL display as a security boundary

The protocol's URL-handling rules are stricter than "open this link." Clients must not automatically fetch the URL or its metadata, must show the full URL before consent, and must not open it without explicit user consent. The opened interaction must prevent the client or model from inspecting its contents or user inputs. The specification also recommends highlighting the domain. MCP elicitation specification

Server rules matter too. The URL must not contain sensitive end-user information or be pre-authenticated to a protected resource. HTTPS is recommended outside development. Our recommendation is to avoid link previews that silently contact the destination, and to test the actual client behavior rather than assuming a standard web-link component follows these rules. MCP elicitation specification

The display should tell the user which server requested the interaction and why. Our suggested acceptance test is simple: a person unfamiliar with the implementation can identify the destination domain and the requested task before opening it. A trusted-looking brand name inside the message is not a substitute for inspecting the destination.

Bind the browser flow to the same user

The specification describes a phishing risk in which one user obtains an elicitation URL and persuades another person to complete it. Without an identity check, a callback could bind the second person's third-party access to the first person's request. It therefore requires the server to verify that the person completing the external interaction is the person who initiated it. MCP elicitation specification

An implementation example in the specification checks a signed-in browser identity against the authenticated identity behind the MCP request before continuing to third-party authorization. The important requirement is the identity binding, not any single cookie implementation. Client-supplied text claiming an identity must not be treated as proof. MCP elicitation specification

Our backend review includes cross-user and cross-tenant tests, link tampering, expired attempts and callbacks arriving after cancellation. Store enough state to determine which operation can resume, but avoid putting private context into the URL. Keep authorization checks on the server even when the client has already displayed a reassuring confirmation screen.

Do not confuse accepted with completed

Elicitation responses distinguish accept, decline and cancel. For URL mode, accept means the user consented to the interaction; it does not mean the out-of-band step succeeded. The 2026-07-28 specification says the server checks completion when the client retries the original request, using echoed request state or its own stored state. It can return a final result or request further input. MCP elicitation specification

Our suggested application states are awaiting input, external step pending, verified complete, declined, canceled, expired and failed. They are a design proposal, not protocol enum values. Showing a browser window, receiving a click or getting an accept response must not by itself move the workflow to verified complete.

This matters for paid or account-changing operations. Our recommendation is to check the authoritative service result before showing success, then resume only the specific operation the user intended. Make a retry safe if the service finished but the response was lost. Our AI agent idempotency guide covers the separate problem of avoiding duplicate tool actions.

Pin the protocol version and client behavior

There is a material version difference. The 2025-11-25 elicitation specification describes capabilities during initialization, server-to-client requests and completion notifications. The 2026-07-28 specification describes client capabilities in request metadata and input requests delivered through an InputRequiredResult. Copying an older example into a newer client can produce a workflow that looks plausible but does not resume correctly. MCP 2025-11-25 elicitation MCP 2026-07-28 elicitation

AWS's AgentCore documentation also distinguishes the versions. For 2026-07-28, it describes URL elicitation through the multi round-trip pattern, with a retry carrying input responses and unmodified request state, and requires the gateway's supported versions to include that revision. This is implementation-specific guidance, not evidence that every MCP client supports the same flow. Source

Before release, our recommendation is to record the protocol revision, client, SDK, server and gateway versions together. Test the capabilities actually advertised. The specification forbids sending a mode that the client does not support; an empty elicitation capability object means form-only support for backwards compatibility, not universal URL support. MCP elicitation specification

Build a failure path before the happy path ships

The specification requires servers to handle decline, cancel and client-processing failures. Our release tests also cover a browser tab closed halfway through, an authorization refusal, a callback delivered twice and a user returning after the pending operation has expired. Verify that none silently falls back to asking for a secret in form mode. MCP elicitation specification

For unsupported clients, our recommendation is to explain the missing interaction and provide a supported next step without pretending the request completed. Do not loop the same prompt until the user accepts. Keep cancellation available and preserve the user's original task so they can resume without reconstructing every earlier choice.

For broader controls around the server, read our MCP server security best practices. Elicitation adds a user-input boundary; it does not replace authorization, tenant isolation or safe tool execution. If you are building an agent workflow and need to review those boundaries together, contact Codesprint.