MCP Elicitation: When Should an Agent Ask the User Back?

When an agent lacks a critical fact, guessing and re-calling tools often means wrong arguments, duplicate side effects, and eroded trust. MCP elicitation is the pattern where a server sends elicitation/create to the client to request user input formally. It only works when the client declared the elicitation capability. Product UI labels differ; the behavior (message, schema, response actions) is what the spec fixes.

This post covers three axes: tool failure vs ask-back · minimal question design · timeout and cancel. No pricing, plans, or affiliates.

Grounding: the Model Context Protocol elicitation spec (form/URL modes, message + requestedSchema, response action: accept / decline / cancel). No invented product menu paths—behavior only.

Tool failure vs asking the user back?

One-line answer: A tool failure is a tools/call that ended in an error or incomplete result. Elicitation is a separate server→client request for structured user input during processing. Same symptom (“missing info”), different fix: retry/schema vs user confirmation.

	Tool failure (`tools/call`)	Elicitation (`elicitation/create`)
Direction	Result of client→server tool call	Server→client user-input request
Signal	JSON-RPC error or failure content	`message` + (form) `requestedSchema`
User role	Agent may guess and retry	Client UI asks; user responds
Prerequisite	Tool + argument schema	Client declared `elicitation` capability

Ask back when:

You need a choice or confirmation (target branch, delete yes/no, project id) that is not in context.
The value is not secret but unsafe to invent (display name, contact email)—form mode.
The value is a password, API key, or payment credential—spec says URL mode, not form (must not transit the client/LLM).

Prefer tool failure / redesign when:

Required args exist on the tool inputSchema but the agent left them empty → fix schema/docs or agent rules before call.
Network, auth, or server faults → error handling and retry policy, not elicitation.
The client did not declare elicitation → the server must not send unsupported modes.

Conceptual form request:

{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Choose the deploy environment.",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "env": {
          "type": "string",
          "title": "Environment",
          "enum": ["staging", "production"]
        }
      },
      "required": ["env"]
    }
  }
}

One short ask plus accept.content beats two guessed deploy calls.

How do you design a minimal question?

One-line answer: Keep one elicitation = a flat object with few required fields. Put “why” in message. Restrict requestedSchema to the primitives the spec allows (string / number / boolean / enum). Nested objects and arrays of objects are intentionally out of scope for form mode.

Checklist:

Minimize required — only keys needed for the next tool step. Drop “maybe later” fields.
One-sentence message — what and why (e.g. “Confirm the storage bucket name; a wrong bucket mixes data.”).
title / description / enum / format — help the client render and validate (email, uri, date, …).
default only when safe — clients that support defaults may prefill; never default to a dangerous path (e.g. production deploy).
No secrets in form mode — passwords, tokens, payment data belong in URL mode so they do not pass through the client or logs.

Avoid:

Dumping a whole profile/settings form into one prompt (abandonment and typos rise).
Huge all-optional schemas that push guessing back onto the agent.
Hiding clickable URLs inside form fields (prefer not to; URL mode owns navigation consent).

Minimal schema example:

{
  "type": "object",
  "properties": {
    "confirm": {
      "type": "boolean",
      "title": "Proceed with delete",
      "description": "This is hard to undo."
    }
  },
  "required": ["confirm"]
}

A boolean or single enum usually beats a free-form essay for replay and automation.

Timeouts and cancel?

One-line answer: Spec responses use three actions: accept / decline / cancel. Explicit refusal → decline; dismiss without choosing (close, Escape, click-away) → typically cancel. There is no separate timeout action name in the spec; implementations often map a timed-out UI to cancel-like handling or a JSON-RPC failure. Regardless of product chrome, servers must assume all three outcomes plus no response.

action	Spec meaning	Sensible server handling
`accept`	User submitted / consented	Continue with form `content`. URL mode: consent only, no content
`decline`	Explicit refusal	Offer alternatives or stop; do not immediately re-spam the same prompt
`cancel`	Dismissed without a choice	Ask later or fall back to a safe path

Ops notes:

No response / timeout — if the UI closes after a deadline, treat it like cancel or failed request. Never treat silence as accept.
URL mode — accept means “OK to open the URL,” not “out-of-band flow finished.” Completion may arrive as optional notifications/elicitation/complete; clients should still expose manual retry/cancel if the notification never comes.
Capability mismatch — sending an undeclared mode yields Invalid params (-32602). Check capabilities at initialize.
State — real elicitations need per-user state bound securely; do not key state on session IDs alone (security guidance).

{
  "result": {
    "action": "cancel"
  }
}

After cancel or timeout, avoid infinite identical message loops. Summarize once in chat (“Environment selection was cancelled. Continue with staging only?”) and move to the next turn.

FAQ

Q. Can I just ask in chat—“which one?”—without elicitation?
A. Yes, but you lose structured validation and clear decline/cancel semantics. A form schema lets the client validate; the server can read stable content keys.

Q. Must requestedSchema mirror the tool inputSchema?
A. No. Tool schemas are the call contract; elicitation should be the minimal subset the user must confirm. Map into tool args after accept.

Q. Product button labels differ—is that OK?
A. Yes. The protocol does not mandate widgets; it defines request/response meaning. Map Submit/Reject/dismiss to accept/decline/cancel.

Takeaway

Missing information is not always a cue to hit tools harder. MCP elicitation sends elicitation/create with a clear message and a minimal schema (form), then branches on accept / decline / cancel (and silence). Keep secrets in URL mode, never treat timeout as accept, and prefer one short confirmation over speculative side effects.