Elicitation is newly introduced in this version of the MCP specification and its design may evolve in future protocol versions.
The Model Context Protocol (MCP) provides a standardized way for servers to request additional information from users through the client during interactions. This flow allows clients to maintain control over user interactions and data sharing while enabling servers to gather necessary information dynamically. Servers request structured data from users with JSON schemas to validate responses.
Elicitation in MCP allows servers to implement interactive workflows by enabling user input requests to occur nested inside other MCP server features.
Implementations are free to expose elicitation through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
For trust & safety and security:
Applications SHOULD:
Clients that support elicitation MUST declare the elicitation
capability during
initialization:
To request information from a user, servers send an elicitation/create
request:
Request:
Response:
Request:
Response:
Reject Response Example:
Cancel Response Example:
The requestedSchema
field allows servers to define the structure of the expected response using a restricted subset of JSON Schema. To simplify implementation for clients, elicitation schemas are limited to flat objects with primitive properties only:
The schema is restricted to these primitive types:
String Schema
Supported formats: email
, uri
, date
, date-time
Number Schema
Boolean Schema
Enum Schema
Clients can use this schema to:
Note that complex nested structures, arrays of objects, and other advanced JSON Schema features are intentionally not supported to simplify client implementation.
Elicitation responses use a three-action model to clearly distinguish between different user actions:
The three response actions are:
Accept (action: "accept"
): User explicitly approved and submitted with data
content
field contains the submitted data matching the requested schemaDecline (action: "decline"
): User explicitly declined the request
content
field is typically omittedCancel (action: "cancel"
): User dismissed without making an explicit choice
content
field is typically omittedServers should handle each state appropriately:
Elicitation is newly introduced in this version of the MCP specification and its design may evolve in future protocol versions.
The Model Context Protocol (MCP) provides a standardized way for servers to request additional information from users through the client during interactions. This flow allows clients to maintain control over user interactions and data sharing while enabling servers to gather necessary information dynamically. Servers request structured data from users with JSON schemas to validate responses.
Elicitation in MCP allows servers to implement interactive workflows by enabling user input requests to occur nested inside other MCP server features.
Implementations are free to expose elicitation through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
For trust & safety and security:
Applications SHOULD:
Clients that support elicitation MUST declare the elicitation
capability during
initialization:
To request information from a user, servers send an elicitation/create
request:
Request:
Response:
Request:
Response:
Reject Response Example:
Cancel Response Example:
The requestedSchema
field allows servers to define the structure of the expected response using a restricted subset of JSON Schema. To simplify implementation for clients, elicitation schemas are limited to flat objects with primitive properties only:
The schema is restricted to these primitive types:
String Schema
Supported formats: email
, uri
, date
, date-time
Number Schema
Boolean Schema
Enum Schema
Clients can use this schema to:
Note that complex nested structures, arrays of objects, and other advanced JSON Schema features are intentionally not supported to simplify client implementation.
Elicitation responses use a three-action model to clearly distinguish between different user actions:
The three response actions are:
Accept (action: "accept"
): User explicitly approved and submitted with data
content
field contains the submitted data matching the requested schemaDecline (action: "decline"
): User explicitly declined the request
content
field is typically omittedCancel (action: "cancel"
): User dismissed without making an explicit choice
content
field is typically omittedServers should handle each state appropriately: