Server has 4 tools with clear, domain-specific purposes (claim verification). All tools have descriptions (50-150 chars, within baseline 34-392 range). Input schemas are present and typed. However, parameter descriptions are minimal or absent for several inputs, and output schemas are not formally documented. Error handling is basic, no recovery guidance or actionable error messages. The deterministic, no-LLM design is sound, but tool composition could be tighter (tier_claim and check_claim overlap in intent).

• Add formal output schema documentation for each tool. Use JSON Schema or TypedDict annotations visible in the code. Example: 'Returns {"tier": str, "verdict": str, "signals": List[Dict], "next_action": str}'.
• Expand parameter descriptions to 50-100 chars each. For 'evidence', write: 'Raw tool output or artifact supporting the claim (e.g., exit code, HTTP status, file content). Leave empty if no evidence yet.' For 'verification_kind', write: 'How the claim was verified: fact, inference, speculation, or tool_output. Guides tier classification.'
• Merge report_templates and tier_definitions into a single 'get_verification_schema' tool that returns both the tier definitions and report template shape in one call. Reduces tool count and simplifies agent planning.
• Add error handling with actionable messages. If evidence is empty and verification_kind is unrecognized, return a clear error: 'Cannot classify tier: evidence is empty and verification_kind is not recognized. Provide either raw tool output (exit code, status, etc.) or specify verification_kind as one of: fact, inference, speculation.'
• Clarify the distinction between tier_claim and check_claim in their descriptions. Suggest: tier_claim for 'full classification with evidence and verdict'; check_claim for 'quick signal scan when you only have the claim text'. Add a note: 'Use check_claim first to flag issues, then tier_claim to classify.'