Single tool 'get-metar' has a clear action verb and basic schema with Zod validation. However, the tool lacks critical production-grade features: no output schema documentation, no error recovery guidance, no parameter constraints beyond length validation, and no handling of edge cases (e.g., invalid ICAO codes, API timeouts). The description is adequate (56 chars) but does not explain when to use this tool or what the output structure contains. Parameter description is present but minimal. Error handling returns generic 'Failed to retrieve METAR data' without actionable recovery steps.

• Document the output schema explicitly. Add a TypeScript interface or JSON Schema showing: { metar_id: number, name: string, icaoId: string, temp: number, dewp: number, wdir: string, wspd: number, visib: string, altim: number, rawOb: string }. Include this in tool registration or a separate schema file.
• Enhance error handling with categorized, actionable messages. Example: if metarResponses is empty, return 'ICAO code not found: KBOS. Verify the code is valid (4 uppercase letters). Try a nearby airport.' If fetch fails, return 'Aviation Weather API unavailable (HTTP 503). Retry in 30 seconds.'
• Add input validation with clear feedback. Validate icaoId is exactly 4 letters and uppercase. Return: 'Invalid ICAO code: "kbo", must be exactly 4 uppercase letters (e.g., KBOS, EGLL, RJTT).'
• Expand tool description to 100 - 150 chars explaining purpose and output. Example: 'Fetch current METAR weather data for an airport by ICAO code. Returns temperature, wind, visibility, and altimeter setting. Use to check real-time aviation weather conditions.'
• Add fetch timeout (5 - 10 seconds) and handle timeout errors gracefully. Return: 'Aviation Weather API request timed out. The service may be slow or unreachable. Retry in a few seconds.'