What can you do with this server?

This server provides secure, read-only access to MySQL databases. * List available databases: Retrieve all accessible databases on the server * List tables in a database: View all tables in a specified database * Describe table schemas: Show the schema for a specific table * Execute read-only SQL queries: Run SELECT, SHOW, DESCRIBE, and EXPLAIN statements All operations include security features like query validation, timeout, and row limits to ensure safe and efficient data access.

Which integrations are available for this server?

Provides read-only access to MySQL databases with tools for listing databases, exploring table schemas, and executing secure SQL queries with protection against data modification.

How do I use MySQL Database Access?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MySQL Database Access show me the top 10 customers by total orders" 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.

en es ja ko zh

MySQL Database Access

by dpflucas

Overview Schema Related Servers Score Discussions

JavaScript

Remote

npm version

MySQL Database Access MCP Server

This MCP server provides read-only access to MySQL databases. It allows you to:

List available databases
List tables in a database
Describe table schemas
Execute read-only SQL queries

Security Features

Read-only access: Only SELECT, SHOW, DESCRIBE, and EXPLAIN statements are allowed
Query validation: Prevents SQL injection and blocks any data modification attempts
Query timeout: Prevents long-running queries from consuming resources
Row limit: Prevents excessive data return

Related MCP server: mysql-mcp-server

Installation

1. Install using one of these methods:

Install from NPM

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

# Or install locally in your project
npm install mysql-mcp-server

Build from Source

# Clone the repository
git clone https://github.com/dpflucas/mysql-mcp-server.git
cd mysql-mcp-server

# Install dependencies and build
npm install
npm run build

Install via Smithery

To install MySQL Database Access MCP Server for Claude AI automatically via Smithery:

npx -y @smithery/cli install @dpflucas/mysql-mcp-server --client claude

2. Configure environment variables

The server requires the following environment variables:

MYSQL_HOST: Database server hostname
MYSQL_PORT: Database server port (default: 3306)
MYSQL_USER: Database username
MYSQL_PASSWORD: Database password (optional, but recommended for secure connections)
MYSQL_DATABASE: Default database name (optional)

3. Add to MCP settings

Add the following configuration to your MCP settings file:

If you installed via npm (Option 1):

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["mysql-mcp-server"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

If you built from source (Option 2):

{
  "mcpServers": {
    "mysql": {
      "command": "node",
      "args": ["/path/to/mysql-mcp-server/build/index.js"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Available Tools

list_databases

Lists all accessible databases on the MySQL server.

Parameters: None

Example:

{
  "server_name": "mysql",
  "tool_name": "list_databases",
  "arguments": {}
}

list_tables

Lists all tables in a specified database.

Parameters:

database (optional): Database name (uses default if not specified)

Example:

{
  "server_name": "mysql",
  "tool_name": "list_tables",
  "arguments": {
    "database": "my_database"
  }
}

describe_table

Shows the schema for a specific table.

Parameters:

database (optional): Database name (uses default if not specified)
table (required): Table name

Example:

{
  "server_name": "mysql",
  "tool_name": "describe_table",
  "arguments": {
    "database": "my_database",
    "table": "my_table"
  }
}

execute_query

Executes a read-only SQL query.

Parameters:

query (required): SQL query (only SELECT, SHOW, DESCRIBE, and EXPLAIN statements are allowed)
database (optional): Database name (uses default if not specified)

Example:

{
  "server_name": "mysql",
  "tool_name": "execute_query",
  "arguments": {
    "database": "my_database",
    "query": "SELECT * FROM my_table LIMIT 10"
  }
}

Advanced Connection Pool Configuration

For more control over the MySQL connection pool behavior, you can configure additional parameters:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["mysql-mcp-server"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database",
        
        "MYSQL_CONNECTION_LIMIT": "10",
        "MYSQL_QUEUE_LIMIT": "0",
        "MYSQL_CONNECT_TIMEOUT": "10000",
        "MYSQL_IDLE_TIMEOUT": "60000",
        "MYSQL_MAX_IDLE": "10"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

These advanced options allow you to:

MYSQL_CONNECTION_LIMIT: Control the maximum number of connections in the pool (default: 10)
MYSQL_QUEUE_LIMIT: Set the maximum number of connection requests to queue (default: 0, unlimited)
MYSQL_CONNECT_TIMEOUT: Adjust the connection timeout in milliseconds (default: 10000)
MYSQL_IDLE_TIMEOUT: Configure how long a connection can be idle before being released (in milliseconds)
MYSQL_MAX_IDLE: Set the maximum number of idle connections to keep in the pool

Testing

The server includes test scripts to verify functionality with your MySQL setup:

1. Setup Test Database

This script creates a test database, table, and sample data:

# Set your MySQL credentials as environment variables
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password

# Run the setup script
npm run test:setup

2. Test MCP Tools

This script tests each of the MCP tools against the test database:

# Set your MySQL credentials as environment variables
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password
export MYSQL_DATABASE=mcp_test_db

# Run the tools test script
npm run test:tools

3. Run All Tests

To run both setup and tool tests:

# Set your MySQL credentials as environment variables
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password

# Run all tests
npm test

Troubleshooting

If you encounter issues:

Check the server logs for error messages
Verify your MySQL credentials and connection details
Ensure your MySQL user has appropriate permissions
Check that your query is read-only and properly formatted

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

4 tools

describe_tableB

Show the schema for a specific table

ParametersJSON Schema

Name	Required	Description	Default
`database`	No	Database name (optional, uses default if not specified)
`table`	Yes	Table name

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states 'show the schema' without disclosing behavioral traits like read-only nature, required permissions, idempotency, or error handling. This is insufficient for a tool with zero annotation coverage.

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 with no waste. However, it could include a brief note on sibling differentiation or usage context, but overall it is appropriately concise.

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?

For a simple introspection tool with two parameters and no output schema, the description is adequate but lacks details on return format, error cases, or prerequisites (e.g., table must exist). It does not reference siblings, leaving the agent to infer context.

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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema (e.g., clarifying what 'table' or 'database' refer to). It does not enhance parameter semantics.

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?

"Show the schema for a specific table" uses a specific verb and resource, and clearly distinguishes from siblings like list_tables and execute_query.

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 usage for schema retrieval, but provides no explicit guidance on when to use this tool vs alternatives like list_tables (which only lists names) or execute_query (for custom queries). No when-not-to-use or alternative mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_queryB

Execute a read-only SQL query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query (only SELECT, SHOW, DESCRIBE, and EXPLAIN statements are allowed)
`database`	No	Database name (optional, uses default if not specified)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It declares read-only, which is a key behavioral trait, but does not disclose result format, performance, or error handling. The parameter schema already specifies allowed statements, so description adds little beyond that.

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?

Single sentence of 5 words with no redundancy. Front-loaded and efficient.

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?

Given no output schema, the description does not explain the return format of the executed query. It also omits potential side effects (though read-only) and error scenarios. For a query tool, this is somewhat acceptable but could be more complete.

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%, with clear descriptions for both parameters. The tool description adds no additional parameter information beyond what the schema provides. Baseline 3.

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' and the resource 'read-only SQL query', distinguishing it from sibling tools like describe_table which describe schema. The title is null but description suffices.

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 explicit guidance on when to use this tool over alternatives. It does not mention that for table metadata users should use describe_table or list_tables. The description is standalone without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_databasesA

List all accessible databases on the MySQL server

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates it returns 'all accessible databases', which is a basic behavioral trait. No annotations are provided, so the disclosure is minimal but adequate for a simple read operation. It does not mention permissions, system databases, or performance implications.

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?

A single sentence of 9 words front-loaded with the core purpose. No extraneous information, every word earns its place.

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 no parameters, no output schema, and no annotations, the description covers the essential purpose. It could be enhanced by clarifying 'accessible' (user privileges) or whether system databases are included, but it is sufficient for a basic list operation.

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 zero parameters, so the description need not add parameter details beyond what the schema provides. Per guidelines, baseline is 4 for 0 parameters.

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 'List' and resource 'databases', specifying scope 'all accessible' and context 'MySQL server'. It effectively differentiates from sibling tools like list_tables and describe_table.

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?

The description does not provide any guidance on when to use this tool versus alternatives. No mention of prerequisites, when-not, or references to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesC

List all tables in a specified database

ParametersJSON Schema

Name	Required	Description	Default
`database`	No	Database name (optional, uses default if not specified)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic function but does not elaborate on side effects, read-only nature, error handling (e.g., what if the database doesn't exist), or the meaning of 'default' database. This lack of detail limits transparency.

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 sentence with no redundant information. It is concise and to the point, using no filler words.

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?

Given the tool's simplicity (one optional parameter, no output schema), the description is minimally adequate. However, it misses details like what 'default' database refers to or whether the tool requires any privileges. It does not fully prepare the agent for all usage scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter 'database', which already explains its optionality and default behavior. The description adds no additional semantic value beyond restating 'in a specified database', which is already implicit from the schema.

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 'List all tables in a specified database' clearly identifies the action (list) and resource (tables), distinguishing it from sibling tools like list_databases (lists databases) and describe_table (describes a single table). However, the word 'specified' implies the database parameter is required, while the schema marks it as optional, causing minor ambiguity.

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?

The description provides no guidance on when to use this tool versus alternatives such as describe_table or execute_query. There is no mention of prerequisites, limitations, or explicit when-to-use/when-not-to-use instructions, leaving the agent to infer appropriate usage.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.3May 6, 2026
- Addeddescribe_table
- Addedexecute_query
- Addedlist_databases
- Addedlist_tables

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a distinct purpose: listing databases, listing tables, describing a table schema, and executing read-only queries. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (describe_table, execute_query, list_databases, list_tables), making them predictable.

Tool Count4/5

Four tools for a read-only database access server is appropriate. It covers the essential introspection and querying needs without being too sparse or excessive.

Completeness4/5

The tool surface covers listing databases, tables, describing schemas, and executing queries—complete for read-only access. Minor gaps like viewing current database or query metadata are acceptable.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292
mcp-grafanaOAuth
io.github.grafana
An MCP server giving access to Grafana dashboards, data and more.
Observability Monitoring
33,416

Related MCP Servers

mysql-mcp
Databases Developer Tools
rlembo06
A
license
Not graded
quality
D
maintenance
A lightweight MCP server providing safe, read-only access to MySQL databases. It enables users to query multiple MySQL instances securely while preventing write operations.
Updated 5 months ago (2026-04-13 14:19 UTC)
1,090
MIT
mysql-mcp-server
mukul975
A
license
Not graded
quality
D
maintenance
A production-ready MCP server for MySQL database operations, providing secure HTTP endpoints for read-only queries, performance analysis, and server monitoring.
Updated 2 days ago (2026-09-04 04:00 UTC)
121
16
MIT
MySQL Ops MCP
Databases Developer Tools
lemonq3q
F
license
Not graded
quality
C
maintenance
A generic MCP server for MySQL operations, enabling listing databases/tables, describing schemas, running read-only SQL, and optionally executing write SQL with logging.
Updated 2 months ago (2026-07-06 00:46 UTC)
1
-
mysql-mcp-server-all
Databases Developer Tools
ByteTora
A
license
A
quality
C
maintenance
A read-only MySQL MCP server supporting stdio, SSE, and Streamable HTTP transports, enabling secure querying and schema inspection of MySQL databases from MCP clients.
Updated a month ago (2026-08-11 02:05 UTC)
3
MIT

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 July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/dpflucas/mysql-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server