Loading ToolBench
An MCP server that provides weather information and random number generation tools
The server defines 2 tools with visible schemas and descriptions. However, both tools have significant quality gaps: descriptions are minimal (20-30 chars), parameter descriptions lack context about expected formats/ranges, no output schemas are documented, and error handling is absent. GetRandomNumber is a trivial demo tool unsuitable for production. GetCityWeather has external dependencies but no error recovery guidance. The codebase shows proper dependency injection and logging setup, but tool definitions themselves do not meet production quality baselines.
Describes random weather in the provided city.
Generates a random number between the specified minimum and maximum values.
Tool descriptions are too generic and under 50 characters. 'Generates a random number between the specified minimum and maximum values' (GetRandomNumber) and 'Describes random weather in the provided city' (GetCityWeather) do not explain WHEN to use these tools or provide actionable context for LLM selection.
Input parameter descriptions lack constraint information. The 'min' and 'max' parameters in GetRandomNumber state they are integers with defaults, but do not specify valid ranges, whether defaults are inclusive/exclusive, or side effects. The 'city' parameter in GetCityWeather has no documentation of expected format, case sensitivity, or what happens if a city is not found.
No output schemas documented. GetRandomNumber returns an int but the context (is it always positive? what does overflow mean?) is undocumented. GetCityWeather returns a Task<string> formatted as free text, but the exact format, field structure, and whether it can fail are not specified. LLMs cannot reliably parse unstructured string responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Error handling is minimal or absent. GetCityWeather calls external services (city geometry lookup, weather API) but there is no documented error recovery. The code does call response.EnsureSuccessStatusCode() and checks 'if (!root.TryGetProperty(...))' but error messages are generic Exception throws. LLMs receive no guidance on whether to retry, which step failed, or what to do next.
GetRandomNumber is a trivial demo tool (generates random integers) that has no clear real-world use case in a weather MCP server. It violates tool composition principles, adding noise to the tool palette without serving user intent. This tool should be removed or replaced with something weather-relevant.
API credentials are injected via environment variables (appsettings.json + environment variables) which is correct, but there is no documentation in tool descriptions or code comments about how agents should authenticate or what credentials are required. The server silently fails or succeeds depending on config, no clarity for tool users.
No pagination or result limits documented. GetRandomNumber trivially returns one int, but GetCityWeather calls external weather APIs that may return verbose JSON. The code in WeatherService.GetWeatherAsync does extract only temp + description, which is good, but there is no documented limit, no explanation of what fields the response will contain, and no guidance on result size.