bernstein-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@bernstein-mcpverify this receipt and explain its verdict"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.

bernstein-mcp
Stateless, read-only MCP endpoint at https://mcp.bernstein.run that verifies bernstein run receipts and hash chains. No account, no key, nothing stored, nothing fetched.
claude mcp add --transport http bernstein https://mcp.bernstein.run/mcpWhat it does
Tool | Result |
| recomputes every chain a run receipt embeds, rebuilds the signed subject, checks the Ed25519 signature; verdict + one line per check, plus the verdict as a signed statement (below) |
| the same verification, narrated: what the run recorded, where it diverges, what the result does and does not prove |
| walks journal rows, lineage entries or audit events on their own (pass the file text for byte-exact rows); names the first broken link |
| TRACE v0.2 conformance checks on one Trust Record, stateless, no account: vendored schema, profile rules, the embedded signature with the key in |
| walks a set of Trust Records from the leaf to the root and classifies the chain ( |
| stateless check of a signed agent manifest (v0.2 COSE envelope): vendored schema, profile, canonicalization, embedded signature (Ed25519, P-256, P-384); optional trust record cross-check via |
| how a bernstein run maps onto a TRACE v0.2 Trust Record, claim by claim; pass a receipt to fill in what its journal answers |
| the compliance presets this release ships |
| the agent adapters bundled with this release |
| version and limits |
Same walk as bernstein verify-receipt, reachable from any MCP client or the
paste form at /verify. A verdict's page
address is the receipt's own digest.
Related MCP server: ShipReceipt MCP Server
Trust model
Proves | Does not prove |
the embedded rows are exactly the rows that were signed | that the embedded key belongs to who you think (trust-on-first-use; pin the operator's published key yourself) |
nothing was edited, reordered, dropped or appended after signing | audit-range HMAC values (keyed by the producing install; their linkage and content hash are still checked) |
Pass the receipt file's contents as a string: an already parsed object
cannot tell 1 from 1.0, and the reference hashes the original spelling.
Signed verdicts
Every verdict comes back as a DSSE
envelope (signed_verdict) signed with this deployment's Ed25519 key: the
payload is a JCS-canonical statement naming the receipt by digest, the
verdict, every check, and an appraisal block in the EAR status vocabulary
(affirming / contraindicated / none). Keep it next to the receipt;
anyone can re-check it offline against the public key at
/.well-known/bernstein-mcp/keys.json
(kid = RFC 7638 thumbprint). The signature covers the DSSE PAE of
application/vnd.bernstein.verdict+json, the same construction the receipt
itself uses. It attests that this verifier reached this verdict for these
bytes at this time — nothing about the receipt's producer.
Session receipts
bernstein-attest turns a Claude Code or Codex CLI session into a signed run receipt that this server verifies.
npx bernstein-attest init # registers hooks for both agents (user scope); --claude-code / --codex / --project to narrow
bernstein-attest link # verify link + one Markdown line for a PR description
bernstein-attest verify .bernstein/receipts/<session>.jsonCodex runs project hooks only after they are trusted once with /hooks in an interactive session; codex exec skips untrusted hooks without printing anything. With --project, Claude Code hooks go to .claude/settings.local.json and Codex hooks to .codex/hooks.json; both name the bundle under your home directory, so keep .codex/hooks.json out of version control.
Recorded per tool call: tool name, hashes of its input and output, success flag, repo-relative path for files the call wrote (hash only for paths outside the project), the program name of a shell command (first token, path stripped, at most 32 characters). Not recorded: prompts, model output, command text, file contents, absolute paths. The receipt is sealed at the end of every turn that recorded something new, and every 2 000 rows; the file lives in .bernstein/receipts/ and can be committed with the change it describes. Because later turns reseal the same file, run npx bernstein-attest link right before committing it so the link you paste names the current bytes.
Limits
Request body | 1 MiB |
Rows per chain | 2 000 (larger receipts: verify locally) |
Rate | 60 requests/min per address on |
Logging | one JSON line per request: route, method, status, JSON-RPC method, tool, verdict, producer family, MCP client name/version, country, colo. Never the address, a header, the body or the receipt |
Correctness
vectors/ holds eight golden vectors generated by the Python reference
(scripts/gen_vectors.py against the pinned bernstein source). The
TypeScript verifier must reproduce each vector's verdict, every check, the
binding bytes and the receipt digest byte for byte (test/vectors.test.ts).
vectors/session/ holds three frozen session receipts written by
bernstein-attest (scripts/gen-session-vectors.mjs).
Development
npm install
npm test # no-fetch guard + vitest
npm run typecheck
npm run dev # wrangler devsrc/ may not call fetch, eval or new Function; CI fails otherwise.
Deploying: see DEPLOY.md. Licence: Apache-2.0.
This server cannot be deployed
Maintenance
Related MCP Connectors
Verify before your agent acts on data it paid for. Signed verdicts, checkable offline, via x402.
Issue & verify signed (ed25519), hash-chained, timestamped provenance receipts for agent actions.
Verify VerixID proof-of-existence records and optionally prove ownership.
Post-quantum, tamper-evident receipts for agent actions. Ed25519 + ML-DSA-65, offline verify.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceVerifies signed SAR v0.1 settlement receipts offline using Ed25519 signatures and bundled key registry.-
- AlicenseNot gradedqualityBmaintenanceProvides tools to create, run, and verify deterministic delivery receipts for completion claims, enabling reviewers to check freshness and correctness of evidence.MIT
- AlicenseNot gradedqualityCmaintenanceEnables offline, deterministic verification that one immutable artifact followed a declared build-to-production promotion chain, using only hash-based evidence and failing closed on incomplete or nonconformant gate records.MIT
- AlicenseNot gradedqualityCmaintenanceEnables offline verification that a supplied DSH workflow adhered to declared duty-separation constraints, producing a redacted, content-addressed JSON verdict.MIT