Tool-using agents fail in a very specific way: they often do the next plausible action instead of stopping to ask a human.

In 2026, that is no longer an “agent intelligence” problem. It is a product interface problem.

If your assistant can run tools that touch deployments, billing, permissions, or customer data, you need a reliable way to:

  1. pause the workflow,
  2. ask for explicit user input or approval,
  3. and only then proceed.

That is exactly what Elicitation adds to the Model Context Protocol (MCP): a standardized, client-controlled way for servers to request user input during an interaction instead of faking it with “please confirm” text. See the spec: Elicitation (MCP draft).

If you want the bigger ecosystem context, read: Why MCP Is Becoming the Default Standard for AI Tools in 2026. If you want the “why guardrails matter” argument, read: AI Coding Agents Need Guardrails, Not More Autonomy.

What changed (and why it matters now)

The key detail is that elicitation is new in the MCP spec and is still explicitly described as evolving.

Even within elicitation, MCP calls out a specific version milestone: URL mode is introduced in the 2025-11-25 version of the specification. That is the point where MCP stopped being “just ask for form fields” and added a standard way to redirect users into secure, out-of-band flows.

If you are building tool-using AI today (March 29, 2026), this is one of the cleanest protocol-level signals that the ecosystem is formalizing human approval and sensitive-step UX instead of leaving it to prompting.

What “elicitation” actually is

Elicitation is an MCP feature where an MCP server can ask the MCP client to collect extra user input and send it back in a structured way.

The important detail is control: the client owns the user interaction pattern. The protocol does not dictate UX; it gives a clean message flow and a small set of primitives.

The spec defines two modes:

  • Form mode: the server requests structured data (optionally with a simplified JSON schema for validation).
  • URL mode: the server returns a URL and asks the client to send the user through an out-of-band flow for sensitive interactions that must not pass through the MCP client.

That second one matters. URL mode exists because some “confirmations” are actually auth flows, payment steps, or secret entry, where the safe place to do it is a browser session with real identity checks.

The protocol also standardizes how the user responds:

  • accept: the user approved and (for forms) provided content
  • decline: the user explicitly said no
  • cancel: the user backed out of the flow

That is a small detail that makes agent workflows more reliable: your server can treat these paths differently instead of guessing from freeform text.

Why this matters for builders (not just protocol nerds)

The MCP Elicitation Pattern Diagram

Most teams already try to do “confirmation” with one of these patterns:

  • the model prints “Are you sure?” and hopes the user replies correctly
  • the tool takes a confirm: true flag and the model decides when to flip it
  • the UI pops a modal, but the server has no clean way to resume the flow

Those are all fragile in different ways.

Elicitation is a better default because it:

  • makes the pause explicit (protocol-level, not prompt-level)
  • gives you a structured approval signal (accept/decline/cancel)
  • lets clients enforce UX consistency and safety policies
  • supports secure out-of-band flows via URL mode

In other words: you can design “human-in-the-loop” as a first-class system behavior instead of a prompt convention.

The practical pattern: classify tool calls by risk

If you want to apply this immediately, do not start by “eliciting everything.” Start by splitting tool calls into three buckets:

1) Low risk: no elicitation

Read-only operations that are easy to undo or validate:

  • search docs
  • read repository files
  • run non-destructive queries

2) Medium risk: form-mode elicitation

Actions where the model might have the right idea but you need human intent captured cleanly:

  • “create a new API key named X with scope Y”
  • “open a PR titled … with these files”
  • “send a customer email to …”

Here you can ask for the missing fields and force an explicit “submit” moment.

3) High risk: URL-mode elicitation (or a hard block)

Actions that are dangerous to route through a chat UI at all:

  • OAuth authorization flows
  • entering secrets
  • payments / billing changes
  • permission escalation

URL mode is designed for this class of interaction, and the spec is explicit that the server must verify user identity and guard against phishing-style abuse.

What to do if the client does not support elicitation (yet)

Reality check: not every MCP client will support elicitation on day one.

So design your server to degrade safely:

  • Hard requirement for high-risk operations: if the client cannot do URL mode, return an error and instruct the user to complete the flow elsewhere.
  • Two-phase commits for medium-risk operations: require an explicit intentId or confirmationToken returned by the first step before the second step will execute.
  • Never let the model self-authorize: avoid “if you are sure, set confirm=true” patterns where the model can satisfy its own gate.

This is the same principle we talk about in prompt testing: if the system can act, it needs tests and constraints. See: Prompt Testing Is Becoming Mandatory: A Practical Promptfoo Evals Workflow.

The .NET ecosystem angle (why this is not theoretical)

One reason elicitation matters right now is that SDKs are already forming around MCP.

If you build on .NET, Microsoft maintains documentation for an MCP C# SDK. Even if you are not on C#, it is a useful signal: when ecosystems start publishing SDK docs for MCP clients/servers, teams can implement protocol features like elicitation consistently instead of ad hoc. Start here: MCP C# SDK overview.

That is the adoption signal you should watch: when frameworks bake the human-in-the-loop primitive into their SDK surface area, teams stop treating confirmations as “prompting” and start treating them as engineering.

Final verdict

Agents do not become trustworthy because they get smarter.

They become trustworthy when the system has a clean way to say: stop, ask the human, then continue.

MCP Elicitation is one of the clearest building blocks for that future. If you are building tool-using AI in 2026, treat elicitation as a default guardrail—especially for anything that can delete, deploy, pay, or escalate permissions.

Sources