Eclipse Herald MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HERALD_JWKS | No | Override the path to the exported public JWKS document (default is keys/jwks.json). | |
| HERALD_LEDGER | No | Override the path to the append-only, hash-chained receipts ledger (default is receipts.jsonl). | |
| HERALD_KEY_PATH | No | Override the path to the local signing key file (default is keys/signing-key.json). | |
| HERALD_CARDS_DIR | No | Override 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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
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.
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.
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.
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.