What Can an MCP Tool Ask You For Mid-Task, and What Can't It?

What elicitation actually is

Elicitation is a message type inside the Model Context Protocol. It lets a server-side tool pause in the middle of a task and ask the person using it for more information, instead of guessing, failing, or silently proceeding with incomplete data.

The specification supports two distinct modes. Form mode lets a server request structured data from the user through a JSON Schema the client renders as a form. URL mode sends the user to an external URL for interactions that must never pass through the MCP client at all.

Every elicitation response resolves to one of three actions: the user accepted and provided data, declined, or cancelled the whole exchange. A tool that can't handle a decline or a cancel gracefully is not implementing the pattern correctly.

Sources: Elicitation - Model Context Protocol.

What a tool must not ask for through a form

The line between the two modes is not stylistic. It's a security boundary written into the spec. The official documentation is explicit that servers must not request certain categories of information through the in-band form.

The specification states that "Servers MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials." Those must go through URL mode instead, where the exchange happens outside the client entirely.

The definition of sensitive here is narrow but firm: "secrets and credentials that grant access or authorize transactions." General contact details like a name or email aren't automatically banned from a form — the server can ask, but the user still has to be able to review and decline.

If you see a connected tool's form asking for a password, an API key, or a card number, that's not a quirky UI choice. It's a spec violation, and it's a signal to stop and check what else that tool might be doing wrong.

Sources: Elicitation - Model Context Protocol, One Year of MCP: November 2025 Spec Release.

A worked example: booking a meeting room (illustrative)

Say a scheduling bot uses a meeting-room tool over MCP. The bot asks it to book a room for 2pm. The tool doesn't know your seating preference or whether you need a projector, so it sends a form-mode elicitation: 'Which room feature matters most — projector, whiteboard, or capacity?' You pick one, the client lets you review the choice before sending, and the tool books accordingly. That's a normal, bounded use of form mode.

Now say the same tool needs to check room availability against your company's calendar provider, and that provider requires you to log in and grant access. Under the 2025-11-25 spec, that exchange cannot happen as a form. The server can use URL mode to offer a link that starts an external authorization flow. After you inspect the full URL and consent to open it, you complete the provider login outside the MCP client. The client does not receive your password or the resulting third-party tokens; the server manages any tokens it obtains.

This second case is illustrative, not a report of a real deployment, but it maps directly onto why the spec splits the two modes: one is for filling in gaps in a task, the other is for anything where a credential or a payment changes hands.

What to check before you trust a tool's elicitation requests

Before you connect a bot to a tool that uses elicitation, there are a handful of concrete things worth checking rather than assuming compliance.

First, whether your client declares support for elicitation during initialization. In the 2025-11-25 protocol, the client declares the form and URL modes it supports, and the server must not send a mode the client did not declare. A newer draft uses per-request capability metadata instead, so check the protocol version your client and server actually use.

Second, whether URL-mode requests are handled the way the spec demands: the client must show you the full URL before you consent, must not fetch it automatically, and must open it in a way that keeps the page's content and your input away from the client and the model.

• For 2025-11-25, client declares the form and URL modes it supports during initialization
• Every request gives you a visible way to decline or cancel, not just accept
• Form-mode requests never ask for passwords, API keys, tokens, or payment details
• URL-mode requests show you the full target URL and wait for your consent before opening it
• The URL opens in a secure context that keeps page content and input away from the client and model

Sources: Elicitation - Model Context Protocol, Elicitation - Draft Specification.

Why this matters for how you scope tool access

Elicitation changes what "connecting a tool" means. A tool that only ever answers a call and returns a result is easy to reason about: you know its inputs and outputs ahead of time. A tool that can pause and ask you something mid-task introduces a second channel you have to trust — and the mode it uses tells you how much trust that channel actually requires.

If you're auditing which tools a bot can reach, review form-mode requests for the data they collect and treat URL-mode requests as sensitive interactions that deserve scrutiny before you open the link. A permission review should show which modes a tool can use and which server is asking, before a bot is allowed to run it unattended. BotBento is still in development.