Which integrations are available for this server?

Provides tools for interacting with MySQL databases, including establishing connections, executing queries with prepared statements, listing tables, and describing table structures. Supports secure connection handling, multiple concurrent users, and connection pooling. Includes TypeScript support for type safety and development assistance when working with the MySQL database operations.

How do I use MCP MySQL Server?

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., "@MCP MySQL Server list all tables in the database" 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.

MCP MySQL Server

by Malove86

Overview Schema Related Servers Score Discussions

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

Name	Required	Description
`database`	Yes	Database name
`host`	Yes	Database host
`password`	Yes	Database password
`port`	No	Database port (optional)
`user`	Yes	Database 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_tableC

Get table structure

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Table name

TDQS

C2.7/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. 'Get table structure' implies a read-only operation, but it doesn't specify if this requires authentication, has rate limits, returns detailed metadata (e.g., column types, indexes), or handles errors (e.g., for non-existent tables). For a tool with zero annotation coverage, this is a significant gap in describing behavior beyond basic purpose.

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 'Get table structure' is extremely concise and front-loaded, consisting of just three words that directly convey the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse for an AI agent.

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 tool's complexity (a read operation with one parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'structure' includes (e.g., schema details), potential outputs, or behavioral aspects like error handling. For a tool that likely returns metadata, more context is needed to guide the agent 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?

The input schema has 100% description coverage, with the 'table' parameter clearly documented as 'Table name'. The description adds no additional meaning beyond this, such as format examples (e.g., case sensitivity) or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting for parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get table structure' states a clear verb ('Get') and resource ('table structure'), but it's vague about what 'structure' entails (e.g., columns, types, constraints). It doesn't differentiate from sibling tools like 'list_tables' or 'query', which might also provide structural information. This is adequate but lacks specificity and sibling distinction.

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 doesn't mention prerequisites (e.g., after connecting to the database with 'connect_db'), differentiate from 'list_tables' (which might list names only) or 'query' (which might retrieve data), or specify use cases like schema inspection. This leaves the agent without contextual usage cues.

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

Name	Required	Description	Default
`random_string`	No	Dummy 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.

queryC

Execute a SELECT query

ParametersJSON Schema

Name	Required	Description	Default
`params`	No	Query parameters (optional)
`sql`	Yes	SQL SELECT query

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 behavioral disclosure. 'Execute a SELECT query' implies a read-only operation, but it doesn't specify permissions required, potential side effects (e.g., read locks), rate limits, or error handling. This is a significant gap for a database query 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core action without unnecessary elaboration.

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 database queries and the lack of annotations and output schema, the description is incomplete. It doesn't address return values, error cases, or behavioral traits, which are crucial for an agent to use this tool effectively in a database 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?

The schema description coverage is 100%, so the input schema already documents both parameters (sql and params) adequately. The description doesn't add any meaning beyond what the schema provides, such as SQL dialect or param usage examples. Baseline 3 is appropriate when 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 'Execute a SELECT query' clearly states the verb ('Execute') and resource ('SELECT query'), making the purpose understandable. However, it doesn't differentiate from potential siblings like 'describe_table' or 'list_tables' that might also involve database operations, so it's not fully specific about when to use this versus those alternatives.

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 the sibling tools (connect_db, describe_table, list_tables). It doesn't mention alternatives, prerequisites, or exclusions, leaving the agent to infer usage context from the tool name alone.

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 updatesv1.0.0Aug 15, 2025
- First observedconnect_db
- First observeddescribe_table
- First observedlist_tables
- First observedquery

Install Server

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

TDQS

B3.1/5.0

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

ResponsivenessSyncing

Resources

Need Help?

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233

Related MCP Servers

MySQL MCP Server
Databases RAG Systems
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.
Updated a year ago (2025-03-23 12:46 UTC)
28
MIT
MCP MySQL App
Databases Developer Tools
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.
Updated a year ago (2025-03-23 09:43 UTC)
MIT
MCP MySQL Server
Databases Developer Tools Code Execution
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.
Updated 2 years ago (2025-02-22 00:55 UTC)
5
342
MIT
MCP MySQL Server
Databases Developer Tools
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.
Updated a year ago (2025-03-08 03:37 UTC)
7
-

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

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