Two tools with minimal documentation. getWeatherForecastByLocation has a basic description (54 chars) and properly typed numeric parameters (latitude, longitude as doubles). toUpperCase has a trivial description (34 chars, below 20-char threshold) and a single string parameter. Neither tool has output schemas documented. No error handling guidance, no parameter constraints, no recovery paths. Tool names follow verb_noun convention but descriptions lack context on when/why to use them. Missing: output structure, error cases, rate limits, API dependencies.

• Document output schema for getWeatherForecastByLocation: specify returned fields (temperature, humidity, wind_speed, precipitation, weather_code), their types, and units (Celsius/Fahrenheit, m/s, mm). Include example response.
• Expand getWeatherForecastByLocation description from 54 to 100-150 chars: 'Retrieve weather forecast for a location by latitude/longitude. Returns current conditions and 7-day forecast from Open-Meteo API. Coordinates must be in decimal degrees (-90 to 90 latitude, -180 to 180 longitude).'
• Add parameter constraints: latitude description should state 'Decimal degrees, range -90 to 90'; longitude should state 'Decimal degrees, range -180 to 180'. Add validation error handling for out-of-range values.
• Implement error handling with recovery guidance: 'If coordinates are invalid, return error with valid range. If API is unreachable, suggest retry with exponential backoff. If rate-limited, return 429 with retry-after guidance.'
• Remove or repurpose toUpperCase. If retained for testing, document it as a demo tool and move to a separate 'demo' tool group. If needed for production, expand description and add use cases (e.g., 'Normalize user input for case-insensitive matching').