@forestrie/mcp-resolve
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FORESTRIE_RPC_URL | No | Optional chain RPC URL. Used only when a call omits it. | |
| FORESTRIE_BASE_URL | No | Optional SCRAPI base URL. Used only when a call omits it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fetch_scitt_configurationA | 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_registrationA | 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. |
| fetch_receiptA | GET a receipt: either by receiptUrl (as returned by query_registration) or by {baseUrl, bootstrapLogId, logId, massifHeight, entryId}. Returns the receipt bytes base64-encoded plus the verifier's decoding of them. 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_genesisA | GET {baseUrl}/api/forest/{logId}/genesis: the forest's genesis document as CBOR, base64-encoded, with the chain binding it carries (univocity contract address, chain id, forest log id) decoded; the bootstrap key stays in the bytes for the verifier's genesis root to read. 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 is likewise the operator's claim today; keep the copy from registration, or cross-check it against a source you trust independently. Provenance: fetched. Supports: sealing, as known-log-key with the key this copy carries. |
| fetch_accumulatorA | 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. 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. |
| verify_fetched_receiptA | 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. Supply payload bytes and the entry id to have attribution answered. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools target distinct resources: configuration, registration status, receipt, genesis, accumulator, and verification. The only overlap is fetch_receipt and verify_fetched_receipt, where the latter fetches and verifies the same receipt, but descriptions clarify the distinction.
All names use lower snake_case with an action_entity pattern. The verbs vary (fetch, query, verify) appropriately, though fetch_ is used for four of six tools, making the pattern mostly predictable.
Six tools is well-scoped for a resolver/verifier that fetches SCITT configuration, registration status, receipts, genesis, accumulators, and verifies receipts. Each tool has a clear, non-redundant role.
The surface covers core fetch and verify operations, but notable gaps exist for a transparency verifier: there is no tool to fetch checkpoints/signed tree heads, public keys (keyXy), or log entries by index. These are referenced as trust roots or verification inputs, so agents may hit dead ends.