Loading ToolBench
A Model Context Protocol server implementation for MySQL database operations, providing tools for schema management, data querying, and modifications with safety checks
The server defines 9 tools with proper MCP registration (mark3labs/mcp-go). All tools have descriptions and visible input schemas with JSON types. However, several critical gaps prevent a higher score: (1) Parameter descriptions are often minimal or absent (e.g., 'dsn' param repeats same description across 9 tools with no context on how to construct a MySQL DSN); (2) Output schemas are entirely undocumented, no tool declares what structure it returns, forcing LLMs to guess at response fields; (3) Error handling is invisible in the source, no guidance on recovery or error categorization; (4) Some tool names are ambiguous ('create_table', 'alter_table' are clear, but 'write_query' vs 'update_query' vs 'delete_query' creates cognitive overhead for LLMs choosing between them); (5) The 'dsn' parameter is repeated across all 9 tools identically, suggesting poor parameter reuse design. The server follows basic MCP patterns but lacks the robustness expected of production tooling.
Alter an existing table in the MySQL server. Make sure you have updated comments for each modified column. DO NOT drop table or existing columns!
Create a new table in the MySQL server. Make sure you have added proper comments for each column and the table itself
Execute a delete SQL query. Make sure you have knowledge of the table structure before executing the query. Make sure there is always a WHERE condition. Call `desc_table` first if necessary
Describe the structure of a table
List all databases in the MySQL server
List all tables in the MySQL server
Execute a read-only SQL query. Make sure you have knowledge of the table structure before writing WHERE conditions. Call `desc_table` first if necessary
No documented output schemas. All 9 tools lack documented return types. LLMs cannot plan subsequent calls or extract required fields without guessing at response structure. E.g., 'read_query' returns results but format is unknown (JSON rows? CSV? typed objects?).
Parameter 'dsn' repeated identically across all 9 tools with generic description 'MySQL DSN (Data Source Name) string. If provided, this overrides the configuration.' No guidance on format (should it be 'user:pass@tcp(host:port)/db'? or something else?). Violates DRY principle and provides insufficient context for LLM usage.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Execute an update SQL query. Make sure you have knowledge of the table structure before executing the query. Make sure there is always a WHERE condition. Call `desc_table` first if necessary
Execute a write SQL query. Make sure you have knowledge of the table structure before executing the query. Make sure the data types match the columns' definitions
Overlapping tool names create disambiguation overhead. 'read_query', 'write_query', 'update_query', 'delete_query' all execute SQL but differ in intent. An LLM must read all 4 descriptions to pick correctly. Pattern suggests separate verb_noun pairs (e.g., 'execute_select', 'execute_insert', 'execute_update', 'execute_delete') or a single 'query' tool with a 'statement_type' enum parameter.
No error handling guidance in tool descriptions. Tools like 'delete_query' and 'update_query' are destructive but descriptions lack warnings or guidance on pre-checks, dry-runs, or recovery. Per pattern:confirmation-request, irreversible operations should support confirmation.
Parameter descriptions for 'query' are minimal ('The SQL query to execute' or 'The SQL query to create the table'). No guidance on: allowed statement types, SQL syntax requirements, injection safeguards, performance warnings. LLMs cannot infer if JOIN syntax is supported, subqueries allowed, or large result limits imposed.
'create_table' and 'alter_table' descriptions include hints ('Make sure you have added proper comments for each column'; 'DO NOT drop table or existing columns!') but these are polite suggestions, not enforced constraints. Hints should be formalized as parameter validation and error checks, not LLM instructions.