Loading ToolBench
Este projeto é um experimento de utilização e testes de um servidor MCP (Model Context Protocol).
This server exposes 5 CRUD tools for user management via HTTP. Tools have basic descriptions and input schemas with type definitions and constraints (minLength, maxLength, format). However, critical gaps limit production readiness: (1) Descriptions are minimal (10-50 chars) and lack context on WHEN to use each tool or what happens on error; (2) No output schemas documented, LLMs cannot predict response structure for chaining; (3) Parameter descriptions are validation error messages, not usage guidance ('E-mail inválido' vs 'Email address in RFC 5322 format'); (4) No error recovery guidance, tools return HTTP status codes but no actionable next steps; (5) Destructive operations (deleteUser) lack confirmation or dry-run patterns; (6) No pagination support on listUser despite potential for large result sets. Naming is clear (verb_noun pattern) and schemas are present, but descriptions and output documentation are insufficient for reliable LLM tool selection and chaining.
Create a new user with name, email, and password
Delete a user by ID
Get a specific user by ID with their id, name, and email (password excluded)
List all users with their id, name, and email (password excluded)
Update an existing user by ID with optional name, email, and/or password
Descriptions are too short (10-50 chars) and lack context. 'Create a new user with name, email, and password' does not explain WHEN to use this vs other tools, what happens on validation failure, or what the response contains. LLMs cannot reliably select tools with such minimal guidance.
No output schemas documented. Controllers return JSON with 'success', 'message', 'data' fields, but LLMs have no formal schema to predict structure. This breaks tool chaining, after createUser, the LLM cannot reliably extract the new user's ID for downstream calls.
Parameter descriptions are validation error messages ('E-mail inválido', 'A senha deve ter no mínimo 6 caracteres') rather than usage guidance. LLMs need to understand what the parameter controls, not just what makes it invalid. Example: 'Email address in RFC 5322 format (e.g. [email protected])' is actionable; 'E-mail inválido' is not.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
deleteUser lacks confirmation or dry-run pattern. Destructive operations should support a confirmation step to prevent accidental data loss when agents make mistakes. No recovery guidance in error responses.
listUser has no pagination support (limit, offset, page_size parameters). If the user table grows large, returning all users will exhaust context windows and degrade LLM reasoning. Baseline: paginated tools should accept limit (1 - 100, default 20) and offset/cursor.