MySQL MCP Server
Enables secure interaction with MySQL databases, allowing AI assistants to list tables, read table contents, and execute SQL queries with proper error handling.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MySQL MCP Servershow me the last 10 orders from the customers table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MySQL MCP Server
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.
Features
List available MySQL tables as resources
Read table contents
Execute SQL queries with proper error handling
Secure database access through environment variables
Comprehensive logging
Installation
pip install mysql-mcp-serverConfiguration
Set the following environment variables:
MYSQL_HOST=localhost # Database host
MYSQL_PORT=3306 # Optional: Database port (defaults to 3306 if not specified)
MYSQL_USER=your_username
MYSQL_PASSWORD=your_password
MYSQL_DATABASE=your_databaseUsage
With Claude Desktop
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"mysql": {
"command": "uv",
"args": [
"--directory",
"path/to/mysql_mcp_server",
"run",
"mysql_mcp_server"
],
"env": {
"MYSQL_HOST": "localhost",
"MYSQL_PORT": "3306",
"MYSQL_USER": "your_username",
"MYSQL_PASSWORD": "your_password",
"MYSQL_DATABASE": "your_database"
}
}
}
}As a standalone server
# Install dependencies
pip install -r requirements.txt
# Run the server
python -m mysql_mcp_serverDevelopment
# Clone the repository
git clone https://github.com/yourusername/mysql_mcp_server.git
cd mysql_mcp_server
# Create virtual environment
python -m venv venv
source venv/bin/activate # or `venv\Scripts\activate` on Windows
# Install development dependencies
pip install -r requirements-dev.txt
# Run tests
pytestSecurity Considerations
Never commit environment variables or credentials
Use a database user with minimal required permissions
Consider implementing query whitelisting for production use
Monitor and log all database operations
Security Best Practices
This MCP server requires database access to function. For security:
Create a dedicated MySQL user with minimal permissions
Never use root credentials or administrative accounts
Restrict database access to only necessary operations
Enable logging for audit purposes
Regular security reviews of database access
See MySQL Security Configuration Guide for detailed instructions on:
Creating a restricted MySQL user
Setting appropriate permissions
Monitoring database access
Security best practices
⚠️ IMPORTANT: Always follow the principle of least privilege when configuring database access.
License
MIT License - see LICENSE file for details.
Contributing
Fork the repository
Create your feature branch (
git checkout -b feature/amazing-feature)Commit your changes (
git commit -m 'Add some amazing feature')Push to the branch (
git push origin feature/amazing-feature)Open a Pull Request
Available Tools
1 toolexecute_sqlC
Execute an SQL query on the MySQL server
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The SQL query to execute |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It fails to mention that executing SQL can be destructive (e.g., DROP, DELETE), requires authentication, or may have side effects. The agent is left unaware of potential risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and direct. However, it could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain the return value (e.g., result set, affected rows). It does not, leaving the agent without expectations. Also, no mention of safety precautions or supported SQL operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'query' parameter. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'SQL query on the MySQL server'. It is specific enough to understand the basic action, but lacks differentiation from potential sibling tools (none exist here).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus others (though no siblings exist), nor does it mention prerequisites, constraints, or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
execute_sql
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools, as there are no other tools to compare it against. The tool's purpose is clearly defined and singular.
Since there is only one tool, it inherently follows a consistent naming pattern with itself. The tool name uses a clear verb_noun format (execute_sql), which is straightforward and appropriate.
A single tool for a MySQL server is too minimal for the typical scope, which usually involves multiple operations like querying, inserting, updating, deleting, and managing databases. This server lacks the breadth expected for database interactions.
The tool surface is severely incomplete; it only provides a generic SQL execution tool without covering essential CRUD operations, schema management, or specific query types. This will likely cause agent failures due to missing functionality for common database tasks.
Related MCP Connectors
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
- dataOAuthco.thinair
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
