Loading ToolBench
MCP server for user management with resource and prompt support
Single tool with critical gaps across naming, description completeness, and parameter documentation. The tool 'createuser' lacks parameter descriptions entirely, violating 3 baseline rules. Descriptions present but generic. No error handling guidance for LLM recovery. This server exhibits the 'poor/failing' tier typical of minimal community implementations.
Create a new user from the given parameters
CRITICAL: All parameter descriptions are null. The createuser tool has three parameters (name, email, phone) with zero documentation.
Tool description is generic and lacks actionable context. 'Create a new user from the given parameters' (47 chars) states WHAT but not WHEN or prerequisites. Does not clarify idempotency (timestamps used as ID suggest non-idempotent), prerequisites, or typical usage. Should be 50-200 chars with context.
No output schema documented. Tool returns a simple text success message, but LLM cannot reason about structure for downstream composition. Current code returns role/content object but structure is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Error handling returns unstructured text without recovery guidance. On failure, returns 'Error creating user' + raw error.message. Per pattern:recovery-guide, errors should guide next steps: 'Email already exists. Try search_users() or update_user().' Raw errors give LLM nothing actionable.
Parameter naming lacks type suffixes. 'email' and 'phone' are bare strings without format hints. LLM has no constraint hints.
Destructive tool lacks confirmation/dry-run pattern. createuser writes to users.json without any validation loop or confirmation request. Per pattern:confirmation-request, irreversible operations should support confirmation. Agent mistakes are inevitable.
Tool hints are incomplete/misleading. Schema declares idempotentHint: true, but implementation uses Date.getTime() as ID, each call generates a new ID, making the tool non-idempotent. Hint contradicts behavior.
No input validation. Tool accepts any string for email/phone without format checks. Per pattern:tool-gateway, LLMs often pass invalid data (hallucinated emails, malformed phones). Tool should validate and return 'Invalid email: got "notanemail", must be RFC 5322 format ([email protected])'.