Elicitation lets an MCP server ask the user for information partway through a request instead of failing. Per the elicitation spec (2026-07-28), the server returns an input-required result containing an `elicitation/create` request; the client shows it to the user, and then retries the original request with the answers in `inputResponses`. There are two modes: **form mode** for structured data collected through the client, and **URL mode**, which sends the user to an external URL for sensitive interactions that must not pass through the client.
Form mode vs URL mode
All rows follow the elicitation spec, 2026-07-28.
| Form mode | URL mode | |
|---|---|---|
| What it collects | Structured data, optionally described by a JSON schema | An interaction on an external URL |
| Schema limits | Flat objects with primitive properties only | n/a |
| Secrets (passwords, API keys, access tokens, payment credentials) | MUST NOT be used | MUST be used for this kind of information |
| What "accept" means | The user submitted the data | The user consented to open the URL, not that the interaction is complete |
| Version note | none | The spec notes it was introduced in 2025-11-25 and may change in future revisions |
One more rule from the spec: servers MUST NOT rely on URL mode elicitation to authorize users for themselves. That is separate from MCP authorization.
The request flow
- The client calls a tool; the server needs a value it doesn't have.
- The server returns an input-required result with an `elicitation/create` request (tools spec, Input Required Tool Results).
- The client shows the request, including which server is asking, and collects an action: `accept`, `decline` or `cancel`.
- The client retries the original request with `inputResponses`. The JSON-RPC `id` MUST differ on the retry.
Rules for clients and servers
From the elicitation spec, 2026-07-28:
- Clients that declare elicitation MUST support at least one mode, and servers MUST NOT send modes the client doesn't support.
- Clients MUST show which server is asking, offer clear decline and cancel options, let users review form answers, and show the target domain for URL mode.
- Servers SHOULD NOT assume success and MUST handle decline, cancel or client failure.
Client support
Cursor's MCP docs list Elicitation as "Supported." Claude Code's MCP docs say it "displays an interactive dialog and passes your response back to the server. No configuration is required." Neither doc says which elicitation modes it supports, so check the client's declared capabilities before sending URL mode.
Pitfalls
- Asking for an API key through form mode. The spec forbids it; use URL mode.
- Treating URL-mode accept as done. It's consent to open the URL, not completion.
- Assuming the user said yes. Handle `decline`, `cancel` and client failure on every elicitation.
- Nested form schemas. Form mode is limited to flat objects with primitive fields.
- Reusing the JSON-RPC id on retry. The spec says it MUST differ.
How to check it
Trigger the elicitation path in Cursor or Claude Code, then decline it and cancel it, and confirm your server handles both without assuming success. Check that no form schema asks for a secret.
Where the kit fits
The MCP Starter Kit ($27) is built for teams putting OAuth-protected remote MCP servers in front of Cursor and Claude Connect. Soft path: start at /free; Cheat Sheet for the skim checklist mindset; kit when you want the auth-ready layout.
Soft next step
Find the tools that currently fail on a missing user choice, decide whether each needs form mode or URL mode, and add decline and cancel handling. Soft ladder: /free, then the MCP Starter Kit ($27). Related: OAuth pillar, MCP server scopes, MCP tool annotations.