Run offline, read-only Forestrie receipt verification and decoding against a user-chosen trust root with no network, key, or account.
Verify a payload receipt (verify_receipt) against exact registered payload bytes and an entry id, mirroring forestrie verify.
Verify a grant receipt (verify_grant_receipt) against a committed grant or raw grant payload plus entry id, to answer append authority.
Decode a COSE receipt's CBOR to JSON (decode_receipt) without performing any verification.
Select a trust anchor/rung: genesis, known-log-key, known-accumulator, or checkpoint-chain; anchors can be supplied as base64 bytes or local file paths.
Receive mechanical stages (parse, signature, inclusion, binding) and the four trust questions (sealing, split-view, append-authority, attribution) with statuses ok, failed, or not_answered_at_this_rung.
Inspect anchor metadata, diagnostics, and verifier package/version info.
All tools are annotated read-only (readOnlyHint: true) and closed-world (openWorldHint: false), with task execution forbidden.
Provided schema exposes three tools; the README also mentions verify_self, which is not in this schema.
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., "@forestrie-verify verify this receipt against my genesis root"
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.
An MCP server whose only tools verify and decode Forestrie receipts. No backend, no account, no key, no network.
{
"mcpServers": {
"forestrie-verify": {
"command": "npx",
"args": ["-y", "@forestrie/mcp-verify"]
}
}
}npx -y @forestrie/mcp-verify demoAgents act on statements they did not witness being made: a quote, an approval, a tool result, another agent's output. Usually the record of what was said is kept by the party that said it, so nobody downstream can ask "did you really say that, and did you say it to everyone?"
A Forestrie receipt is a proof that a statement was sealed into an append-only transparency log. This package checks that proof against a trust root you hold, in your own process, without contacting Forestrie. With the right root it also answers the harder question: whether the log you were shown is the log everyone else was shown. What transparency adds, where it stops, and what a receipt contains: TRANSPARENCY.md.
Related MCP server: VouchSpec Catalog MCP
Tool | Reference verb | What it answers |
|
| Were these exact payload bytes sequenced at this entry id? |
|
| Was this grant admitted to this log — i.e. was the signer entitled to write? |
|
| Does this package's own release receipt vouch for the bytes it ships? |
|
| What is actually in this receipt? (Renders the CBOR only. Verifies nothing.) |
Every tool is annotated readOnlyHint: true, openWorldHint: false. That is
not decoration: it is the machine-readable form of "this tool touches
nothing", and an agent can see it without running anything.
You do not ask for "verification". You say which root you trust, and the result says what that root can see:
Root | What you supply |
| the forest's genesis document, captured when you registered |
| a log owner key you hold out of band |
| a snapshot of the log's peaks, from a chain read |
| a retained chain of |
The roots are not ordered by strength. The first two check the operator's signature
locally and cannot see a split view. The last two match the peak against an
accumulator the operator does not control, and can. Every result answers
four questions, sealing, split-view, append-authority and
attribution, each ok, failed, or not_answered_by_this_root. The
last is a real answer and must reach the user; a client that renders only
ok is using this tool wrong.
When each root is the effective choice, why a genesis document fetched at check time is weaker than one kept from registration, what a signature root cannot distinguish, and the demo transcript: docs/trust-roots.md.
The root of trust is the univocity checkpoint the receipt chains to, not the package; the package supplies the arithmetic, which any independent implementation can re-run.
Which is why this repo goes to some trouble to make that re-running possible:
A differential test against the published, sha256-pinned forestrie
release binary. For every tamper variant under both signature roots, our ok,
stage, reason and stages[] must equal the reference's byte for byte.
Currently 18 tests, zero disagreements. See
docs/differential-test.md.
Frozen conformance vectors, sha256-pinned to their manifest, shipped inside the tarball. See fixtures/PROVENANCE.md.
files includes src. The package that asks you to trust its
arithmetic ships the arithmetic.
Exact, provenance-attested dependencies — no bundling, so
npm ls and npm audit signatures both see the real graph. Bundling would
hide @forestrie/receipt-verify's own SLSA attestation behind ours.
The verification itself is @forestrie/receipt-verify@1.0.0, which is
published, MIT, and SLSA-attested independently of this package.
At release time, this package also registers its own provenance in a Forestrie log and ships the receipt inside the tarball — two independent trust roots, npm's SLSA provenance and a Forestrie receipt, rather than one circular one. See docs/self-registration.md.
mise install # node 22.14.0, pnpm 10.6.5
pnpm install
pnpm test # browser-safe gate + encoding-copy gate + unit tests
pnpm test:differential # needs the pinned forestrie CLI binary
pnpm buildConventions, invariants and the release checklist: AGENTS.md. Dependency surface and install weight: docs/dependency-surface.md.
MIT.
Render a COSE receipt's CBOR as JSON — headers, named labels, payload, signature and inclusion proof. NO VERIFICATION is performed: a receipt that decodes cleanly may still be invalid. Mirrors forestrie decode-receipt --json.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | the COSE receipt to render |
| Name | Required | Description |
|---|---|---|
| tag | Yes | |
| payload | Yes | |
| inclusion | Yes | |
| protected | Yes | |
| signature | Yes | |
| byteLength | Yes | |
| unprotected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The all-caps NO VERIFICATION disclosure is valuable, non-obvious behavioral context that goes beyond the annotations (which cover read-only/idempotent safety but say nothing about semantics). Adding that clean decoding doesn't imply validity is a strong behavioral caveat. Not a 5 only because it omits output shape details and error behavior on malformed CBOR.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action and output shape, followed by the critical caveat and the CLI mirror. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't enumerate return fields; it still usefully names the rendered components. Annotations cover safety, schema covers params, so the remaining gaps (no-verification semantics, sibling routing) are handled — nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single param (receipt, either b64 or path) is fully documented in the schema, so baseline 3 applies. The description nudges above baseline by clarifying that the receipt is a COSE receipt whose CBOR is being decoded, adding framing for how the param is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (render/decode) and resource (COSE receipt CBOR to JSON), and enumerates exactly what is rendered: headers, named labels, payload, signature, inclusion proof. This clearly distinguishes it from siblings verify_receipt and verify_grant_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the key when-to-use/when-not distinction: it performs NO VERIFICATION, so a clean decode does not imply validity — implicitly routing agents to verify_receipt for validation. This is exactly the disambiguation an agent needs when choosing between decode and verify siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Forestrie grant receipt against the committed grant (Forestrie-Grant COSE Sign1, or raw grant payload CBOR plus an entry id), at a trust rung you choose. Mirrors forestrie verify-grant. This is the tool that answers the append-authority question: the leaf IS the grant.
| Name | Required | Description | Default |
|---|---|---|---|
| trust | Yes | Which anchor you are willing to trust (plan-2609-02 D2/D3) | |
| entryId | No | required when committedGrant is a raw payload | |
| receipt | Yes | the COSE receipt | |
| committedGrant | Yes | Forestrie-Grant COSE Sign1, or raw grant payload CBOR |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| rung | Yes | |
| stage | Yes | |
| anchor | No | |
| reason | No | |
| stages | Yes | the mechanical stages, exactly the reference CLI's contract |
| verifier | Yes | |
| questions | Yes | the four trust questions. 'not_answered_at_this_rung' is a real answer and must be shown to the user, never collapsed into a pass. |
| diagnostics | Yes | named notes about what the arithmetic could not separate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds conceptual context (trust is chosen, leaf-is-grant) but no operational traits like auth needs, rate limits, or failure behavior beyond what the rich schema already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and followed by the distinguishing question. Efficient, with no filler, though the parenthetical enumeration of formats is somewhat dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully documented schema, an output schema covering returns, and rich annotations, the description only needs to establish purpose and the trust model, which it does. Minor gap: no explicit routing against the two sibling verify/decode tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters including the trust rungs and the entryId/committedGrant relationship. The description restates the raw-payload-plus-entry-id case but adds no syntax or format detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify a Forestrie grant receipt against the committed grant') and frames its unique role as 'the tool that answers the append-authority question: the leaf IS the grant.' This differentiates it conceptually from generic verify_receipt/decode_receipt, though it never names those siblings to route the agent explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives implied usage ('at a trust rung you choose', 'mirrors forestrie verify-grant') and clarifies the append-authority context, but offers no explicit when-to-use/when-not guidance or named alternatives among verify_receipt and decode_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Forestrie receipt against the EXACT registered payload bytes and an entry id, at a trust rung you choose. Mirrors forestrie verify. Offline: no network, no key, no account. Returns both the mechanical stages and the four trust questions.
| Name | Required | Description | Default |
|---|---|---|---|
| trust | Yes | Which anchor you are willing to trust (plan-2609-02 D2/D3) | |
| entryId | Yes | 32 lowercase hex: idtimestamp_be8 || mmrIndex_be8 | |
| payload | Yes | the EXACT registered payload bytes whose SHA-256 is the leaf ContentHash | |
| receipt | Yes | the COSE receipt |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| rung | Yes | |
| stage | Yes | |
| anchor | No | |
| reason | No | |
| stages | Yes | the mechanical stages, exactly the reference CLI's contract |
| verifier | Yes | |
| questions | Yes | the four trust questions. 'not_answered_at_this_rung' is a real answer and must be shown to the user, never collapsed into a pass. |
| diagnostics | Yes | named notes about what the arithmetic could not separate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive and openWorldHint=false, so the safety profile is covered. The description still adds real context by spelling out 'no network, no key, no account' and by noting the return includes both mechanical stages and the four trust questions, though the return detail overlaps an existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core action and scope. The final sentence on return contents is the least essential given an output schema exists, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter, fully-covered schema with an output schema present, the description supplies the operational context an agent needs (offline execution, CLI equivalence, trust model) without needing to re-document returns or parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each rung, entryId pattern, and payload/receipt shape is already documented in the schema. The description adds no parameter syntax or format detail beyond 'EXACT registered payload bytes', so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (a Forestrie receipt) plus the exact inputs it binds against (registered payload bytes and an entry id). It never names its siblings verify_grant_receipt or decode_receipt, so the agent must infer the boundary, which keeps this just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys that the operation is offline and mirrors the `forestrie verify` CLI, which implies the context of use, but gives no explicit when-to-use versus verify_grant_receipt or decode_receipt, and no exclusions or prerequisites beyond 'trust rung you choose'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0decode_receiptverify_grant_receiptverify_receiptScored across 3 tools
verify_receipt and verify_grant_receipt both perform verification but target different artifact types (regular receipt vs. grant receipt), and the descriptions clarify the distinction. decode_receipt is clearly separate since it only renders CBOR without verification.
All tool names use snake_case and follow a predictable verb_noun pattern: verify_receipt, verify_grant_receipt, decode_receipt. The longer grant variant remains readable and consistent with the others.
Three tools is a focused, well-scoped set for a verification service, with each tool earning its place. It sits at the low end of the typical 3–15 range, so it is slightly thin but still appropriate.
The server covers the core lifecycle: verifying a standard receipt, verifying a grant receipt, and decoding raw receipt data. Minor gaps exist around batch verification or chain-level checks, but the essential verification surface is present.
Read-only verifier for 25 ProofRelay MCP tools and non-confidential evidence bundles.
Verify Seal AI decision receipts: signed evidence anyone can check, no account needed.
Find governed AI capabilities and verify signed receipts. Read-only, no account.
Read-only Remote MCP for externally grounded AI agent trust receipts.
