Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HERALD_JWKSNoOverride the path to the exported public JWKS document (default is keys/jwks.json).
HERALD_LEDGERNoOverride the path to the append-only, hash-chained receipts ledger (default is receipts.jsonl).
HERALD_KEY_PATHNoOverride the path to the local signing key file (default is keys/signing-key.json).
HERALD_CARDS_DIRNoOverride the directory where signed agent cards are written (default is cards/).

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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
card_buildB

Build an A2A v1.0-shaped Agent Card for a hireable CETech face (test-bench, verity-audit, argus-research, silas-engineering) from its template. Unsigned.

card_signB

Build + sign a face's Agent Card with the local signing key (JWS/RS256), write it to cards/, and export the public JWKS. The private key never leaves keys/ (chmod 600).

card_verifyA

Validate a card's schema and verify its JWS signature against the local JWKS. Tampered cards are rejected.

gateway_delegateB

Delegate a task through the governed gateway to a LOCAL test agent (echo, research-stub, silent, injecting): verify card -> certify-check -> mandate (budget cap, expiry) -> dispatch -> quarantine ingest -> receipt-on-delivery. No artifact, no payment.

receipt_listB

Read the hash-chained delegation ledger: mandates, refusals, delivery receipts. Includes chain verification.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 5 tools

Disambiguation4/5

Each tool targets a distinct stage of the card/delegation lifecycle, and gateway_delegate vs receipt_list are clearly separate concerns. The one soft overlap is card_build versus card_sign, since card_sign explicitly also builds the card, making card_build a strict subset step—descriptions disambiguate but an agent could reasonably pick the wrong one for a signed-card need.

Naming Consistency5/5

All names follow a uniform snake_case noun_verb pattern (card_build, card_sign, card_verify, gateway_delegate, receipt_list). The subject-first convention is applied consistently across the whole surface with no style mixing.

Tool Count5/5

Five tools is well-scoped for a narrow domain: card build/sign/verify, one delegation entry point, and one ledger read. Each tool maps to a real step in the pipeline with no filler or redundancy.

Completeness4/5

The core lifecycle (build → sign → verify → delegate → audit via receipts) is fully covered with no dead ends. Minor gaps remain: there is no tool to list/get existing cards from cards/, no key rotation or card revocation, and delegation is restricted to local test agents by design.

Maintenance

ActivityMaintained
ResponsivenessNo issues