5 tools with mixed quality. Tool names lack consistent verb prefixes (tally, list_claims, sweep_claim, refute_claim, audit_attestors). Descriptions range from adequate (list_claims: 127 chars) to vague (tally: 67 chars). Input schemas present for 4/5 tools but tally lacks visible schema. Parameters have descriptions but lack type constraints (enums for 'deployment' would prevent hallucination). No output schemas documented. Error handling absent, no recovery guidance for failed calls. Security concern: refute_claim accepts a 'confirm' boolean but no mention of PRIVATE_KEY validation or permission gating in tool definition.

• Add explicit enum constraint to deployment parameter: {"type": "string", "enum": ["mainnet", "sepolia"], "description": "Which registry to read: mainnet or sepolia"}
• Document output schema for list_claims: {"type": "object", "properties": {"claims": {"type": "array", "items": {...}}, "nextCursor": {"type": "string"}, "total": {"type": "integer"}}}
• Rename tally to get_tally or read_tally and add input schema (currently missing); clarify what 'both registries have done' means in output
• Add error handling guidance to refute_claim: 'If confirm=true and PRIVATE_KEY is not set, returns error: PRIVATE_KEY_MISSING. If bond is insufficient, returns error: INSUFFICIENT_BOND with required amount.'
• Document pagination limits: 'list_claims returns max 50 claims per page; use nextCursor to fetch subsequent pages. Total claim count available in response.'

Inferred effective spec: 2026-07-28+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained