Introducing MCP elicitation: Request user input at runtime

Modern AI systems thrive on context—but they often need more of it, and at the right time. Whether it’s a user’s timezone, role, or intent, models perform better when they can ask for missing information on the fly.

With the latest release of the MCP specification (June 18, 2025 edition), the protocol introduces a major new capability that addresses exactly that: elicitation.

MCP elicitation lets servers request additional context dynamically, at runtime, while a session is in progress. No more brittle workarounds or bloated prompts. Just structured, standardized back-and-forth between models and the applications they power.

Let’s take a closer look at what this enables, how it works, and why it changes how we build context-aware AI.

What is MCP elicitation?

Many workflows require the ability to dynamically ask users for additional information during execution. For example, ask for confirmation before an irreversible action or prompt the users to authenticate.

Until now, MCP lacked a standardized way for servers to handle these kinds of runtime interactions. Developers had to build custom tooling, multi-step tool calls, or proprietary protocols just to support basic back-and-forth flows.

MCP elicitation solves this cleanly.

At its core, MCP elicitation is a mechanism that lets a model (or model-serving system) ask the client for missing or additional context during a session. This is especially useful when the model’s prompt or logic refers to a variable that hasn't yet been resolved—like {{current_user}}, {{timezone}}, or {{organization.name}}.

Instead of hardcoding all context up front or relying on guesswork, elicitation introduces a formalized way for the model to say: "I need more information before I can respond accurately. Please provide it."

This can unlock many scenarios. Some examples are:

• Action confirmation: A model attempts to trigger an irreversible operation—like deleting a workspace—and uses elicitation to ask the user, "Are you sure you want to proceed?" before executing.
• Authentication redirect: During a workflow, the server needs to verify the user’s identity and elicits a redirect into the client’s sign-in or re-authentication flow.
• Clarifying ambiguity: A user asks, “Cancel my subscription,” but the model detects multiple subscriptions. It uses elicitation to prompt: "Which one would you like to cancel—Pro or Enterprise?"
• Progressive input gathering: A project planning agent starts with a high-level question like “What’s your deadline?” and then uses elicitation to collect additional inputs like team size, milestones, or budget—one step at a time.‍
• Contextual branching: In a customer support scenario, the model notices that device info is missing and uses elicitation to ask, “What device are you using?” so it can tailor troubleshooting steps.

How MCP elicitation works

MCP elicitation introduces a new protocol message type: ElicitationRequest. This is sent by the MCP server to the client whenever it needs additional context to proceed.

Here’s a typical interaction:

1. The server detects a missing or ambiguous variable and sends an elicitation/create request.
2. The client presents the user with the request for information. The client should allow users to review and modify their responses before sending, as well as to reject providing the info or cancel the request.
3. The client sends back the response. If the user provides the information, then the necessary context is included in the response.
4. The MCP server continues processing using the new information.

Here’s a request for the user’s timezone and locale. Only the timezone is required information:

	
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "elicitation/create",
  "params": {
    "message": "Please provide your timezone",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "timezone": {
          "type": "string",
          "description": "Your timezone (e.g., America/New_York)"
        },
        "locale": {
          "type": "string",
          "description": "Your locale (e.g., en-US)"
        },
      },
      "required": ["timezone"]
    }
  }
}
	

If the user chooses to provide the info, the response should be:

	
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "accept",
    "content": {
      "timezone": "America/New_York"
    }
  }
}
	

If the user refuses to provide this info, the response should be:

	
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "reject"
  }
}
	

If the user does not explicitly reject (by clicking “Reject”, “Decline”, “No”, etc.) but dismisses the request without making an explicit choice (closes the dialog, clicks outside, presses Escape, etc.), the response should be:

	
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "cancel"
  }
}
	

For details on the request schema and the supported schema types, check the MCP documentation.

Security considerations

MCP Elicitation introduces a flexible, powerful mechanism for requesting runtime context—but with that flexibility comes responsibility. Both clients and servers must take steps to ensure that user privacy, data integrity, and trust are preserved.

The specification defines several critical recommendations and requirements:

• Servers must not require sensitive information: Elicitation is not a vehicle for requesting personally identifiable information (PII), credentials, or any other sensitive data. Servers must not request such information through elicitation. If a model requires this kind of context, it should be handled through secure, out-of-band mechanisms.
• Clients should implement user approval controls: Elicitation is inherently interactive. Clients should always provide clear options to the user that allow them to reject or cancel a request. They should also present elicitation requests in a manner that clearly indicates what information is being requested and why.
• Clients and servers should validate elicitation content against the provided (JSON) schemas. This ensures that values like "America/New_York" are valid timezones, booleans are not sent as strings, etc.
• Clients should clearly indicate which server is making the elicitation request—especially in multi-server or multi-agent contexts.
• Servers should be able to proceed or degrade gracefully in the event that a request is rejected or canceled.
• Clients should implement rate limiting to prevent abusive or excessive elicitation behavior from misbehaving servers or models.

Final thoughts

The arrival of MCP elicitation marks a significant step forward in making AI systems both modular and interactive. By enabling runtime context negotiation between models and clients, developers can create more adaptive, secure, and intelligent applications—without having to overfit models or prompts for every possible user state.

Whether you're building chatbots, copilots, or embedded AI systems, this feature gives you a powerful new tool in the MCP toolkit. As AI continues to shift toward more real-time and contextual applications, elicitation offers a principled, interoperable way to bridge the last mile between models and reality.