MCP 企业级部署前要准备哪些基础设施与安全边界
MCP 企业级部署方案的核心不是写一个启动命令，而是先回答三个问题：服务跑在哪里、客户端通过什么协议连过来、调用工具时用什么身份做权限判断。
如果直接照搬本地开发模式，把未加认证的 MCP 服务暴露到内网或公网，工具就可能被任意客户端调用。
下面按准备、操作、避坑和验证的顺序说明。
先定托管位置和传输方式
MCP 服务端通常有两种运行形态：本地进程和远程服务。
本地进程由客户端拉起，适合个人使用；
企业内要多人共用同一组工具时，一般需要把服务托管到一台可控的内网服务器上，由客户端通过约定传输方式连接。
判断条件可以这样用：
- 工具只服务单个客户端、数据不出本机，优先本地进程，部署成本最低。
- 多个客户端或团队成员需要调用同一批工具，选远程托管，并把服务放在内网或受 VPN 保护的区域。
- 需要审计调用记录时，远程托管更容易集中收集日志，但必须同时配置认证，否则日志只能记录匿名调用。
传输方式要和客户端能力匹配。
常见做法是服务端监听一个固定地址和端口，客户端在配置中写入该地址。
具体参数名以你使用的 MCP 客户端和服务端实现为准，不要混用不同实现的示例。
部署时把认证和工具白名单一起做
企业部署最容易漏掉的是认证。
MCP 规范本身不强制服务端提供认证，很多示例默认匿名访问。
上线前至少做到两点：
- 每个客户端分配独立凭据，例如 API Key 或 OAuth 客户端身份，不要全团队共用一个密钥。
- 在服务端按工具名配置允许列表，只注册业务确实需要的工具，权限校验放在工具执行前，而不是依赖客户端自觉。
一个可参考的服务端启动配置片段如下，参数名请替换为你所用实现的实际字段：
server:
listen: "0.0.0.0:8080"
auth:
type: "api_key"
header: "X-MCP-Key"
tools:
allow:
- "read_file"
- "query_ticket"
deny:
- "exec_shell"如果服务需要跨网访问，建议在前面加反向代理或网关做 TLS 终止和来源限制，不要让 MCP 服务端口直接对公网开放。
接入验证和常见坑
部署完成后，先用最小客户端做连通性验证：用配置好的地址和凭据发起一次工具列表请求，确认返回的工具名与允许列表一致。
再调用一个只读工具，检查服务端日志是否记录了调用者身份、工具名和结果状态。
常见问题集中在三处：
- 客户端连不上：先确认服务进程是否监听在预期地址，再检查防火墙和代理是否放行端口。
- 认证通过但工具不可用：检查允许列表是否包含该工具名，大小写和命名空间是否一致。
- 日志里全是匿名调用：说明认证头没有正确传递，检查客户端配置中的 header 名称是否与服务端一致。
上线前再复查边界
企业级部署的验收标准不是“能调通”，而是“只有该调的人能调该调的工具”。
复查时确认服务没有监听在公网地址、密钥没有写进客户端明文共享配置、禁用工具确实不在允许列表中。
如果后续要扩大工具范围，按新增工具重新走权限配置和日志验证，不要直接放开全部工具。
