Verify SCITT receipts from Forestrie transparency logs, offline MCP server

@forestrie/mcp-verify

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"]
    }
  }
}

npx -y @forestrie/mcp-verify demo

Why

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.

What it proves

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.

Trust roots

You do not ask for "verification". You say which root you trust, and the result says what that root can see:

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

Not a trust circle

The root of trust is the univocity checkpoint the receipt chains to, not the

package; the package supplies the arithmetic, which any independent

implementation can re-run.

Which is why this repo goes to some trouble to make that re-running possible:

Shortened. The full README is on GitHub.