There are two moments when AI work quietly becomes a trust problem.
The first is delivery. An AI made the file, you are about to send it to a client, and a week later someone asks whether the file being discussed is the same file that was delivered. Screenshots do not answer that. File names do not answer that. A digest can, if you computed it before the file left your hands.
The second is setup. You built an MCP server, the metadata file looks right, and a client or registry rejects it anyway. The error rarely tells you which field failed, what shape it expected, or how to fix the line in front of you.
Two free tools shipped today for those two moments. Both run in your browser. Nothing is uploaded to run either one.
Tool 1: fingerprint a deliverable before you send it
The Deliverable Sealer computes a file's SHA-256 digest locally in the page. Drop in the file, or paste text, and it shows the digest, file name, size, and timestamp. Keep the digest with the delivery note.
It also has the return trip built in. Later, paste the digest you kept and drop in the file someone hands back. The page says MATCH or NO MATCH. That gives you a plain answer to a question that otherwise turns into a thread of screenshots and claims.
Use it for the everyday cases:
- A document, spreadsheet, image, archive, or build artifact an AI produced for a client.
- A revised file where the dispute is not quality, but whether this is the revision that was approved.
- A handoff between two people or two agents where the file crosses tools and folders.
Now the limit, because the limit is what makes the tool honest: the digest is a fingerprint you keep yourself. It is not a receipt.
an agent receipt is a record of one ai agent tool call that anyone can check: it keeps the exact saved bytes and their sha-256 digest, and it proves the result was not changed since it was saved, not that it was right.
A fingerprint helps when you kept it, kept it with the right delivery, and can produce it later. A verifiable receipt is the kept record from the call itself. It is stored when the work runs and can be checked by the client, a reviewer, or anyone else at zambo.dev/verify. The sealer covers files you already have. Zambo covers the work while it is being done.
Tool 2: find the server.json field that will get your MCP server rejected
The MCP server.json validator reads a server.json file field by field and reports PASS, FAIL, or WARN with the fix written in plain language.
It checks the things that commonly stop a listing or a connection:
- Whether the name is in reverse-DNS form.
- Whether the description fits the registry limit.
- Whether the version has the expected shape.
- Whether website and repository fields are usable URLs.
- Whether each remote names a supported type and an https URL.
- Whether package entries carry the fields a client needs.
- Whether the file includes a remote or a package at all, because a server with neither gives a client nothing to connect to.
The worked example is not invented. The page can load Zambo's live registry record and validate it in front of you. It also gives the honest closing line for this tool: a valid server.json is step one. It gets your server listed and connectable. It does not give the calls that server makes a checkable record. Zambo issues a verifiable receipt for every call, which is the part clients can test after the connection works.
Which one do you need?
If the work is already done and sitting in a file, fingerprint the file before it moves.
If you are publishing or connecting an MCP server, validate the metadata before someone else's system rejects it.
If the work has not run yet and the result will matter later, run it somewhere the record is kept as part of the work. Start at zambo.dev/add: 20 free calls per day, and every call leaves a verifiable AER-1 receipt.
Zambo is the verifiable work layer for AI: tools behind one MCP endpoint, continuity that carries sessions, memory, and work across AIs, and a verifiable AER-1 receipt for every job. Start at zambo.dev, verify any receipt at zambo.dev/verify, and read the draft at the IETF Datatracker.
Related reading:
Top comments (0)