搭一个 MCP server 最省事的方式，是把一个 API 包起来、每个端点暴露一个工具。这也是做出一个糟糕 agent 界面最快的方式之一。
生产级的 MCP 设计不只是接通协议，它设计的是一个面向 agent 的产品界面：哪些能力可见、用户怎么输入、凭据放在哪里、什么进模型的上下文、整个集成怎么打包。
这十二个模式把这块设计归成五个方面。
工具界面
1. 远程优先的 server
本地 stdio server 只适用于 agent 能在同一台机器上起进程的场景；浏览器、移动端和多数云端 agent 都被排除在外。
要触达生产环境，优先选远程托管的 server，配标准传输与认证。本地部署留给开发、离线和机器本地的能力。
2. 按意图分组的工具
agent 按任务思考，不按 API 端点思考。一对一的包装强迫模型把长串原语拼起来，撑大工具列表，也让链条多出无数出错点。
围绕用户意图组织操作：「准备发布」「排查事故」「更新客户记录」，而不是把每条 REST 路由照搬一遍。
3. 薄界面
有些平台有成百上千个操作，即使按意图分组，留在上下文里的定义还是太多。
刻意只暴露一层薄界面，比如「搜索 + 执行」：agent 找到正确的操作，写一小段程序，在服务端沙箱里跑，只有有用的结果返回。
交互语义
4. 内联 UI
别让模型用文字描述每张图表、表格、表单、预览或确认框。结果天然是视觉的或可交互的，就返回客户端能在会话里直接渲染的 UI。
server 应该自己持有产品形态的交互，而不是把所有渲染都外包给语言。
5. 征询式输入
工具缺参数、需要确认、或匹配到多个结果时，停下来征询结构化输入，比让模型猜安全。
调用中途返回一份表单 schema，客户端收集答案，然后继续执行。用户不丢上下文，server 拿到合法数据。
6. 外部交接
有些数据永远不该进 agent 的上下文：下游 OAuth、支付、另一个服务的凭据。
把用户交给一个受保护的外部流程，完成后再回来。敏感交互留在模型边界之外。
认证与凭据
7. 可发现的认证
自定义的粘贴 token 流程带来安装摩擦和过期凭据。发布标准 OAuth 元数据，让客户端自动发现注册与授权。
认证是协议界面的一部分，不是 README 里的谜题。
8. 凭据交给保险库
别让每个 MCP server 各自重建一套密钥存储、刷新、轮换与吊销。让平台保险库持有 token 生命周期，往正确的连接注入正确的凭据。
模型该拿到的是能力，不是密钥。
上下文经济
9. 按需加载工具
接上几个 server，第一次动作之前就可能塞进来几百条工具定义。通过搜索做惰性加载，只让相关的定义进上下文。
工具发现的规模应该跟着任务走，不是跟着集成目录的总量走。
10. 程序化调用工具
大块 JSON 结果、日志、trace、文档集合，如果任务只需要过滤、连接或聚合，就不该原样落进上下文窗口。
在代码沙箱里处理结果，只返回最终有用的输出。用确定的计算换掉费 token 的解读。
打包与分发
11. 插件打包
一个真实的集成往往不止一个 server：还有技能、hooks、子代理，也许还有语言工具链。
把这些部件作为一个带版本的插件一起发布，安装、兼容与升级才保持一致。
12. 技能随 server 分发
工具访问不等于专业知识。提供方通常知道安全的操作序列、最佳工作流和常见错误。
把过程性知识随 server 一起分发，客户端同时拿到能力和用好它们的方法。
生产形态
合起来，这些模式指向一个更大的架构：
- 工具按意图组织，不按端点。
- 交互可以是文本、UI、结构化输入或受保护的交接。
- 认证可发现，凭据留在模型上下文之外。
- 定义与结果只在有用时进上下文。
- server 连同让它们可运营的工作流与控制一起交付。
这就是「把 API 暴露给 agent」和「设计一个 agent 集成」之间的差别。