# resolve [Health: Active]

**Category:** 🔑 Cryptography  
**Repository:** https://github.com/forestrie/mcp-resolve  
**GitHub Stars:** 0  
**npm Downloads (last month):** 1036  
**Views:** 6  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/resolve

## Description
Fetches receipts, genesis and accumulator snapshots for @forestrie/mcp-verify and labels provenance

## Tools
Capabilities this server exposes over MCP:

- **fetch_scitt_configuration** — GET {baseUrl}/.well-known/scitt-configuration: the transparency service's self-description (service id, base URL, supported algorithms), returned as JSON. Provenance: fetched. Supports: none of the four questions; this is what the operator says about itself.
- **query_registration** — One GET of {baseUrl}/logs/{bootstrapLogId}/{logId}/entries/{contentHash}, where contentHash is the hex sha256 of the signed statement bytes. Returns pending (with retryAfterMs when the server said so) or the receipt's URL, which includes the massif height, and the entry id. pending is the operator's answer for any content hash its sequencing index does not hold yet, including one that was never registered: the operator does not distinguish the two, so a retry only helps for a statement you know was submitted. receipt-available is the index's answer, not proof the receipt is written: fetch_receipt is the check, and a 404 there is not_found, never pending. Never polls: call again yourself if you want to. Provenance: fetched. Supports: none of the four questions; this is registration status.
- **fetch_receipt** — GET a receipt: either by receiptUrl (as returned by query_registration) or by {baseUrl, bootstrapLogId, logId, massifHeight, entryId}. Returns the receipt bytes base64-encoded, the verifier's decoding of them, and receiptLogId: the log the receipt's delegation certificate names, which is the operator's statement like the rest of the receipt. A 404 is the structured problem not_found carrying the operator's own title (for example 'Entry receipt not found (checkpoint missing)' for a wrong massif height); it is never reported as pending, because a receipt URL the operator holds nothing at does not fill in by waiting. Provenance: fetched. Supports: none on its own; a receipt is the operator's claim, so verify it under a trust root you hold (or use verify_fetched_receipt).
- **fetch_genesis** — GET {baseUrl}/api/forest/{logId}/genesis: the forest's genesis document as CBOR, base64-encoded, with what it carries decoded: the chain binding (univocity contract address, chain id, forest log id) and, for an ES256 forest, the bootstrap public key as bootstrapKeyXy (x‖y hex). Both are read from these bytes, so they stand exactly where the copy stands. For capture: obtain it once, keep it, and pass it as bytes from then on. A copy obtained at check time is not the genesis trust root as intended, and its chain binding and bootstrap key are likewise the operator's claim today; keep the copy from registration, or cross-check them against a source you trust independently. Provenance: fetched. Supports: sealing, as known-log-key with the key this copy carries.
- **fetch_accumulator** — Read the log's published accumulator from the univocity contract at your rpcUrl: eth_chainId, then eth_getBlockByNumber latest, then one eth_call logState(logId) at that block. The contract address and chain id come from a genesis you hold ({genesis, rpcUrl, logId}) or are given explicitly ({rpcUrl, univocity, logId, chainId?}); a chain id mismatch is reported as a problem before any call. Optionally pass forReceipt (the receipt bytes with the registered payload and its entryId, or the committed grant bytes with grant true; bytes base64): if later growth has buried that receipt's peak, so the latest state no longer holds it, the tool walks the contract's CheckpointPublished history backwards within the bounds you set in chain.history and returns the newest checkpoint that holds the peak, saying so in provenance.history; running out of range is a structured problem, history_scan_exhausted. Returns the snapshot CBOR the verifier's known-accumulator root consumes, base64-encoded, with size, block number and block hash. Provenance: chain-read. Supports: split-view under known-accumulator, against the chain rather than the operator; sealing and append-authority by inheritance from the contract's publish-time checks, not by a local signature check.
- **fetch_checkpoint_history** — Read the log's published checkpoints from the univocity contract's CheckpointPublished events at your rpcUrl, newest first, in windows of history.chunkBlocks (default 10000) walking back from the latest block to history.fromBlock, or for at most history.maxBlocks (default 200000): one eth_getLogs per window, never an unbounded scan. The contract address and chain id come from a genesis you hold or are given explicitly, as for fetch_accumulator. Returns each checkpoint's size, accumulator, block number, block hash and transaction hash, plus the same checkpoint as a known-accumulator snapshot (base64) you can keep and later pass to verify_fetched_receipt as supplied bytes; and scannedFrom, scannedTo and the number of requests made. For capture: the contract keeps only its latest state, and a receipt whose peak later growth has buried verifies only against a checkpoint that still holds that peak, so keep the ones you need. Provenance: chain-read. Supports: as fetch_accumulator, split-view under known-accumulator against the chain rather than the operator; sealing and append-authority by inheritance from the contract's publish-time checks, not by a local signature check.
- **fetch_ks256_attestation** — For a receipt whose delegation certificate is signed by a contract KS256 root (a Safe, say): ask the contract whether it accepts that certificate, and return the answer as an attestation @forestrie/mcp-verify can consume offline. Reads the chain at your rpcUrl (this tool does; mcp-verify never does): eth_chainId, eth_getBlockByNumber for your block (default latest), then eth_getCode at the root and one eth_call isValidSignature(digest, signature), where digest and signature come from the receipt's certificate. Both state reads are pinned by the block's hash (EIP-1898, requireCanonical), so the hash in the attestation is the state that was read. Give the receipt, and the root as root (0x 20-byte address) or as a genesis you hold (genesis; it supplies the root when root is absent, which must then be a KS256 bootstrap root, and always supplies the chain the RPC must be on; a chain id mismatch is a problem before any further call). Returns the attestation as canonical CBOR, base64-encoded, with its fields (chain id, root address, digest, signature hash, block number, block hash, magic). Pass it to verify_receipt in mcp-verify as ks256Attestation: it then attests the certificate valid under the contract's signers at block N, which is narrower than an EOA root's offline ecrecover check; anyone with RPC can re-run the call at that block to confirm or disprove it. Refuses, with a structured problem and never an attestation, when there is no contract code at the root (an EOA root verifies by ecrecover and needs none), when the call reverts, or when the return is anything but exactly one 32-byte word, 0x1626ba7e followed by 28 zero bytes (a short return, dirty padding, extra words or an echo of the call's own data are all refused); a malformed chain id, block or hash from the RPC is an rpc_error problem. With root given beside a genesis, root is the contract asked and the genesis supplies only the expected chain (provenance.binding is explicit, chainFrom held-genesis); binding is held-genesis only when the root came from the genesis. Provenance: chain-read. Supports: none of the four questions on its own; the attestation is evidence only once mcp-verify consumes it under a root you hold.
- **verify_fetched_receipt** — Fetch a receipt (as fetch_receipt) and verify it with @forestrie/mcp-verify's core under a trust root you supply as bytes (genesis, keyXy, accumulator, or checkpoints; each {b64} or {path}) or under an accumulator read from the chain in this call ({root: 'known-accumulator', chain: {genesis, rpcUrl, logId?} or {rpcUrl, univocity, logId?, chainId?}}). A genesis fetched in the same call is never the root. The result is the verifier's own: stages, the four questions (sealing, split-view, append-authority, attribution; not_answered_by_this_root is a real answer) and diagnostics, passed through unaltered, plus receipt_fetched_from_operator always and root_read_from_chain when the chain path was taken. If the latest chain state no longer holds the receipt's peak, the chain path walks CheckpointPublished history backwards within the bounds in chain.history (default 200000 blocks in windows of 10000, one eth_getLogs each) and verifies under the newest checkpoint that holds it, adding root_read_from_chain_history; running out of range is the structured problem history_scan_exhausted. The log read is the one you name, in chain.logId or in the receipt coordinates; if the receipt's delegation certificate names a different log, the result adds receipt_log_id_mismatch and the call still uses yours. If you name none, the call uses the certificate's log id and says so in provenance.logId, with source receipt-delegation-certificate. Supply payload bytes and the entry id to have attribution answered. The genesis root's offline walk resolves one delegation hop from the forest root: a receipt from a log further down the grant chain (the verifier's own publications log is a grandchild) fails under a supplied genesis with delegation_invalid, and the result adds genesis_root_reaches_direct_delegates_only to say that this is the walk's limit, not a finding about the receipt; verify such a receipt under known-log-key or known-accumulator.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "resolve": {
    "command": "npx",
    "args": ["-y","@forestrie/mcp-resolve"],
    "env": {
      "FORESTRIE_BASE_URL": "",
      "FORESTRIE_RPC_URL": ""
    }
  }
}
```

**Requires environment variables:** `FORESTRIE_BASE_URL`, `FORESTRIE_RPC_URL` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What resolve does

The resolve MCP server supplies the network-fetched inputs used by `@forestrie/mcp-verify`. It can retrieve a SCITT service configuration, check whether a content hash has been registered, download a receipt, fetch a forest genesis document, and read accumulator state from the associated univocity contract. It can also enumerate published checkpoints and obtain a contract-backed KS256 attestation for a receipt delegation certificate.

The resolve MCP server does not replace the verifier. Fetch operations report where bytes came from and identify which trust-model questions they can support. Operator responses remain operator claims until a verifier checks them under a trust root. Chain reads provide chain-backed evidence, but the returned material still needs to be consumed by the verification workflow.

## How it works

SCITT data is read from a caller-selected `baseUrl`. Registration lookup uses the bootstrap log, target log, and SHA-256 digest of the signed statement bytes. A result can be pending or receipt-available; the tool never polls, and a receipt URL must be checked with `fetch_receipt` before treating the receipt as present. Missing receipts are reported as `not_found`, not as pending.

Genesis data is returned as base64-encoded CBOR with decoded chain binding and, for ES256 forests, the bootstrap public key. Capture and retain the original bytes rather than treating a later fetch as the intended trust root. Accumulators and checkpoints are read through JSON-RPC using the contract and chain binding from a held genesis or explicit parameters. Reads are bounded by configurable history settings, so a lookup cannot scan an unbounded event range.

`verify_fetched_receipt` combines receipt retrieval with `@forestrie/mcp-verify`. It accepts trust material such as a genesis, log key, accumulator, or checkpoint, or it can read an accumulator from the chain. If the latest state no longer contains the receipt's peak, it searches bounded checkpoint history. Payload bytes and an entry ID can be supplied for attribution.

## Setup and configuration

The package requires Node 20.11 or later and runs as a standard stdio MCP process. A typical client launches `npx -y @forestrie/mcp-resolve` and may provide these optional environment variables:

- `FORESTRIE_BASE_URL`: fallback SCRAPI base URL when a tool call omits `baseUrl`.
- `FORESTRIE_RPC_URL`: fallback JSON-RPC endpoint when a chain-reading call omits `rpcUrl`.

Neither value selects a default operator or provider. Calls can provide both URLs explicitly. The RPC endpoint must be on the chain identified by the supplied binding; mismatches are reported before the relevant chain call.

## Tools and capabilities

The resolve MCP server exposes tools for service configuration, registration lookup, receipt retrieval, genesis retrieval, accumulator retrieval, checkpoint-history scans, KS256 contract attestations, and combined receipt verification. `fetch_ks256_attestation` pins its contract reads to a block hash and refuses invalid contract responses rather than producing an attestation. `verify_fetched_receipt` returns verifier stages, diagnostics, provenance, and the four trust-model answers, including explicit not-answered results.

This belongs in the Cryptography category because it handles signed receipts, trust roots, delegation certificates, accumulator snapshots, and attestations. It is suited to agents that need to gather evidence before an offline verifier evaluates sealing, split-view, append-authority, or attribution.

## Limitations and notes

A receipt URL indicates that the registration index has an entry; it is not proof that receipt bytes are available. The operator does not distinguish an unregistered hash from a registration still being indexed. A genesis fetched during verification is not automatically accepted as the trust root.

Genesis-root verification resolves only one delegation hop from the forest root. Receipts from deeper descendants may require a known log key or known accumulator instead. Chain-based verification requires the caller's RPC access and bounded history settings. `fetch_accumulator` and checkpoint history return bytes and metadata, but offline verification remains the responsibility of `@forestrie/mcp-verify`.

_Full upstream README: https://allmcps.com/mcp/resolve/readme_