MySQL ReadOnly MCP Server
Provides read-only access to MySQL databases with tools for executing SELECT queries, listing tables and databases, and describing table structures with built-in security features like SQL injection protection and automatic query limits.
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 ReadOnly 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 ReadOnly MCP Server
🔒 生产就绪 的 MySQL 只读 MCP (Model Context Protocol) 服务器,提供安全、高性能的数据库查询服务。
✨ 核心特性
🔒 只读安全: 仅允许 SELECT 查询,多层安全防护
🚀 高性能: 连接池、自动LIMIT、查询优化
🛡️ 企业级安全: SQL注入防护、配置验证、SSL支持
🧪 测试覆盖: 17个全面的单元测试
📝 TypeScript: 完整类型支持
🔧 多平台支持: Claude Desktop、Claude Code、Gemini CLI
Related MCP server: MCP MySQL Server
🚀 快速开始
1. 安装依赖
git clone https://github.com/jway8975/mysql-readonly-mcp.git
cd mysql-readonly-mcp
npm install2. 配置数据库连接
cp .env.example .env编辑 .env 文件:
# 基本连接配置
MYSQL_HOST=localhost
MYSQL_PORT=3306
MYSQL_USER=your_mysql_username
MYSQL_PASSWORD=your_mysql_password
MYSQL_DATABASE=your_database_name
# SSL 配置(可选)
# MYSQL_SSL_CA=path/to/ca.pem
# MYSQL_SSL_CERT=path/to/cert.pem
# MYSQL_SSL_KEY=path/to/key.pem
# MYSQL_SSL_REJECT_UNAUTHORIZED=true3. 构建项目
npm run build4. 配置到您的AI客户端
选择以下任一配置方式:
🔧 配置方法
Claude Desktop 配置
找到 Claude Desktop 配置文件:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
添加以下配置:
{
"mcpServers": {
"mysql-readonly": {
"command": "node",
"args": ["完整路径/mysql-readonly-mcp/dist/index.js"],
"env": {
"MYSQL_HOST": "localhost",
"MYSQL_PORT": "3306",
"MYSQL_USER": "your_username",
"MYSQL_PASSWORD": "your_password",
"MYSQL_DATABASE": "your_database"
}
}
}
}⚠️ 重要提醒:
使用绝对路径,例如:
/Users/username/projects/mysql-readonly-mcp/dist/index.js确保路径中有正确的项目名称
mysql-readonly-mcp配置完成后重启 Claude Desktop
Claude Code 配置
Claude Code 会自动识别项目中的 .claude_config 文件。在项目根目录创建:
# 创建 Claude Code 配置文件
cat > .claude_config << 'EOF'
tools:
mysql-readonly:
type: mcp
command: node
args: ["./dist/index.js"]
env:
MYSQL_HOST: ${MYSQL_HOST}
MYSQL_PORT: ${MYSQL_PORT}
MYSQL_USER: ${MYSQL_USER}
MYSQL_PASSWORD: ${MYSQL_PASSWORD}
MYSQL_DATABASE: ${MYSQL_DATABASE}
EOF使用步骤:
构建项目:
npm run build设置环境变量:
export MYSQL_HOST="localhost"
export MYSQL_USER="your_username"
export MYSQL_PASSWORD="your_password"
export MYSQL_DATABASE="your_database"验证配置:
# Claude Code 会自动发现并配置 MCP 工具
claude-code "列出数据库中的所有表"Gemini CLI 配置
安装 Gemini CLI:
npm install -g @google/generative-ai-cli创建 MCP 配置文件:
mkdir -p ~/.gemini
cat > ~/.gemini/mcp_config.json << 'EOF'
{
"servers": {
"mysql-readonly": {
"command": "node",
"args": ["完整路径/mysql-readonly-mcp/dist/index.js"],
"env": {
"MYSQL_HOST": "localhost",
"MYSQL_USER": "your_username",
"MYSQL_PASSWORD": "your_password",
"MYSQL_DATABASE": "your_database"
}
}
}
}
EOF配置 Gemini CLI:
export GEMINI_MCP_CONFIG="$HOME/.gemini/mcp_config.json"
export GEMINI_API_KEY="your_gemini_api_key"测试连接:
gemini "请帮我查询用户表的前10条记录" --use-mcp mysql-readonly📋 环境变量说明
变量名 | 必需 | 默认值 | 说明 |
| ✅ | localhost | MySQL 服务器地址 |
| ❌ | 3306 | MySQL 服务器端口 |
| ✅ | - | MySQL 用户名 |
| ✅ | - | MySQL 密码 |
| ❌ | - | 默认连接的数据库 |
| ❌ | - | SSL CA 证书路径 |
| ❌ | - | SSL 客户端证书路径 |
| ❌ | - | SSL 客户端密钥路径 |
| ❌ | true | 是否拒绝未授权的 SSL 证书 |
🛠️ 可用工具
1. mysql_query - 执行SQL查询
执行只读 SQL 查询。
参数:
query(string, 必需): 要执行的 SQL 查询(仅允许 SELECT 语句)
示例:
{
"query": "SELECT * FROM users WHERE age > 18 ORDER BY name LIMIT 10"
}2. mysql_list_tables - 列出表
列出数据库中的所有表。
参数:
database(string, 可选): 数据库名称(默认使用配置的数据库)
示例:
{
"database": "my_app_db"
}3. mysql_describe_table - 表结构
获取表的结构和列信息。
参数:
table(string, 必需): 要描述的表名database(string, 可选): 数据库名称
示例:
{
"table": "users",
"database": "my_app_db"
}4. mysql_list_databases - 列出数据库
列出所有可用的数据库(排除系统数据库)。
参数:无
🔒 安全特性
多层只读验证: 严格的 SELECT 语句检查
SQL注入防护: 检测危险关键词和注入模式
自动LIMIT: 为查询添加默认限制,防止大数据集
配置验证: 启动时验证必需配置
连接池: 高效的连接管理,防止连接泄露
SSL支持: 加密数据库连接
🧪 测试
# 运行所有测试
npm test
# 运行测试并生成覆盖率报告
npm run test:coverage
# 监视模式运行测试
npm run test:watch📊 性能优化
连接池: 复用数据库连接,减少连接开销
查询限制: 自动添加 LIMIT 子句,防止大查询
智能缓存: 优化重复查询性能
内存管理: 流式处理大型结果集
🔍 故障排除
连接问题
✅ 检查 MySQL 服务是否运行
✅ 验证
.env文件中的凭据✅ 确保用户具有数据库的 SELECT 权限
✅ 检查网络连接和防火墙设置
配置问题
✅ 确保使用了绝对路径
✅ 验证环境变量设置
✅ 检查 SSL 配置(如适用)
常见错误
"Access denied": 检查用户名/密码和权限"Connection refused": MySQL 服务未运行或端口错误"Unknown database": 数据库不存在"Only SELECT statements are allowed": 尝试执行非只读查询
🚀 开发
开发模式
npm run dev构建生产版本
npm run build运行生产版本
npm start📈 版本历史
v1.0.0 - 初始版本,基础功能
v1.1.0 - 添加连接池和性能优化
v1.2.0 - 增强安全特性和测试覆盖
🤝 贡献
Fork 仓库
创建特性分支 (
git checkout -b feature/amazing-feature)提交更改 (
git commit -m 'Add amazing feature')推送到分支 (
git push origin feature/amazing-feature)创建 Pull Request
📄 许可证
本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。
🆘 支持
如果您遇到问题或有疑问,请:
🎉 感谢使用 MySQL ReadOnly MCP Server!
现在您可以安全地让 AI 助手查询您的 MySQL 数据库了。
Available Tools
4 toolsmysql_describe_tableC
Get table structure and column information
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name to describe | |
| database | No | Database name (optional, defaults to configured database) |
TDQS
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 states the tool retrieves information, implying a read-only operation, but doesn't specify whether it requires specific permissions, returns data in a particular format (e.g., JSON, table), or has any limitations like rate limits or error handling. This leaves significant gaps in understanding how the tool behaves beyond its 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with a single, clear sentence: 'Get table structure and column information.' Every word earns its place by directly stating the tool's purpose without unnecessary details or redundancy. It's appropriately sized for a simple tool, making it easy for an agent to parse quickly.
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 complexity (a read operation with 2 parameters) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what the return values include (e.g., column types, constraints) or address potential behavioral aspects like error cases. For a tool that retrieves structural data, more context on output format and usage constraints would be helpful to ensure correct invocation.
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 input schema has 100% description coverage, with clear documentation for both parameters (table and database). The description adds no additional meaning beyond what the schema provides, such as examples of table names or details on database defaults. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 tool's purpose with specific verbs ('Get table structure and column information'), which indicates it retrieves metadata about a database table. It distinguishes itself from sibling tools like mysql_list_databases and mysql_list_tables by focusing on detailed table structure rather than listing databases or tables. However, it doesn't explicitly differentiate from mysql_query, which might also return structural information depending on the query.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose mysql_describe_table over mysql_query for structural information, or clarify its role relative to mysql_list_tables. There are no explicit instructions on prerequisites, such as requiring an existing database connection, which leaves usage context implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mysql_list_databasesB
List all available databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('List'), implying it's likely safe and non-destructive, but does not disclose behavioral traits such as permissions required, rate limits, output format, or whether it includes system databases. For a tool with zero annotation coverage, this is a significant gap.
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, efficient sentence ('List all available databases') that is front-loaded and wastes no words. It directly conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
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 low complexity (0 parameters, no output schema), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral aspects like return format or constraints. It meets basic needs but leaves gaps that could hinder effective use by an AI agent.
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 input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline for 0 parameters is 4, as the description need not compensate for missing param details.
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 'List all available databases' clearly states the verb ('List') and resource ('databases'), with 'all available' providing scope. It distinguishes from siblings like mysql_list_tables (tables vs databases) and mysql_describe_table (describe vs list), though not explicitly named. However, it lacks the specific sibling differentiation that would earn a 5.
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 provides no guidance on when to use this tool versus alternatives. It does not mention siblings like mysql_list_tables for listing tables within a database or mysql_query for querying data, nor does it specify prerequisites or contexts for usage. This leaves the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mysql_list_tablesB
List all tables in the database
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database name (optional, defaults to configured database) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation (implying read-only), but doesn't mention permissions required, whether it shows system tables, pagination behavior, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality immediately.
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?
For a simple list tool with one optional parameter and no output schema, the description provides the minimum viable information about what the tool does. However, without annotations or output schema, it should ideally mention something about the return format (e.g., 'returns table names as strings') to be more complete.
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 has 100% description coverage, with the single parameter 'database' documented as optional with default behavior. The description doesn't add any parameter semantics beyond what the schema already provides, so it meets the baseline score when schema coverage is high.
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 action ('List') and resource ('all tables in the database'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like mysql_list_databases (which lists databases rather than tables) or mysql_describe_table (which describes table structure).
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 provides no guidance on when to use this tool versus alternatives like mysql_list_databases or mysql_describe_table. It lacks context about prerequisites, timing considerations, or explicit exclusions. The agent must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mysql_queryA
Execute a read-only SQL query on MySQL database
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL query to execute (SELECT statements only) |
TDQS
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. It specifies 'read-only' and mentions 'SELECT statements only,' which are useful constraints. However, it lacks details on permissions, rate limits, error handling, or result format, leaving gaps in behavioral context.
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, efficient sentence that front-loads key information ('execute a read-only SQL query') without any wasted words. It's appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description provides basic purpose and constraints but is incomplete. It doesn't cover behavioral aspects like authentication needs, result structure, or error scenarios, which are important for a database query tool. Adequate but with clear gaps.
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 description coverage is 100%, with the input schema fully documenting the 'query' parameter as 'SQL query to execute (SELECT statements only).' The description adds no additional meaning beyond this, as it restates the same constraint. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('execute a read-only SQL query') and resource ('MySQL database'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like mysql_describe_table or mysql_list_tables, which also involve database operations but for different purposes.
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 usage for read-only SQL queries, particularly SELECT statements, but doesn't provide explicit guidance on when to use this tool versus alternatives like mysql_list_tables for listing tables or mysql_describe_table for table structure. No exclusions or clear alternatives are mentioned.
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 updates
- First observed
mysql_describe_table - First observed
mysql_list_databases - First observed
mysql_list_tables - First observed
mysql_query
TDQS
Each tool has a clearly distinct purpose with no overlap: describe_table focuses on schema details, list_databases and list_tables handle enumeration at different levels, and query provides general read-only execution. An agent can easily distinguish between these four functions.
All tools follow a consistent 'mysql_verb_noun' pattern with snake_case throughout (e.g., mysql_describe_table, mysql_list_databases). This predictable naming scheme makes the tool set easy to navigate and understand.
Four tools is a reasonable number for a read-only MySQL server, covering core operations like listing databases/tables, describing structure, and executing queries. It's slightly lean but well-scoped, with no obvious bloat or missing essentials for the stated purpose.
For a read-only MySQL server, the tool set covers key operations: enumeration (databases, tables), schema inspection (describe_table), and data retrieval (query). Minor gaps might include tools for viewing indexes or constraints, but agents can work around this with queries, making it largely complete.
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
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
AI agents propose database changes as reviewable requests — no direct write access.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables secure interaction with MySQL databases, allowing AI assistants to list tables, read data, and execute SQL queries through a controlled interface.-
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to safely query MySQL databases with read-only access by default, supporting table listing, structure inspection, and SQL queries with optional write operation control.18MIT
- AlicenseNot gradedqualityDmaintenanceProvides AI assistants with secure read-only access to MySQL databases through validated SELECT queries. Supports SSL/TLS connections and implements multiple security layers to prevent data modification.1,0813MIT
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to securely interact with MySQL databases through tools for query execution, schema inspection, and transaction management. It features built-in safety controls like row limits and query validation to ensure safe and standardized database access.454-
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/zhaojw-php/mysql-readonly-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server