In MCP elicitation, what do the accept, decline and cancel actions mean?
answer
- Three outcomes, only one carries data
- Submitted, refused, dismissed
- One is a decision, one is an absence of one
- Re-asking is fine after only one of them
- Anything unclear is never consent
basics
~20 sAn MCP elicitation result carries one of three actions. Accept means the user filled the form in and the values are attached. Decline means they explicitly refused. Cancel means they dismissed it without deciding. Only accept carries data.
solid answer
~50 sThe result of an `elicitation/create` ask reports one of three actions, and a server must handle all three distinctly. `accept` means the user explicitly submitted the form, and the collected values are attached — this is the only action that carries data. `decline` means the user made a deliberate negative choice: they saw what was asked and said no. `cancel` means they dismissed the dialog without answering — closed the window, hit escape, navigated away. The distinction that matters in practice is decline versus cancel: a decline is a decision you should respect and probably record, so re-asking is user-hostile; a cancel is an absence of a decision, so retrying later or asking differently can be reasonable. Never treat a missing action or an empty answer as consent, and never read the collected values on anything but `accept`.
go deeper
Memorise the three names and what each means: accept submitted with values, decline refused, cancel dismissed. Say plainly that only accept carries data.
Explain why decline and cancel are kept apart — one is a decision to respect, the other an absence of a decision — and that both end the operation without the value the server wanted.
Demonstrate the operational angle: report a decline as a normal tool result rather than an error, separate the two in telemetry, and never re-prompt after an explicit refusal.
Own the consent invariant across your server fleet: only an explicit accept authorises the action, ambiguity always fails closed, and prompt fatigue is treated as a product defect rather than a user problem.
## The three outcomes When an MCP server raises an `elicitation/create` ask, the client shows it to the user and reports back what happened. There are exactly three possible actions. **`accept`** — the user actively submitted the form. The values they supplied come back with the result, and this is the only action under which any data is present. A server reading fields on any other action has a bug. **`decline`** — the user made an explicit negative decision. They read the ask and chose "no", "deny", "reject". This is a real answer; it just is not the answer the server wanted. **`cancel`** — the user dismissed the interaction without deciding either way. They closed the dialog, pressed escape, switched to another window, or the client itself tore the prompt down. Nothing was decided. ## Why decline and cancel are separate Collapsing them is the mistake this question is designed to catch. They carry different information about the user's intent, and correct behaviour differs. A **decline** is a signal about the request itself. The user understood it and said no. The right server behaviour is to abandon that branch and say so in its final result — "the deploy was not confirmed" — and not to ask the same thing again on the next call. Re-prompting after a decline is how software earns the reputation of nagging, and in a consent context it is worse than annoying: it trains users to click through prompts. A **cancel** is a signal about the interaction. The user may have been distracted, may have been in a client that closed the panel, may not have understood the ask. There is no negative decision to respect. It can be legitimate to raise the ask again later, phrase it differently, or offer the operation through a path that needs no input. Both are, however, terminal for the request in flight. Neither gives the server the value it wanted, so the operation the server was performing cannot proceed on the assumption it was answered. ## Never treat silence as yes The hard rule underneath all three: only `accept` is consent. Not an absent action, not an empty set of values, not a timeout, not a client that answers with something the server does not recognise. Elicitation is frequently used exactly where consent matters — confirming a destructive action, choosing what data to expose — and a server that defaults to "proceed" when the answer is unclear has converted a consent prompt into a rubber stamp. The same applies one layer up. In revision 2026-07-28 an elicitation reaches the client inside the interim result of a `tools/call`, `prompts/get` or `resources/read`, and the client answers by re-issuing that request with the answer attached. A client that simply never comes back has told the server nothing at all; that is not a decline, not a cancel, and certainly not an accept. The server's request is simply over. ## What the server should do with each - **accept** — validate the returned values against the schema you asked with. The client may have validated them too, but it is a separate program you do not control; check types, ranges and enum membership yourself before the values touch a query, a path or a subprocess. Then resume the work. - **decline** — stop. Return a clear, non-error result explaining that the operation was not performed because the user declined. This is usually a normal outcome rather than a failure: the tool worked exactly as designed. - **cancel** — stop, and say the interaction was dismissed. Distinguish it in your own logs and metrics from a decline; a high cancel rate on one prompt is a usability signal that the ask is confusing or badly timed, whereas a high decline rate says users understand it and do not want it. ## Reporting it back A declined or cancelled elicitation is not a protocol error, and a server should not surface it as a JSON-RPC error. For a tool, the natural expression is an ordinary result whose content states plainly that the action did not happen and why — the model reading that result needs to understand that nothing was done, so it does not narrate a success to the user or immediately retry the same call. ## Version note The three actions have been part of elicitation since it was introduced and are unchanged in revision 2026-07-28. What changed in that revision is only how the ask and the answer travel: elicitation is no longer a server-initiated request but an interim result the client answers on retry.
- Should a declined elicitation come back to the model as a JSON-RPC error?No. Nothing failed at the protocol level — the tool behaved exactly as designed and the user said no. Return an ordinary tool result whose content states plainly that the operation was not performed because the user declined. That way the model reports the truth to the user instead of narrating a success or immediately retrying the same call.
- Your metrics show one elicitation is cancelled far more often than it is declined. What does that tell you?Cancels are dismissals without a decision, so a high cancel rate points at the ask rather than at the operation: unclear wording, bad timing, too many fields, or a prompt that appears when the user has no context for it. A high decline rate is the opposite signal — people understand it fine and genuinely do not want the action.
- On accept, can the server trust that the returned values match the schema it requested?No. A well-behaved client validates before returning, but it is a separate program — another vendor's implementation, an older build, or something written to probe your server. Re-validate types, ranges and enum membership server-side before the values reach a database query, a filesystem path or a subprocess.
saying these in an interview costs you the question
- Treats decline and cancel as the same outcome
- Reads submitted values on a cancel result
- Re-prompts immediately after a user declines
- Defaults to proceeding when the answer is unclear
- Returns a JSON-RPC error because the user said no