Loading ToolBench
A multi-database MCP server with lazy short-lived connections, strong read-only defaults, and explicit confirmation for writable SQL.
This MCP server demonstrates solid foundational quality with 22 well-structured tools covering SQL and Redis operations. All tools have explicit descriptions and input schemas defined via Zod with type validation. Naming is consistent (verb_noun pattern: list_*, describe_*, execute_*, etc.). Parameter descriptions are detailed and include constraints (e.g., 'Row limit; defaults to 200', 'Case-insensitive name fragment'). However, output schemas are not documented in the visible source code, tool descriptions state what they return but the actual response structure is not formally specified in the tool definitions themselves. Error handling guidance is minimal; descriptions don't explain recovery paths or error categorization. Risk annotation (READ_ONLY vs WRITE) is present in metadata but not exposed as tool annotations in the MCP schema. Schema quality is strong (Zod-based with validation), but composition could be optimized, some tools like execute_statement and execute_script could benefit from dry-run/confirmation patterns, which are mentioned in toolRegistry comments but not explicitly in the schema.
Analyze query execution and get detailed statistics
Get column definitions for a table or view
Execute a read-only SELECT query and return results
Execute a multi-statement SQL script from inline text or a .sql file with confirmation
Execute a write statement (INSERT, UPDATE, DELETE, MERGE, or DDL) with confirmation
Get query execution plan without running the query
Get table statistics and metadata
Output schemas not formally documented. Tool descriptions reference what is returned but the actual response structure (fields, types, pagination) is not formally specified in the MCP tool definitions. This forces LLMs to infer response shape and risks parsing errors.
Missing error handling guidance. Tool descriptions do not explain what errors are retryable, user-fixable, or fatal. No recovery paths are suggested (e.g., 'if connection fails, check database configuration'). This limits LLM ability to self-correct.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not exposed in schema. Risk metadata (READ_ONLY vs WRITE) exists in internal registry metadata but is not propagated to the MCP tool definition. This prevents clients from understanding which tools are safe vs destructive.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 73 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
List all configured databases
List indexes on a table
List schemas in a SQL database
List tables in a schema
List currently running long-duration queries
Delete a key from Redis
Get a value from Redis by exact key name
Scan Redis keys matching a pattern
Set a value in Redis
Manually reload the configuration from disk
Search for columns matching a name pattern
Search for tables matching a name pattern
Get the CREATE TABLE statement for a table
Show the currently loaded configuration summary
Show database system variables
Write operations lack confirmation/dry-run pattern. execute_statement and execute_script modify databases but offer no way to preview changes or request user confirmation before execution. Agents can inadvertently execute destructive queries.
Pagination not explicitly documented for list tools. While maxRows parameter exists, tools like list_databases, list_schemas, list_tables do not specify whether results are truncated, whether there is a cursor or offset for continuation, or what the total count is. Large result sets could silently truncate.
Redis tools accept only exact keys (redis_get, redis_set, redis_del) but do not document whether keys are case-sensitive, whether special characters are allowed, or what character encoding is expected. This invites agent errors when working with unfamiliar key naming conventions.