seal

The core pair decode_receipt vs verify_receipt is explicitly separated (decode reads fields but does not check the signature; verify checks the signed envelope), and verify_receipt vs verify_evidence_pack is scoped to single receipt vs pack. The only soft overlap is get_sample_receipt vs get_review_pack, both of which surface demo/sample artifacts, and explain_attestation_format is a documentation tool rather than an action, but none of these create real misselection risk.

Nine of ten tools follow a clean verb_noun pattern (decode_receipt, get_public_key, list_my_receipts, verify_evidence_pack, etc.), with get_* and verify_* used predictably for fetch and validation. The single deviation is workspace_summary, which drops the verb and reads as a noun phrase, a minor inconsistency in an otherwise disciplined set.

Ten tools for a receipt verification and transparency service is well-scoped: verification, key retrieval, listing, summary, samples, and format documentation each occupy a distinct slot. Nothing appears redundant enough to cut, and there is no bloat.

The verification lifecycle is largely covered: read, verify, key fetch, list by outcome/policy/model/date, transparency proof, and aggregate summary all exist. Minor gaps remain — there is no tool to fetch or verify a transparency proof directly (only get_transparency_proof to retrieve it), no way to list available policies or issuer key history, and receipt creation is implicitly handled outside the MCP surface.