Loading ToolBench
Comprehensive MCP server for database management and analysis. Supports PostgreSQL, MySQL, SQLite, SQL Server, MongoDB, and Redis.
28 tools with consistent structure but significant definition gaps. All tools have descriptions (10-60 chars, mostly generic), names follow verb_noun convention, and input schemas are present with parameter descriptions. However, output schemas are not documented anywhere in source code, error handling is minimal, and descriptions lack LLM-optimization (below 194 char baseline). Tools like 'execute_query' and 'restore_backup' are high-risk (WRITE/DESTRUCTIVE) but lack confirmation/dry-run patterns. Parameter documentation is present but formulaic. No per-tool security/permission scoping. Average tool quality is fair, adequate for discovery but weak on guidance, error recovery, and safety.
Analyze data quality issues in a table
Analyze foreign key relationships and issues
Analyze database user permissions and roles
Analyze a SQL query for performance and issues
Create a database backup
Create a new database connection
Detect slow queries in database logs
Detect SQL injection patterns in query
No output schemas documented. All 28 tools lack return type definitions in code comments or schema. LLMs cannot plan downstream tool chaining or extract needed fields.
High-risk tools (execute_query, restore_backup) lack confirmation/dry-run pattern. No way for agents to verify intent before destructive operations. execute_query marked WRITE, restore_backup marked DESTRUCTIVE, but no mechanism to prevent accidental execution.
Descriptions are generic and brief (35-60 chars). Below production baseline of 194 chars. Lack context about WHEN to use tool, WHAT it returns, and dependencies. Examples: 'Execute a SQL query against a database' (48 chars) provides no guidance on result pagination, performance impact, or when to use vs explain_query.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Detect security vulnerabilities in database
Disconnect from a database
Generate documentation for database schema
Execute a SQL query against a database
Get execution plan for a query
Find duplicate rows in a table
Find columns containing sensitive data (PII, passwords, etc)
Generate migration script between two schemas
Get details of a specific connection
Get database schema information
Get schema for a specific table
Get statistics for a specific table
List available backups
List all active database connections
Get optimization suggestions for a query
Restore from a backup
Sample data from a table
Test a database connection
Verify integrity of a backup
Generate ER diagram for database schema
generate_migration accepts 'sourceSchema' and 'targetSchema' as object types with no schema definition. What fields do these objects require? No validation or examples. LLMs will guess at structure.
No pagination support documented. list_connections, list_backups, analyze_data_quality, and similar discovery tools do not declare limit/offset or cursor parameters. Large result sets could exhaust context.
No security scoping or permission gates declared. Tools like analyze_permissions and detect_vulnerabilities expose sensitive database metadata without scope declarations. No audit trail setup visible.
Minimal error handling and recovery guidance. Server-level error catching in server.ts (src/server.ts) converts all exceptions to generic McpError with stack trace, but individual tools provide no actionable guidance (e.g., 'Connection failed. Retry with test_connection first').
Tool composition gap: execute_query returns raw SQL results with no documented structure, but no tools accept those results as input. No tool takes 'previous_query_result' or similar to enable chaining.
create_connection accepts both 'host/port/database' AND 'connectionString' but no description of mutual exclusivity or precedence. LLMs may pass both, causing ambiguous behavior.
Tools lack idempotency guarantees. create_backup, generate_migration, and others could produce duplicate side effects if retried. No documented idempotency tokens or idempotent markers.