Loading ToolBench
A tutorial project for learning MCP (Model Context Protocol) server development from scratch, covering JSON-RPC over stdio, tool introspection, and async patterns.
This is a tutorial/exercise repository, not a production MCP server. The codebase contains MULTIPLE DUPLICATED TOOLS (add appears 3×, greet appears 3×, celsius_to_fahrenheit appears 3×) across different exercise files. Most tool definitions are either TODO stubs or incomplete implementations. Descriptions are present but minimal (10-50 chars). Input schemas are visible in exercise files but many lack parameter descriptions. The server uses STDIO transport only, which is not remotely accessible. This is educational material demonstrating JSON-RPC over stdio, not a finished MCP server ready for production use.
Add two integers and return the result.
Add two integers and return the result.
Add two integers and return the result.
Add two integers and return the result.
Convert Celsius to Fahrenheit.
Convert Celsius to Fahrenheit.
Convert Celsius to Fahrenheit.
Return a personalised greeting.
Return a personalised greeting.
CRITICAL: Duplicate tool definitions. Tool 'add' appears 3 times, 'greet' appears 3 times, 'celsius_to_fahrenheit' appears 3 times across different exercise files. This indicates incomplete consolidation, test artifacts, or that the repository contains multiple tutorial exercises rather than a single production server. Duplicate tool names will cause registration conflicts and undefined behavior in a real MCP server.
Minimal descriptions for most tools. 'Add two integers and return the result.' (40 chars) and 'Return a personalised greeting.' (35 chars) are below the recommended 50-200 char range. Descriptions lack context for WHEN to use the tool or what distinguishes it from similar tools. 'celsius_to_fahrenheit' is slightly better at 50 chars but still sparse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | 2024-11-05+ | v1 |
Return a personalised greeting.
Input schema parameters lack descriptions. All tools show parameter type definitions (integer, number, string) but no description text explaining what each parameter controls or constraints on valid values. LLMs cannot infer parameter intent from names alone, 'a' and 'b' in the add tool are ambiguous without documentation.
No output schema documented. Tool definitions show input schemas but never document what the tool returns. LLMs cannot plan downstream tool calls or extract required fields without knowing the response structure. E.g., does 'add' return {result: number} or {sum: number, operands: [a, b]}?
Many exercise files contain TODO stubs. 01_the_wire/exercise/server.py has incomplete implementations (send(), handle_initialize(), handle_tools_list(), handle_tools_call(), dispatch(), main() are all marked with TODO). This is intentional for a tutorial but means the server is not functional as-is.
No parameter constraints or enums. Integer parameters 'a' and 'b' in add() have no min/max bounds. Number parameter 'celsius' in celsius_to_fahrenheit has no range constraint (e.g., -273.15°C min for absolute zero). LLMs can pass unreasonable values without validation guidance.
No error handling guidance. Tool implementations do not show error recovery paths. If add() is called with non-integer arguments or celsius_to_fahrenheit() is called with invalid input, no error documentation tells LLMs how to self-correct or what alternatives exist.