MySQL Query MCP Server
The MySQL Query MCP Server enables AI assistants to perform read-only operations on MySQL databases:
Execute read-only queries (SELECT, SHOW, DESCRIBE) across configured environments (local, development, staging, production)
Retrieve database information (server version, connection status, variables, available databases)
List all configured database environments
Support query execution with configurable timeout settings
Provide secure access through SSL connections
Work with predefined environments and isolated connection pools
Interface with AI tools through the Model Context Protocol (MCP)
Enables read-only MySQL database queries for AI assistants, with support for SELECT, SHOW and DESCRIBE operations across multiple environments
Click on "Install 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 Query MCP Servershow me the top 10 customers by total purchases"
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 Query MCP Server
A Model Context Protocol (MCP) server that provides read-only MySQL database queries for AI assistants. Execute queries, explore database structures, and investigate your data directly from your AI-powered tools.
Supported AI Tools
This MCP server works with any tool that supports the Model Context Protocol, including:
Cursor IDE: Set up in
.cursor/mcp.jsonAnthropic Claude: Use with a compatible MCP client
Other MCP-compatible AI assistants: Follow the tool's MCP configuration instructions
Related MCP server: MCP Server for MySQL
Features & Limitations
What It Does
✅ Execute read-only MySQL queries (SELECT, SHOW, DESCRIBE only)
✅ Work with predefined environments (local, development, staging, production)
✅ Provide database information and metadata
✅ List available database environments
✅ Support SSL connections for secure database access
✅ Implement query timeouts to prevent long-running operations
What It Doesn't Do
❌ Execute write operations (INSERT, UPDATE, DELETE, CREATE, ALTER, etc.)
❌ Support custom environment names (limited to local, development, staging, production)
❌ Provide database design or schema generation capabilities
❌ Function as a full database management tool
This tool is designed specifically for data investigation and exploration through read-only queries. It is not intended for database administration, schema management, or data modification.

Quick Install
# Install globally with npm
npm install -g mysql-query-mcp-server
# Or run directly with npx
npx mysql-query-mcp-serverSetup Instructions
Configure Your AI Tool to Use the MCP Server
Create or edit your MCP configuration file (e.g., .cursor/mcp.json for Cursor IDE):
Basic Configuration:
{
"mysql": {
"name": "MySQL Query MCP",
"description": "MySQL read-only query access through MCP",
"type": "bin",
"enabled": true,
"bin": "mysql-query-mcp"
}
}Comprehensive Configuration with Database Credentials:
{
"mysql": {
"command": "npx",
"args": ["mysql-query-mcp-server@latest"],
"env": {
"LOCAL_DB_HOST": "localhost",
"LOCAL_DB_USER": "root",
"LOCAL_DB_PASS": "<YOUR_LOCAL_DB_PASSWORD>",
"LOCAL_DB_NAME": "your_database",
"LOCAL_DB_PORT": "3306",
"DEVELOPMENT_DB_HOST": "dev.example.com",
"DEVELOPMENT_DB_USER": "<DEV_USER>",
"DEVELOPMENT_DB_PASS": "<DEV_PASSWORD>",
"DEVELOPMENT_DB_NAME": "your_database",
"DEVELOPMENT_DB_PORT": "3306",
"STAGING_DB_HOST": "staging.example.com",
"STAGING_DB_USER": "<STAGING_USER>",
"STAGING_DB_PASS": "<STAGING_PASSWORD>",
"STAGING_DB_NAME": "your_database",
"STAGING_DB_PORT": "3306",
"PRODUCTION_DB_HOST": "prod.example.com",
"PRODUCTION_DB_USER": "<PRODUCTION_USER>",
"PRODUCTION_DB_PASS": "<PRODUCTION_PASSWORD>",
"PRODUCTION_DB_NAME": "your_database",
"PRODUCTION_DB_PORT": "3306",
"DEBUG": "false",
"MCP_MYSQL_SSL": "true",
"MCP_MYSQL_REJECT_UNAUTHORIZED": "false",
"MYSQL_TIMEZONE": "Z"
}
}
}Choosing the Right Configuration Approach
There are two ways to configure the MySQL MCP server:
Binary Configuration (
type: "bin",bin: "mysql-query-mcp")When to use: When you've installed the package globally (
npm install -g mysql-query-mcp-server)Pros: Simpler configuration
Cons: Requires global installation
Command Configuration (
command: "npx",args: ["mysql-query-mcp-server@latest"])When to use: When you want to use the latest version without installing it globally
Pros: No global installation required, all configuration in one file
Cons: More complex configuration
Choose the approach that best fits your workflow. Both methods will work correctly with any AI assistant that supports MCP.
Important Configuration Notes
You must use the full environment names: LOCAL_, DEVELOPMENT_, STAGING_, PRODUCTION_
Abbreviations like DEV_ or PROD_ will not work
Global settings like DEBUG, MCP_MYSQL_SSL apply to all environments
At least one environment (typically "local") must be configured
You only need to configure the environments you plan to use
For security reasons, consider using environment variables or secure credential storage for production credentials
DATETIME, DATE, and TIMESTAMP columns are returned as strings to preserve the exact value stored in MySQL without host timezone shifting
Configuration Options
Environment Variable | Description | Default |
DEBUG | Enable debug logging | false |
[ENV]_DB_HOST | Database host for environment | - |
[ENV]_DB_USER | Database username | - |
[ENV]_DB_PASS | Database password | - |
[ENV]_DB_NAME | Database name | - |
[ENV]_DB_PORT | Database port | 3306 |
[ENV]_DB_SSL | Enable SSL connection | false |
MCP_MYSQL_SSL | Enable SSL for all connections | false |
MCP_MYSQL_REJECT_UNAUTHORIZED | Verify SSL certificates | true |
MYSQL_TIMEZONE | Timezone mysql2 uses when sending JavaScript Date values in queries | Z |
Date and Time Values
MySQL DATETIME, DATE, and TIMESTAMP columns are returned as raw strings, for example 2026-05-13 16:12:08. This preserves the exact stored value and prevents the Node host timezone from shifting results during JSON serialization.
MYSQL_TIMEZONE defaults to Z (UTC). Override it only if your application intentionally sends JavaScript Date objects to MySQL using a different connection timezone.
Callers that already handle date/time values as strings do not need to change. Callers that previously expected JavaScript Date objects from this MCP server should parse the returned string explicitly.
Integration with AI Assistants
Your AI assistant can interact with MySQL databases through the MCP server. Here are some examples:
Example queries:
Can you use the query tool to show me the first 10 users from the database? Use the local environment.I need to analyze our sales data. Can you run a SQL query to get the total sales per region for last month from the development database?Can you use the info tool to check what tables are available in the staging database?Can you list all the available database environments we have configured?Using MySQL MCP Tools
The MySQL Query MCP server provides three main tools that your AI assistant can use:
1. query
Execute read-only SQL queries against a specific environment:
Use the query tool to run:
SELECT * FROM customers WHERE signup_date > '2023-01-01' LIMIT 10;
on the development environment2. info
Get detailed information about your database:
Use the info tool to check the status of our production database.3. environments
List all configured environments from your configuration:
Use the environments tool to show me which database environments are available.Available Tools
The MySQL Query MCP server provides three main tools:
1. query
Execute read-only SQL queries:
-- Example query to run with the query tool
SELECT * FROM users LIMIT 10;Supported query types (strictly limited to):
SELECT statements
SHOW commands
DESCRIBE/DESC tables
2. info
Get detailed information about your database:
Server version
Connection status and uptime
Selected server variables (character set, timezone, timeouts, connection limits)
Connection counters (threads connected, threads running, query counts)
Available databases
The full SHOW VARIABLES output and the server process list are deliberately not
reported. See SECURITY.md.
3. environments
List all configured environments from your configuration:
Use the environments tool to show me which database environments are available.Security Considerations
✅ Only read-only queries are allowed (SELECT, SHOW, DESCRIBE)
✅ Each environment has its own isolated connection pool
✅ SSL connections are supported for production environments
✅ Query timeouts prevent runaway operations
✅ Tool responses never include configuration values, and are checked for secrets before being returned
⚠️ Credentials are still configured as plaintext environment variables in your MCP client config. Keep that file out of version control
If you used a version before 1.3.0
Versions up to and including 1.2.2 returned database credentials in the environments
tool response, which means they could have been written into an AI chat transcript.
Rotate any credential you configured through this server. Details are in
SECURITY.md.
Troubleshooting
Connection Issues
If you're having trouble connecting:
Verify your database credentials in your MCP configuration
Ensure the MySQL server is running and accessible
Check for firewall rules blocking connections
Enable debug mode by setting DEBUG=true in your configuration
Common Errors
Error: No connection pool available for environment
Make sure you've defined all required environment variables for that environment
Check that you're using one of the supported environment names (local, development, staging, production)
Error: Query execution failed
Verify your SQL syntax
Check that you're only using supported query types (SELECT, SHOW, DESCRIBE)
Ensure your query is truly read-only
For more comprehensive troubleshooting, see the Troubleshooting Guide.
For examples of how to integrate with AI assistants, see the Integration Examples.
For implementation details about the MCP protocol, see the MCP README.
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
CI/CD and Release Process
This project uses GitHub Actions for continuous integration and automated releases.
CI/CD Workflow
The CI/CD pipeline consists of:
Build and Test: Runs on every push to
mainanddevelopbranches, and on pull requests to these branchesTests the codebase with Node.js 16.x and 18.x
Ensures the package builds correctly
Validates all tests pass
Release: Runs when changes are pushed to the
mainbranch and the build/test job succeedsUses
release-pleaseto manage version bumps and changelog updatesCreates a release PR with version changes based on conventional commits
Automatically publishes to npm when a release PR is merged
Release Process
The project follows Semantic Versioning:
Major version: Breaking changes (non-backward compatible)
Minor version: New features (backward compatible)
Patch version: Bug fixes and minor improvements
Commits should follow the Conventional Commits format:
feat: add new feature- Minor version bumpfix: resolve bug- Patch version bumpdocs: update documentation- No version bumpchore: update dependencies- No version bumpBREAKING CHANGE: change API- Major version bump
When you push to main, release-please will analyze commits and automatically create or update a release PR with appropriate version bumps and changelog entries.
License
This project is licensed under the MIT License - see the LICENSE file for details.
Author
Abou Koné - Engineering Leader and CTO
For more information or support, please open an issue on the GitHub repository.
Available Tools
3 toolsenvironmentsA
List available MySQL database environments
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates a read-only listing operation with no side effects. With no annotations provided, this straightforward disclosure is sufficient.
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, well-structured sentence with no unnecessary words. It is front-loaded with the action and resource.
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 tool's simplicity (no parameters, no output schema), the description adequately explains its purpose. It could optionally hint at the format of the list, but not required.
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 tool has no parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed; baseline score for zero parameters is 4.
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 uses the specific verb 'List' and clearly identifies the resource as 'available MySQL database environments'. It distinguishes from sibling tools 'info' and 'query' by implying this is a listing operation.
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?
The description implies use when the agent needs to see available environments before running queries or getting info, but does not explicitly state when to use or avoid this tool relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
infoC
Get information about MySQL databases
| Name | Required | Description | Default |
|---|---|---|---|
| environment | Yes | Target environment to get information from |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation ('Get information') without explicit statements about safety or side effects. It fails to disclose any behavioral traits beyond the basic action.
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, no wasted words, and appropriately sized for a simple tool. It is front-loaded with the core action.
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 and the tool's simple nature, the description is too minimal. It does not specify what kind of information is returned or any additional context, leaving the agent underinformed.
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 schema provides 100% coverage with a description for the 'environment' parameter. The tool description adds no additional semantics beyond what is in the schema, earning the baseline score.
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 'Get information about MySQL databases,' specifying the verb and resource. However, it does not differentiate from siblings like 'query', which might also retrieve data.
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 guidance on when to use this tool versus alternatives like 'query' or 'environments'. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
queryA
Execute read-only SQL queries against MySQL databases
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute (SELECT and SHOW only) | |
| timeout | No | Query timeout in milliseconds (default: 30000) | |
| environment | Yes | Target environment to run the query against |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It declares read-only behavior but does not elaborate on error handling, authentication, rate limits, or result limits. The constraint 'SELECT and SHOW only' is only in the schema, not the description.
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, front-loaded sentence with no superfluous words. It efficiently conveys the tool's purpose.
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?
The description lacks details about output format, pagination, or behavior under errors/timeouts. Given no output schema, the agent might need more context. However, for a simple query tool, the description is minimally sufficient.
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?
Schema coverage is 100%, so all parameters have descriptions. The description adds no extra parameter semantics beyond the schema, which is adequate but not additive.
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', the resource 'SQL queries', and the context 'against MySQL databases', specifying 'read-only'. This distinguishes it well from its siblings 'environments' and 'info'.
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?
The description implicitly indicates usage for read-only SQL queries but does not explicitly state when to use or avoid it, nor does it mention alternative tools. However, the sibling tools are distinct enough that ambiguity is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool serves a distinct purpose: environments lists available databases, info retrieves database metadata, query executes read-only SQL. No overlap in functionality.
All tool names are single lowercase words, which is consistent, but they don't follow a strong verb_noun pattern. Names are clear and unambiguous.
Three tools is ideal for a focused MCP server that provides database environment listing, metadata retrieval, and query execution. No unnecessary tools.
The tool surface covers the core workflow of exploring and querying databases. Missing explicit schema or table listing tools, but info may partially address this.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceA Model Context Protocol server that provides read-only access to MySQL databases, enabling LLMs to inspect database schemas and execute read-only queries.15,0852,091MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server providing read-only access to MySQL databases, enabling LLMs to inspect database schemas and execute read-only queries.191MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides read-only access to MySQL databases, enabling LLMs to inspect database schemas and execute read-only queries.15,085MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables AI models to interact with MySQL databases, providing tools for querying, executing statements, listing tables, and describing table structures.5342MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devakone/mysql-query-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server