Critical gaps across all 13 tools. While tool names follow verb_noun convention (validate_intake, calculate_compensation, search_sources), descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Input schemas are present but severely underdeveloped: the 'case' parameter is typed as generic 'object' with minimal constraint; no enums for termination_type or source_types; no min/max bounds on numeric fields. Audit parameters (audit, audit_session_id, audit_db_path, db_path) are repeated across all tools, suggesting poor abstraction. Output schemas are completely undocumented, no indication of what fields are returned or how to chain tools. Error handling is absent from descriptions. No evidence of parameter validation rules, format constraints, or recovery guidance in any tool description.

• Document output schemas for all 13 tools. Specify field names, types, and which fields enable chaining (e.g., if calculate_compensation returns compensation_amount, state that explicitly).
• Replace generic 'case' parameter with a structured schema defining required fields (jurisdiction, parties, employment, wage, dispute). Use JSON Schema properties with type and description for each field.
• Add enums to constrained parameters: termination_type ∈ {economic_layoff, non_fault_dismissal, ...}, source_types ∈ {national, city_rules, ...}, format ∈ {zip, pdf, ...}.
• Expand tool descriptions to 100 - 150 characters. Include: (1) what the tool does, (2) when to call it vs. similar tools, (3) what it returns, (4) any prerequisites. Example: 'Calculate compensation amounts based on case facts and applicable legal rules. Call after validate_intake succeeds. Returns compensation_amount, breakdown_by_category, and applicable_articles.'
• Move audit parameters (audit, audit_session_id, audit_db_path, db_path) to server-level configuration or request metadata (_meta). Reduce tool parameter count and simplify LLM reasoning.