A
licenseNot graded
qualityB
maintenanceAdds a human-in-the-loop checkpoint to MCP-capable AI coding agents, enabling them to pause and request user feedback before executing actions.
10
71
MIT
confirm-mcp
by confirm-ai
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@confirm-mcprequest approval to refund $500 to customer 78910"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
confirm-mcp
An MCP server that gives any MCP-compatible agent (Claude Desktop, Cursor, and others) a human-approval tool. Before the agent does something irreversible, it calls request_approval, a human approves or edits the action at confirm.dev, and the agent proceeds with the approved result. Every decision is logged.
Setup
Get an API key at confirm.dev, then add the server to your MCP client config.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"confirm": {
"command": "npx",
"args": ["-y", "confirm-mcp"],
"env": { "CONFIRM_API_KEY": "cfm_live_..." }
}
}
}That's it. The agent now has two tools.
Related MCP server: call-a-human-mcp
Tools
request_approval
Pause and ask a human to approve a sensitive action. Blocks until the human decides or the wait elapses.
Input | Description |
| One line the human reads, e.g. "Refund $10,000 to customer #4821". Required. |
| Approver email, or |
| The exact action as structured data. The human can edit it before approving. |
| Why the agent wants to do this. |
| The agent's recent steps, for context (max 10). |
| How long the request stays valid (5 to 10080). |
| How long to block before returning "pending" (default 15). |
On APPROVED, the tool returns the effectivePayload to use (the human may have edited it). On REJECTED or EXPIRED, it tells the agent to stop. If the wait elapses while still pending, it returns the request id so the agent can poll later.
check_approval
Poll a previously created request by id to see whether a human has decided.
Why a tool, not a prompt
The approval is enforced server-side: the agent cannot fake a verdict, and every decision is recorded in an immutable audit log. Teaching the agent when to call this (via a system prompt or an agent skill) is the coverage layer; the tool is the enforcement layer.
For production agents where you need guaranteed coverage of specific actions, use the deterministic policy engine in @confirm/sdk (guard()) rather than relying on the model to remember to call the tool.
Docs: confirm.dev/docs. Node 18+.
Development
This package is developed in a private monorepo alongside the Confirm.dev service and mirrored here on every release, which is why the history starts at the first public release. Issues and PRs are welcome; PRs get cherry-picked upstream.
Build: npm install && npm run build. Test: node smoke.mjs (after a build; uses a mocked client, no network).
Available Tools
2 toolscheck_approvalCheck a pending approvalA
Poll a previously created approval request by id to see if a human has decided yet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The approval request id returned by request_approval. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a poll (read-oriented) operation and adds context about human decision, but it does not specify the return format, possible errors, or whether it is strictly non-mutating. For a simple tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and purpose. Every word contributes, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does, what it expects (id), and what it checks for. It lacks details about return values, but that is acceptable for a straightforward polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the 'id' parameter, including its source from request_approval. The description only says 'by id' and adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (poll), the resource (previously created approval request), and the purpose (see if a human has decided). It distinguishes from the sibling tool request_approval by focusing on checking an existing request rather than creating one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after request_approval by saying 'previously created approval request'. It provides clear context for when to use it, though it does not explicitly state exclusions or mention alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_approvalRequest human approvalA
Pause and ask a human to approve a sensitive or irreversible action before you perform it (refunds, deletes, deploys, outbound messages, spending money). Blocks until the human approves, rejects, or the wait elapses. If APPROVED, use the returned effectivePayload exactly (the human may have edited it). If REJECTED or EXPIRED, do not perform the action.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| notify | Yes | Approver email address, or 'group:<key>' to escalate to a group. | |
| payload | No | The exact action as structured data. The human can edit this. | |
| summary | Yes | One line the human reads, e.g. 'Refund $10,000 to customer #4821'. | |
| reasoning | No | Why you want to do this. | |
| agent_name | No | Your name, shown to the approver. | |
| ttl_minutes | No | How long the request stays valid. | |
| wait_minutes | No | How long to block before returning pending (default 15). | |
| recent_actions | No | Your recent steps, for context. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it blocks until approved/rejected/expired, and instructs to use the returned effectivePayload exactly if approved, since the human may edit it. This is critical operational context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the tool's purpose, no wasted words. Each sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers outcomes (approved/rejected/expired) and resulting action. The 8 parameters are all documented in the schema, and the description supplements with enough behavioral context for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful operational instruction about payload handling (use returned effectivePayload exactly), which goes beyond the schema's 'human can edit this' and clarifies the payload's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it requests human approval for sensitive actions, with specific examples (refunds, deletes, deploys, outbound messages, spending money). However, it does not explicitly reference sibling tool check_approval, so sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use before performing sensitive or irreversible actions. It does not explicitly state when not to use or mention alternatives like check_approval, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.2- First observed
check_approval - First observed
request_approval
TDQS
A4.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one initiates an approval request and blocks, the other polls an existing request's status. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tool names follow the consistent verb_noun pattern (request_approval, check_approval), using snake_case and parallel structure. This is a predictable and coherent naming convention.
Tool Count4/5
With only 2 tools, the server is slightly under the typical 3-15 range, but the scope is highly focused on approval workflows. Both tools are essential and the count does not feel excessive or severely lacking.
Completeness4/5
The core lifecycle of approval is covered: creating a request and checking its status. A possible gap is cancellation of an approval request, but the blocking behavior of request_approval partially mitigates this, so the missing functionality is minor.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Human-in-the-loop for AI agents over MCP: durable approvals with a hosted review page & audit trail
Preventive human-approval write-gate for AI agents: writes commit only after a human approves.
Human-in-the-loop review and approval for AI agents. Audit trail, approval policies, native MCP.
Human-in-the-loop approval for agent actions, with verifiable action-bound receipts.
Related MCP Servers
- AlicenseAqualityAmaintenanceAn MCP server that enables AI agents to pause and request human approval or information via Slack, Telegram, or macOS dialogs before proceeding with actions.215Apache 2.0
- FlicenseNot gradedqualityBmaintenanceProvides a secure MCP boundary for AI agents, intercepting and validating tool calls, redacting secrets, and requiring human approval for sensitive actions with a tamper-evident audit trail.-
- AlicenseNot gradedqualityCmaintenanceMCP server that provides human-in-the-loop approval for risky AI agent actions, with durable state and audit logs.MIT