Loading ToolBench
An MCP server that provides database functions for storing and retrieving game statistics. Part of a multi-service system that extracts stats from images and loads them into a database.
The MCP server exposes 3 tools via FastMCP with basic schemas and descriptions, but falls short of production-quality standards. Tool names lack clear action verbs (add_stat_to_db is borderline acceptable, but get_* tools are minimal). Descriptions exist but are generic and lack actionable context. Parameter descriptions are trivial or missing depth. No output schemas are documented. Error handling is absent, no recovery guidance, no error classification, no validation hints. The schema definitions present in code show types (string, int) but lack constraints, enums, format specifications, or validation rules. Tool composition is reasonable (separate read and write operations), but the overall definition quality reflects a prototype rather than a production-grade agent tool.
Add a game stat to the database. using the user_id (not the user_name) of the user
Retrieve user id from the database, by providing the username.
Retrieve all users from the database.
Parameter descriptions are minimal or missing actionable constraints. stat_name, value, user_id lack format hints, validation rules, or examples of valid inputs. LLMs cannot infer whether to pass 'user_123' or 'U12345' for user_id.
No output/return schemas documented. Tool descriptions do not specify what fields the response contains, what structure is returned (JSON object, array, string), or what the agent can chain downstream. add_stat_to_db returns str; get_user_id_by_username returns int; get_users_from_db returns str, but no indication of content or format.
No error handling or recovery guidance. If get_user_id_by_username('invalid_user') fails, the tool provides no hint about what the agent should do next: search for a partial name? Fetch all users first? No error messages are documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Tool descriptions lack actionable context. 'Add a game stat to the database' does not explain when to use this vs. alternatives, what stat_name and value format are accepted, or what the user_id must look like. Descriptions should answer: What? When? Prerequisites?
Input parameter value in add_stat_to_db is typed as 'string' with no constraints. Should stats be numeric? JSON? Free-form text? No validation rules or format specification provided.
get_users_from_db() has no pagination. If the database contains thousands of users, the tool will return all of them, bloating context and risking token exhaustion. No limit, offset, or cursor documented.
Tool composition: get_user_id_by_username returns an int (user_id), but add_stat_to_db expects user_id as string. Type mismatch may force LLM to reason about serialization or fail silently. Output of one tool should align with input signature of downstream tool.
No input validation or error classification documented. If add_stat_to_db is called with a user_id that does not exist, is the error retryable? User-fixable? Fatal? No error responses guide the agent's recovery strategy.