MCP Is Not Replacing REST. It Is Replacing the Entire Mental Model of How Agents Use Tools.

MCP 并没有取代 REST，它正在取代智能体使用工具的整个思维模型。

REST was designed for humans writing code to call services. You read the docs, you write the client, you ship it. That whole loop assumes a developer is in the middle, translating intent into HTTP calls. When you put an LLM in the driver’s seat, that assumption breaks completely, and the cracks are showing up in every agent system I have seen in production. REST 是为人类编写代码以调用服务而设计的。你阅读文档，编写客户端，然后发布。整个流程都假设中间有一个开发者，负责将意图转化为 HTTP 调用。当你把大模型（LLM）放在驾驶座上时，这个假设就彻底失效了，我在生产环境中见过的每一个智能体系统都出现了这种裂痕。

What Actually Happened

实际发生了什么

Model Context Protocol (MCP), originally introduced by Anthropic, has crossed from “interesting spec” to “actual adoption pressure” faster than most protocol transitions I have watched. The pattern is now visible across the ecosystem: Cognizant just expanded their Anthropic partnership specifically to bring Claude-powered agents to enterprise workflows, and when you look at what those workflows require, MCP is not optional. You cannot bolt REST onto an agent loop and call it done. 由 Anthropic 最初推出的模型上下文协议（MCP），从“有趣的规范”转变为“实际的采用压力”的速度，比我观察到的大多数协议转型都要快。这种模式现在在整个生态系统中清晰可见：Cognizant 刚刚扩大了与 Anthropic 的合作伙伴关系，专门将 Claude 驱动的智能体引入企业工作流。当你审视这些工作流的需求时，MCP 并非可选项。你无法简单地将 REST 强加到智能体循环中就完事了。

The short version of what MCP is: a standardized, bidirectional protocol that lets LLMs discover, negotiate, and invoke tools without a human writing a custom client for each integration. The server advertises its capabilities. The model reads them. The model calls them. No glue code, no prompt-stuffed API docs, no fragile JSON schema passed in a system prompt and hoped for the best. 简单来说，MCP 是一种标准化的双向协议，它允许大模型在无需人类为每个集成编写自定义客户端的情况下，发现、协商并调用工具。服务器发布其能力，模型读取这些能力，然后进行调用。不再需要胶水代码，不再需要塞满提示词的 API 文档，也不再需要将脆弱的 JSON 模式放入系统提示词中并祈祷它能正常工作。

REST was never the problem. HTTP is fine. The problem was the integration layer that had to exist between “LLM knows what it wants” and “service exposes an endpoint.” That layer has been killing agent reliability in production. REST 从来不是问题所在，HTTP 本身很好。问题在于必须存在于“LLM 知道它想要什么”与“服务暴露端点”之间的集成层。正是这一层一直在破坏生产环境中智能体的可靠性。

The Technical Detail That Matters

关键的技术细节

Here is the specific failure mode that MCP fixes. In a typical REST-based agent integration, you stuff tool descriptions into the context window. The model reads them, generates a function call, and you parse that back into an HTTP request. This works until it does not, which is: when the schema drifts, when the model hallucinates a parameter name, when the endpoint returns an unexpected shape, or when you need the tool to push state back to the model mid-task. 以下是 MCP 修复的具体故障模式。在典型的基于 REST 的智能体集成中，你将工具描述塞入上下文窗口。模型读取它们，生成函数调用，然后你将其解析回 HTTP 请求。这在某些情况下有效，但在以下情况会失效：模式发生偏移、模型幻觉出参数名称、端点返回了意外的数据结构，或者当你需要在任务中途让工具将状态推回给模型时。

MCP is a session-oriented protocol, not a request-response one. The connection stays open. The server can send notifications. The model can maintain state across multiple tool calls without you serializing and deserializing context between every round trip. For anything involving multi-step agent tasks, that is not a nice-to-have. It is the difference between an agent that can actually complete a workflow and one that loses the thread halfway through. MCP 是一种面向会话的协议，而不是请求-响应协议。连接保持开启，服务器可以发送通知。模型可以在多次工具调用中保持状态，而无需你在每次往返之间序列化和反序列化上下文。对于任何涉及多步智能体任务的工作来说，这不仅仅是锦上添花，它决定了一个智能体是能够真正完成工作流，还是在中途丢失逻辑。

The other piece that matters architecturally: MCP separates capability discovery from capability invocation. The model can ask “what can you do?” before it commits to a plan. That changes how you build agent orchestration. Instead of hardcoding tool availability into your system prompt, you let the agent discover it dynamically. Your multi-tenant platform can serve different tool sets to different tenants from the same agent runtime, without rewriting prompts per customer. 架构上另一个重要的点是：MCP 将能力发现与能力调用分离开来。模型可以在确定计划之前询问“你能做什么？”。这改变了你构建智能体编排的方式。你不再需要将工具可用性硬编码到系统提示词中，而是让智能体动态发现它们。你的多租户平台可以在同一个智能体运行时中为不同租户提供不同的工具集，而无需为每个客户重写提示词。

What This Means for Builders

这对开发者意味着什么

If you are running a RAG pipeline that exposes retrieval as a tool, you are probably doing it via a function-calling schema today. That works, but you are carrying a maintenance burden every time your retrieval interface changes. MCP gives you a contract that the agent runtime and the retrieval server negotiate directly. 如果你正在运行一个将检索作为工具暴露的 RAG 流水线，你现在可能正在通过函数调用模式来实现。这确实有效，但每当你的检索接口发生变化时，你都要承担维护负担。MCP 提供了一种契约，让智能体运行时和检索服务器直接进行协商。

If you are building a multi-tenant AI platform, the capability discovery model is the real unlock. You stop thinking about tools as static config and start thinking about them as services the agent can introspect. Tenant A gets access to Salesforce tools. Tenant B gets Jira tools. The agent figures out what is available per session. You stop managing a matrix of prompt templates. 如果你正在构建一个多租户 AI 平台，能力发现模型才是真正的突破口。你不再将工具视为静态配置，而是将其视为智能体可以内省的服务。租户 A 可以访问 Salesforce 工具，租户 B 可以访问 Jira 工具。智能体会在每个会话中自行判断可用工具。你不再需要管理复杂的提示词模板矩阵。

If you are building agent frameworks, the session model means you can implement proper long-running task patterns, including progress updates, partial results, and cancellation, without hacking them on top of webhook callbacks and polling loops. 如果你正在构建智能体框架，会话模型意味着你可以实现真正的长任务模式，包括进度更新、部分结果和取消操作，而无需在 Webhook 回调和轮询循环之上进行各种“黑客式”的修补。

The practical risk right now: MCP servers vary wildly in quality. The spec is solid but the implementations are early. Plan for defensive handling on the client side. 目前的实际风险是：MCP 服务器的质量参差不齐。规范很扎实，但实现尚处于早期阶段。请在客户端做好防御性处理的准备。

One Thing to Do Today

今天可以做的一件事

Pull down the MCP TypeScript SDK from the official repo at github.com/modelcontextprotocol/typescript-sdk and spin up the example server locally. Then write a minimal MCP client that connects to it, calls the capability discovery endpoint, and logs what comes back. That single exercise will reframe how you think about tool integration faster than any blog post will, including this one. 从官方仓库 github.com/modelcontextprotocol/typescript-sdk 下载 MCP TypeScript SDK，并在本地启动示例服务器。然后编写一个最小化的 MCP 客户端来连接它，调用能力发现端点，并记录返回的内容。这一个练习将比任何博客文章（包括这一篇）更快地重塑你对工具集成的思考方式。