How it works
MCP elicitation inserts a human-response step inside an active tool call. The tool reaches a point where it lacks information that should not be inferred, such as a missing parameter, an operating preference, or a consequential choice. It sends an elicitation request through the MCP interaction path, and the client presents that request to the operator. The call remains unresolved until the harness receives a response or applies a timeout, cancellation, or failure policy.
A sound control loop is:
- The tool identifies the exact missing input and stops before crossing the affected boundary.
- The client renders a bounded question with enough context to make the choice intelligible.
- The operator answers, declines, or cancels.
- The harness correlates the response with the suspended call and validates its shape.
- Execution resumes only if policy permits the selected path.
The response is input, not ambient conversation. It should be attached to the call that requested it, recorded with its provenance, and excluded from unrelated sessions. The harness also needs a defined outcome when no response arrives. Leaving a tool call suspended indefinitely is not a control mechanism. It is an unbounded dependency on operator availability.
Why it matters in an agent harness
Agentic systems often encounter decisions that are easy to express but unsafe to infer. A tool may need a target environment, a preferred account, a choice between two irreversible actions, or information held only by the operator. Elicitation gives the system a deliberate way to obtain that input without pretending the model already knows it.
The main benefit is control at the point of use. A generic chat message can lose its connection to the operation that needed it. Synchronous elicitation keeps the question, response, and suspended tool call in one execution context. That makes the resulting trajectory easier to inspect and replay. An operator can see which action was waiting, what was asked, what answer was supplied, and how execution changed afterward.
The mechanism also narrows failure propagation. When required input is absent, the tool can stop locally rather than inventing a value that contaminates later steps. Cancellation can terminate the affected branch without necessarily discarding the entire run. Validation can reject a malformed or stale response before it becomes tool input.
Elicitation does not remove the need for permission checks. Human-provided data may select an object or clarify intent, but it does not automatically authorize the tool to modify that object. The harness must still enforce credential scope, application permissions, execution limits, and any required approval policy. Capability, input, and authority are separate concerns.
The operator interface matters as much as the protocol exchange. A vague prompt such as “Continue?” hides the action and its consequences. A useful elicitation names the pending operation, the decision being requested, the relevant constraints, and the available exit path. Sensitive values also require care. The harness should not ask for secrets through an ordinary elicitation surface when a dedicated credential flow or secure boundary is required.
MCP elicitation vs approval gates
The distinction changes where each mechanism belongs. Elicitation obtains information. An approval gate authorizes or rejects a proposed action. One interaction can contain both ideas, but treating every answer as approval creates ambiguous authority.
| Mechanism | Primary question | Typical outcome | Control requirement |
|---|---|---|---|
| MCP elicitation | What input is missing? | Supply, decline, or cancel | Validate and bind the response to the requesting call |
| Approval gate | May this proposed action proceed? | Approve, reject, or request revision | Present the concrete action and enforce the decision before execution |
If a tool asks which repository to inspect, elicitation is sufficient. If it proposes deleting data from that repository, selecting the repository is not approval to delete. The harness should create a separate authorization checkpoint with a legible proposal and an explicit decision.
The Rifty take
We treat elicitation as a narrow interruption for information the system should not infer, not as a general escape hatch for weak planning. We accept the latency of a synchronous pause when the missing input materially affects the execution path. We keep authorization separate because a human answer should never acquire more authority than the question explicitly requested.
Implementation checks
- Bind each response to one suspended tool call and reject stale or mismatched replies.
- State what operation is waiting and why the requested input is necessary.
- Define explicit outcomes for response, refusal, cancellation, timeout, and client disconnection.
- Validate response shape and allowed values before resuming execution.
- Do not interpret supplied information as permission for a consequential action.
- Preserve the request, response provenance, timing, and resulting control decision in the execution trace.
- Prevent elicited content from leaking into unrelated calls, agents, or sessions.
- Use a secure credential path when the requested value is secret or authentication material.
- Test recovery after interruption so a resumed call does not duplicate effects already committed.
- Measure repeated elicitations. Frequent requests for predictable inputs usually indicate a weak run contract or incomplete context assembly.
Frequently asked questions
When should a tool use MCP elicitation?
Use MCP elicitation when an active tool call needs human-held input that materially changes its execution path and should not be guessed. Good cases include selecting a target, resolving a bounded ambiguity, or supplying an operating preference. Predictable inputs should instead be collected before the call or included in its contract.
Does an elicitation response count as approval?
No. An elicitation response supplies requested information but does not inherently authorize a consequential action. If the chosen value leads to a write, deletion, payment, publication, or permission change, the harness should evaluate the applicable approval policy and present a separate, concrete authorization decision when required.
What should happen if the operator does not respond?
The harness should apply an explicit timeout or suspension policy rather than leaving the call unresolved indefinitely. Depending on the run contract, it may cancel the branch, checkpoint resumable state, or fail closed. The resulting status must remain visible so silence cannot be mistaken for consent or successful completion.
How should elicitation appear in an execution trace?
Record the requesting tool call, the bounded question, response provenance, timing, validation result, and the control decision that followed. Sensitive values may need redaction, but their handling should remain evident. The trace should let an operator determine why execution paused and whether the resumed action used the intended response.
Can MCP elicitation be used to collect secrets?
Ordinary elicitation should not be the default channel for secrets. Credentials need a surface with appropriate masking, storage, transmission, and access boundaries. Elicitation can direct an operator into that controlled flow, but the harness should avoid placing raw authentication material into general conversation history, traces, or reusable model context.