MCP Confirm

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:

pip install mcp-confirm

Start it with at least one permitted root:

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.