Hearsay demonstrates solid tool definition quality with complete schemas, detailed descriptions, and clear parameter constraints. All 12 tools have explicit input schemas with proper JSON Schema types and enums. Descriptions are comprehensive (100-300 chars typical), explaining WHAT the tool does and WHEN to use it. Parameter naming follows verb_noun convention (hearsay_status, hearsay_summary). However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Error handling guidance is absent; tools do not indicate what to do on failure. Tool composition is strong: tools chain naturally (suggest_prompts → setup_tracking → run_panel). No security issues detected (no secrets in params). Main gaps: missing output documentation and error recovery guidance.

• Document output schemas for all 12 tools. Include field names, types, and descriptions. Example: hearsay_summary should document {brand_mention_rate: number, confidence_interval: [number, number], recommendation_rate: number, per_provider: object, ...}.
• Add error handling guidance to hearsay_setup_tracking and hearsay_run_panel. Example: 'If setup fails with "duplicate_prompt", the prompt already exists, call hearsay_status to verify. If run_panel returns cost_exceeds_threshold, relay the estimate to the user and retry with confirm:true after approval.'
• Unify parameter naming: change hearsay_answers_search 'provider' enum from [openai, anthropic, gemini, perplexity] to match 'surface' naming (openai-api, anthropic-api, gemini-api, perplexity-api), or document the mapping explicitly.
• Add string length constraints to free-form parameters. Example: category_hint max 100 chars, keywords max 500 chars, name max 50 chars, aliases each 3-50 chars. Document in parameter descriptions.
• Implement dry-run for hearsay_run_panel: add optional 'dry_run: boolean' parameter. When true, return cost estimate without charging. This prevents accidental overspend and aligns with the confirmation-request pattern.