Understanding Elicitation
When a tool needs user input, it sends an elicitation request to the client. The client handles presenting this request to the user and returning their response. This enables:- Interactive workflows: Tools can ask for input mid-execution
- Secure credentials: Request sensitive data without storing it
- Dynamic decisions: Get user approval for actions
- OAuth flows: Redirect users for authentication
Two Modes Available: Form mode for structured data collection, and URL
mode for directing users to external authentication or approval pages.
Elicitation Modes
Form Mode
Collect structured data with JSON schema validation. Best for:- Non-sensitive information
- Structured input requirements
- Client-side form rendering
URL Mode
Direct users to external URLs. Required for:- Sensitive credentials (passwords, API keys)
- OAuth authentication flows
- External approval processes
- Third-party integrations
Server API: Servers use a simplified API like
ctx.elicit(message, zodSchema) or ctx.elicit(message, url). The mode is automatically detected and the request is sent to the client with the appropriate JSON schema or URL.Server-Side Validation with mcp-use: When using the mcp-use server library with Zod schemas (simplified API), returned data is automatically validated server-side before reaching your tool logic. This is a convenience feature provided by mcp-use, ensuring type safety and data integrity.Configuration
With MCPClient
Provide anonElicitation function when initializing the MCPClient. The elicitationCallback name is still supported but deprecated; use onElicitation.
With React Hook
Use theonElicitation prop in the useMcp hook:
Client helpers
mcp-use provides helpers so you don’t have to hand-roll defaults, validation, or result building. Import them (and types) frommcp-use or mcp-use/client. For a typed callback without importing the SDK, use OnElicitationCallback from mcp-use.
- Defaults:
getDefaults(params)— default values from the request schema;applyDefaults(params, partial?)— merge partial content with defaults;acceptWithDefaults(params)— return an accept result using schema defaults. - Result builders:
accept(content),decline(reason?),cancel(),reject(reason?)(reject is an alias for decline). - Validation:
validate(params, content)returns{ valid: boolean; errors?: string[] }(Zod-based; usesrequestedSchema). Types:ElicitContent,ElicitValidationResult.
acceptWithDefaults:
Form Mode Elicitation
Form mode collects structured data from users with JSON schema validation.Validation Flow: The client receives a JSON Schema to guide user input.
When data is returned, the server validates it against the original Zod schema
(if using simplified API) or JSON Schema (if using verbose API). This provides
defense-in-depth validation.
Request Parameters
| Field | Type | Description |
|---|---|---|
| mode | "form" (optional) | Specifies form mode (can be omitted for backwards compatibility) |
| message | string | Human-readable prompt explaining what information is needed |
| requestedSchema | object | JSON Schema defining the expected response structure |
Client-Side vs Server-Side Validation
Client-Side (Optional):- You can validate data before sending to improve UX
- Shows errors immediately without round-trip
- Not required - server validates anyway
- Server always validates returned data
- Ensures data integrity regardless of client behavior
- Protects against malicious or buggy clients
- Returns clear validation error messages
Client-Side Validation (Optional but Recommended)
While the server always validates data, implementing client-side validation improves UX by catching errors before the round-trip. You can use the built-invalidate(params, content) helper from mcp-use (Zod-based); no need to implement validateAgainstSchema yourself unless you need custom logic.
Best Practice: Implement client-side validation for better UX, but
remember that the server always validates as the final authority. Never rely
solely on client-side validation.
Handling SEP-1330 Enum Schema Variants
For form-mode elicitation, clients should support these enum schema shapes:| Variant | Schema Shape | Recommended UI |
|---|---|---|
| Untitled single-select | type: "string" + enum | Single-select dropdown |
| Titled single-select | type: "string" + oneOf[{ const, title }] | Single-select dropdown with labels from title |
| Legacy titled enum | type: "string" + enum + enumNames | Single-select dropdown using enumNames as labels |
| Untitled multi-select | type: "array" + items.enum | Multi-select checkbox group |
| Titled multi-select | type: "array" + items.anyOf[{ const, title }] | Multi-select checkbox group with labels from title |
- Single-select fields should return a string.
- Multi-select fields should return an array of strings.
- Use the
const/enumvalues as submitted data, even when displaying a different label.
URL Mode Elicitation
URL mode directs users to external URLs for sensitive operations. This mode MUST be used for:- Authentication credentials
- API keys and tokens
- OAuth authorization flows
- Payment information
- Any sensitive personal data
Request Parameters
| Field | Type | Description |
|---|---|---|
| mode | "url" | Specifies URL mode (required) |
| message | string | Human-readable explanation of why the user needs to visit the URL |
| url | string | The URL to direct the user to |
| elicitationId | string | Unique identifier for tracking this elicitation (auto-generated by server) |
Example: OAuth Authorization
Response Structure
The elicitation callback must return anElicitResult object:
ElicitContent is Record<string, string | number | boolean | string[]>.
Response Actions
| Action | When to Use | Field |
|---|---|---|
| accept | User provided valid input | content required for form mode when accepting |
| decline | User explicitly declined to provide information | Omit |
| cancel | User dismissed the request without making a choice | Omit |
Error Handling
If noonElicitation handler is provided but a tool requests user input, the tool call will fail:
Next Steps
- Learn how to create tools with elicitation on the server side
- See the example server for working implementations
- Explore sampling for LLM completions
- Check out notifications for server-to-client messages