webhook-signature-verifier checks a signature somebody else produced, against a published vendor scheme. This tool does the opposite job. It designs the binding set that goes inside an MCP requestState token, mints one with real WebCrypto HMAC-SHA-256 in front of you, and computes what each binding does and does not prevent. Its entire point is a case where every signature check is correct and a correct signature is still not the answer.
This is a faithful reading of normative text made executable, not a discovery. The Multi Round-Trip Requests page of the Model Context Protocol specification, version 2026-07-28, states the trap itself, in one sentence, inside a warning callout. Everybody will skim it. So here it is running: press Replay 5 times and read five PASS results.
Each binding is independent. Turn one off and the residual table below changes on the spot, so the page teaches which binding stops which attack instead of handing you a fixed recipe.
This is the primary output. Every row is computed live, by minting and verifying real tokens with the current binding set, not looked up in a table of stored answers.
| Attack | Result | Stopped by |
|---|
Same principal, same method, same params, inside the TTL. The token is not modified in any way. Every check the token can perform is performed, and every one of them is correct.
-
Shown here because you are the server. A client MUST NOT do this: the specification says the value is opaque to clients.
-
-
Quoted verbatim from the Multi Round-Trip Requests page of the Model Context Protocol specification, version 2026-07-28.
An opaque string meaningful only to the server. Clients MUST NOT inspect, parse, modify, or make any assumptions about its contents.
If a client request contains arequestStatefield, servers MUST treatrequestStateas an attacker-controlled input. IfrequestStateinfluences authorization, resource access, or business logic, servers MUST protect its integrity (e.g. HMAC or AEAD) and MUST reject state that fails verification. Integrity protection MAY be omitted only when tampering can cause nothing worse than request failure.
To prevent replay, servers SHOULD include the following inside the integrity-protectedrequestStatepayload and verify each on receipt:
- the authenticated principal, rejecting state presented by a different principal.
- a short expiry (TTL), rejecting state presented after it lapses;
- an identifier for the originating request, e.g. the method name and a digest of its salient parameters, rejecting state presented on a request that does not match.
Three bindings are listed under that SHOULD. Integrity protection is a separate MUST, in the paragraph above it. The four checkboxes at the top of this page are those three plus integrity.
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.
On the published page that paragraph sits in a callout marked as a warning, attached to the third bullet above.
Because requestState passes through the client, malicious or compromised clients could attempt to modify it to alter server behavior, bypass authorization checks, or corrupt server logic. Servers MUST validate request state as described in the server requirements above.
Source: modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr
The specification permits either construction: servers MUST protect the integrity of the state, e.g. HMAC or AEAD
. This page implements the HMAC one, because HMAC-SHA-256 is what WebCrypto hands you with no key-agreement ceremony, and because the payload stays legible in the panel above, which is the entire point of a teaching tool.
An AEAD build, for example AES-GCM, differs in exactly two ways that matter here. First, the payload is encrypted, so the principal, the expiry and the digest stop being readable by anyone holding the token, which is worth having when the state carries internal identifiers. Second, the same bindings still have to be inside the plaintext and still have to be checked on receipt, and not one row of the residual table changes. Confidentiality is not single-use. The specification's own example writes the field as a placeholder reading "AEAD-protected blob".
The encoding is explicitly your business: Servers are free to encode the state in any format (e.g. base64-encoded JSON, encrypted JWT, serialized binary).
crypto.getRandomValues, imported non-extractable through crypto.subtle.importKey. It is never written to storage, never sent anywhere, and dies with the tab. Press New session key and every token minted before that moment stops verifying.jti and holds it until exp, so the set stays bounded. The demonstration keys on the jti when there is one, which is the same idea with the housekeeping left out.