Loading ToolBench
Collection of Model Context Protocol server implementations demonstrating various patterns including weather data fetching, calculator operations, currency conversion, and project management APIs
This repository is a collection of educational MCP server examples (demonstration, calculator, stdio, money converter, API project server) with 18 tools total, but the tools suffer from severe definition quality issues: (1) massive duplication with inconsistent naming and descriptions across files (add/substract/multiply/divide appear 3-4 times each), (2) minimal or missing parameter descriptions (many tools expose only type information without context or constraints), (3) no output schemas documented anywhere, (4) trivial tool descriptions that do not explain WHEN to use or WHAT the tool returns (e.g., 'add two numbers' vs. 'Add two numbers'), (5) no error handling guidance, and (6) no parameter validation hints or ranges. The fetch-weather tool (00-demostration/server.js) is the only tool with slightly more substance, returning raw JSON from external APIs without shaping. Overall, this reads as educational starter code, not production-ready tool definitions.
Add two numbers
add two numbers
Add two numbers
divide two numbers
Tool a fetch weather of a city
Generate greeting personalized
Generate a personalized greeting
Massive tool duplication across multiple files without clear distinction. Tools named 'add', 'substract', 'multiply', 'divide' appear 3 - 4 times each with inconsistent descriptions ('add two numbers' vs. 'Add two numbers') and varying parameter documentation. This violates the single canonical naming principle and forces the LLM to reason about which variant to use.
9 out of 18 tools have no description or descriptions under 20 characters. Tools 'add' (variant 6 - 9), 'greeting' lack ANY description, violating the fundamental rule that every tool must explain WHAT it does and WHEN to use it. LLMs cannot select these tools without guessing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Generate information about this mcp server
Generate information about this mcp server
multiply two numbers
multiply two numbers
multiply two numbers
substract two numbers
Input parameter descriptions are almost universally missing or trivial. Parameters like 'a', 'b', 'name', 'city' lack context about expected format, range, constraints, or why the parameter exists. Example: 'city' in fetch-weather has no hint about what format is expected (e.g., 'Berlin, Germany' vs. 'Berlin'). Parameter descriptions average ~5 - 10 chars; baseline is 72 chars.
No output schemas are documented for any tool. LLMs cannot plan downstream tool calls or extract required fields (e.g., does fetch-weather return temperature in Celsius or Fahrenheit? Is it a scalar or nested object?). The source code shows raw JSON responses with no schema specification.
Tool descriptions are generic and do not follow the WHAT/WHEN/RETURN pattern. Example: 'add two numbers' tells the LLM the operation but not when to prefer this tool over alternatives, what the output type is, or whether it handles edge cases (division by zero for 'divide'). Baseline descriptions are 194 chars; these average ~20 chars.
No error handling or recovery guidance. The fetch-weather tool has inline error handling (API down, city not found) but returns plain text error messages without actionable next steps (e.g., 'Try search_cities() with a partial match'). Other tools (calculator ops) have no error handling visible.
No enums or constraints on parameters. Parameters like 'city' accept free-form strings with no validation or format guidance. If the LLM passes 'XYZ123' as a city name, fetch-weather will silently fail or return irrelevant results.
Inconsistent naming conventions. 'substract' is misspelled (should be 'subtract'). Mix of camelCase ('get_greeting') and verb_noun ('fetch-weather'). This introduces cognitive load and makes it harder for LLMs to predict tool names.