本项目基于 designcomputer/mysql_mcp_server 二次开发。原有功能（工具、Prompts、环境变量配置等）请参考上游文档，本文只介绍本仓库新增的功能：
Web 管理页面 — 浏览器中管理多个数据库连接，无需改配置文件重启；支持配置导出/导入备份与一键连通性体检
多数据库别名 — 一个服务端同时服务多个库，客户端按别名接入
读/写双账号 — 查询走只读账号，写操作确认后走读写账号
SQL 三级判定 — 每条语句自动判定 读 / 写 / 删除
写操作双通道确认 — MCP elicitation 弹窗，或聊天内令牌二次确认
令牌冷静期 — 签发后 6 秒内不可使用，杜绝绕过用户确认
删除权限开关 — DELETE / TRUNCATE / DROP 默认拒绝，需显式开启
DDL 权限开关 — CREATE / ALTER / RENAME / GRANT / REVOKE 默认拒绝，按别名显式开启
全表写警告 — UPDATE / DELETE 无 WHERE 时确认文案附加全表影响警示
写免确认开关 — 可选让 INSERT / UPDATE 等写操作跳过二次确认
写操作审计 — 所有写操作尝试（含被拒）记录在页面与日志文件，含状态/耗时/影响行数，可选用读审计
执行错误入库 — 打到数据库的执行失败记入 logs/error_log.db 的 mcp_error_log 表（含别名、工具、SQL、数据库报错），管理页面可查可筛选；UPDATE/DELETE 无权限与确认拦截不入库，默认保留 90 天
查询防护 — SELECT 结果默认截断到 500 行、语句默认 60 秒超时，防止大查询拖垮服务
连接池 — MySQL 连接按配置指纹复用（默认池 3，可按别名配置/禁用）
SSH 隧道常驻 — 按条目复用隧道、本地端口自动分配，管理页测试连接同样走隧道
search_schema 工具 — 按关键字搜索表名/列名/注释，大库定位表不用全量拉 schema
Streamable HTTP — 新增 POST /mcp?alias=别名 无状态传输，兼容不支持 SSE 的客户端
达梦 DM8 支持 — 与 MySQL 并存，一个服务端可同时管理 MySQL 与达梦库（需安装 dmPython 驱动）
Linux 单文件部署 — 打包为不依赖 glibc 版本的静态可执行文件 + 启停脚本
以 SSE 模式启动（管理页面与别名功能仅在 SSE 模式下可用）：
# Windows PowerShell
$env:MCP_TRANSPORT="sse"; $env:MCP_SSE_PORT="8000"; python -m mysql_mcp_server
# Linux/macOS
MCP_TRANSPORT=sse MCP_SSE_PORT=8000 python -m mysql_mcp_server启动后打开管理页面：http://127.0.0.1:8000/admin/
Related MCP server: mysql-mcp-server
一键打包为可导入 MCP 客户端（如 Claude Desktop）的安装包：
bash scripts/build_mcpb.sh产物为 dist/mysql-mcp-server.mcpb（约 120KB 源码包，uv 类型：依赖由客户端安装，跨平台）。安装时在界面填写 MySQL 主机、端口、用户名、密码、数据库名（可空，即多库模式）与删除开关即可，无需手写 JSON 配置。包内为 stdio 单库模式（读/写同一账号，走环境变量兼容配置）；如需别名多库、SSE 管理页、达梦支持，请用源码/SSE 方式部署。
说明：仓库根目录遗留的旧
mysql-mcp-server.mcpb为上游 v0.3.1 产物，已过时，请使用新打包的dist/产物。
页面从上到下分为三个区域：
区域 | 功能 |
数据库列表 | 每个别名一张卡片：标记默认库、显示删除权限状态；操作按钮 编辑、测试连接（读账号）、测试写账号、删除；右上角 ＋ 添加数据库 |
客户端接入说明 | 自动生成每个别名的 SSE 接入地址，点击即复制，附 TRAE / Claude Desktop 配置指引 |
写操作审计 | 最近 100 条写操作记录（时间、别名、SQL 类型、确认通道、状态、SQL 摘要），可刷新 |
局域网访问：管理页面默认仅限本机（回环）访问。设置环境变量
ADMIN_TOKEN后，局域网客户端需在页面输入该令牌（或请求带X-Admin-Token头）才能访问。
测试连接：先验证实例连通与账号认证，再校验配置的数据库名（达梦为模式名）是否存在且对账号可见；数据库名留空的多库模式跳过库名校验。
点击 编辑（或 ＋ 添加数据库）打开配置表单：
配置项 | 说明 |
别名 | 客户端接入时 |
数据库类型 |
|
主机 / 端口 / 数据库名 / 字符集 | 连接目标。数据库名留空即多数据库模式 |
查询用户（只读） | 执行 SELECT / SHOW / DESCRIBE / EXPLAIN 的账号 |
操作用户（读写） | 确认通过后执行 DML / DDL 的账号 |
写操作策略 |
|
UPDATE 等写操作免二次确认 | 勾选后 INSERT / UPDATE / CREATE / ALTER 等写操作直接执行，不再弹确认（删除类仍需确认与删除权限） |
允许删除操作 | DELETE / TRUNCATE / DROP 的总开关，默认关闭。开启后操作账号可修改表字段、新建表、删除表，数据不可恢复 |
SSH 隧道（高级） | 可选经由跳板机连接数据库 |
配置保存后立即生效：新连接直接使用新配置，已连接的会话需重连。密码在接口返回中始终以 **** 脱敏，编辑时留空表示不修改。
配置持久化在 config/databases.json（可用 MYSQL_MCP_CONFIG_DIR 重定向）。当该文件没有任何条目时，自动回退为读取 MYSQL_* 环境变量的单库模式（读写同一账号），与上游行为兼容。
客户端 MCP 配置的 URL 格式：
http://<主机>:<端口>/sse?alias=<别名>省略 alias 时使用默认别名
TRAE：MCP 市场 → 添加自定义服务器 → 类型选 SSE，URL 填上述地址
Claude Desktop：在 claude_desktop_config.json 的 mcpServers 中配置 {"type":"sse","url":"http://主机:端口/sse?alias=别名"}
服务端对每条 SQL 做三级判定：读（SELECT / SHOW / DESCRIBE / EXPLAIN）、写（INSERT / UPDATE / CREATE / ALTER 等）、删除（DELETE / TRUNCATE / DROP）。支持 CTE（WITH ...）取主语句关键字、剥离注释、EXPLAIN ANALYZE 按实际语句递归判定；无法判定的一律按写处理。
执行流程：
读 → 直接用查询账号执行。
删除 → 未开启「允许删除操作」直接拒绝；开启后进入与写相同的确认流程。
写 / 删除（未开免确认）→ 依次尝试两个确认通道：
通道一：elicitation 弹窗 — 客户端支持 MCP elicitation 时，弹出服务端确认框展示完整 SQL，接受则用操作账号执行，拒绝则中止。
通道二：聊天内令牌二次确认 — 客户端不支持 elicitation 时（按写策略降级）：
服务端返回 confirm_token，并提示 AI 向用户完整展示 SQL、征求同意；
用户同意后，AI 用相同 query 携带 confirm_token 重新调用 execute_sql；
令牌校验通过 → 用操作账号执行。
令牌特性：一次性、5 分钟有效、绑定别名与 SQL；签发后 6 秒内使用会被拒绝且令牌作废（冷静期）——防止客户端拿到令牌后跳过用户确认立即执行，强制经过真实的用户授权环节。
写（开启免二次确认）→ 直接用操作账号执行，审计记录标记 skip_confirm。
在管理页面添加数据库时选择数据库类型为 达梦 DM8，与 MySQL 库并存于同一服务端。安装驱动后即可使用：
pip install "mysql_mcp_server[dameng]"
# 或直接安装驱动
pip install dmPython要点：
达梦默认端口 5236（表单留空端口时自动使用）；“数据库名”对应达梦的模式名（schema），留空则进入多模式模式（列出可访问模式，过滤 SYS 等系统用户）
元数据查询走达梦数据字典：表列表 USER_TABLES / ALL_TABLES，列信息 ALL_TAB_COLUMNS（可空性 Y/N 自动对齐为 YES/NO），标识符使用双引号引用
execute_sql、get_schema_info、get_table_sample、search_schema 四个工具行为与 MySQL 一致（含三级判定、双通道确认、审计）；alias 参数同样支持别名与项目名称两种匹配
未安装 dmPython 时连接达梦条目会返回明确的安装提示，不影响 MySQL 条目正常使用
单文件打包（build_remote.sh）已包含 --collect-all dmPython，无需额外处理驱动动态库
所有写操作尝试（无论成功、被拒还是等待确认）都会记录：
管理页面「写操作审计」表格实时查看（内存中最近 100 条）
磁盘文件 logs/audit.log 追加写入，格式：时间 | 别名 | SQL类型 | 确认通道 | 状态 | SQL
确认通道取值：elicitation（弹窗确认）、token（令牌确认）、skip_confirm（免确认执行）、-（未进入确认环节）；状态包含 executed、pending_token、token_too_early、invalid_token、user_decline、rejected_delete_disabled、blocked_policy 等。
凡是真正发往数据库并返回错误的调用（execute_sql、get_schema_info、get_table_sample、资源列表/读取）都会入库：
存储：本机 SQLite logs/error_log.db 的 mcp_error_log 表（id / time / alias / tool / sql_type / role / sql / db_error，SQL 与错误信息各截断 2000 字符），目标库不可用也不影响记录；另有内存最近 100 条与 logs/error_log_fallback.log 兜底
排除：确认流程拦截（未开启删除权限、令牌无效/过期/冷静期、用户拒绝、elicitation_only）在执行前即返回，不会入库；数据库返回的 UPDATE/DELETE 无权限错误（command denied）同样不入库
查看：管理页面「执行错误日志」表格，或 GET /admin/api/errors?limit=100&alias=别名（最新在前）
提供一键脚本将服务打包为单文件静态可执行程序（staticx 静态化，不依赖目标机器 glibc 版本，CentOS 7 等老系统可直接运行）：
# 在 Linux 构建机上（需 python3 >= 3.11）
bash scripts/build_remote.sh脚本完成：venv 隔离 → 安装依赖 → PyInstaller 打包（--collect-all mysql 收集 mysql-connector 运行时动态加载的认证插件与错误消息数据）→ staticx 静态化 → patchelf 清理 RPATH。产物在 dist/ 下三个文件：
文件 | 用途 |
| 静态可执行文件（约 35MB） |
| 启动脚本（后台运行，支持 |
| 停止脚本 |
部署到目标服务器：
./start.sh # 启动，输出管理页面与 SSE 地址
./stop.sh # 停止说明：若目标机器 glibc 版本与构建机一致或更新，也可用
scripts/build.sh（仅 PyInstaller、不做 staticx）产出体积更小的普通单文件。认证兼容：单文件部署下 MySQL 连接默认使用纯 Python 实现（
use_pure=True），以避开 mysql-connector 26.7+ C 扩展在冻结环境中找不到自带认证插件（mysql_native_password等）的问题；如需强制 C 扩展，设置环境变量MYSQL_USE_PURE=false。
Execute a SQL statement against the MySQL server. Use for SELECT, DML (INSERT/UPDATE/DELETE), SHOW, DESCRIBE, and ad-hoc queries. Supports cross-database queries using database.table notation. Single statements only — use fully qualified names instead of USE statements. Write/delete statements require user confirmation: depending on the client, either a confirmation prompt appears, or the first call returns a confirm_token — show the SQL to the user, and after explicit consent re-call with the same query plus confirm_token. Use the optional alias parameter to target a different configured database within a single connection.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | 数据库别名，或管理页面 /admin 中为该库配置的项目名称（项目文件夹名）。在单个 SSE 连接内通过此参数切换不同库；省略时用连接 URL ?alias 指定的别名或默认别名。建议优先传当前项目文件夹名自动匹配对应数据库。 | |
| query | Yes | The SQL statement to execute. Single statements only. | |
| confirm_token | No | One-time confirmation token returned by a previous write attempt. Pass it with the SAME query after the user explicitly approved the SQL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructive, and the description substantially expands on this by detailing the confirmation workflow: a prompt appears, or a confirm_token is returned and must be re-sent with the same query after explicit user consent. It also discloses single-statement-only behavior and cross-database support, going well beyond the annotation flags.
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 dense but well-structured, front-loading the main purpose, then constraints, confirmation flow, and alias behavior. Every clause contributes essential information without redundancy, and its length is justified by 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?
For a destructive SQL tool with no output schema, this description covers all critical operational aspects: statement types, single-statement enforcement, cross-db notation, the confirmation protocol, and alias usage. The only gap is return-format details, but that is standard SQL client behavior and not essential for 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 schema already covers all parameters, so the baseline is 3. The description adds meaningful semantics for confirm_token (one-time token from a prior write attempt, pass with the same query after approval) and alias (switch database within a single connection), enriching the raw schema definitions.
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 identifies the tool as executing SQL statements against a MySQL server and enumerates supported statement types (SELECT, DML, SHOW, DESCRIBE, ad-hoc queries). It is distinct from sibling inspection tools by its general-purpose scope, though it does not explicitly name or contrast them.
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?
It provides direct usage guidance by enumerating applicable statement types and imposing constraints: single statements only, fully qualified names instead of USE statements, and confirmation for writes/deletes. It does not explicitly discuss when to prefer sibling tools like get_schema_info, but the implied distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get column metadata for a table or all tables in the configured database: column names, data types, nullability, default values, and comments. Call this before querying an unfamiliar table. Omit table_name to see all tables at once. Accepts bare table names (uses MYSQL_DATABASE) or database.table for cross-database lookups. Use alias to target a different configured database.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | 数据库别名，或管理页面 /admin 中为该库配置的项目名称（项目文件夹名）。在单个 SSE 连接内通过此参数切换不同库；省略时用连接 URL ?alias 指定的别名或默认别名。建议优先传当前项目文件夹名自动匹配对应数据库。 | |
| table_name | No | Optional: bare table name, or database.table for a cross-database lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context: it can return metadata for all tables when table_name is omitted, accepts database.table for cross-database lookups, and uses bare names with MYSQL_DATABASE, plus alias switching behavior. This goes beyond the annotations without contradicting them.
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 compact and front-loaded with the core purpose, then provides usage details in logical order. Every sentence contributes useful information without excessive verbosity.
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 simplicity, annotations, and full schema coverage, the description is complete enough for an agent to select and invoke it. It covers scoping, naming, and alias switching. Minor gaps like return format are acceptable since no output schema exists and the tool is a read-only metadata lookup.
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%, so the schema documents both parameters. The description still adds meaning by explaining the semantic effects of omitting table_name, the database.table format, bare-name resolution via MYSQL_DATABASE, and alias behavior.
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 retrieves column metadata (names, data types, nullability, defaults, comments) for a table or all tables, with a specific resource and verb. It also distinguishes itself from sibling tools by positioning it as the pre-query metadata lookup.
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 explicitly says to call this before querying an unfamiliar table, explains how to list all tables, and notes cross-database usage and alias-based targeting. This provides clear contextual guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a small sample of rows from a table to understand its data format and content. Use alongside get_schema_info before writing complex queries. Accepts bare table names (uses MYSQL_DATABASE) or database.table for cross-database lookups. Use alias to target a different configured database.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | 数据库别名，或管理页面 /admin 中为该库配置的项目名称（项目文件夹名）。在单个 SSE 连接内通过此参数切换不同库；省略时用连接 URL ?alias 指定的别名或默认别名。建议优先传当前项目文件夹名自动匹配对应数据库。 | |
| limit | No | Number of rows to return (default 5, max 20). | |
| table_name | Yes | Table to sample. Use database.table notation for cross-database queries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: bare table names use MYSQL_DATABASE, database.table enables cross-database lookups, and alias switches the configured database target. It does not describe return shape or sampling order, but these are less critical given the read-only annotations.
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 four sentences with no filler: purpose, usage timing, table-name syntax, and alias behavior each get one focused sentence. It is front-loaded with the core action and reads efficiently.
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 read-only sampler with no output schema, the description covers what the tool does, when to use it, how to name tables, and how to override the database target. An agent has enough information to invoke it correctly without needing to infer anything beyond the schema.
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%, so the baseline is 3. The description goes beyond the schema by specifying that bare table names resolve to MYSQL_DATABASE and reinforcing how alias targets a different configured database. The limit parameter needs no extra explanation because the schema already documents default and maximum.
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?
Description states a specific action and resource: 'Fetch a small sample of rows from a table to understand its data format and content.' It also names a companion tool (get_schema_info) and clearly frames this as an exploration tool, which distinguishes it from execute_sql even without an explicit contrast.
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 gives clear context: 'Use alongside get_schema_info before writing complex queries,' indicating when this tool is appropriate. It does not explicitly state when to prefer execute_sql instead, but the phrase 'before writing complex queries' implies the alternative, so it falls just short of fully explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.4execute_sqlget_schema_infoget_table_sampleScored across 3 tools
Each tool has a clear, distinct role: execute_sql for arbitrary SQL, get_schema_info for metadata, and get_table_sample for row previews. Although execute_sql can also run SHOW/SELECT statements, the specialized helper tools are explicitly framed as complementary, not competing.
All tool names follow a consistent verb_noun pattern in snake_case: execute_sql, get_schema_info, get_table_sample. This makes the action and target of each tool predictable.
Three tools is a compact but appropriate scope for a SQL database server: one general execution path plus two focused inspection helpers. Each tool serves a distinct need without redundancy.
The surface covers the core workflow: inspect schema, preview data, and execute arbitrary SQL for reads and writes. Cross-database behavior and user confirmation are handled, and remaining database-level operations can be reached via execute_sql.
Guard AI agents' PostgreSQL/MySQL access via MCP: SQL audit, auth, masking, write approval
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
Paid remote MCP for governed database query review, SQL simulation, approvals, and audits.
