Loading ToolBench
An MCP server for Portuguese weather and geophysical data, with stdio and authenticated Streamable HTTP transports.
The server has 6 well-named tools with clear action verbs (get_*). Descriptions are comprehensive and include important context about data sources, limitations, and filtering options. However, several critical gaps reduce the score: (1) Tool #5 (get_weather_stations) and #6 (get_uv_forecast) have empty input schemas with no parameters documented, this violates the requirement that every parameter needs a description; (2) Output schemas are not formally documented anywhere in the visible source code, forcing LLMs to infer response structure; (3) Error handling patterns are not evident in the tool definitions themselves. The naming is solid (avg 20 chars, all verb-first), and descriptions are well-formatted (avg 180 chars, within the 10-1024 char baseline), but the lack of output documentation and some parameter gaps prevent a higher score.
Discover supported forecast locations with stable IPMA identifiers, district IDs and coordinates. Optionally filter by query and districtId. Coverage is limited to the IPMA catalogue.
Get up to ten recent events from the past-30-day feeds. continent and madeira both select the combined mainland/Madeira feed; all also includes the Azores. Times are UTC.
Get UV forecasts for up to three dates and ten locations per date. Includes risk categories, null for missing values and peak intervals in UTC.
Get 1–5 daily forecasts by city or stable locationId. Exact names take precedence; ambiguous partial names return candidates. Use get_locations for supported places; nearby places are never substituted.
Get up to 15 stations with measurements at the latest hourly observation time (UTC). Missing measurements are null in structured data and omitted from text.
Get current and upcoming yellow, orange and red warnings for Portugal. Green and expired entries are excluded; validity times are UTC.
get_weather_stations (#5) and get_uv_forecast (#6) have completely empty input schemas (no properties, empty required array). This violates the parameter documentation requirement. LLMs cannot determine what inputs these tools accept or what constraints apply.
Output schemas are not documented in any tool definition. The descriptions mention what data will be returned (e.g., 'stations with measurements', 'UV forecasts for dates and locations'), but there is no formal response schema documenting the structure of fields, types, or required vs optional fields. LLMs cannot reliably extract or chain results without this.
get_weather_stations (#5) description is vague about what 'measurements' include and what null values mean in structured output. It mentions '15 stations' but does not explain the pagination or how to get more. No constraint on the limit.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
get_uv_forecast (#6) description is terse and does not explain what 'up to three dates and ten locations per date' means structurally. Are dates and locations passed as parameters, or inferred from some context? No input schema makes this ambiguous.
No error handling guidance in tool descriptions. If a tool is called with an invalid city name or locationId, what happens? How should the LLM recover? Descriptions should include recovery hints like 'Use get_locations to discover valid IDs if the call fails.'
get_weather_forecast parameter descriptions reference 'stable locationId' but do not explain what makes it stable or how users should obtain it. Dependency is mentioned ('Use get_locations for supported places') but the schema does not link to that tool.