Guide · Model Context Protocol
Human approval for MCP tool calls
What you want is for a consequential tool call — a refund, a deploy, an email to a client — to wait until the person who owns it has decided, and for a record of that decision to exist afterwards. The protocol leaves who approves to the client and the server, so in practice there are three places the approval can live.
What the protocol gives you
The Model Context Protocol asks clients to keep a person able to deny tool calls, and lets a server mark a tool as destructive or read-only with annotations, so a client can decide when to prompt. Elicitation lets a server ask the user for input mid-call. All three put the question to the person using the client. None of them reaches somebody else, applies an organisation's rules, or keeps the answer.
Three places the approval can live
| Where | What it is good for |
|---|---|
| In the client | The permission prompt in Claude, ChatGPT, Cursor or VS Code. Right for a developer approving their own agent; the answer is one person's and is not kept. |
| In a gateway in front of the servers | A proxy that checks each tool call before the server sees it, against policy. Good for deny-by-default and for actions that must never run unasked. A gateway that can ask a person, not only allow or deny, covers the cases policy should not settle alone. |
| In an approval server the agent calls | A server whose tools ask a named person and return their answer, so the agent asks before acting. Works from any client, reaches people who never open it, and keeps the decision. |
What to look for in an approval server
- It asks a named person or group, not whoever is at the keyboard.
- It reaches them where they are: email, Slack, Teams, a phone.
- Its tools can never approve: an agent asks, a person decides.
- It can settle routine calls from rules and send the rest to a person.
- It signs in with OAuth, so nobody pastes a long-lived token into a client.
- It keeps who decided, what they saw and when, and exports it.
How Deliverd does it
Deliverd is a remote MCP server, over Streamable HTTP with OAuth 2.1 sign-in. Its request_approval tool asks a named person or group, who answers by email, Slack, Teams or a page on their phone; the agent reads the answer with get_approval and can never approve anything itself. Before an action, check_gate declares it and the organisation's rules allow it, refuse it or send it to a person.
A server of your own can go further than trusting the agent to ask: a call the gate allowed can carry a signed decision token, which the server verifies with the TypeScript or Python SDK before it acts, so arguments nobody agreed to are refused. Afterwards record_execution notes what ran, and the decisions export as evidence.
Questions
- Isn't the client's confirmation prompt enough?
- For a developer approving their own agent, often yes. It is not enough when the decision belongs to someone else, when the agent runs unattended, or when the decision has to be kept.
- Does Deliverd use MCP elicitation?
- No. Elicitation asks the person using the client. Deliverd asks a named person who may never open the client, and the agent reads their answer with get_approval.
- Which MCP clients does Deliverd work with?
- Claude Code, Claude's desktop and web apps, ChatGPT, Codex, Cursor, VS Code, Windsurf and Gemini CLI, among others. It is one server; every client uses the same tools.