Loading ToolBench
An MCP server that manages user records with tools for creating users, generating fake user data, and accessing user resources. Includes a client for interacting with the server using an LLM.
Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names follow verb_noun convention (create-user, create-user-from-name, create-random-user), which is good. However, descriptions lack depth on WHEN to use each tool and what distinguishes them. Input schemas use Zod but lack descriptions for parameters, the rubric requires 100% of A+ tool params to have descriptions. create-random-user has NO inputSchema property at all (empty object), violating the schema requirement. Error handling is minimal: generic 'failed to save user' messages provide no recovery guidance. No output schema documentation. Annotations present but incomplete (destructiveHint should be true for WRITE operations).
Create a random user with fake data
Create a new user in the database
Create a new user when only a name is provided by generating realistic contact details.
create-random-user has NO inputSchema (empty object {}). This violates pattern:constrained-input and makes the tool's contract unclear.
All three tools lack parameter descriptions in their Zod schemas. Rubric baseline: 100% of A+ tool params have descriptions. LLMs cannot infer what 'name', 'email', 'address', 'phone' mean without explicit guidance (e.g., format, constraints, examples).
Error responses are generic ('failed to save user', 'failed to create user from name'). Per pattern:recovery-guide, errors must tell the LLM what to do next. Current errors provide no recovery path or classification (retryable vs fatal).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Tool annotations mark destructiveHint=false for all three WRITE tools. Per pattern:command-tool, tools that modify state (create, update, delete) must declare destructiveHint=true so agents know these calls have irreversible consequences.
No output schema documented. Rubric baseline: 100% of A+ tools have documented return types. Agents cannot plan downstream calls or extract fields without knowing the response structure (id, name, email, address, phone).