Log inSubmit server
Resolve logo

Resolve

Fetches SCITT receipts, genesis and accumulator data for verification with provenance and chain-read evidence.

InstallRepositoryWebsite
Full README Compare alternatives Embed widget Claim this listing

Install Resolve

Pick your client, then add it in one click or paste the config.

STDIONode.js
~/Library/Application Support/Claude/claude_desktop_config.json
claude_desktop_config.json
{
  "mcpServers": {
    "resolve": {
      "command": "npx",
      "args": [
        "-y",
        "@forestrie/mcp-resolve"
      ],
      "env": {
        "FORESTRIE_BASE_URL": "YOUR_VALUE_HERE",
        "FORESTRIE_RPC_URL": "YOUR_VALUE_HERE"
      }
    }
  }
}

Settings → Developer → Edit Config, merge this into mcpServers, then fully quit and reopen Claude Desktop.

Values are written into the snippet above so you can paste it as is. They never leave your browser.

Install not yet sandbox-tested— the server itself is confirmed live (we called its tools/list endpoint). The stdio install command is a separate, ongoing check.

Overview

The resolve MCP server fetches SCITT receipts, registration status, genesis documents, accumulator snapshots, checkpoints, and service configuration. It reads operator endpoints and, for chain-backed evidence, uses a caller-supplied JSON-RPC endpoint to query contract state and events. Results include provenance and distinguish operator claims from chain reads. Reach for it when an agent needs material to pass to @forestrie/mcp-verify, including split-view verification against a known accumulator.

Use cases

  • Fetch a SCITT receipt for offline verification
  • Check registration status without polling
  • Read an on-chain accumulator for split-view verification
  • Capture checkpoint snapshots before later verification
  • Obtain a KS256 contract attestation for a receipt

Key features

  • SCITT configuration and registration lookup
  • Receipt and genesis retrieval
  • On-chain accumulator and checkpoint reads
  • KS256 contract attestation generation
  • Combined receipt fetching and verification
  • Provenance and bounded history reporting

Tools8

What Resolve lets your agent do. Expand a tool for its parameters.

Verified live~7.5k tokens of context

Security & health

What it can reach and how reliably it runs — from our own checks, not the maintainer’s claims.

ActiveLast checked 1d ago

Recent health check succeeded.

9/9 checks healthy over the last 45d

What it can do

From the 8 tools this server returned when we ran it; 8 declare their own safety hints.

Makes network requests · 8Read-only tools · 8
Network at startup3 connections
Files written at startupNone
Install scriptsNone
npm provenanceSigned build
Package age37 days
Maintainers1

Observed 2026-10-21 in an isolated sandbox. A description of reach, not a security audit.

Supply-chain signal

No high-severity advisories surfaced by our automated scan.

Critical 0High 0Medium 0Low 0

Scanned 14d ago via OSV.dev · @forestrie/mcp-resolve (npm)

Adoption & maintenance

Factual signals from GitHub, npm, and our automated checks — not a rating.

npm downloads1kPackage downloads in the last 30 days.
Last commit10d agoMost recent push to the default branch.
Tools exposed8Callable tools this server registers over MCP.
Directory activity6 viewsConfig copies, upvotes, and views on AllMCPs.

How Resolve works

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.

Read the full README View source on GitHub

Reviews

No reviews yet — be the first to share how it worked for you.

Frequently Asked Questions about Resolve

resolve is an MCP server that connects to SCITT operator endpoints and a caller-supplied blockchain RPC. Its main tools fetch receipts, genesis documents, registration status, accumulators, checkpoints, and service configuration, then provide fetched material or chain-backed evidence to @forestrie/mcp-verify for trust-model verification.

Run it through an MCP client with `npx -y @forestrie/mcp-resolve`. The package requires Node 20.11 or later. Configure `FORESTRIE_BASE_URL` and `FORESTRIE_RPC_URL` when you want fallback endpoints, or pass `baseUrl` and `rpcUrl` directly in tool calls.

Yes, resolve can run in Cursor as a standard stdio MCP server. Configure Cursor to launch `npx -y @forestrie/mcp-resolve`; provide the operator base URL and, for chain-reading tools, your own JSON-RPC endpoint.

Use `verify_fetched_receipt` with the receipt coordinates and a supplied trust root, such as genesis, key, accumulator, or checkpoint bytes. It can also read an accumulator from the chain and returns verifier stages, diagnostics, provenance, and the four trust-model answers.

Yes, `fetch_accumulator` and `verify_fetched_receipt` can read the published accumulator through JSON-RPC. They use a held genesis or explicit contract and chain parameters, validate chain identity, and can search bounded checkpoint history when the latest state no longer contains the receipt's peak.

Related MCP servers

All in Cryptography All alternatives
Add a badge to your READMEShow it’s listed — live SVG, Markdown or HTML.

AllMCPs Directory Badge

Full Badge Customizer

Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.

Badge Style:
Live Dynamic SVG PreviewResolve AllMCPs Directory Badge
Markdown (GitHub README)
[![AllMCPs](https://allmcps.com/api/badge/resolve?style=directory)](https://allmcps.com/mcp/resolve)
HTML Embed
<a href="https://allmcps.com/mcp/resolve"><img src="https://allmcps.com/api/badge/resolve?style=directory" alt="Resolve on AllMCPs" /></a>