This MySQL MCP server has fundamental design and documentation deficiencies. While all 6 tools are explicitly defined with input schemas, the quality is poor across naming, descriptions, parameter documentation, and security practices. Tool names lack clarity on the distinction between similar operations (insert_data vs update_data vs delete_data could all be 'modify_data'). Descriptions are generic and fail to guide LLM selection. Most critically, the server accepts raw SQL strings from agents without sanitization, creating severe SQL injection and data destruction risks. Parameter descriptions are minimal (single phrase: 'The SQL ... query to execute'). Output schemas are not documented. Error handling returns raw database errors without recovery guidance. The tool design violates fundamental agent safety patterns by exposing dangerous write operations with no confirmation, validation, or permission checks.
Tools (6)
create_tablewritesource verified47/100
Creates a new table in the MySQL database.
delete_datadestructivesource verified45/100
Deletes data from a table in the MySQL database.
execute_sqldestructivesource verified40/100
Executes any non-SELECT SQL statement (e.g., ALTER TABLE, DROP, etc.)
insert_datawritesource verified45/100
Inserts data into a table in the MySQL database.
run_sql_queryread onlysource verified62/100
Executes a read-only SQL query (SELECT statements only) against the MySQL database.
All 6 tools accept raw SQL strings from agents with NO input validation, sanitization, or SQL injection protection. An agent can be tricked into passing malicious SQL (e.g. DROP DATABASE or UNION-based injection). This violates pattern:tool-gateway (treat agent input as untrusted) and pattern:secret-injection (credentials in query strings leak to logs).
Destructive operations (create_table, insert_data, update_data, delete_data, execute_sql) have NO confirmation step, dry-run, or permission check. An agent can destroy tables, delete all records, or drop the entire schema without any safety gate. This violates pattern:confirmation-request and pattern:permission-gate.
Implement input validation and SQL query sanitization. Use parameterized queries (prepared statements) instead of raw SQL strings. Reject queries with dangerous keywords (DROP, TRUNCATE, ALTER, DELETE without WHERE) or require explicit agent confirmation.
Add a 'dry_run' parameter to all write tools (create_table, insert_data, update_data, delete_data, execute_sql). When dry_run=true, return what WOULD happen without committing changes. This enables safe agent exploration per pattern:confirmation-request.
Add explicit confirmation step for destructive operations. For delete_data and execute_sql, require a 'confirm_deletion=true' parameter and document in the description that this is a safety gate. Return the count of affected rows so agent can verify before final commit.
Document output schemas for all tools. Specify what fields are returned (e.g., for insert_data: {rows_affected: number, last_insert_id: number}). For run_sql_query, document column names and types returned from the query.
Add pagination to run_sql_query. Include 'limit' and 'offset' parameters (default limit=20, max=100). Return total_count and has_more boolean so agents can navigate large result sets without context explosion.
Improve parameter descriptions. Replace 'The SQL ... query to execute' with explicit guidance: 'The SELECT query to execute. Use WHERE clauses to filter results. Avoid SELECT *, specify columns. Maximum 10,000 rows returned; use LIMIT and OFFSET for pagination.'
Rename and disambiguate tools: 'insert_data' → 'insert_into_table', 'update_data' → 'update_table', 'delete_data' → 'delete_from_table'. Add explicit table_name and column parameters instead of raw SQL to constrain the scope of each operation.
Output schemas are completely undocumented. LLMs have no guidance on what fields to expect from query results, how many rows will be returned, or whether results are paginated. For run_sql_query, unbounded SELECT results could return thousands of rows and exhaust context window. This violates pattern:paginated-result and pattern:response-shaper.
Parameter descriptions are minimal placeholders (e.g. 'The SQL SELECT query to execute') with no guidance on format, constraints, examples, or limitations. Descriptions should explain WHAT queries are valid, WHEN to use each tool, and any prerequisites. Current descriptions fail to disambiguate between similar tools. This violates pattern:tool-description.
Tool names are poorly differentiated. 'insert_data', 'update_data', 'delete_data' are all generic NOUN-based names. They should follow verb_noun pattern with clear verbs (insert_into_table, update_table, delete_from_table) and parameter names should indicate which table and columns. Current names force LLMs to read full descriptions to distinguish tools. This violates pattern:tool (naming best practices).
Error handling returns raw MySQL error messages ('MySQL error: ...') without recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next. A raw 'Syntax error near ...' gives no actionable recovery path. Errors should be categorized as retryable (transient connection) vs user-fixable (invalid query) vs fatal (permission denied).
No audit logging or permission checks. Tools do not verify that the calling agent has permission to modify the database. There is no record of which agent called which tool when, making compliance and debugging impossible. This violates pattern:audit-trail and pattern:scope-declaration.
Database credentials are stored as environment variables and used globally. There is no per-agent role-based access control, no column-level security, and no field masking. An agent with access to this MCP server can query any table and modify any record. This violates pattern:scope-declaration (minimum necessary permissions).
No pagination or result limits on read queries. run_sql_query has no limit parameter and no result cap. An agent running 'SELECT * FROM large_table' could return millions of rows, exhausting context window and token budget. This violates pattern:paginated-result.
Tool descriptions lack dependency hints and disambiguation. There is no guidance on when to call run_sql_query vs create_table, or why insert_data exists separately from execute_sql. Descriptions do not answer: 'What does this tool do? When should I call it instead of a similar tool? What does it return?' This violates pattern:tool-description.
Implement error recovery guidance. Errors should return: (1) the error message, (2) the type (syntax_error, constraint_violation, permission_denied, etc.), (3) a suggestion (e.g., 'Try: check table name spelling' or 'Missing WHERE clause?'). This follows pattern:recovery-guide.
Add audit logging. Log all tool calls with: timestamp, agent_id (if available), tool_name, parameters (with sensitive values redacted), result (success/failure, rows affected), and duration. Send logs to stderr or a logging service for compliance.
Implement role-based access control (RBAC). Accept a 'user_role' parameter and restrict tool access by role: agents with 'read-only' role can only call run_sql_query; 'editor' role can call insert/update; 'admin' role can call execute_sql. Document required roles in tool descriptions.
Remove raw SQL execution (execute_sql). Replace with a set of parameterized tools: alter_table(table_name, change_description), drop_table(table_name, confirm_deletion), create_index, etc. This reduces blast radius and improves safety per pattern:tool (single responsibility).
Add input constraints to the query parameter. Use JSON Schema patterns (e.g., 'query must start with SELECT for run_sql_query'). Document in parameter description: 'Must be a valid SELECT statement; UNION, subqueries, and CTEs are allowed; maximum 5000 characters.'
Return structured results instead of JSON dumps. For insert_data, return {status: 'success', rows_affected: 5, last_insert_id: 42}. For run_sql_query, return {rows: [{id: 1, name: 'Alice'}, ...], total_count: 1000, has_more: true}. This matches pattern:response-shaper.
Add a 'table_schema' discovery tool or parameter. Before write operations, agents should be able to query table structure (columns, types, constraints). Add a 'describe_table(table_name)' tool that returns schema without exposing full data.
Document the risk profile of each tool. Add a description note: 'WARNING: This tool is DESTRUCTIVE. All changes are permanent and cannot be undone. Ensure you have a backup before proceeding.' Include this for delete_data, drop_table, and execute_sql.
Implement timeout protection. Set a maximum execution time (e.g., 30 seconds) for long-running queries. Return a timeout error with guidance: 'Query took too long. Consider adding LIMIT clause or running during off-peak hours.'
Add support for transaction management. Provide tools to BEGIN, COMMIT, and ROLLBACK transactions, enabling agents to compose multi-step operations safely.
Validate query structure before execution. Check for missing WHERE clauses on DELETE/UPDATE, reject SELECT * with no LIMIT, reject DDL on production tables without explicit confirmation. Provide clear error messages that guide correction.