Power your agent
คำสั่งของผู้เผยแพร่เอง ไม่ใช่เอนด์พอยต์ของ PlugMCP
Host a copy with our keys and logs.
npx -y @forestrie/[email protected]Claude Code ไม่มีลิงก์ติดตั้งสำหรับคำสั่งแบบโลคัล ให้คัดลอกคำสั่งด้านล่างแล้วรันในเทอร์มินัล
claude mcp add forestrie-mcp-verify -- npx -y @forestrie/mcp-verify@0.8.1รันในเทอร์มินัล
{ "mcpServers": { "forestrie-mcp-verify": { "command": "npx", "args": [ "-y", "@forestrie/[email protected]" ] } }}claude_desktop_config.json
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดจากผู้เผยแพร่
Verify a SCITT receipt from a Forestrie transparency log under a trust root you hold. Offline: no backend, no account, no key, no network. An MCP server whose only tools verify and decode receipts.
{
"mcpServers": {
"forestrie-verify": {
"command": "npx",
"args": ["-y", "@forestrie/mcp-verify"]
}
}
}
Verify a SCITT receipt under a trust root you hold — offline, no backend, no key, no network
npx -y @forestrie/mcp-verify demo
Agents act on statements they did not witness being made: a quote, an approval, a tool result, another agent's output. Usually the record of what was said is kept by the party that said it, so nobody downstream can ask "did you really say that, and did you say it to everyone?"
A Forestrie receipt is a proof that a statement was sealed into an append-only transparency log. This package checks that proof against a trust root you hold, in your own process, without contacting Forestrie. With the right root it also answers the harder question: whether the log you were shown is the log everyone else was shown. What transparency adds, where it stops, and what a receipt contains: TRANSPARENCY.md.
Every tool is annotated readOnlyHint: true, openWorldHint: false. That is
not decoration: it is the machine-readable form of "this tool touches
nothing", and an agent can see it without running anything.
You do not ask for "verification". You say which root you trust, and the result says what that root can see:
KS256 (secp256k1) roots verify offline too. An EOA root verifies by
ecrecover, from a genesis or a known-log-key with ks256Address. A
contract root (a Safe) cannot be checked without a chain read, which this
package never makes: pass ks256Attestation, an ERC-1271 record fetched
elsewhere (@forestrie/mcp-resolve's fetch_ks256_attestation tool, or
forestrie-cli's fetch-ks256-attestation). The result is then valid
under the contract's signers at the attested block, and says which block.
A 20-byte ks256Address asserts, and does not prove, which log it owns.
checkpoint-chain takes ks256Attestation too, with the KS256 genesis for
the forest chain id; one attestation covers one delegation certificate, so a
Safe that rotated its delegate needs one per certificate: pass them as the
ks256Attestations array. Every attestation is reported in the result as
used, or unused with a reason; none is silently ignored.
checkpoint-chain also enforces each link's delegation limits (mmrStart,
mmrEnd, expiresAt): delegation_out_of_range, delegation_expired.
Since 0.7.0 a peak attached to a receipt is checked against the leaf and
inclusion path rather than trusted (@forestrie/receipt-verify 3.2.0), which
closes a hole in the known-accumulator and checkpoint-chain roots.
Details: docs/trust-roots.md.
The roots are not ordered by strength. The first two check the operator's signature
locally and cannot see a split view. The last two match the peak against an
accumulator the operator does not control, and can. Every result answers
four questions, sealing, split-view, append-authority and
attribution, each ok, failed, or not_answered_by_this_root. The
last is a real answer and must reach the user; a client that renders only
ok is using this tool wrong.
When each root is the effective choice, why a genesis document fetched at check time is weaker than one kept from registration, what a signature root cannot distinguish, and the demo transcript: docs/trust-roots.md.
A receipt means something without assuming the Forestrie operator is honest:
An operator can still decline to act, and that is visible: it can refuse admission, withhold data it serves, or stop sealing. It cannot rewrite or fork anchored history, or sign for a log that has not leased its key. Who holds which key, and what an operator can and cannot do: key custody and operator powers.
Software provenance is the familiar use case for a transparency log, so this
package applies it to itself. Every release registers a small statement
(package name, version, git commit) in a Forestrie log and ships the receipt
inside the tarball. npx -y @forestrie/mcp-verify verify --self, or the
verify_self tool, checks it offline. This complements npm's SLSA
provenance; it does not replace it. Today the receipt chains to a log on the
public development lane. Details:
docs/self-registration.md.
That bundle is also the subject of a worked example: fetching this
package's own release receipt from the public lane, verifying it under the
bundled key, seeing the documented delegation_invalid under the genesis
root, and getting split-view ok from a chain read — end to end in a few
seconds, with no account. It lives in
@forestrie/mcp-resolve's README,
because fetching is that package's job, not this one's.
The verification arithmetic comes from @forestrie/receipt-verify, pinned
to an exact version and published and attested separately. The tarball
ships src and the frozen conformance vectors it is tested against
(fixtures/PROVENANCE.md), so the arithmetic can be
re-run rather than taken on trust.
Installing the package pulls in more than a verifier needs.
@modelcontextprotocol/sdk brings a web stack, including express, hono,
jose, cors and ajv, for HTTP transports this package never uses: it
constructs only the stdio transport. The verification core never imports
the SDK, and the browser-safety gate enforces that, so importing the
package's "." export gives you the arithmetic without any of it.
The tarball ships its fixtures as forestrie://fixtures/… MCP resources,
so an agent that holds nothing of its own can run a real verification.
Two calls reach a pass from resources alone; both are asserted by
test/node/mcp-smoke.test.ts.
A grant receipt at the genesis root — verify_grant_receipt with:
Result: verify-grant: PASS · root=genesis · sealing ok, split-view not answered at this root, append-authority ok, attribution ok.
A payload receipt at an accumulator root, offline, against a real
anchor — verify_receipt with the lane-A bundle
(fixtures/lane-a/PROVENANCE.md): a real
receipt from a public lane and the accumulator the univocity contract had
published for its log at block 46770471, captured by an independent chain
read. (That lane's content was reset on 2026-09-20; the bytes still verify,
the URLs they came from no longer resolve.)
Result: verify: PASS · root=known-accumulator · sealing ok, split-view ok, append-authority ok, attribution ok, with anchor.matchedPeak set.
Unlike the demo's self-derived snapshot, this anchor is the contract's
published state, so the split-view answer is evidence as of that block.
The same receipt passes under {root: "known-log-key", keyXy: {b64: <text of lane-a/log-key.xy.b64>}} and reports delegation_invalid under
{root: "genesis", genesis: lane-a/genesis.cbor}, because its log is a
grandchild of the forest root (docs/self-registration.md).
A resource's bytes are passed back as {b64: <the blob>}; a text
resource such as lane-a/log-key.xy.b64 is base64 text already, so its
text goes in b64 as is. golden/burial/public-key.xy.b64 offers the
burial chain's root key the same way, so checkpoint-chain can be driven
from resources — to its documented negative verdict, since the burial
bundle ships no leaf preimage.
This server is listed as dev.forestrie/verify in the
official MCP registry.
mise install # node 22.14.0, pnpm 10.6.5
pnpm install
pnpm test # browser-safe gate + encoding-copy gate + server.json gate + unit tests
pnpm build
Conventions, invariants and the release checklist: AGENTS.md.
MIT.
Verify a SCITT receipt under a trust root you hold — offline, no backend, no key, no network
{ "mcpServers": { "forestrie-mcp-verify": { "command": "npx", "args": [ "-y", "@forestrie/[email protected]" ] } }}เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก stdio สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ระเบียนนี้ไม่ได้ระบุตัวแปรสภาพแวดล้อมที่จำเป็น
@forestrie/mcp Verify ทำงานแบบโลคัลผ่าน stdio
ตรวจสอบล่าสุดเมื่อ 2026-11-15 Verify a SCITT receipt under a trust root you hold — offline, no backend, no key, no network