Loading ToolBench
This MCP server provides 12 database query and schema inspection tools with clear verb-noun naming and generally well-structured schemas. Most tools have descriptions and typed parameters. However, several critical gaps limit the score: (1) output schemas are completely undocumented, no responses are formally specified, forcing LLMs to infer result structure; (2) parameter descriptions lack actionable constraints (e.g., no mention of pagination limits, max query timeout, or performance impact); (3) error handling is minimal, no recovery guidance for common failures (connection errors, missing tables, timeouts); (4) several parameter descriptions are generic or omit dependency hints; (5) the 'ping' tool is deprecated per MCP spec 2026-07-28 and should be removed. The server correctly emphasizes READ_ONLY safety across all tools, which is a strong foundation for a database tool. Naming is consistent (get_*, execute_*, find_*, visualize_*) and matches database semantics well.
Compares the schema definitions of two MySQL databases or PostgreSQL schemas and returns a detailed diff report.
Executes a standard read-only SQL query (SELECT, SHOW, EXPLAIN, DESCRIBE). Requires 'databaseName' for MySQL context, or 'schemaName' for PostgreSQL context (sets search_path). Supports parameters and pagination.
Executes an EXPLAIN statement for a SQL query to retrieve execution plan details.
Finds all paths connecting two tables via foreign key relationships in a MySQL database or PostgreSQL schema.
Retrieves constraint definitions (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK) for tables in a MySQL database or PostgreSQL schema.
Retrieves index definitions for tables in a MySQL database or PostgreSQL schema.
No output schemas documented. Tools return responses but LLMs have no way to know result structure, field types, or required fields for downstream tool chaining. This forces LLMs to infer structure, increasing hallucination risk.
Parameter descriptions lack actionable constraints. Examples: (1) 'execute_query' accepts 'query' but no mention of max query length, allowed SQL statement types, or timeout; (2) 'pagination.limit' has no min/max bounds stated in description; (3) 'find_table_paths' has 'maxDepth' default of 5 but no guidance on performance implications of larger values; (4) 'get_performance_metrics' metric_types accepts patterns but no example patterns or valid options listed.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Retrieves basic global/database-level performance metrics/statistics from MySQL or PostgreSQL (e.g., Uptime, Threads, Queries, Activity). Requires 'databaseName' for PostgreSQL context.
Retrieves foreign key relationships between tables in a MySQL database or PostgreSQL schema.
Retrieves comprehensive schema details (tables, columns, indexes, constraints) for a MySQL database or PostgreSQL schema.
Retrieves the column definitions (schema) of a specific table within a MySQL database or PostgreSQL schema.
A simple tool to check if the MCP server is responding. Returns 'Pong!'
Generates a visual ASCII or DOT representation of database schema for a MySQL database or PostgreSQL schema.
'ping' tool is deprecated per MCP spec 2026-07-28. The spec removed ping as a first-class tool pattern. This tool should be replaced with server-side health checks or removed entirely.
Error handling provides no recovery guidance. Tool descriptions mention READ_ONLY safety but do not explain what happens on connection failure, missing table, SQL syntax error, or timeout. LLMs receive raw errors with no actionable next steps.
No tool produces documented return schemas. LLMs cannot verify they have the fields needed for chaining (e.g., does 'get_relationships' return 'table_id' or 'table_name'? Does 'execute_query' return result count?). Forced to guess or hallucinate field names.
Parameter 'query' in 'execute_query' lacks dependency documentation. Description says 'read-only SQL query' but does not warn that parameterized queries require matching 'params' array or that SHOW/EXPLAIN have different formats per database type.
Several tools mix MySQL/PostgreSQL parameters in a single schema (databaseName vs schemaName). Descriptions attempt to clarify conditional requirements but do not state that passing both is ambiguous. LLMs may pass both, causing unintended behavior.
No rate-limiting or result-size caps documented. 'execute_query' can return thousands of rows; 'find_table_paths' can explore deeply nested relationships without explicit bounds on output size. This risks context window overflow and token waste.