# mcp-confirm [Health: Active]

**Category:** 🔒 Security  
**Repository:** https://github.com/les-k/mcp-confirm  
**GitHub Stars:** 0  
**npm Downloads (last month):** 20  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/mcp-confirm

## Description
An MCP server whose confirmation cannot be replayed against a different call.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "mcp-confirm": {
    "command": "uvx",
    "args": ["mcp-confirm"]
  }
}
```

## Documentation

## What mcp-confirm does

The mcp-confirm MCP server demonstrates protections for a destructive file operation: deleting a file under administrator-selected filesystem roots. Its focus is the security gap left after the MCP SDK validates and binds a confirmation but permits the same valid approval to be presented repeatedly during its lifetime.

The package adds an in-memory ledger that records confirmations issued by the current process and marks them spent when redeemed. It also sanitizes the text shown to the person approving an action, checks that a requested path is within a configured root, and verifies the resource immediately before deletion. A path that becomes a symlink after approval is rejected.

These controls place the project in the 🔒 Security category. The SDK remains responsible for sealing request state, binding it to the method, target, argument digest, audience, principal, and TTL. This package does not replace that middleware.

## How it works

The MCP SDK's `RequestStateBoundary` protects the round-trip approval with AES-256-GCM and treats returned request state as attacker-controlled. That boundary prevents an approval for one file from being applied to another and rejects forged state. The mcp-confirm MCP server builds on those checks rather than duplicating them.

A confirmation can be spent only once in the process that issued it. The prompt layer converts untrusted values to a single-line representation, removes bidirectional and zero-width characters, and truncates from the middle when necessary. Control characters become spaces, preserving distinctions such as `a\nb` versus `ab`.

Before deletion, the server checks the path against startup-configured roots and tests the resource again. This handles changes made between approval and execution, including a swap to a symlink. Requests outside the allowed roots are refused before a confirmation prompt is shown.

## Setup and configuration

Install the package with:

```bash
pip install mcp-confirm
```

Start it with at least one permitted root:

```bash
mcp-confirm --root /path/you/allow
```

Roots are fixed when the process starts and are not selected by the agent. If no root is supplied, requests are refused. The README does not specify environment variables or a separate signing-key configuration; the MCP server supplies its own request-state key through the SDK.

## Tools and capabilities

The mcp-confirm MCP server provides a deliberately small demonstration centered on deleting one file. Supporting capabilities include:

- Single-use confirmation tracking
- Sanitization of approval messages
- Allowed-root path validation
- Pre-execution resource checks
- Symlink rejection after approval

The repository reports tests for the server, confirmation ledger, and prompt sanitization. Its server tests run through the SDK request-state middleware rather than calling the tool manager in a way that bypasses that boundary.

## Limitations and notes

The ledger is memory-resident and correct only within one process. With multiple replicas, a confirmation issued by one replica is not available to another; the failure is closed safely, but the approval may appear to stop working. A deployment behind a load balancer needs shared storage such as Redis or a database row with atomic compare-and-delete.

The project is a small demonstration rather than a general file-management layer. Its README also notes that it is based on the MCP specification and SDK behavior, not on a published CVE. The SDK's own request-state protection is required for the assumptions made by the single-use ledger.

_Full upstream README: https://allmcps.com/mcp/mcp-confirm/readme_