Loading ToolBench
A barebones proof-of-concept MCP server demonstrating basic tool registration and execution
Three tools with minimal quality. All have trivial descriptions (10-30 chars, well below the 50-200 char baseline for A+ tools). Two tools (kai_favorite_city, kai_favorite_food) have empty input schemas and no parameters, they are discovery/getter tools but lack context on when/why to call them. The sum tool has typed parameters (int) but zero parameter descriptions, violating the critical rule that every parameter needs a description. No output schemas documented. No error handling guidance. No tool annotations. The server demonstrates basic tool registration but falls far short of production quality.
This function gets Kai's favorite city.
This function gets Kai's favorite food.
Sum three integers.
All tool descriptions are under 20 characters and provide no context on when/why to call them. 'This function gets Kai's favorite city' (30 chars) and 'Sum three integers' (18 chars) lack actionable guidance for LLM selection.
sum tool has three parameters (a, b, c) with no descriptions. LLMs cannot infer that these are integers to be summed or what valid ranges are. Critical rule violation: every parameter needs a description.
No output schemas documented. LLMs do not know what fields to expect from responses, preventing downstream tool chaining and forcing unstructured parsing.
No error handling guidance. Tools return strings but do not document failure modes, recovery steps, or what errors might occur (e.g., if sum overflows).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Tool names lack action verbs. 'kai_favorite_city' and 'kai_favorite_food' are nouns, not verbs. Should be 'get_favorite_city' and 'get_favorite_food' to signal retrieval intent.