KNMI Weather server has clear, functional tool definitions with reasonable descriptions and basic input schemas. However, there are significant gaps in output schema documentation, parameter descriptions lack detail, and error handling guidance is minimal. The four tools follow a consistent naming pattern (verb_noun) and all have descriptions, but descriptions are short (24-62 chars, below the 50-200 char optimum for LLM reasoning). Parameter descriptions are present but generic. No tool has documented return types or output schemas. Error handling returns raw strings rather than structured guidance. The server uses HTTP transport (good), but lacks modern MCP protocol features like tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY, and has no per-request logLevel support.

• Document return schema for each tool. Example for get_location_weather: 'Returns dict with keys: temperature (float, Celsius), humidity (int, 0-100), wind_speed (float, km/h), condition (string: clear|cloudy|rainy|snow), timestamp (ISO 8601). Use this data for weather summaries or to trigger alerts.'
• Expand tool descriptions to 50-200 chars and include WHEN/WHY to call. Example: 'Get current weather for a location in the Netherlands. Returns temperature, humidity, wind, condition. Use this before what_is_the_weather_like_in for raw data, or call get_nearest_station first if you have coordinates instead of a city name.'
• Add explicit constraints to all parameters: latitude/longitude range (±90/±180), location format (city/region name in Netherlands), query min/max length. Use JSON Schema properties: minimum, maximum, pattern, minLength, maxLength.
• Replace unstructured error strings with structured error responses. Example: '{"error": "location_out_of_bounds", "message": "Location outside Netherlands", "recovery": "Try a city name within the Netherlands, or use get_nearest_station with coordinates inside the country."}'
• Add tool annotations to schema: mark all tools with 'readOnlyHint: true' in their definitions to signal to LLMs that these are safe, non-destructive calls.
• Rename 'what_is_the_weather_like_in' to 'describe_weather' or 'interpret_weather_data' for brevity and consistency.
• Add pagination to search_location: accept optional 'limit' (1-50, default 5) and 'offset' (0+, default 0) parameters, and return 'total_results' and 'next_offset' in the response to enable multi-page discovery.

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

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