- wire spec: lifecycle, stdio + Streamable HTTP transports, tools, utilities, legacy SSE, versioning, changelog (14 Tier 1) - client ecosystem: Claude Code/VS Code/Cursor/Codex configs, mcp-remote, Smithery, registries, Glama (12 Tier 1) - security/ops: authorization draft, trust model, poisoning, rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards - conclusions: minimal stdlib client on 2025-11-25, normalizer + resolver agent for pasted configs/GitHub URLs, untrusted-until- consent trust model; nothing built yet - audit PASS (14 subjects, 797 sources, 32 conclusions)
3.5 KiB
Elicitation (client feature, 2025-11-25)
Metadata
| Field | Value |
|---|---|
| Institute | Molodetz Institute - Research & Retrieval Division |
| Subject | mcp-client-support |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | Elicitation (MCP Specification v2025-11-25) |
| Source URL | https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation |
| Source publisher / author | Model Context Protocol authors (Anthropic-donated open project; site docs) |
| Source type | standard |
| Source date (published) | 2025-11-25 (version stamp; no other publish date stated) |
| Date researched | 2026-10-18 |
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
| Research method | gather-subagent direct page fetch, parent synthesis from evidence pack |
| Confidence | High (partial read: 30KB page, head section only, see Cons) |
| Status | Active |
Summary
Elicitation has two modes: form mode for servers requesting structured data, and URL mode for directing users to external URLs for sensitive interactions that must not pass through the client. Clients declare the elicitation capability with form/url sub-capabilities ({} alone means form only; at least one mode is required), and servers must not send requests in unsupported modes. Every elicitation/create must include a human-readable message, mode defaults to form, and form mode must never request sensitive credentials.
Key findings
- Two modes: "Form mode: Servers can request structured data… URL mode: Servers can direct users to external URLs for sensitive interactions that must not pass through the MCP client."
- "Clients that support elicitation MUST declare the
elicitationcapability" ({"form":{},"url":{}});{}alone "is equivalent to declaring support forformmode only"; clients "MUST support at least one mode." - "Servers MUST NOT send elicitation requests with modes that are not supported by the client."
- Every
elicitation/create"MUST include…message" (human-readable reason);modedefaults to"form"if omitted. - "Servers MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials."
Pros / strengths
- The form/URL split is a sound security design: sensitive interactions are routed to external URLs that bypass the client entirely, instead of flowing credentials through it.
- Capability granularity (
form/urlsub-capabilities with a form-only default for{}) lets clients offer exactly the modes they can render. - Mandatory human-readable
messageplus the ban on credential solicitation in form mode give users context and a bright-line server rule.
Cons / limitations / caveats
- The pack marks this page partially read (30KB page, head section only); the full elicitation response schema and deeper subsections were not read, so findings cover the retrieved sections only.
- No explicit author names or publish dates appear on the page; the date above is the version stamp in the URL.
- Needs a user interface (form rendering or URL handoff), which a headless minimal client has no use for; omission is the correct default.
Relevance to tai
Optional user-interaction feature; a minimal client omits it (the formal form/url sub-capabilities matter only if elicitation is offered at all). Relevant to tai only if a future interactive client wants structured user input mid-tool-call.
Changelog
| Date | Change |
|---|---|
| 2026-10-18 | Initial dossier created. |