Elicitation: MCP's standard for human-in-the-loop
An agent is halfway through a task. It needs your approval before proceeding. Or it hit an OAuth flow and needs you to sign in. Or it wants to confirm before spending money.
Until now, every agent framework invented its own way to handle this. MCP just standardized it.
The problem
MCP tools are request-response. Client calls a tool, server returns a result. But real-world agent tasks aren't single-shot. An agent deploying code might need "are you sure?" before pushing to production. An agent booking a flight might need you to pick a seat. An agent connecting to a new service needs you to complete an OAuth flow.
The old workaround: hold the SSE connection open, emit a special event, hope the client knows what to do with it. Fragile, non-standard, and breaks with stateless architecture.
How elicitation works
The MCP 2026-07-28 spec introduces InputRequiredResult. Instead of returning a final result, a tool returns a request for input:
{
"result": {
"_meta": {
"inputRequests": [
{
"type": "confirmation",
"title": "Deploy to production?",
"message": "This will deploy commit a1b2c3 to daslab.run",
"options": ["Deploy", "Cancel"]
}
],
"requestState": "eyJ0b29sIjoiZGVwbG95Iiw..."
}
}
}The client shows the prompt. The user responds. The client resubmits the original tool call with the response and the echoed requestState:
{
"method": "tools/call",
"params": {
"name": "deploy",
"arguments": { "commit": "a1b2c3", "target": "production" },
"_meta": {
"inputResponses": [
{ "type": "confirmation", "value": "Deploy" }
],
"requestState": "eyJ0b29sIjoiZGVwbG95Iiw..."
}
}
}Any server instance can pick this up — the requestState carries everything needed to resume. No sessions, no sticky routing, no held connections.
Input types
The spec defines several inputRequests types:
Why this matters
Before elicitation, agent trust was binary: either you gave the agent full autonomy or you didn't use it. There was no standard way to say "do everything except this one thing — ask me first."
Elicitation makes graduated trust possible. An agent can:
- Autonomously read data (no elicitation needed)
- Ask before writing data (confirmation elicitation)
- Ask before spending money (URL elicitation → payment flow)
- Ask before accessing a new service (URL elicitation → OAuth)
The agent does the work. You make the decisions. The protocol handles the handoff.
How we use this
At Daslab, every agent job runs inside a scene — a workspace with connected tools, credentials, and context. Some tools are auto-approved (read operations, safe queries). Others require confirmation (sending messages, making payments, destructive actions).
We've been doing this with our own approval flow — push notification to your phone, tap to approve, agent resumes. Elicitation standardizes the protocol underneath. Any MCP client connecting to a Daslab workspace now gets the same trust model: the scene's approval policy determines which tools need human confirmation.
The URL-mode elicitation is particularly interesting for us. When an agent needs to connect a new service — say, link your GitHub account — the server returns an OAuth URL. The user authenticates in their browser. The token flows back through the protocol. The agent never sees the credential, but it can now use the service. That's the agent wallet pattern: credentials managed by the platform, approved by the human, used by the agent.
Elicitation spec · MCP 2026-07-28 release candidate