Loading ToolBench
This MySQL MCP server has significant gaps in definition quality. Tool definitions exist with basic schemas, but descriptions are minimal and parameters lack proper documentation. The server implements 5 tools (query_database, list_tables, describe_table, insert_record, update_record) with READ_ONLY and WRITE access patterns. While schemas are present in the code, parameter descriptions are sparse, and output schemas are undocumented. Error handling is minimal, there is no guidance to LLMs on recovery strategies. Critical: parameter descriptions are single short phrases that don't meet the 10-1024 character baseline or explain when to use the tool. The rubric baseline shows avg param description = 72 chars; these are ~10-30 chars. Most parameter descriptions are single words like 'SELECT SQL query to execute' or 'Key-value pairs to insert' without format constraints, valid ranges, or actionable context.
Get the structure of a table
Insert a record into a table
List all tables in the database
Execute a SELECT query on the MySQL database
Update records in a table
Parameter descriptions are far too short and lack actionable detail. 'Key-value pairs to insert' does not explain required vs optional fields, data type constraints, or when this tool should be called. Baseline for param descriptions is 72 chars; these are ~10-30 chars.
Output schemas are not documented in tool definitions. LLMs cannot determine what fields to expect from query_database (does it return rows? metadata? error details?), list_tables (table names only? sizes? types?), or describe_table (column names? types? constraints?). This blocks downstream tool composition and forces agents to guess.
The 'data' parameter in insert_record and update_record accepts an arbitrary object ('type:object') with no schema constraints. This is dangerously loose, LLMs cannot validate which fields are allowed, which are required, or what types they must be. Requires a oneOf schema showing the table-specific structure, or at minimum an enum/pattern constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | 2024-11-05+ | v1 |
Error handling is absent or minimal. There are no error messages guiding LLMs on recovery. If insert_record fails due to a constraint violation, duplicate key, or missing required column, what should the agent do? Retry? Call describe_table first? Without actionable error guidance, agents will spin or give up.
Tool descriptions are generic and do not distinguish between similar tools or explain when to call one vs another. 'Execute a SELECT query' does not say whether this tool handles JOIN queries, subqueries, large result sets, or timeouts. 'Get the structure of a table' does not say whether it returns column names, types, constraints, or all three.
No mention of SQL injection protection or input sanitization in the code or documentation. While the code uses parameterized queries via mysql2, the tool descriptions do not warn LLMs that free-form 'query' parameters are dangerous if passed directly from user input. This creates a false sense of safety.
The 'where' parameter in update_record is an arbitrary object with no validation. An LLM could pass an empty object {} (which would match all rows) or malformed conditions. The description must explain that 'where' is a key-value object representing AND-ed conditions, with examples.
No pagination documented for query_database or list_tables. If a SELECT returns 10,000 rows or a database has 100 tables, the response could blow the context window. Tools must accept limit/offset and return total count. The streaming endpoint exists in HTTP but is not surfaced in the MCP tool definition.