Loading ToolBench
This repository is a learning/class material collection, not a production MCP server. The codebase contains multiple duplicate tool definitions (add and get_weather appear 3 times each) across different files, severe naming conflicts, missing input validation, and inadequate parameter descriptions. Only 3 unique tool types are actually implemented: add, get_weather, and get_crypto_price. Tools lack depth in descriptions (many under 50 chars), have minimal parameter guidance, and no output schema documentation. The crypto tool has a malformed description ('args: name: str' is not a proper docstring). No error handling visible, no recovery guidance, and no indication of idempotency or side effects.
Add two numbers
Get city weather
Duplicate tool definitions across multiple files (add appears 3x, get_weather appears 4x). This creates namespace pollution, makes tool selection ambiguous for LLMs, and suggests incomplete refactoring. Repository structure is chaotic.
Parameter descriptions are missing or trivial. The 'city' parameter in get_weather has description 'City name', which is redundant with the parameter name itself. The 'coin name' in get_crypto_price has description 'Coin name, symbol, or ID' which lists examples but does not explain when to use each form. LLMs cannot infer behavior from these descriptions.
No output schema documentation. Tools return strings (e.g. 'The weather in city X is sunny.') but there is no formal specification of return types, fields, or structure. LLMs cannot plan downstream tool calls without knowing what fields are returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Malformed docstring in get_crypto_price: 'This tool provides real time information for coins args: name: str'. This is not a proper description, it conflates the docstring with an implementation note. Proper description should be: 'Retrieves current price and market data for a cryptocurrency by name, symbol, or ID.'
No error handling or recovery guidance. Code does not validate city names (get_weather uses .lower() and .get() with a fallback string, but no structured error). If a user requests an unsupported city, the response is 'Weather data not available for X', no guidance on which cities ARE available, no suggestion to call get_city_catalog.
Inconsistent naming across get_weather implementations: one file has 'Get city weather' (7 chars), another has 'Returns the current weather for a given city.' (50 chars). LLMs expect consistent metadata for the same logical tool.
No indication of tool side effects or idempotency. All tools marked READ_ONLY, but the repository structure suggests this is auto-inferred from the code, not explicit. There is no @idempotent or @destructive annotation. Agents cannot know whether repeated calls with the same input are safe.