Loading ToolBench
MCP server for interacting with MySQL databases based on Node
This MySQL MCP server has 4 well-named tools with visible schemas and descriptions, but falls short of production quality in several critical areas. All tools start with action verbs (list_, query, execute, get_) and have descriptions between 50-200 characters. However, parameter descriptions are sparse or missing, error handling lacks recovery guidance, output schemas are not documented, and there is no mention of pagination for potentially large result sets. The server properly implements read/write access control and SQL statement validation, which is good security practice, but does not expose these safety features in tool annotations that would help LLMs understand which tools are destructive.
Execute an INSERT, UPDATE, or DELETE statement against a MySQL database. Only allowed if database is configured with readwrite or full access mode.
Get the schema of a MySQL database, including all tables and their columns.
List all configured database names
Execute a SELECT query against a MySQL database. Results are returned as JSON objects.
Output schemas are not documented. The `query` tool description says 'Results are returned as JSON objects' but does not specify field structure, data types, or example shape. LLMs cannot plan downstream tool calls or extract data reliably from undocumented outputs.
Parameter descriptions are minimal or absent. The `sql` parameter in both `query` and `execute` tools has only a one-line description ('SQL SELECT query to execute' / 'SQL INSERT, UPDATE, or DELETE statement to execute'). No guidance on format, length limits, injection prevention, or error handling. The `database` parameter description does not explain what happens if the name is invalid or if the database cannot be reached.
No error handling or recovery guidance in tool descriptions. If a query fails due to syntax error, permission denied, or timeout, the tool description does not tell the LLM how to recover. No guidance like 'If you get a permission error, check your database access mode' or 'For large result sets, use LIMIT to avoid timeouts.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 18 | - | v1 |
No pagination guidance. The `query` tool can execute SELECT statements that return thousands of rows, but there is no limit parameter or description of pagination strategy. The tool description does not warn LLMs that large result sets will exhaust the context window or suggest using LIMIT/OFFSET.
Destructive tools lack confirmation or dry-run guidance. The `execute` tool modifies data (INSERT, UPDATE, DELETE) but the description does not mention that these are irreversible or suggest a confirmation pattern. No guidance like 'This tool modifies your database. Consider testing the query first with a dry-run or transaction rollback.'
Tool annotations are absent. None of the tools declare `readOnlyHint` or `destructiveHint` in the schema. The `query` tool is read-only and should advertise this; the `execute` tool is destructive and should declare that. These hints guide LLM planning and prevent accidental misuse.
Missing parameter validation details. The `database` parameter is marked optional, but the description does not explain the fallback behavior if omitted and multiple databases are configured. The `sql` parameter has no length limits, injection warnings, or format constraints documented.
Response fields not scoped to agent needs. The `get_schema` tool will return the full schema including internal metadata columns (created_at, updated_at, etc.) that are not relevant to the agent's task. Stripping unnecessary fields would reduce token overhead and signal-to-noise ratio.