Building Model Context Protocol (MCP) servers often forces a binary choice when a tool hits a missing parameter: fail hard and lose the user's session context, or silently guess a default and risk incorrect behavior. A new guide from DEV.to outlines a third optionβ€”elicitationβ€”that allows the server to pause, ask the client for a specific value, and resume the original call. This mechanism keeps the user in the loop without breaking the flow of the current operation.

The Three Paths for Missing Data

Without elicitation, developers typically rely on hard errors or silent defaults. A hard error is safe but frustrating, forcing users to restart conversations. Silent defaults are convenient but dangerous, as tools may assume incorrect environments or names. Elicitation bridges this gap by sending a structured request to the client, which then renders a UI for the user to provide the missing information. Once the user answers, the server continues with the new value, preserving all prior context.

Handling Accept, Decline, and Cancel

A critical implementation detail often overlooked is that elicitation requests have three distinct outcomes: accept, decline, and cancel. Servers must explicitly handle all three branches to avoid crashes or hung states. If a user declines, the server must abort the operation cleanly. If they cancel, any upstream work started before the prompt must be rolled back. Assuming every elicitation returns a value is a common bug that leads to undefined parameter errors in production.

When Not to Use Elicitation

Elicitation is not a band-aid for poor schema design. If a parameter is required for every single call, it belongs in the input schema, enforced by the client before the tool runs. Furthermore, never use elicitation to collect secrets like API keys or tokens. These credentials should be injected by the gateway or environment variables to avoid leaking them into interactive logs or UI prompts. Reserve elicitation for genuine decisions that cannot be known in advance, such as choosing between valid deployment targets.

Key Takeaways

  • Use elicitation only for values that are genuinely unknown until the user makes a decision at call time.
  • Always implement logic for 'decline' and 'cancel' actions to prevent server crashes or hanging processes.
  • Keep secrets out of elicitation prompts; manage credentials via the gateway or environment.
  • Treat elicitation messages like user-facing copy: be specific, concise, and explain the consequences of each option.

The Bottom Line

Elicitation is a powerful feature for interactive MCP tools, but it requires rigorous testing of all three response paths. Don't let your server assume the user will always say 'yes'β€”build for the 'no' and the 'cancel' too.