Two tools with basic descriptions but significant schema and parameter documentation gaps. check_invariants_tool has a complex 6-parameter interface with minimal per-parameter descriptions (only 1-2 sentences each). list_invariants_tool is simpler but both lack output schema documentation. No error handling guidance, no enum constraints, no validation rules stated in descriptions. Parameter relationships (suite_path vs policy mutual exclusivity) are undocumented. Naming is adequate (verb_noun pattern) but descriptions lack LLM-optimization depth (194-char baseline for A+ tools; these average ~120 chars). No tool annotations or security considerations visible.

• Add per-parameter descriptions for all 6 parameters in check_invariants_tool. For 'suite_path', specify: 'Path to YAML file (e.g., ./suites/safety.yaml). If missing, policy dict must be provided.' For 'policy', document the required dict structure: '{"field_policies": {...}, "assertions": [...]}'.
• Document the exact output schema for both tools. E.g., check_invariants_tool returns: '{"passed": bool, "invariant_passed": bool, "failures": [{"field": str, "reason": str}]}'. This enables LLMs to extract and chain results.
• Clarify suite_path vs policy mutual exclusivity: 'Provide either suite_path (to load from file) OR policy (inline dict). If both provided, suite_path takes precedence. If neither provided, returns error.'
• Add error recovery hints in descriptions. E.g., 'If invariant fails, review the failures array and adjust model_parsed or final_output. Call list_invariants_tool to inspect field_policies.'
• Expand tool descriptions from ~120 chars to 150-250 chars (A+ baseline). Include WHEN to use each tool: 'Use check_invariants_tool after LLM generates structured output to verify it meets safety constraints before returning to user.'