HydroWatch defines 7 tools with complete JSON schemas and descriptions. All tools have proper type definitions and parameter constraints (enums, array bounds). Descriptions are domain-specific and actionable (avg ~120 chars). However, output schemas are not documented, LLMs cannot predict response structure for chaining. Parameter descriptions lack guidance on when to use each tool vs. alternatives (e.g., query_wells vs. get_region_stats). No error handling guidance or recovery paths. Tool names follow verb_noun convention well. Missing: idempotency guarantees, pagination guidance, and field-level output documentation.

• Document output schemas for all 7 tools. Include field names, types, and nesting. Example: 'Returns {wells: [{id, location, depth, status, yield_ls, tds_mgl}], total_count, next_cursor}'.
• Add error recovery hints to tool descriptions. E.g., detect_anomalies: 'If well_id not found, call query_wells() to list available wells.'
• Clarify tool selection logic. Add to descriptions: 'Use query_wells for individual well details, get_region_stats for aggregated metrics, analyze_interference for well-pair relationships.'
• Add pagination to query_wells and detect_anomalies. Include limit (default 20, max 100), offset/cursor, and total_count in responses.
• Formalize well_id and parameter constraints as regex patterns or enums in schema. E.g., well_id pattern: '^[A-Z]{2,3}-\d{2}-\d{3}$'.