DBHub 数据库 MCP 网关
让 MCP 客户端以更少上下文安全查询多种 SQL 数据库。
证据显示默认仅暴露两个工具，并提供只读模式、行数限制、查询超时、事务、SSH 隧道和 TLS，因此最小权限、外部影响控制及敏感传输有实际设计；但未说明危险查询前的用户确认机制，只读是否默认开启也不明确。README 的客户端—DBHub—数据库图和工具说明使主要数据流可见，但没有完整披露遥测、日志、Workbench 请求追踪中的数据留存或凭据处理。安装示例把密码直接放在命令行 DSN 中，存在 shell 历史和进程列表暴露风险。依赖使用版本范围，所给材料没有锁文件、依赖审计、漏洞扫描或更新策略。事务仅提供有限回滚能力，未说明非事务性 DDL 或已提交写入的恢复方案。Bytebase、仓库地址和 MIT 版权归属清楚，但 package.json 的 author 为空且发布者身份未获企业注册表验证，故归属并非满分。
README、package.json 和发布工作流总体一致地描述数据库范围、Node 要求、包名及交付方式；但“zero-dependency”与 package.json 中多项运行时及可选依赖直接不一致，因此自洽性扣分。Node 版本、pnpm 版本、数据库驱动和 npm/Docker 分发路径有明确记录，普通安装具有可行基础；不过可选驱动的选择和缺失时行为未在给定材料中解释。仅看到 health_check、Debug 链接和测试脚本名称，没有具体错误消息、诊断示例或恢复指引，因此失败消息证据较薄。
本地开发、非技术人员访问、多数据库整合和生产只读排障等受众与场景描述充分，获得满分。支持的数据库、默认及可选工具、自定义工具、传输示例和多连接配置体现了较清楚的能力边界；但写操作边界、各数据库差异及安全模式默认值未完整展开。两个默认工具及 opt-in 工具有助于精确选择，但源材料没有工具输入模式、触发条件或冲突处理细节。Node >=22.5、stdio/HTTP、Docker、MCP Bundle、插件及多架构镜像改善环境适配，但操作系统矩阵、数据库版本兼容范围和部署约束主要未给出。
README 以用途、数据库、工具、Workbench、安装和开发组织信息，并链接到专题文档，结构良好但关键细节依赖未提供的外部页面。安装和开发命令明确，也列出 Node 要求及多种交付形式；然而示例使用 latest 和明文命令行凭据，且缺少升级、卸载及生产加固说明。DBHub、dbhub、包名、MCP 名称和工具名称在材料中稳定一致，因此命名获满分。只有少量命令和用例，没有查询结果示例或 FAQ。已说明 Node 下限、可选工具和只读用途，但没有集中列出已知限制。MIT 元数据与完整 LICENSE 一致，许可获满分。package.json 有 1.2.0，版本同步脚本及 Docker 版本标签流程清楚，但未提供 changelog、发布说明或兼容政策。Bytebase、贡献者入口和仓库维护路径可见，不过 author 为空、没有具体维护者或支持承诺，且发布者身份未知。
两项默认工具、渐进式对象搜索、自定义 SQL 工具、Workbench 和多数据库统一入口表明输出可被 MCP 客户端及人工界面直接利用；但没有实际响应结构、错误输出、分页或结果示例，故不能评为全面。相对于分别部署多个数据库服务器，统一连接和较小工具面具有明确增量价值；不过与替代品的功能覆盖及限制比较不足。1.4k token 和 13–14 倍差异给出了成本主张，但没有测量方法、版本基线或可复核产物，且运行、维护和安全权衡未量化，所以成本收益仅属充分但不全面。
多数基础主张可映射到 README、package.json、LICENSE 和发布工作流，例如数据库范围、工具数量、Node 要求、版本及镜像发布；但 token 数、竞品比较、“official example”和安全效果在给定文件中缺少底层测量或引用材料。多个文件对名称、版本、许可、运行环境和发布路径形成交叉印证，但核心性能与安全营销主张主要只出现于 README。事实、比较结论和推广性措辞混排，未明确区分已实现能力、建议使用方式与实测结论，也未给出测试方法，因此事实—推断分离较弱。
- 在确认只读模式的默认状态、SQL 写入确认机制和数据库账户权限前，不要连接生产数据库。
- 不要在命令行参数中直接传递含密码的 DSN；应采用受保护的配置或密钥注入方式，并核查日志与 Workbench 请求追踪是否记录敏感 SQL 或结果。
- “zero-dependency”与 package.json 不符；部署前应审计完整依赖树、锁定版本，并检查数据库驱动及可选云身份依赖的漏洞。
- 将 1.4k token、13–14 倍优势及安全效果视为未经本材料独立验证的声明；需要固定版本和测量方法后再用于采购或架构决策。
- 事务支持不等于完整恢复能力；写入、DDL 和跨数据库操作前应准备数据库原生备份、审计和回滚流程。
这个 Agent 能做什么，适合哪些场景？
DBHub 是一个可自行部署的轻量级 MCP 服务器，为 PostgreSQL、MySQL、MariaDB、SQL Server 和 SQLite 提供统一接口。Claude Code、Claude Desktop、Cursor、VS Code 和 Copilot CLI 等 MCP 客户端可通过它连接并探索数据库。默认仅加载 execute_sql 与 search_objects 两个工具，文档给出的上下文占用约为 1.4k tokens；explain_sql 和 health_check 需要主动启用。它执行 SQL、检索数据库对象，并可通过配置暴露参数化自定义 SQL 操作，结果返回给发起请求的 MCP 客户端。部署边界由使用者控制，可通过 npx、Docker 或 MCP Bundle 运行，也内置用于执行查询、调用自定义工具和查看请求追踪的 Web Workbench。
MCP 客户端先将数据库操作请求发送给 DBHub，DBHub 再连接一个或多个已配置的数据库。execute_sql 执行 SQL 查询，并提供事务支持、只读模式、行数限制和查询超时等安全控制；search_objects 以渐进披露方式搜索 schema、表、列、索引和存储过程。可选的 explain_sql 在不实际运行查询的情况下返回执行计划，health_check 报告连接池状态和缓冲区缓存命中率。使用者还可在 dbhub.toml 中定义可复用的参数化 SQL 自定义工具，并配置多个数据库连接。连接可使用 SSH 隧道和 SSL/TLS；Workbench 则提供查询执行、自定义工具调用和请求追踪的可视化界面。
- 使用 Claude Code、VS Code 或 Cursor 的开发者在本地探索 schema、验证查询并排查数据问题。
- 数据库管理员向非技术员工开放经过筛选的只读视图，让他们通过 Claude Desktop 等客户端查询数据。
- 同时维护 PostgreSQL、MySQL、MariaDB、SQL Server 或 SQLite 的团队，用一个 DBHub 进程替代多个数据库专用 MCP 服务器。
- 运维或工程团队在生产故障排查时启用只读模式、行数限制和查询超时，降低失控查询的风险。
- 需要重复执行受控 SQL 操作的团队，在 dbhub.toml 中定义参数化自定义工具，并通过 MCP 客户端或 Workbench 调用。
这个 Agent 有哪些优点和局限？
- 默认只有 execute_sql 和 search_objects 两个工具，文档标示约占 1.4k tokens，明显减少 MCP 工具定义对上下文窗口的占用。
- 一个接口覆盖 PostgreSQL、MySQL、MariaDB、SQL Server 和 SQLite，并支持通过 TOML 同时配置多个连接。
- 具备只读模式、行数限制和查询超时等明确的数据库访问护栏。
- 支持 SSH 隧道与 SSL/TLS，并提供 npx、Docker、MCP Bundle 和 Claude Code 插件等多种交付方式。
- 内置 Workbench，可在没有 MCP 客户端时执行查询、运行自定义工具并查看请求追踪。
- 仅支持文档列出的五类 SQL 数据库；没有证据表明它支持 Oracle、MongoDB 或其他数据系统。
- 默认工具集刻意保持精简，执行计划和健康检查分别需要主动启用 explain_sql 与 health_check。
- 从源码开发要求 Node.js 22.5.0 或更高版本，因为项目依赖内置的 node:sqlite 模块。
- 部署者仍需提供并保护数据库凭据、网络路径以及必要的 SSH或TLS 配置；DBHub 不会消除数据库权限管理工作。
- 文档提供了防护选项，但没有说明所有安装方式都会默认启用只读、行限制或查询超时，因此生产部署需要显式核对配置。
如何安装或部署这个 Agent？
最快的 HTTP 启动方式需要可访问的受支持数据库及其 DSN：
npx @bytebase/dbhub@latest --transport http --port 8080 --dsn "postgres://user:password@localhost:5432/dbname?sslmode=disable"请将示例中的 user、password、主机、端口和数据库名替换为真实连接信息。项目也提供 Docker 镜像、默认只读的一键安装 MCP Bundle，以及 Claude Code 插件。若从源码开发，需要 Node.js >= 22.5.0，然后运行：
pnpm install
pnpm dev生产构建可运行：
pnpm build && pnpm start --transport stdio --dsn "postgres://user:password@localhost:5432/dbname"如何使用这个 Agent？
启动 DBHub 后，在兼容的 MCP 客户端中连接其 stdio 或 HTTP 服务，并提供目标数据库 DSN。首次使用可调用 search_objects 查找 schema、表、列、索引或存储过程，再调用 execute_sql 执行查询。生产或共享场景应按需启用只读模式、行数限制和查询超时；多个数据库连接及参数化自定义工具可写入 dbhub.toml。若希望在不执行查询的情况下检查计划，可启用 explain_sql；连接诊断可启用 health_check。也可以打开内置 Workbench，以可视化方式执行查询、运行自定义工具并查看请求追踪。
这个 Agent 与同类方案有什么区别？
README 的默认配置对比显示：DBHub 加载 2 个工具，约占 1.4k tokens；MCP Toolbox 默认加载 28 个工具，约占 19.0k tokens；Supabase MCP 默认加载全部工具，约占 19.3k tokens。这项对比仅说明默认工具数量与上下文占用，不足以判断三者在数据库覆盖、权限模型或完整功能上的优劣。