Loading ToolBench
FastMCP server built on FastAPI that exposes HTTP endpoints as MCP tools via SSE transport
This MCP server exposes 6 FastAPI endpoints as tools via fastmcp. While all tools have names, descriptions, and input schemas are visible in the source code, the quality falls significantly short of production standards. Descriptions are minimal (10-40 chars), often generic platitudes. Parameter descriptions exist but are terse. No output schemas are documented. Error handling relies on generic HTTP exceptions with no guidance for LLM recovery. The tool `save_user` references a client.py file that was not provided, raising questions about tool registration completeness. Overall, this is a C-grade implementation with structural definitions in place but missing the depth, clarity, and error recovery guidance that agents need.
Delete user by email
Get all users
Get user data by email
Health check endpoint
Multiply two numbers
Save user data with email as key
All tool descriptions are critically short (10-40 characters) and lack actionable context. 'Health check endpoint' does not explain WHEN to call it or WHAT it returns. Descriptions must be 50-200 chars and include purpose, return type, and when to use it.
No output schemas are documented. LLMs do not know what fields to expect from tool responses, making downstream chaining and data extraction error-prone. Every tool needs a documented return type (e.g., {status: string, server: string} for health_check).
Error handling is generic and unhelpful. HTTPException(status_code=404, detail='User not found') gives the LLM no guidance on recovery. Should suggest 'Try search_users() with a partial name' or list available users.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Tool `save_user` description is vague: 'Save user data with email as key.' Does not clarify whether this UPDATES an existing user or FAILS if the email already exists. This ambiguity will cause LLMs to misuse the tool.
The `multiply_endpoint` tool name violates verb_noun convention. Should be `multiply_numbers` or `calculate_product`. '_endpoint' is implementation detail, not a behavioral signal for LLMs.
No pagination support on `get_all_users`. Returning all users in a single response risks blowing the LLM context window with large datasets. Should support limit and offset parameters.
Destructive tool `delete_user` has no confirmation or dry-run support. Agents make mistakes, an irreversible deletion should require explicit confirmation before execution.
Tool `save_user` lists 'phone' and 'address' as optional (with defaults None), but the parameter descriptions do not indicate they are optional. LLMs may assume all params are required.