MCP Elicitation: Form, URL, or Task Input?
Choose form, URL, or task input from the trust boundary, then design decline, expiry, idempotent resume, and privacy-preserving receipts.
MCP elicitation should match the boundary of the input, not the convenience of the server. This guide shows when to use a structured form, an external URL, or task input—and how to make decline, expiry, retry, and audit behavior explicit.
MCP elicitation begins with the trust boundary
MCP elicitation is a protocol decision about who may ask for which kind of human input, not a prettier prompt box. A server can request structured data in form mode, direct a person to an external interaction in URL mode, or return an InputRequiredResult so a task can pause and resume. Those paths move different data across different boundaries, so choosing by visual preference is unsafe.
Start with the boundary. If the server only needs non-sensitive values that fit a declared schema, a form can keep the exchange inside the MCP client. If the interaction belongs to another origin, identity system, or regulated surface, a URL can move it there without giving the server a fake browser. If the request emerges during a long-running task, task input can preserve continuity without pretending the work completed.
This makes MCP elicitation reviewable before any interface exists. A second explicit MCP elicitation policy can reject requests whose ownership, lifetime, or proof is still undefined.
The governing rule is simple: choose the narrowest mode that can collect the input without crossing an unnecessary trust boundary. The MCP authorization metadata guide is the adjacent layer: authorization says what a caller may do, while elicitation says when and how the person participates.
| Mode | Owner | Proof |
|---|---|---|
| Form | MCP client exchange | Accepted typed result |
| URL | External origin | Authenticated status |
| Task input | Durable task | Valid resume transition |
Reading rule: text, order, values, shapes, and line styles carry the conclusion; color is supplementary.
Use form mode for small typed decisions
MCP form elicitation works best when the answer is compact, non-sensitive, and meaningfully constrained by a flat schema. Think of choosing a deployment region, approving a bounded budget, or supplying a label. The client can render familiar controls, validate types, and return a structured result whose meaning does not depend on parsing prose.
The schema is a user-interface contract, not a place to smuggle arbitrary application state. Give each field a precise title and description. Prefer enumerations when the options are genuinely closed, numeric minimums and maximums when the server can justify them, and optional fields only when omission has a defined meaning. Keep the form short enough that the person can review the full request before accepting it.
Never request passwords, access tokens, recovery codes, private keys, payment details, or other secrets through a form. The protocol's elicitation specification makes the client responsible for user interaction and explicitly separates form and URL modes. A compliant shape does not make a sensitive request appropriate; product policy still has to reject it.
Use URL mode when another origin owns the ceremony
MCP URL elicitation is the right fit when the decisive interaction must happen on a trusted external origin. OAuth consent, payment authorization, enterprise approval, identity proofing, and account recovery all have established web ceremonies that should not be reconstructed inside a server-authored form. The user needs to see the destination, understand the handoff, and return deliberately.
Treat the URL as an invitation, not proof that the action succeeded. The server should create a short-lived, single-purpose session and give it an opaque correlation identifier. The client presents the destination and clearly labels the external handoff. Completion must be confirmed through an authenticated server-side signal or a later status check, never merely because a tab opened or the user came back.
Bind the session to the initiating principal, tool call, requested operation, expiration, and allowed return state. Reject reuse and mismatched subjects. This resembles the separation in permission budgets for AI agents: the agent may propose a consequential step, but a scoped human ceremony authorizes only the named action.
Use task input for resumable work
An InputRequiredResult belongs to a task lifecycle. Use it when work has already started, the server has durable task state, and progress cannot continue until a person resolves a specific question. The important capability is not another rendering style; it is pausing without losing the task's identity, completed steps, or audit trail.
Return a stable task identifier, a human-readable reason, the accepted input shape, and the state that will remain valid while waiting. The client can surface that request where long-running work already lives. When input arrives, the server resumes from a recorded checkpoint rather than replaying side effects. Cancellation and expiration need explicit states so a forgotten request does not wait forever.
Task input is a poor substitute for a single synchronous choice. It adds persistence, idempotency, status transitions, and retry semantics. Use it only when those costs purchase genuine continuity. If the interaction is a two-field decision the client can answer now, a form is clearer. If another origin owns the ceremony, use a URL and let the task wait on verified completion.
- If another origin owns a sensitive ceremony, choose URL.
- If durable work must pause and resume, choose task input.
- If the data is small, typed, and non-sensitive, choose form.
- For every mode, define decline, cancellation, expiry, and completion proof.
Reading rule: text, order, values, shapes, and line styles carry the conclusion; color is supplementary.
Compare modes with a five-question decision table
Before implementing MCP elicitation, write five answers: who owns the data, whether it is sensitive, where validation can be authoritative, whether the operation is already asynchronous, and what proves completion. Those answers usually eliminate two modes quickly.
| Question | Form | URL | Task input |
|---|---|---|---|
| Data owner | MCP client/server exchange | External origin | Task plus chosen input channel |
| Best for | Small typed values | Sensitive or specialized ceremony | Paused durable workflow |
| Completion proof | Accepted structured response | Authenticated external status | Valid transition on task |
| Main risk | Overbroad schema | Phishing or false completion | Duplicate resume or stale state |
| Essential bound | Field and value limits | TTL and single use | Idempotent checkpoint |
Notice that the table does not say one mode is more modern. It names ownership and evidence. That discipline also clarifies the difference between a prompt response and a durable record, much as MCP resources and tool results separate reference material from the outcome of an action.
Design decline, cancel, expiry, and retry first
The happy path is the smallest part of trustworthy MCP user input. A person can accept, decline, dismiss, time out, lose connectivity, finish the external ceremony after expiry, or answer after the task was cancelled. Model these outcomes before polishing labels. If every non-accept state becomes a generic error, agents will retry unpredictably and users will see pressure instead of control.
Give decline a terminal, non-error meaning: the user chose not to provide the requested input. Give cancel a distinct meaning when the surrounding operation should stop. Expiry should carry a safe route to generate a fresh request, not silently revive the old one. A retry must create or select an idempotency key so repeated clicks cannot duplicate a payment, deployment, or message.
The TypeScript SDK elicitation documentation shows the request and result surfaces, including accept, decline, and cancel outcomes. Build your state machine around those outcomes rather than collapsing them into truthy and falsy values. The UI copy can then explain exactly what will happen next.
- Declined: a legitimate terminal choice, not an exception.
- Cancelled: stop the surrounding operation.
- Expired: create a fresh bounded request.
- Accepted: consume exactly once, then record completion.
Reading rule: text, order, values, shapes, and line styles carry the conclusion; color is supplementary.
Log consent without storing the answer
An audit record should prove that MCP elicitation occurred without becoming a second database of sensitive values. Store the request type, server and client identifiers, schema or policy version, initiating tool and task, timestamps, final action, and a digest of the canonical non-secret payload when that digest is useful. Redact field values by default and prohibit secret fields upstream.
For URL mode, record the destination origin and opaque session identifier, not query parameters that may contain bearer material. For task input, record the state transition and checkpoint version. For a form, keep field names and validation outcomes while minimizing values. Operators should be able to answer “what was requested, under which policy, and what did the person choose?” without reading the person's data.
This pairs naturally with an AI agent activity log. The agent log connects intent to a tool call; the elicitation receipt connects that call to a bounded human decision. Together they create a chain of custody without claiming that consent makes the underlying operation correct.
Ship a mode policy, not three ad hoc dialogs
Production MCP elicitation needs one policy surface shared by servers and clients. Define allowed modes per operation, prohibited data classes, maximum field counts and string lengths, URL-origin allowlists or warning rules, task TTLs, resume idempotency, and the receipt fields required for every outcome. Version that policy and include the version in each request.
Then test decisions as data. A deployment region request should select form; an identity check should select URL; a paused research task awaiting source approval should select task input. Add negative fixtures for a password field, an untrusted URL origin, an expired task, a replayed resume token, and a malformed schema. Each fixture should fail with a named reason instead of a generic exception.
The MCP project's first-anniversary review places elicitation beside authorization and tasks in a protocol that is becoming more capable. Capability increases the importance of boundaries. A good implementation makes the person's agency visible, preserves evidence, and gives every request a safe way to end.
Runnable local artifact — The workbench applies an authored policy matrix to local inputs; it does not contact an MCP client or server, grant consent, follow external URLs, or prove protocol conformance.
Choose sensitivity, data owner, duration, and completion proof; inspect the recommended mode and rejection reasons; run negative fixtures; export JSON or CSV.