MCP server for accessing weather station data from Meteostat API, providing nearby station discovery and hourly weather data retrieval
Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool 1 (get_nearby_stations) has a critical schema error: 'limit' parameter is typed as 'string' but semantically should be 'number'. Both tools lack output schema documentation. Descriptions are present but minimal (10-50 chars), below the 194-char baseline for production tools. No error handling guidance, no parameter constraints (enums, ranges), and no documentation of return structures. Parameter descriptions are generic ('Specify the latitude') and include example values in descriptions, which LLMs tend to reuse literally.
Get nearby stations by latitude and longitude
Get the hourly data for a weather station
Parameter type mismatch: 'limit' in get_nearby_stations is declared as 'string' but should be 'number'. This forces LLMs to pass numeric values as strings, causing API errors.
No output schema documentation. Tools return JSON but LLMs cannot infer the structure of response fields (e.g., what fields are in each station object, what does hourly data contain). This forces LLMs to guess and wastes tokens on exploration.
Descriptions include example values ('39.7492', '-8.8103') which LLMs tend to reuse literally in real calls. Should use formal constraints (min/max bounds) instead.
No parameter constraints documented. 'limit' has no min/max; date parameters have no validation guidance. LLMs can pass absurd values (limit=999999, dates in wrong format).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
No error handling guidance. If API returns 404 (station not found) or 400 (invalid date), handlers return generic 'Failed to retrieve' text. LLMs cannot determine if error is retryable or user-fixable.