
Sign and register statements on a Forestrie log
dev.forestriePublished by forestrie.devv0.3.0Updated Nov 3, 2026
Sign and register statements on a Forestrie log, verify receipts, buy grants via x402 within caps
The publisher's own server: Register.gy
Overview
Signs statements and registers them on a Forestrie transparency log, verifies receipts, and can issue and pay for grants via x402 within caps.
- What you can do
- Sign and register statements: sign a payload (inline base64 or a file path, up to 4 MiB) with the server-held log key and register it on a Forestrie log.
- Check and verify: run a single status check (pending, awaiting seal, sealed), save the receipt once sealed, and verify it over the statement.
- Manage keys and sealing: return the log key's public half and authorise the operator's sealer for a data log.
- Issue and register grants: sign a child data-log grant with the authority key, then register it with canopy, paying its 402 within caps or relaying the payment requirements.
- Guided prompts: register, audit and issue-and-pay walk an agent through the workflow.
- When to use it
- Use it when you need an auditable, signed record of a statement on a Forestrie transparency log, or when you act as requester and must issue and register a child grant, optionally paying the operator's x402 charge.
- Requirements
- Runs locally over stdio via npx, so Node.js is needed. Requires a canopy SCRAPI base URL (FORESTRIE_BASE_URL), the forest root log id, and a Forestrie-Grant (FORESTRIE_GRANT); grant issuing also needs FORESTRIE_AUTHORITY_GRANT, and sealing needs FORESTRIE_COORDINATOR_URL and FORESTRIE_KNOWN_SEALER_KEY. Key files are created on first use under MCP_REGISTER_HOME. Network access to canopy is required.
Installation
In SourceWeft
- Open Sign and register statements on a Forestrie log in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
@forestrie/mcp-register
An MCP server that signs a statement and registers it on a Forestrie transparency log under a Forestrie-Grant, then waits for the seal and verifies the receipt. It can also buy the grant: as the requester, it signs a child grant under your own authority log and registers it with canopy, paying canopy's x402 charge within hard caps. It is the write path of the Forestrie MCP trio:
@forestrie/mcp-verifyverifies receipts offline.@forestrie/mcp-resolvefetches receipts and the material to verify them.- This package writes. It uses the other two as libraries.
The statement is signed with a log key the server holds. The default backend for that key is an ES256 key file the server creates. Child grants are signed with a separate authority key, held the same way. The model never handles signature bytes: you pass the payload and the server signs it. No tool takes a signature or a key as input.
Paying is optional, and the payer is yours. The server never creates a payer key and holds no funds of its own: you choose how payment happens (see Choosing a payer). Whichever you choose, a payer key never crosses the MCP boundary, and the spending caps are configuration, not tool arguments. With no payer configured, the server spends nothing: it returns canopy's payment requirements, and you pay from your own x402 wallet (relay mode).
Status
Version 0.1.1 on npm, published with provenance from publish.yml. 0.1.0 was published by hand and has no provenance attestation; use 0.1.1 or later.
Tools
The prompts walk an agent through the work:
registercovers the key and the grant, sealing, registering, waiting, verifying and keeping the receipt.auditexplains which trust questions a receipt answers under which trust root.issue-and-paycovers buying a grant as the requester: sizing it, issuing it, paying within the caps or relaying the payment, and handing the completed grant to the performer.
Configuration
Every value can be overridden per call.
Choosing a payer
Whoever wants the work done pays for it: the requester, paying canopy directly. The server supports three ways to do that and prefers none of them.
A backend of your own must sign an EIP-3009 authorisation with the nonce it is given. That nonce is what stops one grant being paid for twice (see Payment settings).
Example: a dedicated key file
This is one way to set up the key-file payer, not the way. Any EVM account works; what matters is that it pays for this and nothing else.
-
Create a private key in a file only you can read. Any wallet tool that exports a raw private key will do. With no extra tools:
The server accepts one line,
0xand 64 hex digits, in a regular file (not a symlink) that no other user can read. -
Find the account's address with a tool you already trust to derive one from a private key, or by importing the key into a wallet you use.
-
Fund the address with the asset canopy charges in. On the default network, Base Sepolia, that is testnet USDC, from Circle's faucet. The account needs no ETH: it only signs an authorisation, and the x402 facilitator submits the transfer and pays its gas.
-
Point the server at the file and set the caps:
Keep one account per requester. Payments settle on chain, so anyone can link
a payer address to the grants it paid for. To rotate the key, create a new
one, move what is left to it, and point MCP_REGISTER_PAYER_KEY_FILE at the
new file.
Payment settings
These are read from the environment only. No tool argument can set or raise them.
The server pays only the canopy named in FORESTRIE_BASE_URL, and only for
the request it made. Every payment it signs for a grant uses a nonce derived
from that grant, so the token contract can settle at most one of them: a
retry or two overlapping calls never pay for one grant twice. Each signed
payment is written to the spend ledger before it is sent and counts toward
the daily cap whether or not it settles. The daily cap is approximate when
calls overlap. USDC has 6 decimals, so 10000 is $0.01.
Where grants come from
Forestrie runs no grant issuer. Whoever owns the authority log above yours
issues your grant, naming the key that get_log_key returns. Canopy
sequences grants; it does not issue them.
That owner can be you. If the owner of the root above you creates an
authority log for your authority key (get_log_key with
which: "authority" returns it as a PEM for forestrie-cli's
create-log --auth-log --signer-pem), issue_grant and register_grant
let you issue and register your own child grants. If that authority log
carries the child-payment-required flag, each registration is paid for over
x402, straight to the transparency operator.
Install
Layers
src/coreis browser-safe and works on bytes only.src/netis the only placefetchis called, always through an injectedfetchImpl.src/nodeholds the MCP SDK, stdio, the filesystem, the key files and the payer.
See AGENTS.md.
Licence
MIT.
Source: README.md at commit c6f5745
Tools
0Version history
4- v0.3.0LatestNov 3, 2026
- v0.2.1Oct 20, 2026
- v0.2.0Oct 19, 2026
- v0.1.1Oct 17, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
Other Register integrations
Register.gy
gy.registerOfficial publisher
A remote MCP server for checking, registering and managing .gy (Guyana) domains, and for connecting AI-built websites with preview and undo.
ONRC trade register
com.foreverworks
ONRC trade register's local MCP server, published by foreverworks.com; no sign-in required; STDIO; 9 tools.

US Federal Register Watch MCP
Published by GitHub account donniertf-hub
Remote MCP server that surfaces new US Federal Register rules, proposed rules and notices by keyword or agency, with open comment deadlines.

UK Visa Sponsor Register MCP
Published by GitHub account donniertf-hub
Searches the UK Home Office register of licensed visa sponsors: check an employer, list sponsors by town or route, and track changes.

Zovo Federal Register Digest
Published by GitHub account theluckystrike
Zovo Federal Register Digest's hosted MCP server; no sign-in required; Streamable HTTP; 2 tools.