Loading ToolBench
MCP server for retrieving weather information, managing favorite cities, and providing weather-based prompts
Three tools with basic schemas and descriptions, but significant quality gaps. All tools have non-empty descriptions (10-20 char baseline met for most), and input schemas are present with typed parameters. However, descriptions lack depth and specificity for LLM decision-making. No output schemas documented. Parameter descriptions are minimal. No error handling guidance. The 'add_favorite_city' tool is undescribed regarding return format and side effects. Missing idempotency hints, state-mutation warnings, and chaining field guidance. Parameter descriptions ('City name (e.g. 'London', 'NewYork')') violate the rule against example values in descriptions, LLMs will reuse these examples literally.
Add a favorite city to list
Get the sunrise and sunset for a city. Returns sunrise and sunset timings.
Get the current weather for a city. Returns temperature and conditions.
Tool name contains 'and': 'get_sunrise_and_sunset_in_EST' combines two distinct operations (sunrise retrieval and sunset retrieval) that should be separate tools. LLMs cannot select between 'get_sunrise' and 'get_sunset' independently, forcing unnecessary computation.
Parameter descriptions include example values ('City name (e.g. 'London', 'NewYork')'), violating the constraint against examples in descriptions. LLMs reuse examples literally, causing failures when actual cities are required.
No output schemas documented. Callers cannot infer the structure of returned data (fields, types, nested objects). This forces LLMs to parse free-text responses, wasting tokens and increasing hallucination risk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Tool 'add_favorite_city' lacks description of its side effects and return value. Description only says 'Add a favorite city to list' without explaining idempotency, error conditions, or response format (success message vs. duplicate handling).
No error handling guidance. API calls can fail (invalid city, API key issues, network errors), but no error descriptions explain what the LLM should do next (retry, ask user, fallback).
Tool 'add_favorite_city' has no destructive or state-mutating hint in its description. LLMs cannot determine if the call is idempotent, reversible, or has side effects. Description should explicitly state: 'Adds or confirms city in favorites list. Idempotent, calling twice with the same city has no additional effect.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in the tool definitions. Modern MCP spec supports these for better agent reasoning about side effects.