Loading ToolBench
MCP server for database operations - enables AI assistants to query SQL databases
The server demonstrates solid definition quality with comprehensive parameter schemas and clear action verbs. All 10 tools follow verb_noun naming convention (list_, query_, execute_, describe_, begin_, commit_, rollback_). Descriptions are present and generally informative (90-180 chars typical), explaining what each tool does and when to use it. Parameter schemas are well-structured with proper JSON Schema types, enums, and nested oneOf patterns for parameterized query inputs. However, several areas need improvement: (1) Parameter descriptions are sometimes generic or lack concrete format guidance; (2) Output schemas are undocumented, tools describe queries/operations but not their return structure; (3) Error handling guidance is absent from descriptions; (4) Some parameter relationships (e.g., database vs schema vs connection_id) could be clearer; (5) Transaction tools lack isolation-level guidance in descriptions. The query_database and execute_write tools show solid parameterization with limit constraints (1-10000) and timeout support, but lack documented output schemas. Transaction management tools (begin_transaction, commit_transaction, etc.) are well-named but descriptions don't explain transaction ID lifecycle or conflict handling.
Start a new database transaction and return a transaction ID for subsequent operations
Commit an active database transaction
Get schema information for a database table including column names, types, and constraints
Execute a write operation (INSERT, UPDATE, DELETE) against a database connection
List all available database connections with their configuration details
List all tables in a database
Execute a SELECT query against a database connection and retrieve results
Output schemas are completely undocumented. Tools describe operations (query, execute, describe_table, list_tables) but provide no documentation of their response structure, field names, or data types. This forces LLMs to guess at returned fields and makes tool chaining error-prone.
Parameter descriptions lack actionable format guidance. For example, 'SQL SELECT query to execute' doesn't explain what format is expected, whether subqueries are allowed, or length limits. Similarly, 'Query parameters' doesn't explain when/why to use the oneOf parameter structure with type+value pairs.
Transaction isolation level parameter in begin_transaction lacks documentation explaining what each level means (dirty reads, phantom reads, etc.) or when to use each. LLMs cannot reason about isolation_level choices without guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Execute a SELECT query within an active database transaction
Rollback an active database transaction
Execute a write operation (INSERT, UPDATE, DELETE) within an active database transaction
Error handling guidance is absent from all tool descriptions. No mention of what errors are retryable, what error codes indicate user misconfiguration vs server issues, or what recovery steps LLMs should take. E.g., query_database doesn't document 'timeout exceeded' or 'connection refused' error conditions.
Parameter interdependencies are not documented. For database/schema/connection_id parameters across tools, no explanation of which combinations are valid (e.g., 'database' required for server-level connections but optional for database connections). This causes LLMs to pass invalid parameter combinations.
Transaction lifecycle is unclear. No documentation of transaction_id validity window, what happens if you call commit/rollback on a non-existent or already-committed transaction, or whether nested transactions are allowed. This leaves LLMs guessing about transaction semantics.
No documentation of result pagination for query_database and query_transaction. While a 'limit' parameter is provided (capped at 10000), there is no mention of how to retrieve additional results, whether offset is supported, or whether total_count is returned to enable pagination planning.