Two tools with basic descriptions but significant gaps in schema completeness, parameter documentation, and error handling. setupIndustryDemoData has a clear description (145 chars) but lacks type constraints on array elements and no output schema. scoreAnalysis has minimal description (56 chars, below 20-char floor) and no documented output. Neither tool declares error recovery paths or validates inputs. No tool annotations (readOnlyHint, destructiveHint). Naming is verb-noun compliant but generic. Per-tool average: 42.

• Expand scoreAnalysis description to 100+ chars: 'Analyzes the score breakdown for a previously submitted employee schedule. Returns constraint violations, soft penalties, and optimization opportunities. Requires a valid schedule ID from a prior setupIndustryDemoData or scheduling call.'
• Document output schemas in code comments or JavaDoc. E.g., setupIndustryDemoData returns {schedule_id: string, employee_count: int, shift_count: int}; scoreAnalysis returns {score: string, violations: [{type, count, description}], feasible: boolean}.
• Add enum constraints to array parameters: locations must be 3 items, skills must be 4 items. Document in @ToolArg: 'List of exactly 3 location names (e.g., ["Ambulatory care", "Critical care", "Pediatric care"])'.
• Implement error handling: catch API failures and return structured errors like 'Schedule ID "xyz" not found. Available schedules: [list]. Call setupIndustryDemoData to create a new schedule.'
• Add tool annotations via @Tool: mark scoreAnalysis with readOnlyHint=true; mark setupIndustryDemoData with destructiveHint=true to signal state mutation to the LLM.