The Weather MCP server has 5 tools with clear naming conventions (all verb_noun pattern: get_*, add_*, delete_*). Descriptions are present and reasonably detailed (80-120 chars). Input schemas are well-formed with proper JSON Schema structure, including enums where appropriate (unit parameter). However, there are notable gaps: no output schemas documented, error handling lacks actionable recovery guidance, and some tool descriptions could be more prescriptive about when to use them vs alternatives. Security considerations are partially addressed (OAuth setup visible) but no per-tool permission declarations. Tool composition is sound, each tool has a single responsibility, though the pair (delete_location / delete_all_locations) could benefit from confirmation patterns.

• Document the output schema for get_current_weather. Example: { location: string, temperature: number, unit: string, condition: string, humidity: number, wind_speed: number, pressure: number, cloud_cover: number }
• Document the output schema for get_locations. Specify: returns array of {label: string, location_name: string} with pagination support if needed.
• Add error recovery guidance: if get_current_weather fails with 'not found', suggest checking spelling or calling get_locations() to see available labels.
• Implement a confirm_delete_location() tool or require an explicit --confirm flag in delete_all_locations to prevent accidental data loss.
• Expand delete_location and delete_all_locations descriptions to warn: 'This permanently removes the location and cannot be undone. Requires explicit confirmation.'
• Add permission declarations to each tool: add_location requires 'write:locations', delete_* require 'delete:locations', etc.
• Update get_current_weather description to clarify: 'location can be a city name (e.g., "London") or a saved label (e.g., "home"). If unsure, call get_locations() first.'
• Consider adding a rate limit parameter (or document server-side rate limits) to prevent runaway weather API calls.
• Return location_id or similar in add_location response so agents can immediately use it in delete_location without a lookup.

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

• Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)