Loading ToolBench
This server has 4 database tools with explicit schemas and basic descriptions, but falls significantly short of production quality. Tool names are clear and verb-driven (connect-, disconnect-, execute-), and input schemas use Zod with proper type definitions. However, descriptions are minimal (10-40 chars), completely lack parameter-level descriptions in the Zod schemas, output schemas are undocumented, and error handling provides no recovery guidance. The tool set lacks pagination support, has no idempotency guarantees, returns unstructured text responses instead of structured JSON, and provides no security documentation around credential handling or permission gates. None of the tools declare permissions or destructive hints. This is a functional but rough implementation typical of early-stage community servers.
Connect to a database
Disconnect from a database
Execute a SQL query on the connected database
Execute an update/insert/delete on the connected database
Parameter descriptions missing in Zod schemas. While Zod types are declared (z.string(), z.enum()), they lack descriptions. LLMs cannot infer parameter semantics from names alone: 'connectionId' could mean a UUID, a user-facing label, or an internal identifier. The Zod schema for 'connect-database' shows z.string() and z.enum([...]) with no description field, violating the pattern that every parameter must be documented.
Output schemas are completely undocumented. All four tools return a hard-coded structure {content: [{type: 'text', text: '...'}], isError?: true} but this structure is not declared anywhere. LLMs have no way to know what fields to expect, preventing downstream tool chaining and forcing the LLM to parse unstructured text responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 12 | - | v1 |
Tool descriptions are between 10 - 40 characters and provide no context for when to use each tool or what to expect. 'Execute a SQL query on the connected database' (40 chars) is the longest; 'Connect to a database' (20 chars) is typical. Per the rubric baseline, descriptions should be 50-200 chars and answer: what does it do, when to use it, and what it returns. Current descriptions omit context, prerequisites, and distinguishing factors between similar tools.
No credential/secret handling documentation. The 'connect-database' tool references 'this.processConfig(type)' which merges environment variables, but the implementation is not visible and there is no documentation of how credentials are injected, stored, or protected. The pattern requires explicit secret injection guidance, credentials must never appear in tool parameters or responses.
No permission gates or scope declarations. There is no indication that execute-update (a destructive tool) checks if the calling agent has authority to modify data. Per the pattern, each tool should declare required permissions (e.g., 'write:database', 'admin:database') and gate execution accordingly.
Error responses provide no recovery guidance. When a tool fails (e.g., 'Error connecting to database: connection refused'), it returns only the error text with isError: true. There is no indication of whether the error is retryable, which parameter to fix, or which tool to call next. Per the pattern, errors must guide the LLM: 'Connection refused. Check that the database service is running and the host/port are correct. Retry with connect-database after verifying.'
No idempotency guarantees. execute-query and execute-update provide no indication of whether repeated calls with identical input produce the same result. A non-idempotent tool risks duplicate side effects (double inserts, duplicate charges) when agents retry on ambiguous failures. Tool descriptions must declare idempotency or warn of side effects.
No tool annotations for destructive operations. The execute-update tool modifies/deletes data but includes no destructiveHint annotation. Per the current MCP spec, tools that change state should declare destructiveHint, readOnlyHint, or idempotentHint so clients can apply appropriate safeguards (e.g., require confirmation, limit agent scope).
Parameter 'params' in execute-query and execute-update uses {type: 'array', items: {type: 'any'}} which is not strict. LLMs may pass invalid array contents. The description says '(optional)' but there is no required field constraint in the schema, and the description does not explain what types of values are accepted (strings, numbers, dates, etc.) or how to format them.
No pagination or result limits. The execute-query tool returns all query results in a single text response. Large result sets (thousands of rows) will blow the context window. Per the pattern, tools returning lists must support limit/offset and document the maximum result size.
No dry-run or confirmation pattern for destructive operations. execute-update directly modifies the database with no confirmation step. Agents make mistakes, a confirm_before_execute pattern or dry-run option would prevent accidental data loss. Per the pattern, irreversible operations should support a safety mechanism.