Single tool 'get_weather' has a lengthy description (200+ chars) but lacks critical structure. Input schema is present with basic type info, but parameter description is generic ('City name or zip code'). No output schema is documented, the response structure (location, temperature, humidity, air_quality, condition, usage) is inferred from code, not declared. No error handling guidance. Tool does multiple things (fetch HTML, parse, call LLM, extract data) violating single-responsibility. No parameter constraints (enums, ranges). Naming is acceptable but description undersells the tool's complexity and dependencies.

• Document the complete output schema as a JSON object with typed fields: {location: string, temperature: string, humidity: string, air_quality: string, condition: string, usage: {prompt_tokens: int, completion_tokens: int, total_tokens: int}}.
• Add parameter constraints to 'location': describe expected format (city name, zip code, or 'City, State'), max length, and what happens if ambiguous (e.g., 'Returns weather for the most populous match; use 'City, State' to disambiguate').
• Split tool into smaller, composable pieces: fetch_weather_html (returns raw HTML), extract_weather_data (calls LLM to parse), or keep as single tool but document the multi-step pipeline and all failure modes in the description.
• Add error handling guidance: 'If location is not found, try a nearby city or use 'City, State' format. If OpenAI API fails, retry after 30 seconds. If HTML parsing fails, the location may not have available weather data.'
• Move OpenAI API key to a secure vault or environment variable loaded at startup with validation; never pass credentials as tool parameters. Consider wrapping the API call in a try-except that returns a user-friendly error message instead of a 500 status.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry