# Sign and register statements on a Forestrie log (npm · @forestrie/mcp-register)

Sign and register statements on a Forestrie log, verify receipts, buy grants via x402 within caps

- Trust score: 84/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-06

## Components

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

## Channel facts

- Registry: `npm`
- Package: `@forestrie/mcp-register`
- Version: `0.3.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-11-06.

- **Supply Chain Security**: 81/100
  - No malware found by supply-chain analysis.
  - CVE check failed: a known high-severity CVE affects @modelcontextprotocol/sdk 1.30.0, a direct dependency. A fixed version is available.
  - No install/post-install scripts declared.
  - 30 of 116 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-register).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 4 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 74/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 2184 tokens (~312/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**: 67/100
  - Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **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 Sign and register statements on a Forestrie log MCP server?

Sign and register statements on a Forestrie log runs locally as an npm package, launched with npx -y @forestrie/mcp-register. 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-register -- npx -y @forestrie/mcp-register
```

### Cursor

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

### VS Code

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

### Codex

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

### opencode

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

### OpenClaw

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

### Hermes

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

### Netclaw

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

### Vellum

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

### Other

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

## 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-11-05 (score 84, +1)

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

### 2026-11-03 (score 83, +1)

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

### 2026-11-01 (score 82, 0)

- [security regression] Tool safety: pass → unverified
- [security regression] Stability: 0.47 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Schema quality: 100 → unverified
- [functional] Package version: 0.2.1 → 0.3.0

### 2026-10-31 (score 82, +1)

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

### 2026-10-29 (score 81, +1)

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

### 2026-10-28 (score 80, 0)

- [security regression] GHSA-f897-62hf-6gxq affects this package: high

### 2026-10-27 (score 80, +1)

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

### 2026-10-25 (score 79, +1)

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

## MCP tools (7)

### `get_log_key` (~177 tokens)

Get the log key

Return the public half of one of this server's keys (ES256, 64 bytes x‖y, as hex, base64 and an SPKI PEM) and where it lives, creating it on first use. which: "log" (the default) is the key that owns your data log: a grant issuer names it in the grant's grantData, and a grant naming any other key cannot carry statements this server signs. which: "authority" is the requester's key that owns your authority log and signs the grants issue_grant makes. Never returns private key material.

Input parameters:

- `which` (string): which key: "log" (default), the key that owns your data log and signs statements; or "authority", the requester's key that owns an authority log and signs the child grants issue_grant makes

### `register_statement` (~317 tokens)

Sign and register a statement

Sign a payload with the log key and register it under your Forestrie-Grant. Takes the payload bytes (inline base64 or a file path, up to canopy's 4 MiB statement limit) and its content type. The signed statement is saved before it is sent, so the returned content hash always names it, even if the request fails. A payload path may not point at the log key or inside this server's home. Registration is accepted, not yet sequenced: call check_registration next.

Input parameters:

- `baseUrl` (string): the canopy SCRAPI base URL; falls back to FORESTRIE_BASE_URL — never defaulted by the package itself
- `contentType` (string, required): the payload's media type, e.g. application/json
- `grant` (string): the Forestrie-Grant: base64 (standard or URL-safe) of the completed grant, or a path to a file holding it as raw bytes or base64 text; falls back to FORESTRIE_GRANT
- `issuer` (string): CWT iss; defaults to the hex of the key id
- `payload` (required): the payload to sign and register, up to 4 MiB — { b64 } | { base64 } | { path }
- `rootLogId` (string): the forest's root log id (R in /register/{R}/entries); falls back to FORESTRIE_ROOT_LOG_ID
- `subject` (string): CWT sub; defaults to sha-256:<hex of the payload>

### `check_registration` (~142 tokens)

Check a registration

One status check for a registration, by its content hash: pending (not yet sequenced; retry after the given seconds), awaiting_seal (sequenced, entry id known, receipt not yet sealed — sealing takes minutes, and never happens until delegate_sealing has run for the log), or sealed (the receipt is saved and its path returned). Any other answer from canopy is reported as a problem with its reason. canopy answers a statement it never received exactly like a pending one, so after ten minutes of pending this says so. Does not sleep; pace the retries yourself.

Input parameters:

- `contentHash` (string, required): the content hash register_statement returned (64 lowercase hex)

### `verify_registration` (~169 tokens)

Verify a registration's receipt

Verify a sealed registration's receipt over the statement you registered, with @forestrie/mcp-verify's verifier, and return its four-question answers unaltered. By default the trust root is this server's own log key, the root of your data log; verifying never creates a key. Pass a known accumulator (from @forestrie/mcp-resolve's fetch_accumulator) to use a root that can also answer split-view.

Input parameters:

- `contentHash` (string, required): the content hash register_statement returned (64 lowercase hex)
- `knownAccumulator`: optional: a known accumulator (e.g. from @forestrie/mcp-resolve's fetch_accumulator) to verify against instead of this server's own log key — { b64 } | { base64 } | { path }

### `delegate_sealing` (~343 tokens)

Delegate sealing for your log

Authorise the operator's sealer to publish checkpoints for your data log, signed with the log key. Without it entries sequence but are never sealed. If the coordinator has not learned the log's public root, this calls canopy's prepare with the same grant first. Run once per log; the delegation lasts until the returned expiresAt. With as: "authority" it does the same for your authority log, signed with the authority key, so the child grants you register there get sealed.

Input parameters:

- `as` (string): which key owns the log: "log" (default) for your data log, under the grant you register statements with; "authority" for your authority log, under its creation grant (FORESTRIE_AUTHORITY_GRANT), so t…
- `baseUrl` (string): the canopy SCRAPI base URL; falls back to FORESTRIE_BASE_URL — never defaulted by the package itself
- `coordinatorUrl` (string): the delegation coordinator base URL; falls back to FORESTRIE_COORDINATOR_URL
- `grant` (string): the Forestrie-Grant: base64 (standard or URL-safe) of the completed grant, or a path to a file holding it as raw bytes or base64 text; falls back to FORESTRIE_GRANT
- `knownSealerKey` (string): the registrar's voucher key, base64 of 64 bytes x‖y, as the operator publishes it; falls back to FORESTRIE_KNOWN_SEALER_KEY
- `ttlSeconds` (integer): how long the delegation lasts; defaults to the coordinator's suggestion

### `issue_grant` (~245 tokens)

Issue a child grant as the requester

As the requester, sign a child grant with this server's authority key: a data-log creation grant under your authority log (named by your authority grant, FORESTRIE_AUTHORITY_GRANT), naming the performer's log key (by default this server's own) and sized with maxHeight, the batch ceiling canopy prices it by. Saves the grant under a fresh child log id; nothing is sent. Call register_grant next.

Input parameters:

- `grantee` (string): base64 of the 64-byte x‖y the grant names (the performer's log key); defaults to this server's own log key, for a self-purchase
- `logId` (string): the child data log to create; a fresh random UUID by default
- `maxHeight` (integer, required): the grant's batch ceiling. canopy prices a payment-gated child grant as its unit price × maxHeight, so size it to the work it is for
- `parentGrant` (string): your authority grant: the completed grant that created your authority log and names this server's authority key, as base64 or a file path; falls back to FORESTRIE_AUTHORITY_GRANT

### `register_grant` (~366 tokens)

Register a child grant, paying if canopy asks

Register a child grant with canopy (POST /register/{R}/grants, your authority grant as the parent) and follow it to its receipt; call it again with the same logId to resume until it reports complete. If canopy answers 402 and a payer is configured, it pays within the server's hard caps (per call, per UTC day, one network and asset, testnet only by default) and reports any cap that refuses. With no payer it returns the payment requirements: pay them from your own x402 wallet and call again with payment set to the X-PAYMENT value. Every payment for a grant carries a nonce derived from that grant, so retries and overlapping calls can never pay for it twice. When complete it returns the completed grant for delegate_sealing and register_statement.

Input parameters:

- `baseUrl` (string): the canopy SCRAPI base URL; falls back to FORESTRIE_BASE_URL — never defaulted by the package itself
- `grant` (string): a child grant signed elsewhere (base64 or a file path), instead of logId
- `logId` (string): the child log id issue_grant returned: register_grant resumes that grant from wherever the last call reached
- `parentGrant` (string): your authority grant: the completed grant that created your authority log and names this server's authority key, as base64 or a file path; falls back to FORESTRIE_AUTHORITY_GRANT
- `payment` (string): relay mode: the X-PAYMENT header value your own x402 wallet produced for the payment requirements register_grant returned
- `rootLogId` (string): the forest's root log id (R in /register/{R}/grants); falls back to FORESTRIE_ROOT_LOG_ID

## Diagnostics

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

## Score history

- 2026-11-06: 84
- 2026-11-05: 84
- 2026-11-04: 83
- 2026-11-03: 83
- 2026-11-02: 82
- 2026-11-01: 82
- 2026-10-31: 82
- 2026-10-30: 81
- 2026-10-29: 81
- 2026-10-28: 80
- 2026-10-27: 80
- 2026-10-26: 79
- 2026-10-25: 79
- 2026-10-24: 78
- 2026-10-23: 78
- 2026-10-22: 77
- 2026-10-21: 77
- 2026-10-20: 61
- 2026-10-19: 76
- 2026-10-18: 75
- 2026-10-17: 60

## Common questions

### What is the Sign and register statements on a Forestrie log MCP server?

Sign and register statements on a Forestrie log is an MCP server listed in the public MCP registry as dev.forestrie/register. Sign and register statements on a Forestrie log, verify receipts, buy grants via x402 within caps. This page covers its npm package (@forestrie/mcp-register).

### Is the Sign and register statements on a Forestrie log MCP server safe to use?

Sign and register statements on a Forestrie log scores 84 out of 100 on VerifyMCP. We recorded 6 known advisories against it as of 6 November 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 Sign and register statements on a Forestrie log MCP server expose?

Sign and register statements on a Forestrie log exposes 7 tools: get_log_key, register_statement, check_registration, verify_registration, delegate_sealing, and 2 more. Their descriptions and schemas cost roughly 1,759 tokens of context every time the server is loaded.

### Is the Sign and register statements on a Forestrie log MCP server still maintained?

Sign and register statements on a Forestrie log is still listed as active in the MCP registry. We last reached this channel on 6 November 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 Sign and register statements on a Forestrie log MCP server under?

Sign and register statements on a Forestrie log declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

### What did VerifyMCP test on the Sign and register statements on a Forestrie log MCP server?

VerifyMCP ran 16 checks on Sign and register statements on a Forestrie log, covering Malware scan, Known CVEs, Install scripts, Dependency health and 12 more. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

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