MCP 作为上下文分发比作为 RPC 更有用

大多数人谈论 Model Context Protocol (MCP) 时，关注的是工具调用。

他们将其视为 AI 调用外部工具的一种方式。例如，AI 读取一个 GitHub issue 或获取一个文件。这使得 MCP 看起来像是为智能体（agents）提供的一个 RPC 层。

这很有用，但它并不是最重要的用例。

MCP 的真正威力在于上下文分发（context distribution）。它可以向 AI 客户端分发规则、技能和契约。

RAG 帮助回答一个问题：哪些信息是相关的？ RAG 寻找文档并将其提供给模型。

但团队需要的不仅仅是信息。团队需要规则。

团队需要知道：

• 权威来源是什么？
• AI 何时应该停止？
• 何时需要人工确认？
• 哪个工作流适用于此任务？
• 必须记录哪些证据？

RAG 检索描述这些规则的文档，但文档仅仅是上下文。许多团队试图通过提示词（prompts）来解决这个问题。他们编写类似“遵循我们的编码规则”之类的指令。

这无法规模化。每个开发人员都有不同的本地提示词。工作质量取决于使用 AI 的人。这不是一个团队系统。

MCP 改变了这一点。AI 不仅仅是在工作期间调用工具，它可以在开始工作之前接收工作的规则。

在会话开始时，AI 客户端会调用一个启动函数。该函数返回：

• 访问策略
• 权威上下文来源
• 可用技能
• 工作流目录
• 处理未知情况的规则

模型不仅仅拥有工具的使用权，它还拥有工作的规则。

这创造了明显的区别：

• RPC 风格的 MCP：模型在工作时调用工具。
• 上下文分发风格的 MCP：模型在开始前接收规则。

这种方法使领域知识具有可移植性。与其让每个用户阅读长篇文档或更新本地提示词，不如由一名资深工程师在 MCP 服务器上定义一次技能。

定义技能的人和使用技能的人现在实现了分离。

这也解决了信息陈旧的问题。用户不需要在本地携带完整的规则库。他们只需要一个 MCP 连接。权威定义保留在服务器上。

RAG 回答的是：哪些信息可能相关？ MCP 上下文分发回答的是：哪些规则必须约束这项工作？

RAG 关乎检索知识。MCP 上下文分发关乎定义工作如何开展。

不要再问 AI 可以调用哪些工具了。开始问 AI 在开始之前必须加载哪些上下文。

Source: https://dev.to/synthaicode_commander/mcp-is-more-useful-as-context-distribution-than-as-rpc-ai4

Optional learning community: https://t.me/GyaanSetuAi