# dev.forestrie/resolve (npm · @forestrie/mcp-resolve)

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

- Trust score: 81/100 (high trust)
- Change this week: +18
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- npm · `@forestrie/mcp-resolve`: 81/100 (this document), [markdown](https://verifymcp.io/servers/dev-forestrie-resolve/forestrie-mcp-resolve.md), [page](https://verifymcp.io/servers/dev-forestrie-resolve/forestrie-mcp-resolve)

## Channel facts

- Registry: `npm`
- Package: `@forestrie/mcp-resolve`
- Version: `0.2.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 103 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to forestrie/mcp-resolve).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 5 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2920 tokens (~417/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 92% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 7 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the dev.forestrie/resolve MCP server?

dev.forestrie/resolve runs locally as an npm package, launched with npx -y @forestrie/mcp-resolve. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add dev-forestrie-resolve -- npx -y @forestrie/mcp-resolve
```

### Cursor

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

### VS Code

```json
{
  "servers": {
    "dev-forestrie-resolve": {
      "command": "npx",
      "args": [
        "-y",
        "@forestrie/mcp-resolve"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add dev-forestrie-resolve -- npx -y @forestrie/mcp-resolve
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "dev-forestrie-resolve": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@forestrie/mcp-resolve"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add dev-forestrie-resolve --command npx --arg -y --arg @forestrie/mcp-resolve
```

### Hermes

```yaml
mcp_servers:
  dev-forestrie-resolve:
    command: "npx"
    args: ["-y", "@forestrie/mcp-resolve"]
```

### Netclaw

```json
{
  "McpServers": {
    "dev-forestrie-resolve": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@forestrie/mcp-resolve"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add dev-forestrie-resolve -t stdio -c npx -a -y @forestrie/mcp-resolve
```

### Other

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

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-19 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-15 (score 79, +16)

- [security improvement] Malware scan: unverified → pass

### 2026-09-14 (score 63, 0)

- [security regression] Tool safety: pass → unverified
- [security improvement] Malware scan: unverified → pass
- [security] Stability: Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- [functional regression] Schema quality: 337 → 417
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional improvement] Stability: unverified → 0.03
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.1.2 → 0.2.0

### 2026-09-13 (score 63)

First indexed and scored.

## MCP tools (7)

### `fetch_scitt_configuration` (~97 tokens)

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.

Input parameters:

- `baseUrl` (string): any SCRAPI base URL; falls back to FORESTRIE_BASE_URL when omitted — never defaulted by the package itself

Output parameters:

- `configuration`
- `problem` (object)
- `provenance` (object)
- `supports` (object)

### `query_registration` (~191 tokens)

Query registration status

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 and entry id. Never polls: call again yourself if you want to. Provenance: fetched. Supports: none of the four questions; this is registration status.

Input parameters:

- `baseUrl` (string): any SCRAPI base URL; falls back to FORESTRIE_BASE_URL when omitted — never defaulted by the package itself
- `bootstrapLogId` (string, required): UUID (with dashes), or a 16/32-byte hex log id
- `contentHash` (string, required): hex sha256 of the signed statement bytes
- `logId` (string, required): UUID (with dashes), or a 16/32-byte hex log id

Output parameters:

- `entryId` (string)
- `location` (string)
- `problem` (object)
- `provenance` (object)
- `receiptUrl` (string)
- `retryAfterMs` (number)
- `status` (string)
- `supports` (object)

### `fetch_receipt` (~249 tokens)

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. 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).

Input parameters:

- `baseUrl` (string): any SCRAPI base URL; falls back to FORESTRIE_BASE_URL when omitted — never defaulted by the package itself
- `bootstrapLogId` (string): UUID (with dashes), or a 16/32-byte hex log id
- `entryId` (string): 32 lowercase hex: idtimestamp_be8 || mmrIndex_be8
- `logId` (string): UUID (with dashes), or a 16/32-byte hex log id
- `massifHeight` (integer)
- `receiptUrl` (string): as returned by query_registration

Output parameters:

- `decoded`
- `problem` (object)
- `provenance` (object)
- `receipt` (object)
- `receiptLogId` (string)
- `supports` (object)

### `fetch_genesis` (~243 tokens)

Fetch genesis document

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.

Input parameters:

- `baseUrl` (string): any SCRAPI base URL; falls back to FORESTRIE_BASE_URL when omitted — never defaulted by the package itself
- `logId` (string, required): UUID (with dashes), or a 16/32-byte hex log id

Output parameters:

- `bootstrapKeyXy` (string)
- `chainBinding` (object)
- `genesis` (object)
- `problem` (object)
- `provenance` (object)
- `supports` (object)

### `fetch_accumulator` (~430 tokens)

Fetch accumulator from chain

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.

Input parameters:

- `chain` (required): The forest's chain binding: from a genesis you hold, or given explicitly. Never defaulted, never taken from a fetched genesis, never read from the environment except rpcUrl.
- `forReceipt` (object): The receipt this snapshot must hold the peak of: receipt (base64) with the exact registered payload (base64) and its entryId, or with grant true and payload set to the committed grant bytes. These ar…

Output parameters:

- `accumulator` (object)
- `latest` (object)
- `problem` (object)
- `provenance` (object)
- `snapshot` (object)
- `supports` (object)

### `fetch_checkpoint_history` (~295 tokens)

Fetch checkpoint history from chain

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.

Input parameters:

- `chain` (required): The forest's chain binding: from a genesis you hold, or given explicitly. Never defaulted, never taken from a fetched genesis, never read from the environment except rpcUrl.

Output parameters:

- `chainBinding` (object)
- `checkpoints` (array)
- `problem` (object)
- `provenance` (object)
- `requests` (number)
- `scannedFrom` (number)
- `scannedTo` (number)
- `supports` (object)

### `verify_fetched_receipt` (~578 tokens)

Fetch and verify 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) 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.

Input parameters:

- `baseUrl` (string): any SCRAPI base URL; falls back to FORESTRIE_BASE_URL when omitted — never defaulted by the package itself
- `bootstrapLogId` (string): UUID (with dashes), or a 16/32-byte hex log id
- `entryId` (string): required for payload verification; optional for a COSE grant, required for a raw grant payload
- `grant` (boolean): true to verify a grant receipt (verifyGrantReceipt) instead of a payload receipt
- `logId` (string): UUID (with dashes), or a 16/32-byte hex log id
- `massifHeight` (integer)
- `payload`: the exact registered payload (payload verification), or the committed grant bytes when grant:true
- `receiptUrl` (string): as returned by query_registration
- `trust` (required): Which trust root to verify under: bytes you supply (genesis, keyXy, accumulator, checkpoints), or {root:'known-accumulator', chain:…} to read the accumulator from the chain in this call. Never a gene…

Output parameters:

- `anchor`
- `courier`
- `diagnostics` (array)
- `latest`
- `ok` (boolean)
- `problem` (object)
- `provenance` (object)
- `questions`
- `reason` (string)
- `root` (string)
- `stage` (string)
- `stages` (array)
- `supports` (object)
- `verifier`

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/dev-forestrie-resolve/forestrie-mcp-resolve#diagnostics

## Score history

- 2026-09-20: 81
- 2026-09-19: 81
- 2026-09-18: 80
- 2026-09-17: 80
- 2026-09-16: 79
- 2026-09-15: 79
- 2026-09-14: 63
- 2026-09-13: 63

## Common questions

### What is the dev.forestrie/resolve MCP server?

dev.forestrie/resolve is an MCP server listed in the public MCP registry as dev.forestrie/resolve. Fetches receipts, genesis and accumulator snapshots for @forestrie/mcp-verify and labels provenance. This page covers its npm package (@forestrie/mcp-resolve).

### Is the dev.forestrie/resolve MCP server safe to use?

dev.forestrie/resolve scores 81 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the dev.forestrie/resolve MCP server expose?

dev.forestrie/resolve exposes 7 tools: fetch_scitt_configuration, query_registration, fetch_receipt, fetch_genesis, fetch_accumulator, and 2 more. Their descriptions and schemas cost roughly 2,083 tokens of context every time the server is loaded.

### Is the dev.forestrie/resolve MCP server still maintained?

dev.forestrie/resolve is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the dev.forestrie/resolve MCP server under?

dev.forestrie/resolve declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@forestrie/mcp-resolve
- Socket report: https://socket.dev/npm/package/@forestrie/mcp-resolve
- Repository: https://github.com/forestrie/mcp-resolve
- Changelog RSS feed: https://verifymcp.io/servers/dev-forestrie-resolve/forestrie-mcp-resolve.xml
- Changelog JSON feed: https://verifymcp.io/servers/dev-forestrie-resolve/forestrie-mcp-resolve.json
- HTML version of this page: https://verifymcp.io/servers/dev-forestrie-resolve/forestrie-mcp-resolve