Weather MCP server has only 2 tools with basic schemas and minimal descriptions. Tool naming follows verb_noun convention (get_alerts, get_forecast), but descriptions lack depth and context. Input schemas are present but parameters have minimal guidance. No output schemas documented. Missing error handling guidance, parameter constraints (enums, ranges), and examples of response structure. Parameter descriptions are single short phrases rather than actionable guidance. No mention of prerequisites, when to use each tool, or what to expect back. Descriptions fall well below the 194-char production baseline.

• Expand get_alerts description to 100+ chars: 'Retrieve active weather alerts for a US state. Use this when the user asks about hazards, warnings, or dangerous conditions. Returns list of alert objects with severity, type, and issued timestamp. Requires 2-letter state code (CA, NY, TX, etc.)'
• Expand get_forecast description similarly: 'Get weather forecast for a specific location. Requires latitude (-90 to 90) and longitude (-180 to 180) in decimal degrees. Returns 7-day forecast with daily high/low, precipitation chance, wind speed. Use when user provides coordinates or after geocoding a city name.'
• Add parameter constraints to state: 'Two-letter US state code in uppercase (e.g., CA, NY, TX). Must be a valid FIPS code.'
• Add parameter constraints to latitude/longitude: 'Latitude: -90 to 90 (decimal degrees). Longitude: -180 to 180 (decimal degrees). Example: 37.7749 (San Francisco).'
• Document expected output schema for each tool. Example for get_forecast: '{"forecast": [{"date": "2024-01-15", "high_f": 72, "low_f": 55, "condition": "Sunny", "precipitation_chance": 0.05}], "location": {"lat": 37.7749, "lon": -122.4194}}'
• Add error handling: 'If state code is invalid, tool returns error with list of valid codes. If coordinates are out of bounds, error specifies valid range. Service timeout returns retryable error with suggested wait time.'
• Add composition note: 'To get alerts after a forecast, use state parameter from forecast response's location, or require user to supply state separately.'