Weather MCP demonstrates solid fundamentals: all 17 tools have explicit names, descriptions, and input schemas visible in src/config/tools.ts. Naming is consistent (get_*, save_*, list_*, remove_*) and verb-driven. Descriptions are present and adequate (50 - 150 chars typical), though some lack actionable context about when to use them vs. similar tools. Parameter schemas are well-formed with type annotations and brief descriptions. However, output schemas are not documented in the source, a significant gap for an LLM that must plan downstream calls. Error handling details are absent from the tool definitions. The 'location_name' vs 'city_name' vs 'latitude/longitude' pattern appears across many tools (redundancy issue). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible, missing an opportunity to clarify intent.

• Document output schema for every tool. Create a schema definition (or inline documentation) showing field names, types, and descriptions returned by each call. Example: 'Returns: {forecast: [{date: string, temp_high: number, temp_low: number, condition: string}], updated_at: string}'.
• Simplify location parameters. Choose a primary identifier (e.g., city_name) and document fallback behavior. Consider a single overloaded location param that accepts city name, coordinates, or saved location reference, with internal resolution logic.
• Add tool annotations to all tool definitions. Set readOnlyHint: true for get_* and list_* tools; destructiveHint: true for remove_saved_location; idempotentHint: true for tools that have no side effects on repeated calls.
• Expand error descriptions. For tools that can fail (e.g., search_location if no results; check_service_status if a service is down), add a brief error recovery hint in the description. Example: 'If no results, try a broader city name or use coordinates.'
• Document result limits and pagination. Add to search_location and list_saved_locations descriptions: 'Returns up to N results. Use limit parameter to request fewer. Returns total_count for pagination.'
• Clarify mutually exclusive parameters. For tools accepting lat/lon OR city_name OR location_name, add a note: 'Provide one of: city_name, location_name (if saved), or (latitude, longitude). city_name is preferred if ambiguous.'
• Add actionable error messages for edge cases. When a location cannot be geocoded, the error should suggest calling search_location first to find available matches.

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

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