What an MCP receipt captures
An ordinary MCP call is ephemeral: the client asks, the server answers, and afterwards the only record is whatever the client chose to log. A receipt-issuing server changes the default. At execution time, server-side, it captures:
- The tool name that executed, as called.
- The arguments, committed: a hash of the arguments the call received, so the inputs are bound to the record and any later edit shows.
- The exact result bytes: what the tool actually returned, saved in full, with a SHA-256 digest of those bytes. Not a summary of the result, and not the agent's retelling of it.
- A timestamp for the moment of execution.
- The receipt's canonical bytes and its output hash: the commitment a verifier recomputes to check that the saved record is the record that was made.
- For multi-step jobs, a place in the set: step receipts bind into one workflow record with a single root commitment, so a whole job can be verified as a set, not call by call.
Capture has to happen at execution time, by the executing layer. A receipt reconstructed later from client logs is a claim about the past; a receipt committed while the call ran is evidence from it.
Verification that does not trust the server
The obvious objection: the server issued the receipt, so why believe it? Because verification here is recompute, not belief. The receipt publishes everything the check needs:
- Recompute the commitment. Compute the SHA-256 over the receipt's canonical bytes and compare it to the output hash it carries. A match means the record was not changed after it was saved.
- Check the result. Fetch the saved result bytes and compare their digest to the evidence hash. The result in the record is the result that came back.
- Check the set. For a multi-step job, recompute the workflow root from the step receipt IDs and compare it to the published root. A step added, dropped, or swapped after the fact breaks the root.
- Read the world back. For effects that matter (a payment sent, a record written), confirm the effect in the system of record. The receipt ties the claim to bytes; the readback ties the bytes to reality.
No account, no permission, and no cooperation from the server are required: the bytes are public and the construction is published, so a client, a customer, or a third-party auditor all get the same answer from the same receipt. The verifier walkthrough runs this procedure against a real public receipt, and the live verifier runs the receipt checks in the browser.
The format: AER-1, an open Internet-Draft
A receipt only stays checkable if its format outlives any one server. That is what AER-1 is for: the receipt format is specified in draft-zambo-aer1-23, an open IETF Internet-Draft, so the canonical bytes, the hashes, and the workflow construction are public text anyone can implement from.
Three things keep the format honest in practice. The draft ships with public test vectors, fixed receipts with known-good hashes that any implementation can check itself against. Independent builders have written their own implementations from the draft text and matched the vectors, which is recorded in the implementation report. And the conformance kit is open, so the same checks a verifier runs here can be run offline, against any server's receipts, by anyone.
Add receipts to your MCP workflow
- Route calls through a receipt-issuing server: connect your AI client or agent to the Zambo MCP at zambo.dev/mcp and every call returns its result plus a verifiable receipt at a public URL. No change to how your agents ask; the record appears alongside the answer.
- Use the framework packages: the same receipt pattern is packaged for agent frameworks, including LangChain and CrewAI, so calls an agent makes inside a larger job leave receipts too.
- Try the path end to end first: the live demo mints a real receipt for one call, free, no signup. Check it at zambo.dev/verify/ and you have run the whole loop: call, receipt, verify.
- Keep full runs: a Day Pass ($0.99) keeps every call receipted for 24 hours and seals a closed run so its page, verify badge, and PDF pack stay put after the free viewing window.
MCP server receipts: FAQ
What is an MCP receipt?
An MCP receipt is a verifiable record issued at the moment an MCP server executes a tool call. It captures the tool name, a hash of the arguments the call received, the exact result bytes that came back and their SHA-256 digest, and a timestamp, and it is published at a URL anyone can fetch. Because the result is committed under a hash at execution time, the receipt can be checked later by recompute: if the bytes were changed after the fact, the recomputed hash will not match. The portable format for these receipts is AER-1, an open IETF Internet-Draft.
How do I verify an MCP tool call?
Fetch the call's receipt and recompute it. Compute the SHA-256 over the receipt's canonical bytes and compare it to the output hash the receipt carries; fetch the saved result and compare its digest to the evidence hash. If the call was one step of a multi-step job, recompute the workflow root from the step receipt IDs and compare it with the published root. Every value needed is published with the receipt, so the check needs no account and no trust in the server: matching hashes mean the saved record is the record made when the call ran. A free verifier runs the same checks in the browser if you do not want to run them by hand.
Can an MCP server prove what it executed?
It can prove the record of what it executed, which is the part that can actually be proven. A receipt issued at execution time commits to the tool that ran, the arguments it received, and the exact result bytes, under hashes anyone can recompute. That proves the saved result was not changed since it was saved. It does not prove the result was correct, or that the tool was the right one to call: correctness is a judgment, and no record format can make it for you. What the receipt removes is the need to trust the server's say-so about what happened.
How do I add receipts to my MCP server?
There are two routes. The fast one: route the calls through a receipt-issuing MCP server, so each call returns its result plus a verifiable receipt without changes to your agents; Zambo's MCP at zambo.dev/mcp works this way, and framework packages add the same pattern inside LangChain and CrewAI agents. The build-your-own route: implement the AER-1 format from the open Internet-Draft, using the public test vectors and the open conformance kit to check your implementation against independent ones. Either way, the receipt has to be captured at execution time by the executing layer; a receipt reconstructed later from logs is not the same artifact.