Fetch SCITT receipts and on-chain anchors for offline verification

@forestrie/mcp-resolve

Fetch a SCITT receipt, its log's genesis document and its on-chain accumulator, and hand them to @forestrie/mcp-verify to verify — including the split-view answer, from a chain read. An MCP server that fetches the material the verifier verifies: a receipt, a genesis document, an accumulator snapshot, a registration status, a service configuration. Every result says where its bytes came from and which of the four questions of the trust model they can support. Listed in the MCP registry as dev.forestrie/resolve.

The verifier runs entirely in your process with no network, no account, no key and no backend, and its own rule is that installing it can never imply a network dependency. So anything that fetches lives here.

Use

{

"mcpServers": { "forestrie-resolve": { "command": "npx", "args": ["-y", "@forestrie/mcp-resolve"], "env": { "FORESTRIE_BASE_URL": "https://api-a.forest-2.forestrie.dev", "FORESTRIE_RPC_URL": "https:// " } } } }

Both environment variables are optional and both are yours. baseUrl is any SCRAPI base URL and rpcUrl is your own chain access; a call may pass either explicitly, and the environment values are used only when a call omits them. The package ships no default operator and no default chain provider, and names none.

Two public lanes exist and are examples, not defaults:

Requires Node 20.11 or later.

A worked example: one receipt, end to end

Every value below is public, and the ones that change per release come from the verifier's own tarball. @forestrie/mcp-verify registers each release in a Forestrie log and ships the receipt under fixtures/self/ (docs/self-registration.md there), so the published package is a statement, a receipt, a genesis document and a log owner key that this package can fetch and verify against the live lane. The run below takes about four seconds and ends in split-view ok from a public RPC endpoint, with no key and no account.

To have the tarball at hand in an empty directory:

npm i @forestrie/mcp-verify

ls node_modules/@forestrie/mcp-verify/fixtures/self/ shasum -a 256 node_modules/@forestrie/mcp-verify/fixtures/self/statement.cose

The sequence, with the arguments as JSON and the one-line result each call returned when run on 2026-09-22 against the published 0.5.0 bundle (its entry id is a0caa672b7030b000000000000000001; yours is whatever entry-id.txt says):

1. fetch_scitt_configuration {"baseUrl": "https://api-a.forest-2.forestrie.dev"} → fetched SCITT configuration (serviceId canopy-dev-1) from …/.well-known/scitt-configuration
2. query_registration {"baseUrl": …, "bootstrapLogId": "e22c8d55-3f88-b2b5-f225-5d2c2441bcdd", "logId": "da6f297c-4a0c-4c9a-b2ae-e701e558721d", "contentHash": " "} → registration complete; receipt at https://api-a.forest-2.forestrie.dev/logs/e22c8d55-…/da6f297c-…/14/entries/a0caa672b7030b000000000000000001/receipt — status: "receipt-available", the receiptUrl (with the massif height, 14, inside it) and entryId.
3. fetch_receipt {"receiptUrl": " "} → fetched receipt (438 B) from …/receipt — receipt.sha256 equals the digest of the tarball's receipt.cbor; receiptLogId names the publications log.
4. fetch_genesis {"baseUrl": …, "logId": "e22c8d55-3f88-b2b5-f225-5d2c2441bcdd"} → fetched genesis (160 B) from …/api/forest/e22c8d55-…/genesis: univocity 0xe22c8d553f88b2b5f2255d2c2441bcdd0d50cd58 on chain 84532 — byte-identical to the tarball's genesis.cbor. Keep it: the calls below pass it back as bytes, never fetched in the same call.
5. verify_fetched_receipt {"receiptUrl": …, "entryId": " ", "payload": {"path": "…/fixtures/self/statement.cose"}, "trust": {"root": "known-log-key", "keyXy": {"b64": " "}}} → verify: PASS · root=known-log-key · sealing ok, split-view not answered at this root, append-authority not answered at this root, attribution ok
6. The same call with "trust": {"root": "genesis", "genesis": {"path": "…/fixtures/self/genesis.cbor"}} → verify: FAILED at signature (delegation_invalid) · root=genesis · … This is expected, not tampering: the genesis root's offline walk resolves one delegation hop from the forest root, and the publications log is a grandchild. The result carries genesis_root_reaches_direct_delegates_only saying exactly that. Verify this receipt under a key or an accumulator, as in 5 and 7.
7. verify_fetched_receipt {"receiptUrl": …, "entryId": …, "payload": …, "trust": {"root": "known-accumulator", "chain": {"genesis": {"path": "…/fixtures/self/genesis.cbor"}, "rpcUrl": "https://sepolia.base.org", "logId": "da6f297c-4a0c-4c9a-b2ae-e701e558721d"}}} → verify: PASS · root=known-accumulator · sealing ok, split-view ok, append-authority not answered at this root, attribution ok — anchor.blockNumber, anchor.matchedPeak and provenance.root.from.rpcUrl say which chain state answered. If the log has grown past the receipt's peak since, the same call looks back through published checkpoints and adds root_read_from_chain_history.
8. Optional: fetch_accumulator {"chain": {…as in 7…}, "forReceipt": {"receipt": …, "payload": …, "entryId": …}} returns the snapshot as bytes to keep; later, @forestrie/mcp-verify's verify_receipt under `{"root": "known-accumulator", "accumulator":

}` answers split-view again, offline.

The chain, and where to read it. Step 7 needs JSON-RPC access to chain 84532 (Base Sepolia). This package ships no provider and names none as a default; rpcUrl (or FORESTRIE_RPC_URL) is yours. The endpoints below are third-party public services, listed only as examples of what answered unauthenticated when this example was written; use your own provider for anything beyond a first try.

Two traps. keyXy: {"path": "log-key.xy.b64"} fails: that file is base64 _text_, and path inputs are read as raw bytes — pass its contents as b64. And the byte-field name is b64 in both servers (base64 is accepted here as an alias), so the shapes you learn from the verifier work here unchanged.

test/core/readme-example.test.ts asserts the coordinates in this section against the recorded lane-A fixtures, so a fixture re-capture cannot silently invalidate the example.

The eight tools

fetch_ks256_attestation is for a forest whose root is a contract (a Safe). Such a root cannot be checked by ecrecover, so the verifier needs the contract's own answer, and getting it needs a chain read, which the verifier never makes. Give the tool the receipt and either the root address or a genesis you hold; it reads isValidSignature(digest, signature) at one block (default the latest, then pinned) and returns the answer as a canonical-CBOR attestation:

fetch_ks256_attestation  {receipt: {b64: …}, genesis: {b64: …}, rpcUrl: …, block?: 123}

-> attestation {base64, byteLength, sha256}, fields {chainId, address, digest, signatureHash, blockNumber, blockHash, magic}, provenance, supports verify_receipt {receipt: …, …, ks256Attestation: {b64: }}

The result says the certificate is valid under the contract'