Single tool with critical definition gaps. Tool name 'get_aviation_weather' follows verb_noun convention (+), but description is minimal (67 chars, below 100-char baseline for clarity). Input schema present with type and description for 'airport' parameter (+), but output schema completely undocumented, tool returns raw response.content (bytes) with no structured schema, violating pattern:tool requirement. No error handling guidance: McpError raised but LLM cannot determine recovery path. No pagination, no result limits, no field documentation. Tool lacks idempotency guarantees and does not strip API metadata.

• Document output schema: define return type as object with fields {airport: string, metar: string, parsed: {wind, visibility, temperature, altimeter, remarks}} or similar. Provide example output.
• Expand tool description to 100 - 150 chars: 'Fetch current METAR aviation weather for an airport. Provide the ICAO code (e.g., KJFK). Returns parsed weather including wind, visibility, temperature, and altimeter setting. Use this to brief pilots or check conditions.'
• Add input validation: constrain 'airport' parameter with pattern '^[A-Z]{4}$' (4 uppercase letters) and description 'ICAO airport code (4 letters, e.g., KJFK, EGLL, RJTT).'
• Improve error handling: catch RequestException and return structured error with recovery hint, e.g., 'Airport XXXX not found. Verify the ICAO code (4 uppercase letters) and try again.' For network timeouts, suggest retry.
• Parse METAR response into structured fields instead of returning raw bytes. Use html2text (already imported) or a METAR parser library to extract wind, visibility, temperature, altimeter, and remarks as separate fields.