When an MCP Tool Needs a Missing Value: Elicitation vs Failing the Call

A developer outlined how MCP elicitation lets a server pause a tool call mid-execution to request a missing value from the user through the client, then resume with the answer, offering an alternative to hard errors or silent defaults. The writeup advises reserving elicitation for genuine user decisions, keeping required parameters in the input schema, never collecting secrets through prompts, and testing the accept, decline and cancel branches with a harness that stands in for the client.

Quick answer: Elicitation lets an MCP server ask the client to collect a missing value from the user mid-call, instead of immediately failing or guessing. Use it when the tool genuinely needs a decision only the user can make, such as confirming a target environment or supplying a name. Do not use it to patch a loose input schema or to ask for secrets that should be handled by the gateway. The client renders the request, the user answers, and the original call continues with the new value. Without elicitation, a tool that discovers a missing parameter has two bad options: return an error and force the user to restart the whole conversation, or invent a default and proceed silently. Elicitation adds a third path. The server pauses the current call, sends a structured request describing what it needs, and resumes once the client returns an answer. This keeps the user in control while preserving the context of the work that was already underway. | Approach | What happens | Tradeoff | |---|---|---| | Hard error | Call fails, user restarts | Safe but loses context | | Silent default | Tool guesses a value | Convenient but risky | | Elicitation | Server asks, user answers | Context preserved, user decides | A well-formed request describes the information being collected and, where useful, constrains the answer so the user cannot return something invalid. Here is a tool that needs to know which environment a deployment should target. The constrained enum keeps the answer valid, and the user makes the decision rather than the tool assuming a default. The server then continues the original deployment with the chosen value. An elicitation can be accepted, declined, or cancelled, and the server must handle each. Accept carries the answer, decline means the user chose not to provide it, and cancel means the request should be abandoned cleanly. A server that assumes every elicitation returns an answer will crash on the decline path, so model all three branches in tests, including the case where the user cancels and any upstream work must be cleaned up. It is not a way to rescue parameters that should have been validated up front. If a value is required for every call, put it in the input schema and let the client enforce it before the tool runs. Elicitation is reserved for genuine decisions that cannot be known in advance, such as choosing between valid options or confirming an ambiguous match. Secrets are another boundary: credentials should be injected by the gateway or environment, not collected through an interactive prompt that may be logged. The quality of the message determines whether the user can answer confidently. Name the affected resource, explain why the choice is needed, and show the consequences of each option rather than asking an abstract question. A prompt that merely says "enter a value" gives the user no basis for a decision and encourages a careless accept. Treat the elicitation message like any other piece of user-facing copy: specific, concise, and grounded in the actual operation. An agent that discovers a missing field may add an elicitation for routine parameters that should simply be required, turning every call into a series of prompts. When reviewing generated servers, ask which values are true user decisions and which are predictable inputs, and keep the latter in the schema. If the agent instead hardcodes a default to avoid the prompt, that is the opposite failure; the goal is to reserve elicitation for real choices and make those explicit. Because elicitation is a back-and-forth rather than a single response, it deserves a test that drives the whole exchange. A harness can stand in for the client, answer the elicitation with a chosen value, and assert that the tool continues with that value and reaches the expected result. Separate tests for the decline and cancel paths confirm that the operation aborts cleanly instead of hanging or proceeding with an undefined parameter. Writing these tests also forces a useful design question: if the harness cannot answer without guessing the schema, the requested schema is probably too loose. A well-constrained schema makes the valid answers obvious and keeps the user from returning a value that the tool then has to reject on the next step. A confirmation asks the user to approve a plan, while elicitation collects a missing value the tool needs to proceed. Both pause the call, but elicitation returns structured data rather than a simple yes or no. No. Secrets should be managed by the gateway or environment and kept out of interactive prompts and logs. Elicitation is for decisions and ordinary values, not credentials. The server must handle the decline and cancel actions explicitly, abandon the operation cleanly, and clean up any work already started, rather than assuming an answer always comes back. It is not. Required, predictable parameters belong in the input schema; elicitation is only for values that are genuinely unknown until the user makes a decision at call time. This is part of the The MCP Server Guide https://www.powerduck.com/blog/mcp-server-guide-hub/ — start there for the full model of tools, schemas, and user interaction.