Classification Receipt & Appeal Layer

Most tools have clearly distinct targets: registering agents, querying verdicts, verifying receipts vs attestations, assembling appeals, checking alerts, querying panels. The main soft spot is gatekeeper_fetch, whose description ('gatekeeper-double fetch for evidence') is opaque and could be confused with panel_status or verdict_query as an evidence-retrieval path. verify_receipt and verify_attestation are close in name but clearly differentiated by object.

All names are snake_case and readable, but conventions mix: verb_noun (register_agent, verify_receipt), noun_verb (alert_check, verdict_query), and noun_noun (appeal_packet, panel_status, gatekeeper_fetch). There is no single predictable pattern an agent could rely on to infer new tool names.

Eight tools is well within a comfortable range for a verdict/receipt/appeal workflow. Each tool maps to a plausible step (register, query, verify, appeal, monitor), though gatekeeper_fetch's role is unclear enough that it arguably overlaps with other evidence-access tools.

The surface covers the core lifecycle: agent registration, verdict query, receipt/attestation verification, appeal packet assembly, panel policy lookup, and alerting. Gaps exist around appeal status tracking (no tool to check a submitted packet's outcome) and receipt listing/history, but core workflows are reachable.