Signed receipts on MCP tool calls: 20 lines buys you evidence, not trust

The signature is created inside the handler process, and that is both the value and the boundary. Everything downstream of it becomes checkable. A proxy that rewrites a response, or a transport that turns `weight_kg: 70` into `700` ^[5], breaks the binding between request and result, and a single verified receipt is enough to show it ^[15]. Set against a result that arrives as plain text over stdio with no signature, no binding to the original request and no record of what was evaluated ^[6], that is a real change in what you can prove afterwards.

The third item on the author's own threat list behaves differently. A server binary swapped between sessions, with a changed tool description ^[5], runs the same startup path the tutorial prescribes: mint an Ed25519 keypair, build a verifier around it, wrap the handler ^[7]. The substitute generates its own key and signs entirely valid receipts for whatever it chooses to return ^[10]. Catching it requires a verifier holding a public key pinned before the swap, which is a custody and distribution job the wrapper does not perform. The author is straight about this: in production you already have a keypair, and then the integration is closer to five lines rather than twenty ^[8].

Which means the two line counts describe the same wrapper. The fifteen-line gap between them is key generation ^[9], and in production those fifteen lines are not deleted so much as replaced by whatever holds your signing key. That is the part with an operational bill attached, and it is not measured in lines.

Delayed triggers are the same problem moved from space into time. A trigger that fires sixty seconds after a specific input pattern ^[5] produces a receipt at each call, signed by the code that is misbehaving. Detecting it means keeping receipts and comparing them across calls ^[15], which is storage, a retention policy and someone who reads the output. The decorator is the cheap end of that.

What the receipt actually contains is where the supplied text runs out: the excerpt stops mid-sentence exactly as it begins describing what `withReceipt` does at call time ^[12]. So the schema drift claim in the headline pitch ^[1] cannot be checked from this material. It stands or falls on whether the signed payload includes a hash of the tool description and argument schema, and that is precisely the section we do not have.

The governance is worth reading before the code. The format is the Correctover Conformance Shape, described as an IETF Internet-Draft covering a receipt schema and binding specification ^[2], and the reference implementation is source-available under Elastic License 2.0 ^[3]. The tutorial is published under the dev.to account `correctover` ^[13]. One party wrote the draft, the library and the walkthrough, and nothing in the material shows a second implementation or an independent verifier. A receipt is only useful if the party who doubts you can check it, so the interesting question is not the twenty lines. It is who else can hold the other end.