Loading ToolBench
An MCP server that provides current weather information for specified locations using the OpenWeather API. Supports multiple transport methods (HTTP, SSE, and stdio-based MCP).
The server implements 2 tools with clear verb_noun naming patterns (get_weather_by_location, health_check) that follow arcade patterns. Tool descriptions are present and adequate (193 and 49 characters respectively). Parameter schemas are visible in the GetToolsList handler and include type declarations and descriptions. However, output schemas are only partially documented with example data structures rather than formal JSON Schema definitions. Error handling exists but lacks recovery guidance. The server properly returns structured responses but does not implement pagination or result limiting guidance despite working with potentially large weather datasets. Security baseline is acceptable (read-only tools, no secrets exposed).
Get current weather information for a specified location (city, country)
Check if the weather service is operational
Output schemas documented informally via example data structures rather than formal JSON Schema with typed properties. The GetToolsList handler shows example weather response structure but does not formally define the schema with property types, required fields, or descriptions.
health_check tool has extremely brief description (49 chars). This is below the production baseline of 194 chars average and provides minimal context for LLM decision-making about when to invoke this tool.
Error responses in executeGetWeatherByLocation return tool errors with error codes and messages (e.g., 'geocoding_error', 'weather_error') but do not provide recovery guidance. LLMs receive no instruction on whether to retry, ask the user, or what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No pagination or result limiting documented despite tools returning potentially large datasets (weather includes many fields: temperature, humidity, pressure, wind data, etc.). Tool descriptions do not mention limits or pagination support.
Parameter 'units' accepts any string value but should be constrained to an enum ('standard', 'metric', 'imperial'). Current implementation accepts arbitrary strings without validation, inviting hallucinated values from LLMs.
Tool composition could be simplified: get_weather_by_location internally calls two separate service methods (GetCoordsByLocationName + GetWeatherByCoords). While acceptable, the tool lacks a discovery pattern showing what location formats are valid or what valid units are before calling.