Verify a receipt inside Claude
Seal publishes an MCP connector, so a receipt can be checked in a conversation rather than on our website. The point is not convenience. It is that the check happens in software you already trust, using a verifier you can install yourself, with nothing of ours in the path.
Listed in the public MCP registry as ai.aqta/seal, namespace verified by DNS.
Add it
The connector is a remote server over streamable HTTP. Add this URL:
https://app.aqta.ai/api/mcp
No account, no API key, no sign-in. The verification tools are open to anyone; the tools that read a workspace require your own Seal key.
The ninety-second demonstration
Ask for a sample receipt, verify it, then try to break it.
Get a sample Seal receipt.
Verify it.
Now change cost_prevented_eur to 99.99 and verify it again.
The first check returns valid: true, reason signature verified. The second
returns valid: false, reason signature check failed. Nothing else about the
record changed, and nothing needed to reach us for the check to run.
Tools
| Tool | What it does |
|---|---|
verify_receipt | Checks a receipt's signature. Reports whether the key was pinned by you or embedded in the record, and never treats those as the same thing |
decode_receipt | Reads the twelve fields in plain language |
get_public_key | The published issuer key, so you can pin it rather than trust what the record carries |
get_sample_receipt | A real signed envelope from the demonstration workspace |
get_review_pack | A public review pack by its capability URL |
verify_evidence_pack | Checks every receipt in a pack, and reports what the pack does not establish |
explain_attestation_format | The ATTESTATION-v1 envelope and where it stops |
get_transparency_proof | The inclusion proof for a receipt in the append-only log |
list_my_receipts | Your workspace's records. Requires your API key |
workspace_summary | Counts and outcomes for your workspace. Requires your API key |
Pinned versus embedded, which matters
A receipt carries a public key, and a verifier can check the signature against
it. That establishes the record is internally consistent, not that it came from
us. verify_receipt reports key_source so the distinction stays visible:
- pinned: checked against a key you supplied, from
https://api.aqta.ai/v1/attestation/public-key. This is the real check. - embedded: integrity only. The record has not been altered since signing, by whoever signed it.
Most tools that say "verified" collapse those two. This one does not.
What the connector does not change
The claims boundary is the same in a conversation as it is anywhere else. A verified receipt establishes that the issuer signed exactly those fields and that none has changed since. It does not establish that the record matches the computation that actually ran, that every decision was recorded, or that the decision was correct.
Without the connector
Same check, same result, from a terminal:
bashnpx aqta-verify-receipt receipt.json --key <pinned key> python -m aqta_verify_receipt receipt.json --key <pinned key>
Two implementations, written independently, agreeing on every published conformance vector across both record formats. If they ever disagree on the same bytes, that is a defect and we want to hear about it.