Two tools with complete input schemas and reasonable descriptions. Naming follows verb_noun convention (get_current_weather, get_forecast). Schemas use proper JSON Schema with types, enums, and constraints. However, descriptions are generic (194 chars baseline suggests room for improvement), and output schemas are not documented in the source. Parameter descriptions are present but minimal. No error handling guidance visible. No tool annotations (readOnlyHint, destructiveHint). Missing dependency hints and recovery guidance.

• Document output schemas for both tools. Include field names, types, and what each field represents. Example: 'Returns {city: string, country: string, temp_celsius: number, condition: string, humidity: int, wind_speed: float, visibility: int}'.
• Expand tool descriptions to 100-200 chars. Explain WHAT (current conditions vs forecast), WHEN (use current for now, forecast for planning), and WHAT YOU GET (temperature, wind, humidity, etc.). Example: 'Get current weather conditions (temperature, humidity, wind, visibility) for a location. Use this for immediate conditions; use get_forecast for hourly predictions.'
• Add readOnlyHint: true to both tool schemas to signal safety to LLMs. Update schema registration to include 'readOnlyHint': true in tool metadata.
• Remove example values from parameter descriptions. Replace 'City name (e.g. London,GB or Tokyo)' with 'City name and optional country code (ISO 3166-1 alpha-2, e.g. GB, JP). If omitted, the first match is used.'
• Add error recovery hints in tool descriptions. Example: 'If city is not found, try a larger region (country code) or use lat/lon coordinates instead. If API returns 401, check that WEATHER_API_KEY is set.'

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

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