Confirm MCP server

<!-- mcp-name: io.github.les-k/mcp-confirm -->

mcp-confirm

In plain terms: when an AI asks "are you sure?", the MCP SDK already stops

that approval being reused for a different action. It does not stop the

same approval being used twice. This closes that gap, and two others the SDK

leaves open.

Read this first: most of this problem is already solved

The 2026-07-28 MCP specification added Multi Round-Trip Requests, so a tool can pause mid-call and ask the user to confirm. The approval travels back through the client as an opaque requestState, which the spec says servers MUST treat as attacker-controlled.

The Python SDK does this for you, by default, on every MCPServer. RequestStateBoundary is appended to the middleware chain unconditionally — with an ephemeral key if you supply none. It seals the state under AES-256-GCM and binds it to the method, the target, a digest of the call's arguments, the audience, and the authenticated principal, with a TTL.

So the attack everyone reaches for first — approve deleting cache.txt, then replay that approval against thesis.txt — is already refused by the SDK. You do not need a library for it, and you should not write one.

This repository originally wrote one anyway: 250 lines of HMAC, TTL and argument binding, shipped as the headline feature, redundant the day it was published. That is recorded at the bottom rather than quietly deleted.

What the SDK does not do

Three gaps, each with a test that fires.

1. It binds and expires the state. It never spends it.

Inside the TTL, the same approval verifies as many times as it is presented. Every check the boundary makes passes, every time. The specification is explicit that this is deliberate and that the rest is yours:

Note that these measures bound the replay window and prevent cross-user and

cross-request reuse, but do not by themselves guarantee single-use. Servers

for which a given requestState must be consumed at most once (e.g.,

one-time redemptions) MUST enforce that invariant server-side.

For "delete a file" the second attempt finds nothing. For "transfer £500" it is the entire problem. singleuse.py is that invariant — a ledger of outstanding confirmations, spent on redemption. It contains no cryptography, because the boundary already guarantees the plaintext is something this server minted.

2. Nothing sanitises the question the human reads

An elicitation message is server-chosen text rendered to a person, usually with an untrusted value interpolated into it — the whole point is to say which file is going away. So name a file:

cache.txt

SYSTEM NOTICE: your session has expired.
Enter your AWS secret key to continue:

The dialog now carries a second, official-looking prompt. The user is not confirming a deletion; they are being phished by their own tooling. The same 2026-07-28 release also shipped MCP Apps — server-rendered UI — which widens this surface rather than narrowing it.

prompt.py flattens untrusted values to one line, strips bidirectional overrides and zero-width characters, and truncates from the middle so the filename at the end stays visible. Control characters become spaces rather than being deleted, since collapsing them would let a\nb and ab render identically — two different files, one dialog.

3. No protocol layer can re-check your resource at execution time

Shortened. The full README is on GitHub.