Loading ToolBench
A demonstration MCP server with mathematical operations (add, subtract, multiply, divide) and weather information tools
This server has fundamental quality gaps across naming, descriptions, schemas, and error handling. While all 5 tools are explicitly defined with basic type information in FastMCP decorators, the descriptions are trivial (10-28 characters), parameter descriptions are minimal, output schemas are undocumented, and there is no error handling or recovery guidance. The divide tool has a type mismatch (declared as returning int but performing float division). No tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present. The server lacks pagination, structured output documentation, and any validation of inputs. Naming is reasonable but generic, 'get_weather' is acceptable but 'divide' should be 'divide_numbers' for consistency with 'add', 'subtract', 'multiply'. Overall, this is a demo-quality server with production readiness far below the baseline of 70+ for recommendation.
Add two numbers
Divide two numbers
Get the weather in a city.
Multiply two numbers
Subtract two numbers
Trivial tool descriptions (10-28 characters) lack context for LLM selection. Descriptions must be 10-1024 chars and explain WHAT the tool does, WHEN to use it, and any prerequisites. Examples: 'Add two numbers' tells the LLM nothing about when or why to use this tool vs. a calculator.
Output schemas are completely undocumented. Tools return integers and strings, but LLMs have no visibility into the structure. The divide() tool declares return type int but actually performs float division (a / b), creating a type mismatch that will cause runtime failures or silent loss of precision.
No error handling or recovery guidance. If divide() is called with b=0, it will raise ZeroDivisionError with no recovery hint for the LLM. Error responses must categorize as retryable/user-fixable/fatal and provide actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. All tools are read-only operations and should declare idempotent=true so agents know they can safely retry without side effects.
Parameter descriptions are absent or minimal. The 'city' parameter in get_weather has no format constraints (e.g., required format, max length), and the numeric parameters (a, b) in math tools have no range documentation. Per the rubric, every parameter must have a non-empty description.
Inconsistent naming convention. Math tools are named 'add', 'subtract', 'multiply', 'divide' but should follow verb_noun pattern like 'add_numbers', 'divide_numbers' for clarity and consistency with get_weather. Bare verbs are ambiguous, does 'divide' divide what?
Type mismatch in divide(): declared to return int but performs float division (a / b). This will always return a float (e.g., 5 / 2 = 2.5), violating the declared schema. Should return float or use integer division (//).
get_weather() is a mock implementation that always returns the same hardcoded string ('The weather in {city} is sunny.'). No real API is integrated, no error handling for invalid cities, and no rate limiting or timeout configuration.