Loading ToolBench
Multi-database MCP server supporting MySQL and PostgreSQL with gateway architecture for endpoint-based access control and table-level scoping
DB-MCP exhibits significant structural and documentation gaps. The codebase shows 20 tool definitions across MySQL and PostgreSQL variants, but suffers from: (1) severe duplication (identical tool names registered multiple times: mysql_get_builtin_prompt appears in tools 1 and 11; get_all_schemas in 2 and 7; get_tables in 3 and 8; get_table_schema in 4 and 9; execute_sql in 5 and 10), (2) missing input schemas for at least some tool variants (tools 12-20 show tools with empty input schemas or reduced parameters compared to earlier variants), (3) generic descriptions that lack actionable guidance for LLM tool selection, (4) credentials exposed as tool parameters (host, port, user, password, db_name required in ConnInput for tools 1-10), (5) no per-tool error handling or recovery guidance, (6) no tool annotations (readOnlyHint, etc.), and (7) weak composition discipline, multiple variants of the same tool with overlapping responsibilities rather than a single canonical tool set. Per-tool analysis shows most tools score 40-50 individually due to incomplete schemas and missing parameter-level detail.
Execute read-only SELECT (validated against endpoint scope).
Execute read-only SELECT (JSON).
Execute read-only SELECT (JSON).
Execute read-only SELECT (validated against endpoint scope).
List schemas and compact tables/columns map.
List databases and tables/columns (filtered by endpoint scope).
List databases and compact tables/columns map.
Severe tool duplication: 20 tool registrations collapse into ~8 distinct operations (mysql_get_builtin_prompt, get_all_schemas, get_tables, get_table_schema, execute_sql for MySQL; same 4 for PostgreSQL; plus gateway variants). Duplicated tool names cause confusion in tool selection and violate single-responsibility principle.
Credentials exposed as tool parameters: ConnInput requires host, port, user, password, db_name as parameters for tools 1-10. Passwords in tool parameters are logged, traced, and risk leaking into agent logs and prompt history. Must use server-side secret injection via environment variables or a configured vault.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
List schemas and tables/columns (filtered by endpoint scope).
Describe a table (blocked if outside endpoint scope).
Describe a table.
Describe a table.
Describe a table (blocked if outside endpoint scope).
List tables (filtered by endpoint scope).
List tables (filtered by endpoint scope).
List tables under a database.
List tables under a schema.
Get MySQL built-in prompt by name.
Get MySQL built-in prompt by name.
Get PostgreSQL built-in prompt by name.
Get PostgreSQL built-in prompt by name.
Gateway/scoped tool variants (tools 12-20) have empty or severely reduced input schemas. Tools 12 (get_all_schemas), 13 (get_tables), 14 (get_table_schema), 15 (execute_sql) for MySQL and 17-20 for PostgreSQL show {} or single-parameter inputs with no type declarations. This violates schema completeness requirements and makes it impossible for LLMs to understand what parameters are valid.
Generic descriptions across all tools: 'List databases and compact tables/columns map' (get_all_schemas), 'List tables under a database' (get_tables), 'Describe a table' (get_table_schema), 'Execute read-only SELECT (JSON)' (execute_sql). None explain WHEN to use each variant, what distinguishes the gateway-scoped versions from the full-parameter versions, or how they fit into a larger query workflow. Descriptions lack actionable guidance for LLM tool selection.
No tool annotations: None of the tools declare readOnlyHint, destructiveHint, or idempotentHint. All tools are READ_ONLY (no destructive operations), but this semantic information is not encoded in the tool definition. Modern MCP servers should declare these hints for agent safety and composition reasoning.
Missing per-parameter descriptions for gateway-scoped variants: Tools 12-20 show parameters like 'database', 'schema', 'table' with no descriptions. The ConnInput-based tools (1-10) at least have 'Target database' / 'Table name', but gateway variants omit even minimal guidance.
No error handling or recovery guidance: Tool descriptions do not explain what happens on failure (invalid SQL, connection timeout, permission denied, schema not found). LLMs receive raw errors with no actionable next steps.
No pagination or result-limiting guidance: execute_sql tools accept max_rows parameter, but descriptions do not state the default, the hard limit, or what happens when results exceed the limit. get_all_schemas and get_tables have no obvious limit mechanism, risking context window exhaustion on large schemas.
Inconsistent parameter naming across variants: ConnInput-based tools use 'database' or 'schema' as optional overrides; gateway variants use 'database' or 'schema' as required or scoped. This inconsistency signals poor composition and forces LLMs to reason about which version to call.