A Model Context Protocol (MCP) server that enables secure interaction with MySQL databases. This server allows AI assistants to list tables, read data, and execute SQL queries through a controlled interface, making database exploration and analysis safer and more structured.
The MySQL MCP server provides 7 tools with verb-based naming (list_tables, read_table, insert_data, etc.), which is strong. Tool descriptions are present and contextual (194-char average baseline met). However, parameter descriptions exist but some lack depth around constraints and error handling. Input schemas are visible for most tools (read_table, insert_data, update_data, delete_data show explicit parameter objects with type/description), but output schemas are not documented. Error handling guidance is minimal, tools reference 'prepared statements' for SQL injection prevention but don't guide LLMs on recovery paths. The server correctly uses parameterized queries and validates identifiers, which is good security practice, but error responses are not detailed in the provided source. Overall: solid naming and description baseline, but incomplete schemas and missing recovery guidance limit the score to 62.
Delete rows from a table. Requires specifying the table name and a WHERE clause to specify which rows to delete. Uses prepared statements to prevent SQL injection.
Execute a SELECT query against the database. The query is executed as-is, so be careful with complex queries. Use this to perform aggregations, joins, and other complex SQL operations that are not covered by the simpler read_table tool.
Insert one or more rows into a table. Requires specifying the table name and column values for each row. Uses prepared statements to prevent SQL injection.
List all tables in the connected MySQL database. Does not include any data, only table names and some basic information like row count.
Read data from a table. When no WHERE clause is provided, the tool will return data in chunks. When a WHERE clause is provided, the tool returns all matching rows at once. All SQL injection is prevented by using prepared statements.
Get the schema (column definitions) for a table. Returns column names, types, constraints, defaults, and whether columns are nullable.
Output schemas are not documented. LLMs cannot predict what fields list_tables, read_table, or execute_query return, forcing them to reason blindly about follow-up calls. SCHEMAS & OUTPUT', 100% of A+ tools document return types.
Error handling does not provide recovery guidance. Tools mention 'prepared statements' prevent injection but do not describe what happens if a query fails, what fields are returned on error, or what the LLM should try next. Per pattern:recovery-guide, errors must tell the agent what to do.
Destructive operations (insert_data, update_data, delete_data) lack confirmation or dry-run support. No tool annotation (destructiveHint) is present in the source code. Per pattern:confirmation-request, irreversible operations should support a dry-run or confirmation step to prevent accidental data loss.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Update rows in a table. Requires specifying the table name, the updates to apply, and a WHERE clause to specify which rows to update. Uses prepared statements to prevent SQL injection.
No input validation constraints documented for string parameters. 'where' and 'query' parameters accept free-form SQL; no regex patterns, length limits, or injection-prevention rules are stated in parameter descriptions. Agents cannot detect whether their input violates constraints without trial-and-error.
Parameter 'limit' defaults to 100 with no documented upper bound. PARAMETERS', numeric parameters must specify min/max. Without a cap, an LLM could request 1M rows, exhausting memory or context window.
No pagination or result-limiting guidance in execute_query. A SELECT returning 10,000 rows will blow the context window. SCHEMAS & OUTPUT', tools returning lists should accept pagination parameters and document result limits.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are imported in the source but not applied to any tool. The code imports ToolAnnotations but does not populate them. Per current spec (2026-07-28), tool annotations should be present to help clients restrict access.