Four tools with complete, well-structured schemas and clear descriptions. Tool names follow verb_noun convention (aircraft_near, get_aircraft, find_by_callsign, military_aircraft). Descriptions are detailed (150-250 chars) and explain use cases. All required parameters have type definitions and descriptions. However, output schemas are not formally documented, and error handling lacks recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only operations. Parameter descriptions could specify constraints more formally (e.g., latitude range -90 to 90, radius_nm max 250 mentioned but not in schema).

• Add formal output schema documentation to each tool definition. Example: 'Returns: { count: number, now: number, aircraft: Array<{hex, flight, registration, type, lat, lon, alt_baro_ft, ground_speed_kt, track_deg, vert_rate_fpm, squawk, category, emergency, seen_s}> }'
• Add tool annotations: set readOnlyHint=true and idempotentHint=true on all four tools to signal safe caching and retry behavior.
• Enhance error responses with recovery guidance. Example: 'Invalid hex format. Expected 24-bit ICAO address like "a835af". Call aircraft_near() to discover aircraft first.' instead of raw error codes.
• Add JSON Schema constraints: latitude/longitude with minimum/maximum bounds (-90 to 90, -180 to 180), radius_nm with minimum=0 and maximum=250.
• Document the mapAc() field transformation in tool descriptions so LLMs understand the output field names (alt_baro_ft, ground_speed_kt, etc.) differ from raw API responses.