Skip to main content
Glama
devakone

MySQL Query MCP Server

by devakone

MySQL Query MCP Server

npm version License: MIT

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.json

  • Anthropic 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.

MySQL Query MCP Demo

Quick Install

# Install globally with npm
npm install -g mysql-query-mcp-server

# Or run directly with npx
npx mysql-query-mcp-server

Setup 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:

  1. 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

  2. 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 environment

2. 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:

  1. Verify your database credentials in your MCP configuration

  2. Ensure the MySQL server is running and accessible

  3. Check for firewall rules blocking connections

  4. 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:

  1. Build and Test: Runs on every push to main and develop branches, and on pull requests to these branches

    • Tests the codebase with Node.js 16.x and 18.x

    • Ensures the package builds correctly

    • Validates all tests pass

  2. Release: Runs when changes are pushed to the main branch and the build/test job succeeds

    • Uses release-please to manage version bumps and changelog updates

    • Creates 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 bump

  • fix: resolve bug - Patch version bump

  • docs: update documentation - No version bump

  • chore: update dependencies - No version bump

  • BREAKING 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 tools
environmentsA

List available MySQL database environments

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
environmentYesTarget environment to get information from

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesSQL query to execute (SELECT and SHOW only)
timeoutNoQuery timeout in milliseconds (default: 30000)
environmentYesTarget environment to run the query against

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

A3.7/5.0
Disambiguation5/5

Each tool serves a distinct purpose: environments lists available databases, info retrieves database metadata, query executes read-only SQL. No overlap in functionality.

Naming Consistency4/5

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.

Tool Count5/5

Three tools is ideal for a focused MCP server that provides database environment listing, metadata retrieval, and query execution. No unnecessary tools.

Completeness4/5

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

ActivityMaintained
ResponsivenessSlow

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    A Model Context Protocol server that provides read-only access to MySQL databases, enabling LLMs to inspect database schemas and execute read-only queries.
    15,085
    2,091
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    A 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.
    5
    342
    MIT

Appeared in Searches

Latest Blog Posts

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