The Model Context Protocol (MCP) server establishes a standardized JSON-RPC 2.0 interface for MySQL operations, enabling CRUD execution, transaction management, and ddl
This MySQL MCP server has 7 tools with basic schemas and descriptions, but exhibits multiple quality gaps. Naming is mostly verb-noun compliant (connect_db, query, execute, list_tables, describe_table, show_statement, explain), but descriptions are inconsistent in depth and quality. Schemas are present but incomplete, most parameters lack detailed descriptions of constraints, formats, and valid ranges. Critical issue: the connect_db tool accepts credentials as parameters, violating secret-injection patterns. Parameter descriptions are sparse (e.g., 'Query parameters (optional)' for the 'params' field in query/execute tools lacks format guidance). Output schemas are not documented, LLMs cannot know what fields to expect in responses. Error handling is minimal; no actionable recovery guidance is provided. The server loads credentials from environment variables at startup, but the connect_db tool still exposes them as parameters, creating a footgun. This is below the 'production-grade' bar but functional for basic use.
Connect to MySQL database
Get table structure
Execute an INSERT, UPDATE, or DELETE query
Analyze SQL query performance using EXPLAIN
List all tables in the database
Execute a SELECT query,can not get table structure,use describe_table tool to get table structure
Execute a SHOW statement (e.g., SHOW STATUS, SHOW VARIABLES)
Credentials exposed as tool parameters in connect_db (host, user, password, database). This violates secret-injection pattern, agent traces will log plaintext credentials, leaking them to logs and prompt history.
Output schemas not documented. LLMs cannot infer what fields query, execute, show_statement, and explain return. Responses are opaque black boxes, agents cannot plan multi-step operations or extract needed IDs for follow-up calls.
Parameter 'params' in query and execute tools has minimal description ('Query parameters (optional)'). LLMs do not know format (array of strings? mixed types? null values allowed?). Actual schema hints at mixed-type array but description does not guide LLMs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No error handling or recovery guidance. If a query fails, no actionable next steps are provided. Agents cannot distinguish retryable vs permanent failures or self-correct based on error messages.
Missing destructive operation guardrails. execute tool (INSERT, UPDATE, DELETE) should support dry-run or require explicit confirmation before irreversible actions. No mention of confirmation patterns in description.
show_statement description is vague: 'Execute a SHOW statement (e.g., SHOW STATUS, SHOW VARIABLES)'. No indication of when to use this vs other query tools. Overlap with query tool is unclear, LLMs will struggle to choose correctly.
query description references describe_table as a workaround: 'can not get table structure, use describe_table tool to get table structure'. This is a dependency hint but buried in the description. Should be explicit: 'For table schema, call describe_table first.'