MCP（模型上下文协议）由 Anthropic 推出，目标是统一大语言模型与外部数据源、工具的通信。已有资料勾勒出它的主机、客户端、服务器三层架构，以及 Claude Desktop 接 PostgreSQL、Cherry Studio 与 Cursor 调高德地图等场景。本文不重复概念教程，而是从工程落地角度，讨论接入外部数据源和工具时的安全边界与架构权衡。
一、先看清信任边界
MCP 的主机是承载 AI 交互的应用，如 Claude Desktop、VS Code 通义灵码插件、Cherry Studio、Cursor；客户端负责按协议连接服务器；服务器封装数据库、地图 API 等外部能力。一次工具调用实际跨越三段边界：主机到客户端、客户端到服务器、服务器到外部系统。安全问题往往不发生在协议本身，而发生在凭据如何进入服务器、服务器以什么权限访问外部系统、以及主机内多个会话是否共享同一服务器能力。
二、stdio 与 SSE 的取舍
资料明确 MCP 分为 stdio 和 sse 两类，且 stdio 更常用。stdio 把服务器作为本地子进程启动，延迟低、部署简单，适合桌面客户端。代价是服务器进程通常继承主机的用户权限与环境变量，如果客户端通过 json 配置注入数据库密码或第三方 API Key，密钥容易以明文散落在本机配置中。SSE 面向远程端点，便于集中部署和统一治理，但把调用链暴露到网络，需要额外处理端点认证、传输加密和网络访问控制。工程上，stdio 更适合个人开发与本地数据源，SSE 更适合团队共享服务；不要把 SSE 端点无认证地暴露在公网。
三、数据源接入：从 PostgreSQL MCP Server 说起
用 Claude Desktop 通过 PostgreSQL MCP Server 查询数据库，是资料中给出的典型场景。这里最值得先定的是权限模型：给 MCP 服务器的数据库账号应遵循最小权限，优先只读、限定 schema 和表，避免授予 DDL 或跨库访问。查询类工具还要考虑结果集大小、慢查询和敏感字段脱敏。如果服务器同时开放写操作，应把读工具与写工具拆成不同服务器或不同凭据，降低一次误调用造成的数据损坏。
四、工具集成：API Key 与能力聚合
Cherry Studio、Cursor 调用高德地图 MCP 服务，说明第三方 API 可以通过 MCP 统一接入。此类集成要关注 API Key 的计费与配额、调用频率限制、以及 Key 被客户端配置泄露后的滥用风险。更隐蔽的风险是能力聚合：一个 MCP 服务器往往同时暴露多个工具，主机一旦信任该服务器，会话就可能获得其全部能力。建议按业务域或风险级别拆分服务器，例如只读查询、消息发送、支付类操作分开部署，避免出现权限过大的超级服务器。
五、集成路径的架构权衡
资料提到 MCP 可以通过云平台、软件客户端和程序内使用三种方式接入。云平台托管省去本地进程和配置，但数据与凭据要经过第三方；软件客户端方式依赖图形界面和 json 配置，上手快但审计与版本管理弱；程序内使用最灵活，可以在代码层控制凭据来源、调用审计和超时重试，适合生产系统。选择哪种路径，取决于数据敏感度、团队运维能力和合规要求，而不是单纯看接入速度。
六、与 Function Calling 的关系
现有资料指出 MCP 通过统一协议降低接入成本，并提高插件复用性，实现一次接入、处处可用。这是它的核心收益，但也引入额外进程与协议层。工程上要接受一个事实：MCP 服务器会成为新的故障点。需要为服务器设置启动失败降级、调用超时、并发限制和日志追踪。对于实时低延迟场景，stdio 本地进程通常比远程 SSE 更可控；对跨团队复用，则要优先保证接口版本稳定和工具描述准确。
七、可执行的安全清单
1. 凭据不写死在客户端 json 中，优先用环境变量、系统密钥链或外部密钥管理，并定期轮换。
2. stdio 服务器以低权限账号运行，限制可访问目录和网络出口；SSE 服务器加认证网关与 TLS。
3. 数据库类服务器默认只读，限制 schema、行数和执行时间，禁止 DDL。
4. 第三方 API 类服务器单独管理 Key，设置配额告警，区分测试与生产 Key。
5. 按风险拆分服务器，读与写分离，高危工具要求显式确认。
6. 记录工具名、参数摘要、调用结果状态和耗时，便于审计与故障复盘。
7. 使用 uvx 等指令拉取服务器实现时固定版本，避免依赖漂移和供应链风险。
MCP 把模型与外部世界的连接标准化了，这是它被快速采用的原因。但标准化不等于自动安全。接入面越大，越需要把信任边界、最小权限和故障隔离当作架构的一部分，而不是上线后再补的配置。