Loading ToolBench
Single monolithic tool ('AlegraAPI') that violates the core pattern of one-tool-one-responsibility. Tool name lacks action verb (does not start with get_, create_, update_, delete_, search_). Parameter 'queryParams' is dangerously overloaded and accepts any object, defeating type safety. No output schema documentation. Error handling returns raw API errors without recovery guidance. Descriptions are present but generic. Schema uses Zod correctly but parameter descriptions lack specificity about valid values, ranges, and constraints. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite WRITE risk classification.
Una herramienta para interactuar con la API de contabilidad de Alegra. Permite realizar operaciones CRUD en una amplia gama de recursos como Facturas, Contactos, Items, Notas de Crédito, Órdenes de Compra y muchos más.
Tool name 'AlegraAPI' lacks action verb; does not convey what happens when called. Should be named by primary action (e.g., 'call_alegra_api' or split into verb-based tools: 'get_alegra_resource', 'create_alegra_record', 'update_alegra_record', 'delete_alegra_record'). LLMs rely on verb-starting names to infer intent before reading descriptions.
Single tool combines GET, POST, PUT, PATCH, DELETE across 34 endpoint types. Violates one-tool-one-responsibility. Should be split into semantically separate tools: 'get_alegra_invoices', 'create_alegra_invoice', 'update_alegra_contact', etc. This enables agents to compose operations cleanly and makes tool selection unambiguous.
Parameter 'queryParams' accepts z.record(z.union([z.string(), z.any()])), unbounded and type-unsafe. For GET/DELETE, this should be a typed object with specific query param keys (start, limit, query, etc.). For POST/PUT/PATCH, the body structure should match the resource schema (invoice fields, contact fields, etc.). Current implementation forces agents to guess the correct JSON structure, inviting malformed requests.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
No output schema documented. Tool description and code show it returns JSON.stringify(data, null, 2) wrapped in text content, but agents do not know the structure of 'data'. Different endpoints return different shapes (invoice has different fields than contact). Without per-endpoint output schemas, agents cannot reliably extract IDs or chain calls.
Parameter descriptions lack specificity. 'queryParams' description says 'e.g. start, limit, query for GET' but does not state valid ranges, required vs optional, or per-endpoint variations. 'endpoint' description lists all 34 enum values but does not explain what each does or when to use it. Agents must guess or fail. Pattern: tool-description requires WHAT, WHEN, and prerequisites.
Error responses return raw API error messages (e.g., '404 Not Found', API error body) without recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next. E.g., 'Invoice not found. Try search_invoices() with a date range or customer name.' Current implementation: `Error: Error de la API de Alegra: ${response.status} ${response.statusText} - ${errorBody}` provides no actionable next step.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite tool supporting destructive operations (DELETE, POST, PATCH). Tool declared as Risk=WRITE but agents have no indication which endpoint/method combos are destructive. Per pattern:command-tool, tools with side effects must explicitly declare them so agents know which calls are safe to retry.
No pagination support. Tool accepts queryParams including 'start' and 'limit', but no documentation of how pagination works (is it cursor-based? offset-based?), what the response structure is, or how to detect the end of results. Agents cannot safely iterate over large result sets without risking context window exhaustion.
Credentials (ALEGRA_USER, ALEGRA_TOKEN) injected server-side via environment variables (correct), but tool description and prompts do not clarify that users do not need to provide credentials. Agents might attempt to request or log credentials if not explicitly told they are pre-configured.