Enterprise-grade MySQL database operations service for Model Context Protocol. Provides safe, reliable database access with backup, export, import, and performance management capabilities.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
MySQL MCP server has 15 tools with mixed quality. Tool naming follows verb_noun convention consistently (mysql_*, export_*, import_*), which is good. However, descriptions are adequate but often generic and lack LLM-optimization guidance. Input schemas are present for all tools with type definitions, but lack constraints (enums, ranges, patterns). Most critically, output schemas are NOT documented, we cannot see what these tools return, which severely impacts agent planning and chaining. Error handling is mentioned in features but not evident in tool definitions. No per-tool permission/scope declarations. Security practices regarding credential handling are unclear from code samples.
Tools (15)
export_to_csvread onlysource verified67/100
Export query results to CSV format with support for streaming and custom options
export_to_excelread onlysource verified67/100
Export query results to Excel format with styling, column width adjustment, and multi-sheet support
export_to_jsonread onlysource verified67/100
Export query results to JSON format with support for nested data structures
import_from_csvwritesource verified67/100
Import data from CSV file with support for custom delimiters, field mapping, and data validation
import_from_excelwritesource verified67/100
Import data from Excel file with support for multiple sheets and data validation
import_from_jsonwritesource verified67/100
Import data from JSON file with support for nested structures and flexible field mapping
import_from_sqlwritesource verified67/100
Import data from SQL dump file with transaction support and error recovery
Output schemas completely undocumented. No tool in the definition set shows what fields or structure these tools return. This prevents agents from planning downstream calls, chaining tools, and extracting correct data.
No enum constraints on string parameters. Parameters like 'table_name', 'delimiter', 'encoding', 'sheet_name' accept free-form strings with no validation hints. LLMs cannot auto-correct invalid values; e.g., misspelled table names will fail at runtime with unclear error messages.
Document output schemas for all 15 tools. For each tool, add an explicit 'returns' or 'output' section describing field names, types, and what data they contain. E.g., mysql_select_data should return {success: bool, rows: [], row_count: int, columns: []}.
Add enum constraints to string parameters. Use JSONSchema 'enum' field for fixed values: delimiter in export_to_csv should be enum: [',', ';', '\t', '|']; encoding should be enum: ['utf-8', 'latin-1', 'utf-16']. This guides LLM selection and prevents invalid input.
Add range constraints to numeric parameters. E.g., limit: {type: 'integer', minimum: 1, maximum: 100000, description: 'Row limit (1 - 100000)'}. This prevents absurd values and API overload.
Extend descriptions for destructive tools (DELETE, UPDATE, WRITE). Add warnings: 'WARNING: This operation modifies data and cannot be undone. Ensure your WHERE clause is correct.' Optionally add a confirm_delete pattern or dry_run parameter.
Add per-tool permission declarations. Include in each tool definition: 'Requires: read:database' or 'Requires: write:database, admin:database'. This enables least-privilege agent configuration and audit trails.
Implement tool annotations in fastmcp. Mark destructive tools: @tool(..., hint=MCP_TOOL_HINT_DESTRUCTIVE). Mark read-only tools: @tool(..., hint=MCP_TOOL_HINT_READONLY). Add idempotent hints where applicable (export tools are idempotent; import tools are not).
Clarify tool overlap. Document when to use mysql_query vs mysql_select_data. E.g., 'Use mysql_select_data for filtered retrieval from a known table; use mysql_query for complex joins, aggregations, or raw SQL. mysql_select_data is simpler for simple cases.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Destructive tools (mysql_delete_data, mysql_update_data) have no mention of dry-run, confirmation, or recovery guidance. An agent could issue DELETE without confirmation. Descriptions do not warn of irreversibility or guide recovery.
Parameters lack range/constraint metadata. 'limit' integer parameter in mysql_select_data has no min/max bounds. 'with_progress' boolean is present but its effect is not explained. Numeric parameters should declare valid ranges (e.g., limit 1 - 100000).
No error recovery guidance in tool descriptions. Tools do not explain what errors can occur, whether they are retryable, or what the user should do if a call fails (e.g., 'Table not found, check mysql_show_tables() to list available tables').
Tool composition risks. mysql_select_data and mysql_query overlap in functionality, both execute queries against the database. Unclear when to use each. 'mysql_select_data' implies table-specific SELECT, but 'mysql_query' can do the same with raw SQL. LLMs may waste reasoning cycles choosing between them.
Parameter descriptions are often vague or incomplete. E.g., 'where_clause' in mysql_update_data lacks guidance on format (bare SQL? parameterized? escape requirements?). 'Optional' parameters don't explain defaults or behavior when omitted.
No explicit permission/scope declarations. Tools that modify (INSERT, UPDATE, DELETE, WRITE) or export data should declare required permissions (e.g., 'read:database', 'write:database'). This prevents least-privilege agent configuration.
Tool annotations not present. The fastmcp framework supports tool annotations (readOnlyHint, destructiveHint, idempotentHint per MCP spec), but none are declared in the provided definitions. mysql_delete_data and mysql_update_data should be marked destructiveHint=true.
Credential handling unclear. Requirements state 'python-dotenv' and 'cryptography' are dependencies, suggesting secrets are managed via .env. However, no tool definition shows HOW credentials are injected or whether database connection params are exposed.
Add error guidance to descriptions. E.g., mysql_describe_table: 'If table not found, call mysql_show_tables() to list available tables. If permission denied, check database credentials.'
Expand parameter descriptions. For 'where_clause', clarify: 'SQL WHERE clause without the WHERE keyword (e.g., \'id > 5 AND status = "active"\'. Parameterized queries are not supported; always escape user input to prevent SQL injection.'
Add security notices to tool descriptions. Warn: 'All user-provided input in table names, column names, and WHERE clauses must be validated/escaped to prevent SQL injection. File paths (in import/export) must be validated to prevent directory traversal attacks.'
Consider adding a dry_run or preview parameter to destructive operations. E.g., mysql_delete_data with dry_run=true returns 'Would delete X rows matching the WHERE clause' instead of actually deleting. This allows agents to preview before committing.
Document pagination behavior for tools that return many rows. If mysql_select_data returns > 1000 rows, cap at 1000 and add an offset parameter to allow agents to retrieve subsequent batches.
Add examples in tool descriptions (not parameter descriptions). E.g., 'Example: Export all users to CSV with email as delimiter: export_to_csv(query="SELECT * FROM users", file_path="/tmp/users.csv", delimiter=",")'. Examples in param descriptions confuse LLMs into reusing example values literally.