Model Context Protocol 运维指南：服务器设计、Tool 治理与 Transport 策略

• 引言
• 引入 MCP 前应先确定的事项
  • 1. 服务器边界按业务领域划分
  • 2. 区分 Tool 与 Resource
• Transport 选型：stdio 与 Streamable HTTP
  • 适合 stdio 的场景
  • 适合 Streamable HTTP 的场景
• Tool 设计原则
  • 名称要便于模型推理，范围要窄
  • 输入 schema 要短且严格
  • Tool 结果应贴合"下一步行动"，而非"大块数据"
• Token 预算与减少上下文浪费
  • 常见的浪费模式
  • 运维原则
• 认证与权限模型
  • 必须先厘清的问题
  • 推荐的运维模式
• 可观测性与运维检查清单
  • 上线前检查清单
• 反模式
  • "把内部 API 全部用 MCP 包一层就行"
  • "工具越多越聪明"
  • "本地能跑，运维也没问题"
• 结语
• 参考资料

引言

Model Context Protocol，简称 MCP，是一种试图把智能体应用与外部系统交互方式标准化的尝试。从实际运维的角度看，真正重要的问题往往不是协议本身，而是以下这些：

• 一个 MCP 服务器该管到什么范围为止
• tool 与 resource 该如何划分
• stdio 与 HTTP 该如何取舍
• 如何设计才能不让模型因读取过多工具说明与结果而浪费 token
• 该如何审计是谁调用了哪个 tool

本文以 MCP 官方文档为基准，梳理在生产环境中会立刻遇到的设计与运维问题。

引入 MCP 前应先确定的事项

MCP 很强大，但如果不假思索地把所有内部系统都接到同一个服务器上，很快就会变成运维负担。开始之前，最好先明确以下原则。

1. 服务器边界按业务领域划分

最常见的失败方式，是"把公司全部工具塞进同一个 MCP 服务器"这种做法。这样一来会出现以下问题：

• 工具说明变得过长，占用模型上下文
• 权限边界变得模糊
• 故障隔离变得困难
• 版本管理被固定在一个庞大仓库的粒度上

更好的方式是按业务领域或安全边界来划分。

2. 区分 Tool 与 Resource

按官方文档的定义，tool 更接近调用时会有副作用或需要计算的动作，而 resource 更适合提供可读的上下文。

• tool
  • 审批、部署、创建 issue、查询执行状态等接近函数调用的功能
• resource
  • 策略文档、runbook、架构说明、服务清单等接近可读上下文的信息

这个区分之所以重要，是因为它会改变模型的行为模式。如果把所有可读上下文都做成 tool，模型就会反复进行不必要的调用；反过来，如果把动作包装成 resource，治理与审计就会变得困难。

Transport 选型：stdio 与 Streamable HTTP

在 MCP 官方文档中最先遇到的选择之一就是 transport。

适合 stdio 的场景

• 本地开发工具与桌面客户端
• 单用户场景
• 可以让客户端直接管理进程生命周期的场景

优点：

• 实现简单
• 能在本地安全边界内快速起步
• 相比部署，更利于集成测试

注意事项：

• 服务器进程的生命周期依赖于客户端
• 中央审计与多租户运维较困难

适合 Streamable HTTP 的场景

• 多个客户端调用同一服务器的平台环境
• 需要中央认证、日志、rate limit、网络策略的场景
• 需要按组织单位运维与自动化部署的场景

优点：

• 容易接入运维标准
• 与 API gateway、service mesh、ingress 策略天然结合
• 即使客户端种类繁多也易于扩展

注意事项：

• 需要更明确地设计认证与会话边界
• 设计不当很容易沦为"又一个 HTTP 包装层"

Tool 设计原则

名称要便于模型推理，范围要窄

不好的例子是过于笼统的名称。

run_action
manage_item
operate_system

好的例子是输入与效果都可预期的名称。

list_pull_requests
get_ruleset_status
create_incident_note

名称一旦含糊，模型就得做更多推理，选错 tool 的概率也会随之上升。

输入 schema 要短且严格

输入字段越多，模型出错的可能性也越高。实务中以下规则很有用：

• 必填字段尽量保持最少
• 能用 enum 限制的值不要留成自由文本
• 说明文字要简短，且面向行动
• 不要把人类可读标识符与内部标识符混在一起

Tool 结果应贴合"下一步行动"，而非"大块数据"

比起冗长的 JSON dump，模型更擅长使用为选择下一步行动而结构化的结果。

好的结果示例：

{
  "repository": "platform/api",
  "ruleset_status": "blocking",
  "missing_checks": ["lint", "integration-test"],
  "next_actions": [
    "wait_for_required_checks",
    "request_codeowner_review"
  ]
}

从运维经验来看，在 tool 结果中放入候选的下一步行动，有助于减少模型不必要的重复调用。

Token 预算与减少上下文浪费

正如 GeekNews 上热议的 MCP optimizer 之类工具所展示的那样，实际瓶颈往往不是模型质量，而是上下文浪费。

常见的浪费模式

• tool 说明冗长且重复
• 每次都完整返回 resource 正文
• 把用不到的字段也全部塞进结果
• 单个服务器暴露过多 tool

运维原则

1. 保持 tool 说明简短。
2. 把 resource 拆分成比整篇文档更细的可摘要单元。
3. 结果分为默认摘要与按需详细查询两个阶段。
4. 借助日志与追踪数据，清理实际调用频率低的 tool。

举例来说，如果是 runbook 系统，最好不要一开始就返回完整的 markdown，而是优先返回标题、负责团队、最后修改日期、核心步骤。

认证与权限模型

一旦 MCP 服务器接入组织系统，核心问题就不再是便利性，而是权限边界。

必须先厘清的问题

• 调用主体是用户代理，还是系统账号
• 只读 tool 与可写 tool 是否混在一起
• 敏感资源的访问是否要分离到独立服务器
• 审计日志应保留哪些最小字段

推荐的运维模式

• 将只读服务器与变更型服务器分离
• 对可写 tool 明确设定幂等性与审批环节
• 在调用日志中记录用户、会话、tool 名称、输入摘要、结果状态
• 失败原因也要以人可审阅的形式记录下来

可观测性与运维检查清单

如果把 MCP 服务器当作运维系统来对待，至少应该监控以下内容。

上线前检查清单

• 服务器边界是否按领域与权限划分
• tool 名称与 schema 是否足够窄且明确
• resource 是否会返回过大的 payload
• 审计日志是否充分
• 失败时的 fallback 行为是否已定义
• transport 选型理由是否已文档化

反模式

"把内部 API 全部用 MCP 包一层就行"

这种做法几乎总会失败。MCP 的核心不是简单的代理层，而是让模型能够理解并做出选择的接口设计。

"工具越多越聪明"

恰恰相反，工具数量越多，选择错误与 token 浪费也会随之增加。好的 MCP 靠的不是工具数量，而是边界与命名规范。

"本地能跑，运维也没问题"

即便基于 stdio 的本地集成运行良好，一旦进入中央认证与多客户端环境，就会出现其他问题。在生产环境中，transport、rate limit、审计、部署策略都需要单独处理。

结语

把 MCP 引入得好的团队，与其说是"模型变聪明了"，不如说更接近"设计出了模型可以安全使用的接口"。归根结底，决定成败的不是协议本身，而是服务器边界、tool schema、transport 选型、权限模型，以及 token 预算的运维方式。

可以从小处起步，但以下两点最好从一开始就把握好：

• 按业务领域划分服务器
• 简短明确的 tool 与 resource 接口

守住这两点，后续的认证、可观测性、成本优化也会容易得多。

参考资料

• Model Context Protocol Introduction
• MCP Architecture
• MCP Transports
• MCP Tools
• MCP Resources
• MCP Prompts
• MCP Security Best Practices