MCP 不只是「调工具」
同一个协议两个方向：消费别人的工具 vs 把自己暴露给别人
本页解决的问题
先给结论「MCP 不只是「调工具」」要解决的关键问题是什么？
同一个协议两个方向：消费别人的工具 vs 把自己暴露给别人
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
作为 Client（消费者）
示例应用 连接外部 MCP 服务，调用别人提供的工具能力：
- 日历 MCP — 查看和创建日程
- 邮件 MCP — 读写邮件
- 数据库 MCP — 查询数据
- 浏览器 MCP — 访问网页
关键：示例应用 主动发起请求，获取外部能力。
作为 Server（提供者）
示例应用 把自己的能力通过 MCP 协议暴露出去，被外部调用：
- Cursor — 在编程时调用 示例应用 搜索笔记
- Claude Desktop — 让 Claude 发消息给 示例应用
- 自动化脚本 — 定时触发 示例应用 执行任务
关键：示例应用 被动接收请求，提供自身能力。
单向集成只是工具调用，跟 API 没有本质区别。双向集成意味着 AI 不仅能用工具，还能成为工具。当多个 AI Agent 都能互相调用时，一个 AI 生态就自然形成了。
「双向流程图」的能力藏在每次交接里
「同一个协议两个方向：消费别人的工具 vs 把自己暴露给别人」说明，Agent 的表现不只由模型决定。模型、上下文、工具、状态、权限和人之间的每次交接，都会改变任务能否继续以及出了问题能否恢复。
先写清状态，再增加能力
从「同一个协议两个方向：消费别人的工具 vs 把自己暴露给别人」出发，可以把流程拆成起始状态、下一步动作、工具返回、状态更新和停止条件。这样调试时找的是第一处丢失信息或权限的位置，而不是笼统地说“模型变笨了”。
- Cursor — 在编程时调用 示例应用 搜索笔记
- Claude Desktop — 让 Claude 发消息给 示例应用
- 自动化脚本 — 定时触发 示例应用 执行任务
成功路径不能代表系统可靠
用「同一个协议两个方向：消费别人的工具 vs 把自己暴露给别人」重放一次成功和一次失败，记录每一轮真正传入的上下文、工具结果和负责人；只要第二个人能复述这条链，系统才有可维护性。
从「双向流程图」走到「作为 Client（消费者）」
「双向流程图」先把问题落在「播放双向流动 日历 邮件 数据库 网页 → ← 示例应用 调工具 A 示例应用 既是 Client 也是 Server ← → 外部调 示例应用 Cursor Claude Desktop ⚙️ 自动化脚本」上；到了「作为 Client（消费者）」，讨论继续推进到「示例应用 连接外部 MCP 服务，调用别人提供的工具能力」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析 Agent 时，沿着状态、动作、工具结果和下一步的顺序走一遍；每次交接都要能说明信息从哪里来、由谁确认、失败时停在哪里。
- 「双向流程图」：播放双向流动 日历 邮件 数据库 网页 → ← 示例应用 调工具 A 示例应用 既是 Client 也是 Server ← → 外部调 示例应用 Cursor Claude Desktop ⚙️ 自动化脚本
- 「作为 Client（消费者）」：示例应用 连接外部 MCP 服务，调用别人提供的工具能力
- 「最后的要点」：自动化脚本 — 定时触发 示例应用 执行任务
最后的「最后的要点」把讨论落到「自动化脚本 — 定时触发 示例应用 执行任务」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。