As AI applications evolve from simple prompt-response systems into intelligent workflow engines, they increasingly need the ability to pause, ask for user input, gather approvals, and securely continue execution. This is exactly where "MCP Elicitation" becomes a foundational capability within the Model Context Protocol.
Elicitation introduces a standardized way for MCP servers to request additional information from users through the client during runtime without breaking the protocol flow. Whether it is collecting structured non-sensitive data such as usernames and preferences through Form Mode, or initiating secure out-of-band flows like OAuth authorization, API key onboarding, and payment consent through "URL Mode", MCP provides a robust architecture for human-in-the-loop interactions.
In this post, we will explore how elicitation works, why the distinction between form and URL modes is critical for security, and how this design enables enterprise-grade, stateful, and secure user workflows.
1. Introduction to Elicitation Modes
The Model Context Protocol (MCP) offers a standardized mechanism for servers to request additional information from users through the client during ongoing interactions. This approach ensures that the client retains control over user interactions and data sharing, while still allowing servers to dynamically collect the information required to continue processing.
MCP supports two elicitation modes:
· Form mode: Enables servers to collect structured user input, with optional JSON Schema validation for the responses.
· URL mode: Allows servers to redirect users to external URLs for sensitive interactions, ensuring that such information does not pass through the MCP client.
2. Client Capability Negotiation for Elicitation
This section explains how clients advertise support for elicitation during the MCP initialization handshake.
If a client supports elicitation, it must explicitly declare the capability under capabilities. The declaration also specifies which modes are supported, such as form and url.
For example, a client that supports both modes declares capabilites like below.
{
"capabilities": {
"elicitation": {
"form": {},
"url": {}
}
}
}
For backward compatibility, an empty elicitation object is treated as support for form mode only.
{
"capabilities": {
"elicitation": {}
}
}
A client declaring elicitation must support at least one mode, and servers must only send elicitation requests for the modes the client has explicitly advertised. This ensures compatibility and prevents unsupported interaction flows.
3. Elicitation Request Structure
Whenever a server needs additional information from the user, it sends an elicitation/create request. This is the standard protocol message used to start either a form or URL interaction.
Every elicitation request must include two key parameters:
· mode: defines the type of elicitation, either form or url
· message: a clear, human-readable explanation of why the information is needed
The mode field determines how the interaction should happen, it is one of the following values.
· form: structured, in-band data collection. In-band means the information exchange happens within the MCP communication flow itself. The server sends the request to the client, the client presents the form to the user, and the user’s response is sent back through the same MCP channel. Because the data travels through the client, it is visible to the client and may also be part of the interaction context.
· url: out-of-band interaction. Out-of-band means the interaction happens outside the normal MCP request-response channel. Instead of the user entering data through the client, the client redirects them to an external URL, such as a secure browser page. The sensitive information is then exchanged directly between the user and the external system, without passing through the MCP client. This is typically used for secure workflows like OAuth login, API key setup, or payments.
An important backward compatibility rule is also defined here, if the mode field is omitted, the client must treat the request as form mode by default. This ensures older implementations continue to work seamlessly.
3.1 Form Mode Elicitation Requests
A form mode request must either explicitly specify "mode": "form" or omit the mode field, since form is the default. In addition to the common elicitation parameters, it must include a requestedSchema field.
The requestedSchema is where the server defines the exact structure of the expected response using a restricted subset of JSON Schema. The restriction is intentional, only flat objects with primitive properties are supported to keep the client-side user experience simple and predictable.
Supported field types include:
· string: text inputs, email, date, URI, etc.
· number / integer: numeric inputs with min/max validation
· boolean: checkbox or toggle fields
· enum / oneOf: dropdown or single-select options
· array enums: multi-select fields
This schema allows clients to automatically:
· generate appropriate form controls
· validate inputs before submission
· display helpful labels, descriptions, and default values
Another important design choice is that complex nested objects and advanced schema constructs are intentionally excluded. This keeps form rendering simple across different clients and ensures a consistent user experience.
3.1.1 requestedSchema parameter
The requestedSchema parameter is essentially a contract for user input. It uses a restricted subset of JSON Schema so that the client can reliably generate a form and validate the response before sending it back.
The key design choice here is simplicity, schemas are limited to flat objects with primitive properties only. In other words, each field is a direct property such as a string, number, boolean, or enum. Complex nested objects and advanced schema constructs are intentionally excluded to keep the UI simple and consistent across clients.
a. String Schema
String fields are used for text-based inputs such as:
· name
· username
· URL
· date
· timestamp
Example
{
"type": "string",
"title": "Display Name",
"description": "Description text",
"minLength": 3,
"maxLength": 50,
"pattern": "^[A-Za-z]+$",
"format": "email",
"default": "user@example.com"
}
This allows the server to specify:
· title: label shown in UI
· description: help text
· minLength / maxLength: length validation
· pattern: regex validation
· format: semantic validation
Supported formats include:
· uri
· date
· date-time
For example, format: "email" lets the client validate email syntax before submission.
b. Number / Integer Schema
Used for numeric fields such as:
· age
· score
· quantity
· percentage
Example
{
"type": "number",
"minimum": 0,
"maximum": 100,
"default": 50
}
This defines:
· input type = number
· lower bound
· upper bound
· default value
Clients can render this as:
· numeric text field
· stepper
· slider (optional)
c. Boolean Schema
Used for yes/no or on/off choices.
{
"type": "boolean",
"title": "Subscribe",
"default": false
}
Typically rendered as:
· checkbox
· toggle switch
This is useful for confirmations and preferences.
d. Enum Schema (Single Select)
This is used when the user must choose one option from a list.
Example without titles:
{
"type": "string",
"enum": ["Red", "Green", "Blue"]
}
This is typically shown as:
· dropdown
· radio buttons
With titles
{
"type": "string",
"oneOf": [
{ "const": "#FF0000", "title": "Red" }
]
}
This is more powerful because the value sent can differ from what the user sees. Very useful in real-world systems.
e. Multi-select Enum
This allows multiple choices.
{
"type": "array",
"items": {
"type": "string",
"enum": ["Red", "Green", "Blue"]
}
}
This is typically rendered as:
· multi-select dropdown
· checkbox group
Additional validation:
· minItems
· maxItems
ensures selection limits.
e. Default Values
Every primitive field can include a default.
Example:
{
"type": "string",
"default": "user@example.com"
}
Clients should pre-fill the form with this value. This improves usability by giving users a sensible starting point.
The schema helps clients in three major ways:
· Generate forms: Automatically build UI controls.
· Validate input: Catch invalid values before sending.
· Guide users: Show labels, descriptions, and defaults.
This makes elicitation highly user-friendly.
3.1.2 Example
Request Payload
{
"jsonrpc": "2.0",
"id": 42,
"method": "elicitation/create",
"params": {
"mode": "form",
"message": "We need a few details to create your support ticket",
"requestedSchema": {
"type": "object",
"properties": {
"fullName": {
"type": "string",
"description": "Enter your full name"
},
"email": {
"type": "string",
"format": "email",
"description": "We will use this for updates"
},
"priority": {
"type": "number",
"minimum": 1,
"maximum": 5,
"description": "Ticket priority (1 = low, 5 = critical)"
},
"subscribeUpdates": {
"type": "boolean",
"description": "Receive email updates for this ticket",
"default": true
}
},
"required": ["fullName", "email"]
}
}
}
Response (User Accepts Input)
{
"jsonrpc": "2.0",
"id": 42,
"result": {
"action": "accept",
"content": {
"fullName": "Arjun Gurram",
"email": "arjun.gurram@example.com",
"priority": 3,
"subscribeUpdates": true
}
}
}
Once the server receives this response, the elicitation step is considered complete, and the server can now continue its original workflow using the collected data.
3.2 URL Mode Elicitation Requests
URL mode elicitation allows the MCP server to redirect users to an external, secure URL for out-of-band interactions. This mode is specifically designed for workflows where sensitive information must not pass through the MCP client or the active MCP communication channel.
This is particularly important for secure use cases such as:
· authentication and OAuth consent flows
· API key onboarding
· payment authorization
· third-party service access
· other sensitive user interactions
Unlike form mode, where user input is collected directly through the MCP client, URL mode moves the interaction outside the MCP request-response flow. The client’s role is limited to presenting the URL, explaining why the interaction is required, and obtaining explicit user consent before navigation.
A URL mode elicitation request must explicitly include:
· mode: "url", identifies the interaction as URL-based
· message: provides a human-readable explanation for the user
· url: the external URL the user should open
· elicitationId: a unique identifier used to track and correlate the interaction
The url field must always contain a valid and secure URL. An important distinction to understand is that URL mode is not used to authenticate the MCP client with the MCP server itself. That responsibility belongs to the standard MCP authorization mechanism.
Instead, URL mode is intended for situations where the MCP server needs to obtain sensitive data or third-party authorization on behalf of the user, while keeping that information completely outside the client context.
Elicitation is one of the most powerful capabilities introduced by the Model Context Protocol (MCP), as it enables dynamic, human-in-the-loop interactions within an active protocol flow. Instead of forcing workflows to fail when required information is missing, MCP allows servers to pause execution, request additional input, and seamlessly continue once the user responds.
Through Form Mode, servers can collect structured, non-sensitive data using schema-driven forms, while URL Mode enables secure, out-of-band interactions for sensitive workflows such as authentication, third-party authorization, and payment flows.
What makes this design particularly robust is the clear separation of responsibilities: the server requests information, the client controls the user interaction and consent experience, and sensitive data can remain completely outside the MCP communication channel when required.
Overall, elicitation transforms MCP from a simple request-response protocol into a stateful, secure, and workflow driven interaction model, making it highly suitable for enterprise grade integrations and real-world user journeys.
Previous Next Home
No comments:
Post a Comment