MCP Fundamentals
MCP Elicitation: User Input, Consent and Safe Resumption
By MCP Beast·
MCP elicitation lets a server ask for user input through the client while processing an operation. Use it when the next step requires information or a user decision that the agent should not invent. The important implementation question is not merely how to display a form; it is how to continue safely when the user accepts, declines, cancels, or never responds.
This guide targets MCP revision 2026-07-28. It follows a fictional report-export workflow through a user choice and a separate external connection step. The acceptance cases are proposed tests for your implementation, not claims about universal client or gateway support.
Choose form or URL mode deliberately
The current elicitation specification defines form mode for structured input and URL mode for an external interaction. Form mode must not request passwords, API keys, access tokens or payment credentials. Check the client's advertised mode support before requesting either interaction.
For the export workflow, the server needs to know whether to prepare a summary or a detailed report. That is a non-secret choice suitable for a small form. If connecting an external account is necessary, keep that credential interaction outside the form and model context. See MCP authentication and OAuth for the separate boundary between authorizing the MCP connection and granting downstream access.
| Workflow requirement | Proposed interaction | What to establish before proceeding |
|---|---|---|
| Choose summary or detailed report | Form with bounded choices | Returned choice is valid for this report |
| Supply a report label | Form with length guidance | Label is treated as data, not executable input |
| Connect an external account | Supported URL interaction | Server verifies the required account connection |
| Dismiss the question | Cancel path | Work remains incomplete and no export is sent |
| Refuse the requested step | Decline path | No implied consent or automatic escalation |
Keep the question specific. “Continue?” gives the user little evidence about what comes next. “Choose the detail level for a report that will be prepared as a draft” explains both the requested input and the immediate effect. If a later action sends that report, make that consequence visible at the appropriate decision point.
Follow the current request-and-resume model
In 2026-07-28, multi round-trip requests replace the previous server-initiated request pattern. The server can return an InputRequiredResult during a supported operation. The client collects the requested input and retries the original operation with inputResponses, echoing any supplied requestState unchanged and using a new JSON-RPC request ID.
Treat requestState as opaque on the client. The server must validate state that influences authorization or business behavior. The specification discusses integrity protection and binding to the principal, originating request and expiry; a signed payload alone does not guarantee single use.
A conceptual sequence for the export workflow is:
1. Client requests a report draft.
2. Server needs a detail-level choice and returns input_required.
3. Client presents the question with the requesting server's identity.
4. User submits a choice, declines, or dismisses it.
5. Client resumes the original operation with the corresponding response.
6. Server validates the resumed request and reports its actual outcome.
This is a workflow sketch, not a complete JSON-RPC exchange. A real request needs the metadata and transport details required by the selected protocol revision. Do not copy an older example that holds a server-to-client request open and assume it describes the current wire pattern.
Design the state transition before the dialog
For the fictional export, distinguish “waiting for choice,” “draft prepared,” and “sent.” This table proposes application transitions, not an MCP state machine or a guarantee of exactly-once execution. Each transition depends on server-side verification, regardless of how the client renders the question.
| Prior application state | Verified event | Allowed next state | Action forbidden until verified |
|---|---|---|---|
| Waiting for report choice | Accepted form has a valid choice, bound to this principal, unchanged action and unexpired operation | Ready to prepare the requested draft | Sending the draft still needs its separate authorization; form acceptance alone cannot send it |
| Waiting for report choice | User declined the bound question | Declined; stop this requested continuation | No guessed choice, automatic escalation or repeated prompting as implied consent |
| Waiting for report choice | User cancelled the bound question | Cancelled/incomplete; report any earlier work accurately | No continuation based on dismissal; a restart needs fresh valid input |
| Waiting with expired operation state | Server verifies expiry on resume | Expired; reject old input and offer a deliberate fresh request | No draft preparation or send using expired consent |
| Waiting while the original action changes | Report period, account or dataset no longer matches the pending decision | Previous choice invalidated; ask for input bound to the changed request | No application of the old acceptance to the new action |
| Waiting for external connection | URL interaction accepted/opened, but the intended account connection is not verified complete | Remain incomplete with a recoverable status | No connection-dependent export or success claim until the server verifies completion and current authorization |
| Draft operation already completed | Repeated resume is correlated with the recorded completed operation | Return its permitted recorded status/result, or reject the stale resume | No new execution merely because the response was replayed; a separate operation needs a new decision |
“Ready to prepare” is not “draft prepared,” and neither is “sent.” Record the actual execution outcome after the transition. If earlier effects cannot be established, keep that uncertainty explicit rather than treating replay protection as proof that an operation happened exactly once.
Likewise, consider two open requests from the same user. A response to report A must not satisfy report B's pending question. Use an operation-specific association and verify it during resumption. Keep the relevant identifiers in restricted operational records so an investigator can explain the relationship without retaining unnecessary form content.
For consequential operations, OWASP's transaction-authorization guidance recommends binding authorization to the transaction and controlling execution order. Applied here, the final server-side decision should reflect the action being executed, not just the existence of an earlier interaction. The agent-governance guide provides a broader ownership and approval register.
Handle URL interactions without assuming completion
In URL mode, accept records consent to the interaction; it does not prove the external step completed. The server determines completion when processing the resumed operation. The elicitation specification also requires clear URL presentation and explicit navigation consent, forbids automatic prefetching, and prohibits sensitive or pre-authenticated URLs in the request.
For the report example, test the difference between opening an account-connection page and actually connecting the intended account. A user may close the page, select a different account, or finish after the original request expires. Show a useful status and a deliberate recovery path instead of returning an apparent report success before the connection is usable.
Avoid putting a live token, account credential or personal record into a link merely because the link will be opened in a browser. Keep the credential boundary explicit: the agent-facing interaction should convey what the user needs to do, while the sensitive exchange occurs through the appropriate authenticated external flow.
Make cancellation a normal outcome
A closed dialog is not an affirmative answer. A timeout is not permission to use a guessed default for a consequential action. Decide how the surrounding application reports incomplete work and whether the user can restart it without duplicating previous effects.
For a read-only draft operation, a useful cancellation message might say that no draft was prepared because the required choice was not supplied. For an operation with earlier partial work, report that boundary accurately. Do not say “nothing happened” unless the implementation can establish that no prior step changed anything.
Also bound repeated prompting. A malformed response may justify a corrected question, but a refusal should not produce an immediate loop of increasingly insistent dialogs. Give the user a clear way to end the workflow. Record the outcome category separately from a server fault so operational metrics do not treat every declined request as a broken integration.
Test the whole path through the intended host
Run the following proposed cases in a controlled environment with synthetic records. Capture what the user sees and what the server actually does; a successful handler unit test cannot establish the client's presentation or cancellation behavior.
| Case | Evidence to inspect |
|---|---|
| Supported form, valid selection | Correct question, correct operation association, valid resumed result |
| Client lacks required mode | Clear unsupported path without a misleading success |
| Decline and cancel | Distinct outcomes and no unauthorized continuation |
| Expired or modified state | Rejection or safe restart tied to the original action |
| Parallel pending operations | No cross-association between responses |
| URL opened but unfinished | Pending or recoverable state, never assumed completion |
| Repeated resume after success | No unintended duplicate side effect |
A gateway adds another compatibility boundary. Verify that the actual route preserves the necessary input-required result, user interaction and resumption behavior. Do not infer that from basic tool-call forwarding. Keep the host, server, gateway and protocol versions with your evidence, and use audit records to correlate the attempted operation with its final outcome.
Frequently Asked Questions
What is MCP elicitation?
It is a mechanism for a server to request user input through the client during an operation. The workflow must also handle refusal, dismissal, unsupported capabilities and incomplete work.
Can an elicitation form ask for an API key?
No. Form mode must not request access secrets such as API keys or passwords. Sensitive interactions require the supported external URL flow and appropriate credential handling.
Does accepting a URL request mean authentication finished?
No. It indicates consent to the interaction. The server must determine whether the external step completed before treating the resumed operation as ready to finish.
How does current elicitation differ from older examples?
The 2026-07-28 revision uses input-required results and a retried original request with the user's response. Older server-initiated request examples describe a different protocol lifecycle and need a compatibility review.
Before enabling an interactive workflow, demonstrate its cancel path and a stale-response case in the intended client. Those two exercises often reveal assumptions that a successful form submission leaves hidden.