一份开发者指南阐述了在工作站上运行 Model Context Protocol (MCP) 服务器与将其作为共享 HTTP 服务托管之间的权衡。作者认为，这一选择决定了延迟、凭据暴露程度以及团队扩展 AI 驱动的数据访问层的难易程度。
为什么这一决策至关重要
MCP 是连接 Claude 或 Cursor 等大语言模型助手的桥梁，使它们能够在不接触密码的情况下对数据库执行 SQL。助手调用工具，工具将请求转发给 MCP 服务器，然后由服务器执行查询。如果服务器位于开发者的笔记本电脑上，往返过程本质上是一个本地函数调用。如果它位于中央主机上，则每个请求都需要经过网络，并受主机的身份验证和日志记录机制约束。从单人开发原型转向生产环境的团队必须决定哪种模式更符合其安全态势、性能预期和运维开销。
两种部署模式
本地 (stdio)
客户端将 MCP 服务器作为子进程启动，并通过标准输入/输出 (stdin/stdout) 与其通信。不涉及网络栈。
- 适用场景：个人开发者、快速实验以及仅限本地的测试数据库。
- 优势：延迟几乎为零；进程继承了用户的环境，因此密码永远不会离开机器。
- 缺点：每个用户必须维护自己的配置文件或环境变量；没有中央审计追踪；扩展到多个用户需要在每个工作站上复制设置。
远程 (HTTP)
服务器在可通过 HTTP 访问的主机上持续运行。客户端进行身份验证（通常采用 OAuth 风格的流程），并将请求发送到已知的端点。
- 适用场景：团队、CI 流水线以及必须由多人或多个服务访问的生产数据。
- 优势：审计日志、基于角色的访问控制 (RBAC) 和连接池的单一管理点；凭据存储在受控的保险库中。
- 缺点：需要额外的基础设施进行配置和维护；网络延迟会在每次往返中增加几毫秒。
直观对比
| 维度 | 本地 | 远程 |
|---|---|---|
| 预期用途 | 单用户 | 多用户 |
| 身份验证 | 环境变量或本地配置 | 兼容 OAuth 的 Token 流程 |
| 审计 | 无内置审计 | 中央日志记录每个请求 |
| 设置复杂度 | 极低 | 需要服务器配置、TLS、Token 管理 |
| 延迟 | 近乎为零 | 由于网络跳转而较高 |
| 凭据暴露 | 局限于开发者的机器 | 集中化，但必须防止泄露 |
务实的混合方法
大多数组织不会只选择一种模式并永久沿用。该指南建议采取分阶段实施的策略：
- 本地开发 – 针对沙箱数据库启动本地 MCP 服务器。这种速度有利于快速迭代，并能防止密钥进入版本控制系统。
- 迁移至远程 – 一旦代码库实现共享，就将服务器迁移到中央主机。将客户端配置切换为指向 HTTP 端点并启用 OAuth。
- 保护生产环境 – 将生产数据库置于远程、可审计的网关之后。为 AI 助手强制执行只读角色，并仅将生产密码存储在远程服务器可以访问的密钥管理器中。
应避免的常见陷阱
- 将生产密码存储在开发者的
.env文件或其他本地配置中。如果机器被攻破，数据库就会暴露。 - 在没有 OAuth 或类似 Token 系统的情况下部署远程 MCP 服务器。明文 Basic Auth 或静态 API 密钥极易泄露。
- 授予 AI 助手对生产表的写权限。即使是意外的
DELETE语句也可能导致数据丢失；只读角色可以消除这一风险。
何时本地部署仍然合理
如果团队的工作流从未离开过单台机器——例如在个人笔记本电脑上进行原型设计的单人数据科学家——那么本地部署仍然是最简单、最快的选择。对于短期实验来说，设置 TLS 证书、Token 发行和日志流水线的开销可能并不划算。
核心结论
如果你追求极致的速度且仅供个人使用，本地 MCP 服务器是最直接的选择。如果你需要可审计性、共享访问或生产级安全性，远程 HTTP 服务器是唯一可行的方案。大多数团队为了方便会先从本地开始，然后在接触生产数据之前，过渡到远程的、受 Token 保护的网关。请根据项目阶段以及所暴露数据的风险特征来选择合适的部署模式。