Click on "Deploy 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., "@dameng-mcp-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.
达梦（DM / Dameng）数据库的 MCP（Model Context Protocol）服务器。
达梦是国产主流关系型数据库，把达梦的能力以 MCP 工具的形式暴露给大语言模型，让你能用自然语言查表、看结构、读写数据。
默认只读：写操作在触达数据库前就被拦截。语句白名单 + 多语句拒绝，三层防御。
读写带审计：开启读写后允许增删改查与 DDL，每条写操作落 JSONL 审计日志（前后配对、影响行数、耗时、错误）。
Schema 自省：列库 / 表 / 视图、描述字段类型与主键，让模型不靠猜。
查询安全：参数化占位符防注入、返回行数上限、单语句强制。
零外部服务：纯 Python，单进程 stdio，审计日志就是本地一个文件。
Related MCP server: MySQL MCP Server
模式 | 能做什么 | 审计 |
| 只能 | 不产生 |
| 额外允许 INSERT/UPDATE/DELETE/MERGE 与 DDL | 每条写操作 |
只读是默认且最安全；读写模式专为"允许 AI 改数据，但全程留痕"的场景设计。
Claude / MCP 客户端
│ (stdio / JSON-RPC)
▼
┌──────────────── FastMCP Server ────────────────┐
│ Tools: list_schemas / list_tables / │
│ describe_table / read_query / │
│ execute_write / execute_ddl / │
│ get_audit_log │
│ │ │
│ ▼ 所有 SQL 必经 │
│ ┌─────────────┐ ┌──────────────┐ │
│ │ sql_guard │───▶│ audit (JSONL)│ 写操作记 │
│ │ 分类/只读闸 │ └──────────────┘ 录审计 │
│ └──────┬──────┘ │
│ ▼ │
│ ┌─────────────┐ │
│ │ connection │ 懒连接 + ping 重连 │
│ └──────┬──────┘ │
└─────────┼──────────────────────────────────────┘
▼ dmPython (DB API 2.0)
达梦数据库 (本地 / 局域网)源码组织（src/dameng_mcp/）：
文件 | 职责 |
| 从环境变量 / |
| SQL 分类、只读闸门、多语句拦截（安全核心，纯函数） |
| JSONL 审计写入器与回读 |
| dmPython 连接管理（懒连接 + 重连 + 事务封装） |
| 7 个 MCP 工具的业务实现 |
| FastMCP 装配、工具注册、启动自检 |
| CLI 入口（ |
git clone https://github.com/yizhilangou/dameng-mcp-server.git
cd dameng-mcp-server
pip install -e . # 开发: pip install -e .[dev] (含 pytest)框架依赖说明（容易踩的坑）：本项目基于 FastMCP。FastMCP 在 2.0 拆成了独立包 fastmcp，导入路径随之改变。pip install -e . 会自动装好 fastmcp，代码同时兼容两代路径：
版本 | pip 包 | 导入写法 |
新（FastMCP 2.0+，默认） |
|
|
老（mcp 1.x） |
|
|
如果你单独装的是 mcp 2.0.0（底层协议包，不含高层 FastMCP），启动会报"未安装 mcp SDK"——补一句 pip install fastmcp 即可。
dmPython 是达梦官方原生 Python 驱动（DB API 2.0），依赖达梦的 dpi 原生动态库：
装过达梦数据库的机器已自带，目录形如 C:\dmdbms\bin（Windows）或 /dm/dmdbms/bin（Linux）。
让该目录进入动态库搜索路径，三选一：
Windows：把该目录加入系统 PATH。
Linux：export LD_LIBRARY_PATH=/dm/dmdbms/bin:$LD_LIBRARY_PATH。
让本服务自动注入：设环境变量 DM_LD_LIBRARY_PATH=/dm/dmdbms/bin。
验证：python -c "import dmPython" 不报错即可。详见达梦官方文档 https://eco.dameng.com/document/dm/zh-cn/app-dev/python_environment.html。
复制 .env.example 为 .env 按实际填写（也可全部用环境变量覆盖）：
变量 | 默认 | 说明 |
|
| 数据库主机，本地或局域网 IP |
|
| 端口 |
| 必填 | 用户名 |
| 必填 | 密码 |
| 空 | 登录后切换的模式名 |
|
|
|
|
| 单条 SQL 超时（秒） |
|
|
|
|
| 审计日志路径（仅 readwrite 产生） |
| 空 | 达梦 dpi 库目录，启动时自动注入 |
MCP 是 stdio 子进程，正常使用时由 Claude Code 自动拉起，不需要你手动启动。
在项目目录注册：
claude mcp add dameng \
-s project \
-e DM_HOST=127.0.0.1 \
-e DM_PORT=5236 \
-e DM_USER=SYSDBA \
-e DM_PASSWORD=SYSDBA \
-e DM_MODE=readonly \
-- python -m dameng_mcp-s 作用域：local（本机当前项目，默认）/ project（写入 .mcp.json，可共享）/ user（你的所有项目）。
-e KEY=VALUE 等价于 .env 里的配置。
-- 之后是启动命令；若 Python 不在 PATH，写绝对路径。
等价的 .mcp.json（项目根目录）：
{
"mcpServers": {
"dameng": {
"command": "python",
"args": ["-m", "dameng_mcp"],
"env": {
"DM_HOST": "127.0.0.1",
"DM_PORT": "5236",
"DM_USER": "SYSDBA",
"DM_PASSWORD": "SYSDBA",
"DM_MODE": "readonly"
}
}
}
}验证：
claude mcp list # 看到 dameng
claude mcp get dameng # 详细配置然后 claude 进入会话，首次会提示批准 dameng 服务器（安全机制），批准后输入 /mcp 看到 connected 即成功。之后直接对话：
用 dameng 列一下当前库的表，再看下 EMP 表结构。
切换读写模式：claude mcp remove dameng 后用 DM_MODE=readwrite 重新 add，重开会话即生效；写操作会自动落审计。
手动跑一次确认环境没问题：
python -m dameng_mcp它会先做一次连接自检并输出到 stderr：
[dameng-mcp] 连接自检通过: 127.0.0.1:5236 user=SYSDBA mode=readonly(只读)判定：没有 traceback、之后"卡住没输出"就是成功——它在等客户端的 JSON-RPC，不会打印交互提示。出错时这里会给完整堆栈，比 Claude Code 报的更清晰。
可视化调试可用官方 Inspector（需 Node.js，国内 npm 卡住先 npm config set registry https://registry.npmmirror.com）：
npx @modelcontextprotocol/inspector python -m dameng_mcpMCP stdio 服务没有独立"停止"命令，生命周期跟着调用方：
场景 | 启动 | 关闭 |
Claude Code 托管 | 会话开始时自动拉起 | 退出会话即自动结束 |
手动自检 |
|
|
Inspector | Inspector 拉起 | 关浏览器 + 终止 inspector |
改了配置（如切 readonly↔readwrite）需重启会话；会话内 /mcp 可查看连接状态。
最常见的国产库开发组合：数据库和驱动在 Windows，Claude Code 在 WSL。有两个隔离要处理——网络（WSL2 默认 NAT，访问不到 Windows localhost）和环境（dmPython 只在 Windows Python 装好了）。
最佳实践：让 Claude Code（WSL）调用 Windows 的 python.exe 启动 MCP。 这样 MCP 进程本身就是 Windows 进程，连 Windows 本地达梦走 127.0.0.1 回环——两个隔离一次绕开，WSL 侧什么都不用装。原理是 WSL interop 能直接运行 Windows 可执行文件，stdio 跨边界自动桥接。
1. 定位 Windows Python 完整路径。 WSL 通常不接 Windows PATH，直接敲 python.exe 会 command not found，要用安装路径调用：
PYEXE="/mnt/c/Users/$USER/AppData/Local/Programs/Python/Python312/python.exe"
ls "$PYEXE" && "$PYEXE" --versionWSL 的
$USER是 Linux 用户名，不一定等于 Windows 用户名。路径不对时，在 Windows PowerShell 执行(Get-Command python).Source拿到真实路径，再把C:\...翻译成/mnt/c/...。打印出版本号即说明 interop 通。
2. 验证 Windows 侧驱动：
"$PYEXE" -c "import dmPython; print('dmPython ok')"3. 用完整路径注册：
claude mcp add dameng \
-s project \
-e DM_HOST=127.0.0.1 \
-e DM_PORT=5236 \
-e DM_USER=SYSDBA \
-e DM_PASSWORD=SYSDBA \
-e DM_MODE=readonly \
-- "$PYEXE" -m dameng_mcp对应 .mcp.json：
{
"mcpServers": {
"dameng": {
"command": "/mnt/c/Users/lenovo/AppData/Local/Programs/Python/Python312/python.exe",
"args": ["-m", "dameng_mcp"],
"env": {
"DM_HOST": "127.0.0.1",
"DM_PORT": "5236",
"DM_USER": "SYSDBA",
"DM_PASSWORD": "SYSDBA",
"DM_MODE": "readonly"
}
}
}
}4. 批准并验证。 claude 进会话，首次提示批准 dameng，批准后 /mcp 看到 connected 即成功。claude mcp list 显示 Pending approval 就是还没在会话里批准。
症状 | 原因 | 解决 |
| WSL 没接 Windows PATH | 用完整路径 |
完整路径仍 | interop 被关 |
|
| Windows Python 没装驱动 | Windows cmd： |
dmPython 报 dpi 库错误 | 达梦 | 把 |
| 口令/端口/达梦未启动 | 看 stderr 自检行 |
只读模式下全部可用；读写模式额外开放写工具。
工具 | 作用 | 模式 |
| 列出所有用户(schema) | 只读 |
| 列出表 | 只读 |
| 字段类型 / 主键 / 可空 / 默认值 | 只读 |
| 执行 SELECT/WITH（ | 只读 |
| 回读写操作审计 | 只读 |
| INSERT/UPDATE/DELETE/MERGE | 读写 |
| CREATE/ALTER/DROP/TRUNCATE... | 读写 |
示例：
read_query(sql="SELECT * FROM EMP WHERE DEPTNO = ?", params=[10])
execute_write(sql="UPDATE EMP SET SAL = ? WHERE EMPNO = ?", params=[5000, 7900])
get_audit_log(limit=20)语句白名单：按首关键字分类（READ / DML / DDL / PROC / TCL），readonly 只放行 READ。
模式闸门：非 READ 在进入数据库前直接拒绝，不触达 DB。
多语句拒绝：SELECT 1; DROP TABLE t 这类单次多语句一律拒绝；分号判定对字符串字面量与注释感知，不会被 'a;b' 误导。
会话只读（尽力）：readonly 启动时尝试 SET TRANSACTION READ ONLY，失败仅告警，靠前三层兜底。
JSONL，每行一条：
{"ts":"2026-07-28T12:00:00+00:00","seq":7,"status":"success","mode":"readwrite","op":"UPDATE","sql":"UPDATE EMP SET SAL=? WHERE EMPNO=?","params":[5000,7900],"rows_affected":1,"error":null,"duration_ms":12}写操作前后各记一条（pending → success/error，同 seq 串联），即使进程崩溃也能从 pending 行看出"有一条写结果未知"。
pip install -e .[dev]
PYTHONPATH=src pytest tests/ -v覆盖 SQL 分类、只读闸门、多语句拦截、注释/字符串感知、审计写入与回读，以及工具层（用假连接验证"只读拦写、读写记审计、类型不匹配拒绝"）。无需真实达梦即可跑通全部单测。
启动报"未找到 dmPython 驱动"？
pip install dmPython，并把达梦 bin 目录加入 PATH 或设 DM_LD_LIBRARY_PATH。
明明 pip install mcp 显示已装，却报"未安装 mcp SDK"？
装的是底层 mcp 2.0.0，高层 FastMCP 已拆成独立包。补一句 pip install fastmcp（见安装章节）。
自省工具（list_tables 等）报"表或视图不存在"？
自省基于达梦 ALL_* 系统视图。不同 DM8 小版本视图名偶有差异，把报错贴 issue。
怎么彻底防住写？
保持 DM_MODE=readonly（默认）。即使模型构造恶意语句，也会在触达 DB 前被三层防御拦下，且无任何副作用。
达梦在 Windows、Claude Code 在 WSL，连不上？ 见"WSL + Windows 混合环境"：用 Windows Python 完整路径注册，让 MCP 跑在 Windows 侧走 localhost。
审计日志会不会越撑越大？
纯追加 JSONL，可用 logrotate 或按 since_seq 归档；仅 readwrite 产生。
欢迎 issue / PR，尤其欢迎：不同 DM 版本系统视图的兼容性反馈、更多审计后端（SQLite / 达梦审计表）、HTTP/SSE 传输支持。
描述某张表的列(名/类型/长度/可空/默认值/是否主键)。 name 为表名，schema 可选。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| schema | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 implies a read-only operation by stating it describes columns, but does not explicitly confirm lack of side effects, permissions needed, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two lines front-loading the purpose and parameter explanations. No unnecessary words or redundant information.
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 describe-table tool, the description covers the core behavior and parameters. The output schema exists, so it need not detail return values. However, the lack of usage guidelines and behavioral transparency slightly reduces completeness.
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 0%, so the description must compensate. It clarifies that 'name' is the table name and 'schema' is optional. This adds necessary meaning beyond the raw schema types. However, it could provide more detail on the schema parameter's format or source.
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 verb 'describe' and the resource 'columns of a table', listing the attributes (name/type/length/nullable/default/primary key). It is distinguishable from sibling tools like list_tables (which lists tables) and read_query (which executes queries).
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?
No usage context or conditions provided. The description does not indicate when to use this tool versus siblings, such as when to use describe_table instead of list_tables or read_query for schema information. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 DDL(CREATE/ALTER/DROP/TRUNCATE...)，仅读写模式可用。 每次调用写入审计日志。返回 {status, rows_affected, seq}。
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions that each call writes an audit log, a useful behavioral trait. However, it omits details about potential destructive effects, error handling, or required permissions beyond 'read-write mode'.
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 concise, with two sentences that front-load the core purpose and return format. There is no redundant information, making it 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description provides the return format but lacks details on error responses, idempotency, or rollback behavior. Given the destructive potential of DDL, more completeness would be beneficial.
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 parameter description is minimal. The schema has 0% coverage, and the description only restates that 'sql' is the SQL for DDL. It adds no detail about format, allowed syntax, or constraints, leaving the agent with little beyond the parameter name.
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 that the tool executes DDL statements (CREATE/ALTER/DROP/TRUNCATE), distinguishing it from read-only and write siblings. However, it could more explicitly contrast with execute_write, which may be for DML.
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 specifies that the tool is only available in read-write mode, providing a usage constraint. But it does not explicitly state when not to use it or mention alternatives like execute_write for DML operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 DML(INSERT/UPDATE/DELETE/MERGE)，仅读写模式可用。 每次调用写入审计日志。返回 {status, rows_affected, seq}。
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| params | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that each call writes an audit log and returns {status, rows_affected, seq}, providing key behavioral traits. It lacks details on authentication or error handling but is sufficient for a DML tool.
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?
Two sentences, front-loaded with the core purpose and mode, followed by side effects and return value. No wasted words.
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?
The description covers purpose, mode, side effects, and return format, which is adequate given the presence of an output schema. However, it lacks parameter guidance and error semantics, leaving gaps for a tool with 2 parameters.
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 0%, yet the description adds no explanation for the 'sql' or 'params' parameters. Users cannot infer how to format the SQL or use bind variables from the description.
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 it executes DML (INSERT/UPDATE/DELETE/MERGE), differentiating it from siblings like read_query (read-only) and execute_ddl (DDL).
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 explicitly says '仅读写模式可用' (only available in read-write mode), providing a usage constraint. However, it does not explicitly recommend when to use this vs. alternatives like read_query or execute_ddl.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取最近的写操作审计记录(任何模式可用，便于 LLM 自查写历史)。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since_seq | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool reads audit logs, implying a read-only operation with no destructive side effects. However, it fails to explicitly declare safety (e.g., that it does not modify data) and does not disclose any potential limitations like authentication requirements or rate limits. The description is adequate but not comprehensive.
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, front-loaded sentence that communicates the core purpose. However, it is too brief and lacks details about parameters and usage, making it less helpful. It earns a middle score as it is not wasteful but is incomplete.
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 has 2 parameters and an output schema, the description is insufficient. It explains the purpose and use case but omits parameter semantics and behavioral details. The output schema may cover return values, but the lack of parameter explanation leaves a significant gap 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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It provides no information about 'limit' (capped number of logs) or 'since_seq' (starting sequence ID). This leaves the agent without crucial guidance on how to use the parameters effectively.
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 clearly states the tool reads recent write operation audit logs, specifying the resource (audit logs) and the action (read). It implicitly distinguishes from siblings like execute_write (writing) and read_query (reading data) by focusing on write history, and mentions availability for any schema, leaving no ambiguity.
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 LLM self-checking write history ('便于 LLM 自查写历史'), providing a clear context. However, it does not explicitly state when to use this tool over siblings (e.g., instead of read_query), nor does it mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出达梦数据库中所有用户(schema)。无参数。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It describes a list operation, which implies no side effects, but does not explicitly state read-only or idempotent behavior. It is adequate but minimal, missing details like return format or scope.
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, consisting of a single sentence that front-loads the action. Every word is necessary, and there is no fluff.
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 tool with no parameters and a clear purpose, the description is complete. It tells the agent exactly what the tool does (list all schemas) with no missing information. The presence of an output schema further reduces the need to describe return values.
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?
There are no parameters, and the schema coverage is 100%. The description adds 'no parameters,' which confirms the empty schema. Baseline score of 4 is appropriate as no further parameter explanation is needed.
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 verb 'list' and the resource 'users (schemas)' in the DM database. It distinguishes the tool from siblings like list_tables and describe_table by specifying it lists schemas, not tables or other objects.
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 any context, prerequisites, or conditions for use, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出表。可选 schema 过滤；省略时用连接配置的 schema。 返回 [{schema, name}, ...]。
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the default schema behavior and return format, which is adequate for a read-only list operation. No destructive hints needed.
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?
Two sentences, no wasted words, front-loaded with action. Perfectly concise for a simple tool.
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 and the presence of an output schema, the description covers key behavior and return format. Lacks details on edge cases (e.g., empty results) but sufficient for its purpose.
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 single parameter 'schema' is described as optional with a filtering purpose and default behavior, adding meaning beyond the schema's type definition. This compensates for 0% schema description coverage.
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 verb '列出' (list) and resource '表' (tables), distinguishing it from siblings like list_schemas (schemas) and describe_table (specific table details).
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?
No explicit guidance on when to use this tool versus alternatives, but the description implies usage for listing tables with optional schema filtering. No when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行只读查询(SELECT/WITH)。sql 用 ? 占位符，参数放 params。 受 DM_MAX_ROWS 限制；返回 {columns, rows, row_count, truncated}。
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| params | No | ||
| max_rows | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses read-only nature, parameter style (?, params), DM_MAX_ROWS limit, and return structure including truncated flag. Full transparency for a query tool.
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?
Three sentences, each adding value: purpose, usage details, return format. Front-loaded and no wasted words.
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?
With output schema present, description covers purpose, parameter usage, limit, and output. Complete for a query tool of this complexity.
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 0%, but description explains sql and params usage (? placeholders) and implies max_rows via DM_MAX_ROWS limit. Adds significant meaning beyond bare schema.
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 clearly states it executes read-only queries (SELECT/WITH), uses ? placeholders, parameters in params, limited by DM_MAX_ROWS, and returns structured result. Distinguishes from siblings like execute_write and execute_ddl.
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?
Explicitly states read-only queries, placeholder syntax, and row limit. Implicitly excludes writes/DDL via sibling tool names. Does not explicitly state when not to use or mention alternatives, but context is clear.
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.1.0describe_tableexecute_ddlexecute_writeget_audit_loglist_schemaslist_tablesread_queryScored across 7 tools
Each tool has a unique purpose: listing schemas, listing tables, describing a table, executing read queries, retrieving audit logs, executing DML, and executing DDL. There is no ambiguity or overlap between them.
All tool names follow a consistent verb_noun pattern (e.g., list_schemas, execute_write). The naming is clear and predictable, making it easy for an agent to understand the action and target.
With 7 tools, the server covers essential database operations (schema navigation, table description, querying, auditing, and writes) without being over- or under-sized. The count is well-scoped for its purpose.
The tool surface covers the full lifecycle: schema exploration (list_schemas, list_tables), schema introspection (describe_table), read queries (read_query), DML (execute_write), DDL (execute_ddl), and auditing (get_audit_log). No obvious gaps for typical usage.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Ask questions in plain language, get answers from your business database. No SQL required.
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
