Skip to main content
Glama
forestrie

forestrie-verify

Official
by forestrie

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
verify_receiptA

Verify a Forestrie receipt against the EXACT registered payload bytes and an entry id, at a trust rung you choose. Mirrors forestrie verify. Offline: no network, no key, no account. Returns both the mechanical stages and the four trust questions.

verify_grant_receiptA

Verify a Forestrie grant receipt against the committed grant (Forestrie-Grant COSE Sign1, or raw grant payload CBOR plus an entry id), at a trust rung you choose. Mirrors forestrie verify-grant. This is the tool that answers the append-authority question: the leaf IS the grant.

decode_receiptA

Render a COSE receipt's CBOR as JSON — headers, named labels, payload, signature and inclusion proof. NO VERIFICATION is performed: a receipt that decodes cleanly may still be invalid. Mirrors forestrie decode-receipt --json.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
golden/grant-genesis.cborThe forest-genesis document for the golden log. The genesis rung's trust root.
golden/grant-receipt.cborA 118-byte detached-payload grant receipt. The receipt the collapse table is about.
golden/burial/burial-receipt.cborA receipt whose peak the log has since buried; re-anchored by the retained chain.
golden/burial/sth-0000.cborOne link of the retained .sth chain the checkpoint-chain rung folds.
golden/burial/sth-0001.cborOne link of the retained .sth chain the checkpoint-chain rung folds.
golden/burial/sth-0002.cborOne link of the retained .sth chain the checkpoint-chain rung folds.
golden/burial/sth-0003.cborOne link of the retained .sth chain the checkpoint-chain rung folds.
golden/manifest.jsonFrozen-bytes manifest: the sha256 digests the pin test asserts, plus the log id, grant data and idtimestamp the committed grant is rebuilt from.
golden/burial/manifest.jsonFrozen-bytes manifest: the sha256 digests the pin test asserts, plus the log id, grant data and idtimestamp the committed grant is rebuilt from.

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation4/5

verify_receipt and verify_grant_receipt both perform verification but target different artifact types (regular receipt vs. grant receipt), and the descriptions clarify the distinction. decode_receipt is clearly separate since it only renders CBOR without verification.

Naming Consistency5/5

All tool names use snake_case and follow a predictable verb_noun pattern: verify_receipt, verify_grant_receipt, decode_receipt. The longer grant variant remains readable and consistent with the others.

Tool Count4/5

Three tools is a focused, well-scoped set for a verification service, with each tool earning its place. It sits at the low end of the typical 3–15 range, so it is slightly thin but still appropriate.

Completeness4/5

The server covers the core lifecycle: verifying a standard receipt, verifying a grant receipt, and decoding raw receipt data. Minor gaps exist around batch verification or chain-level checks, but the essential verification surface is present.