Elicitation
Interactive information gathering in MCP
Elicitation is a powerful MCP feature that allows servers to request additional information from users during interactions. This enables dynamic workflows where servers can gather necessary data on-demand while maintaining user control and privacy.
Elicitation is newly introduced in the MCP specification revision 2025-06-18.
What is Elicitation?
Elicitation provides a standardized way for MCP servers to request structured information from users through the client. Instead of requiring all information upfront, servers can ask for specific data exactly when needed, creating more natural and flexible interactions.
For example, a server might:
- Request a username when connecting to a service
- Ask for configuration preferences during setup
- Gather project details when creating new resources
How Elicitation Works
The elicitation flow is straightforward:
- Server sends an elicitation request with a message and expected data structure
- Client presents the request to the user with appropriate UI
- User accepts, declines, or cancels the request
- Client validates and returns the response to the server
- Server continues processing with the provided information
Request Structure
Elicitation requests include two key components:
Message
A clear, human-readable explanation of what information is needed and why.
Schema
A JSON Schema that defines the expected structure of the response. The schema is intentionally limited to flat objects with primitive types to simplify client implementation.
Example request:
Supported Data Types
Elicitation supports these primitive types:
Text Input
Numbers
Boolean Choices
Selection Lists
User Response Actions
Users can respond to elicitation requests in three ways:
- Accept: User provides the requested information
- Decline: User explicitly refuses to provide information
- Cancel: User dismisses without making a choice (e.g., closes dialog)
Servers should handle each response appropriately:
- Accept → Process the provided data
- Decline → Offer alternatives or adjust workflow
- Cancel → Consider retrying later or using defaults
Best Practices
When implementing elicitation:
For Servers
- Be Clear: Write descriptive messages explaining why information is needed
- Be Minimal: Only request essential information
- Be Flexible: Have fallbacks for declined or cancelled requests
- Be Timely: Request information when actually needed, not preemptively
- Be Respectful: Never request sensitive information like passwords or tokens
For Clients
- Be Transparent: Clearly show which server is requesting information
- Be Protective: Allow users to review and modify responses
- Be Validating: Check responses against the provided schema
- Be Empowering: Make decline and cancel options prominent
- Be Limiting: Implement rate limiting to prevent spam
Common Use Cases
Elicitation excels in scenarios like:
- Initial Setup: Gathering configuration during first-time setup
- Dynamic Workflows: Requesting context-specific information
- User Preferences: Collecting optional settings and preferences
- Project Details: Gathering metadata about resources being created
- Service Integration: Requesting usernames or IDs for external services
Example Workflow
Here’s a typical elicitation interaction:
Security Considerations
Servers must never use elicitation to request passwords, API keys, tokens, or other sensitive credentials. Use proper authentication flows instead.
Key security guidelines:
- Servers should only request non-sensitive information
- Clients should clearly indicate which server is requesting data
- Users should always have the option to decline
- Responses should be validated against the schema
- Rate limiting should prevent request flooding
Implementation Example
Here’s how a server might use elicitation to gather project information:
This approach creates a smooth, interactive experience while respecting user control and privacy.