Aviation server has 10 tools with complete input schemas and descriptions in German. Naming follows verb_noun pattern (get_*, track_*). However, descriptions are verbose (200-300 chars) and include example values (e.g., 'JFK', 'FRA', 'DLH400') that LLMs may reuse literally. Parameters lack type constraints (enums, ranges, patterns). Output schemas are not documented, critical for agents planning downstream calls. No error handling guidance. All tools are READ_ONLY, reducing risk, but composition could be tighter (e.g., track_live_flights and track_flight overlap in intent).

• Document output schemas for all 10 tools. Specify field names, types, and what data agents can extract. Example: get_airport_info returns {iata_code, icao_code, name, city, country, timezone, latitude, longitude, elevation_ft}.
• Replace example values in descriptions with formal constraints. Use enums for airport codes (iata_code: enum [JFK, FRA, MUC, ...]) or regex patterns (iata_code: /^[A-Z]{3}$/) instead of 'e.g. JFK'.
• Add min/max constraints to numeric parameters. E.g., lamin/lomin/lamax/lomax: -90 to 90 (latitude), -180 to 180 (longitude); limit: 1-200; hours: 1-24.
• Implement error handling with recovery guidance. Catch API errors (401 Unauthorized, 429 Rate Limited, 404 Not Found) and return actionable messages: 'API key missing or invalid. Set AIRLABS_API_KEY environment variable.' or 'Rate limit exceeded. Retry in 60 seconds.'
• Consolidate overlapping flight tracking tools. Rename track_live_flights → search_flights_by_region and track_flight → get_flight_by_callsign to clarify intent and reduce LLM confusion.