OpenWeather MCP Server exposes a single tool with adequate naming, description, and input schema. The tool name 'get_current_weather_by_coordinates' clearly indicates the action (get) and the method (by_coordinates), aligning with verb_noun conventions. The description is informative (190 chars) and includes usage context, result interpretation, and field documentation. Input parameters (latitude, longitude, units) are typed and described. However, there are significant gaps: the tool description lacks details on prerequisites (e.g., 'requires valid lat/lon'), no output schema is documented despite mentioning returned fields (location, current, units), no error handling guidance is provided (what happens if coordinates are invalid?), and the tool completely lacks error recovery hints. The baseline for A-grade tools expects 100% of params to have descriptions and documented return types, this server has neither output schema documentation nor comprehensive error patterns. The single tool is competent but not production-grade. Code inspection shows tool is registered via FastMCP decorator but lacks formal output schema definition.

• Add formal output schema documentation. Define the response structure: {location: {latitude: number, longitude: number}, current: {temperature: number, humidity: number, weather_code: number, ...}, units: string}. This enables LLMs to extract fields for downstream reasoning.
• Document error scenarios with recovery hints. E.g., 'If coordinates are invalid (lat must be -90 to 90, lon must be -180 to 180), return error with the constraint violated and suggest valid examples. If API timeout occurs after 10s, this is retryable, suggest retry with exponential backoff.'
• Expand parameter descriptions with validation rules. For 'latitude': 'Latitude coordinate (-90 to 90, negative = south). Required.' For 'longitude': 'Longitude coordinate (-180 to 180, negative = west). Required.' For 'units': 'Units of measurement, metric (Celsius, m/s), imperial (Fahrenheit, mph), or standard (Kelvin, m/s).'
• Add context on when to use this tool vs. alternatives. The server instructions mention a two-step pattern (get coordinates first), but the tool description should reinforce: 'Call only after you have latitude/longitude from a geocoding service. For location names, use a separate geocoding tool first.'
• Consider adding result limits or caching hints in the tool description if results are cached. Current implementation caches weather for 24 hours, document this behavior so LLMs know to expect fresh vs. cached results.

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

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