Loading ToolBench
A Model Context Protocol (MCP) server for MySQL database operations with secure read-only queries, schema inspection, and Google Cloud SQL Proxy support
This MySQL MCP server has 3 well-named, read-only tools with solid descriptions and reasonable schema coverage. However, several definition quality issues prevent a higher score: (1) All parameter descriptions are minimal or generic (e.g., 'Name of the table to describe' is only 34 chars, below the 50-100 char baseline for production tools). (2) Output schemas are not explicitly documented, tools return results but there is no formal schema definition visible for the return types, forcing LLMs to infer structure. (3) Error handling lacks recovery guidance, errors are returned as JSON blobs with generic messages ('Failed to describe table') rather than actionable guidance (e.g., 'Table not found. Call show_tables() to see available tables'). (4) No input validation metadata or constraints documented (e.g., table name restrictions are enforced server-side via regex replacement but not declared in the schema). (5) All three tools are read-only with no destructive operations, which simplifies risk but leaves no opportunity to demonstrate confirmation/undo patterns. Naming is strong (verb_object pattern: execute_query, show_tables, describe_table). Tool descriptions are adequate (18-22 chars, on the short side of the 10-1024 range but acceptable for simple tools).
Get detailed schema information for a specific table
Execute a read-only SQL query with automatic sanitization
List all tables in the current database
Output schemas not formally documented. Tools return structured results (JSON with typed fields) but the return schema is not declared in the tool definitions. LLMs must infer the output structure from examples or error messages rather than a schema contract. This violates pattern:tool (Document the output schema).
Parameter descriptions are below production baseline (34-54 chars vs. recommended 50-100 chars). Descriptions lack WHEN-to-use context and are purely definitional. E.g., 'Name of the table to describe' does not explain the query's purpose or acceptable input format (table name constraints, special characters handling).
Error responses lack recovery guidance (pattern:recovery-guide). All three tools return generic error messages ('Failed to ...') without suggesting next steps. E.g., when describe_table fails, should suggest 'Call show_tables() to verify the table exists' or 'Check table name for special characters'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
No pagination support on show_tables(). The tool returns all tables in the database without limit or offset parameters.
Input validation constraints not declared. The code sanitizes table names via regex replacement (/[^a-zA-Z0-9_]/g) but this constraint is not documented in the schema description. LLMs should understand what characters are allowed without reading implementation code.
Tool descriptions do not explain when to use each tool vs. others. The execute_query description does not clarify 'Use this for custom SELECT queries; use show_tables() or describe_table() for schema discovery.' This forces LLMs to reason about tool selection rather than reading clear intent signals.