MCP 工具缺少值時，何時採用 Elicitation 而非讓呼叫失敗

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.

Where elicitation fits

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.

What an elicitation request contains

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.

Handling the three outcomes

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.

What elicitation is not for

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.

Designing the question well

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.

How an agent misuses it

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.

Testing the full interaction in a harness

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.

Frequently asked questions

What is the difference between elicitation and a confirmation?

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.

Should I use elicitation for API keys or tokens?

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.

What happens if the user declines or cancels?

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.

Is elicitation a replacement for a strict input schema?

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 — start there for the full model of tools, schemas, and user interaction.