Skip to main content
Glama
Malove86

MCP MySQL Server

by Malove86
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

mcp-mysql-server

一个基于Model Context Protocol的MySQL数据库操作服务器。该服务器使AI模型能够通过标准化接口与MySQL数据库进行交互。

安装

npx @malove86/mcp-mysql-server

Related MCP server: MCP MySQL App

配置

服务器支持两种部署模式：

1. 本地运行模式

在MCP设置配置文件中使用命令行运行：

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["-y", "@malove86/mcp-mysql-server"],
      "env": {
        "MYSQL_HOST": "your_host",
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_DATABASE": "your_database",
        "MYSQL_PORT": "3306"
      }
    }
  }
}

2. 远程URL模式 (v0.2.2+)

指向远程运行的MCP服务器：

{
  "mcpServers": {
    "mcp-mysql-server": {
      "url": "http://your-server-address:port/mcp-mysql-server"
    }
  }
}

在远程服务器上，您需要设置环境变量后启动MCP服务器：

# 设置环境变量
export MYSQL_HOST=your_host
export MYSQL_USER=your_user
export MYSQL_PASSWORD=your_password
export MYSQL_DATABASE=your_database
export MYSQL_PORT=3306  # 可选，默认为3306

# 启动服务器
npx @malove86/mcp-mysql-server

注意：MYSQL_PORT是可选的，默认值为3306。

版本功能

v0.2.4+ 新特性

  • 多用户并发支持：服务器现在可同时处理多个用户的请求

  • 高效连接池管理：使用改进的连接池，支持最多50个并发连接

  • 请求级别隔离：每个请求都有唯一标识符，便于跟踪和调试

  • 详细日志记录：记录每个请求的执行过程和资源使用情况

  • 改进的错误处理：更精确地捕获和报告数据库错误

  • 性能优化：连接池复用和优化的连接管理提高处理速度

v0.2.2+ 特性

  • 自动数据库连接：在服务器启动时，如果设置了环境变量，会自动尝试连接数据库

  • 无需客户端参数：当使用URL模式时，客户端不需要提供数据库连接信息

  • 无感知数据库操作：可以直接使用list_tables、query等工具，无需先调用connect_db

  • 更安全：敏感的数据库凭据只在服务器端存在，不会暴露在客户端对话中

  • 优雅的容错：即使初始连接失败，后续操作会自动重试连接

可用工具

1. connect_db

使用提供的凭据建立与MySQL数据库的连接。如果已通过环境变量设置了连接，此工具是可选的。

{
  "host": "localhost",
  "user": "root",
  "password": "your_password",
  "database": "your_database",
  "port": 3306  // 可选，默认为3306
}

2. query

执行SELECT查询，支持可选的预处理语句参数。

{
  "sql": "SELECT * FROM users WHERE id = ?",
  "params": [1]  // 可选参数
}

3. list_tables

列出已连接数据库中的所有表。

{}  // 从v0.2.4开始不再需要任何参数

4. describe_table

获取特定表的结构。

{
  "table": "users"
}

功能特点

  • 安全的连接处理，自动清理

  • 支持预处理语句参数

  • 全面的错误处理和验证

  • TypeScript支持

  • 自动连接管理

  • 服务器环境变量配置

  • 支持URL远程连接模式

  • 多用户并发支持

  • 高性能连接池

性能

  • 支持最多50个并发连接（可配置）

  • 连接池自动管理，提高资源利用率

  • 详细的请求跟踪和性能监控

安全性

  • 使用预处理语句防止SQL注入

  • 通过环境变量支持安全密码处理

  • 执行前验证查询

  • 完成后自动关闭连接

  • URL模式下敏感凭据不暴露在客户端

  • 连接隔离，防止用户间数据泄露

贡献

欢迎贡献！请随时提交Pull Request到 https://github.com/Malove86/mcp-mysql-server.git

许可证

MIT

Available Tools

4 tools
connect_dbB

Connect to MySQL database (optional if environment variables are set)

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseYesDatabase name
hostYesDatabase host
passwordYesDatabase password
portNoDatabase port (optional)
userYesDatabase user

TDQS

B3.2/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 the full burden of behavioral disclosure. It mentions the optionality based on environment variables, which adds some context, but fails to describe critical behaviors such as what happens on successful/failed connections, whether the connection persists, authentication requirements beyond parameters, or any rate limits. For a tool that establishes a database connection with security implications, this is inadequate.

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, efficient sentence that front-loads the core action ('Connect to MySQL database') and adds a useful note about environment variables. There is zero waste or redundancy, making it highly concise and well-structured for quick comprehension.

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 complexity of a database connection tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a connection handle, success status), error handling, or behavioral nuances like timeouts or security constraints. This leaves significant gaps for an AI agent to understand how to use the tool effectively.

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%, meaning the input schema already documents all parameters clearly (e.g., 'Database name', 'Database host'). The description adds no additional meaning about parameters beyond implying that some might be optional via environment variables, but it doesn't specify which ones or how they interact. This meets the baseline of 3 since the schema does the heavy lifting.

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 the verb ('Connect to') and resource ('MySQL database'), making the purpose specific and understandable. It distinguishes from siblings like 'describe_table' or 'query' by focusing on establishing a connection rather than operating on an already connected database. However, it doesn't explicitly differentiate from 'list_tables', which might also require a connection, so it's not a perfect 5.

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 provides implied usage guidance by noting that connection is 'optional if environment variables are set', suggesting when it might not be needed. However, it lacks explicit instructions on when to use this tool versus alternatives (e.g., whether to rely on env vars or manual input) or any prerequisites for successful connection, leaving gaps in decision-making context.

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

describe_tableB

Get table structure

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesTable name

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits like read-only nature, side effects, or required permissions. It simply states the function without additional context.

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 extremely concise (two words), front-loaded, and gets straight to the point. However, it could benefit from a bit more detail without sacrificing brevity.

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 is simple with one parameter and no output schema, the description is minimal but adequate for a basic understanding. However, it doesn't specify what 'structure' includes (e.g., columns, types), leaving some ambiguity.

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 the only parameter 'table' described as 'Table name'. The description adds no new meaning beyond the schema, so baseline 3 is appropriate.

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 'Get table structure' clearly states the verb (Get) and resource (table structure), and distinguishes the tool from siblings like execute, list_tables, and query, which have different purposes.

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 vs alternatives, such as list_tables or query. It lacks context on when not to use it or any prerequisites.

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

list_tablesB

List all tables in the database

ParametersJSON Schema
NameRequiredDescriptionDefault
random_stringNoDummy parameter for no-parameter tools

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires database connection, returns paginated results, includes system tables, or has 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?

The description is a single, clear sentence with no wasted words. It's front-loaded with the essential information and earns its place efficiently.

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?

For a database listing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (table names only? metadata?), format, or any constraints, leaving significant gaps for an agent.

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 required parameters (one dummy parameter with 100% schema coverage). The description appropriately doesn't discuss parameters since none are needed for the core functionality, though it could mention the dummy parameter is optional.

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 the verb ('List') and resource ('all tables in the database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'query', which prevents a perfect score.

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 is provided on when to use this tool versus alternatives like 'describe_table' (for table details) or 'query' (for executing SQL). The description only states what it does, not when it's appropriate.

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

queryB

Execute a SELECT query

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsNoQuery parameters (optional)
sqlYesSQL SELECT query

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the tool executes a SELECT query, but does not explicitly confirm it is read-only, mention permission requirements, error handling, or the effect of malformed queries. The implied read-only nature is not sufficient.

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 concise sentence that front-loads the main action. It is not verbose, though it could include more context without losing conciseness. The structure is effective but minimal.

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?

There is no output schema, yet the description does not explain what the tool returns (e.g., result set structure, row count, error messages). It also lacks information on pagination, limits, or behavior with large queries, leaving the agent with significant gaps.

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 schema already documents both parameters ('sql' and 'params') adequately. The description adds no additional meaning or context about parameter usage, formatting, or constraints beyond the schema, earning a baseline score of 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 'Execute a SELECT query' clearly identifies the tool's action (execute) and resource (SELECT query). It distinguishes from sibling tools like 'execute' (which likely handles other SQL statements) and 'describe_table'/'list_tables' (which are informational).

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. It does not mention that for non-SELECT queries (e.g., INSERT, UPDATE) one should use the sibling 'execute' tool, nor does it specify any prerequisites or limitations.

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. 4 tool updatesv1.0.0
    • First observedconnect_db
    • First observeddescribe_table
    • First observedlist_tables
    • First observedquery
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: connect_db handles database connections, describe_table provides table structure, list_tables enumerates tables, and query executes SELECT queries. An agent can easily distinguish between these functions.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern (connect_db, describe_table, list_tables, query), with 'query' being a minor deviation as it lacks a noun component. Overall, the pattern is predictable and readable.

Tool Count3/5

With only 4 tools, the set feels thin for a MySQL server, lacking essential operations like INSERT, UPDATE, DELETE, or schema modifications. While the tools cover basic querying and inspection, the count is borderline for comprehensive database interaction.

Completeness2/5

There are significant gaps in the tool surface for a MySQL server. It only supports SELECT queries and table listing/structure, missing CRUD operations (create, update, delete), transaction management, and other database manipulation functions, which will cause agent failures for common tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MySQL MCP Server

    Mineru98
    A
    license
    Not graded
    quality
    C
    maintenance
    A server that enables AI models to interact with MySQL databases through a Model Control Protocol, providing tools for table creation, schema inspection, query execution, and data retrieval.
    28
    MIT

  • MCP MySQL App

    zalab-inc
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that enables AI assistants to interact with MySQL databases by executing SQL queries and checking database connectivity.
    MIT

  • MCP MySQL Server

    Atomzzm
    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
    156 npm
    MIT

  • MCP MySQL Server

    kevinbin
    F
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI models to interact with MySQL databases through a standardized interface, providing tools for querying, executing commands, and managing database schemas.
    7
    -

Appeared in Searches