1.1 什么是 MCP

MCP 全称 Model Context Protocol，即模型上下文协议。由 Anthropic 公司于 2024 年 11 月 25 日发布，并以 MIT 许可的方式开源。

MCP 是为了解决 AI 大模型集成外部数据问题而制定的一套统一标准，在此之前，AI 大模型与外部数据的集成需要依赖于各种定制化的接口和协议，模型厂商、数据（服务）提供方、AI 应用开发者各自实现、不同场景单独适配，没有一套统一的标准和规范，开发成本高，集成困难。

于是，MCP 诞生了。有一个带头大哥（Anthropic）站了出来，发布了一套统一的标准。

图 1-1：Anthropic 发布 MCP 协议

我们可以通过一个简单的例子来理解 MCP 诞生的意义：

中国古代，战国时期，七国各自为政，使用不同的文字、货币和度量衡，不同小国之间交流困难，经济、文化、科技发展缓慢。

秦始皇统一六国后，为了方便管理，统一了文字、货币和度量衡，各国之间交流变得方便，经济、文化、科技发展迅速。

MCP 诞生的意义与此类似，协议即标准。标准的制定，是为了推进行业形成一种共识，一旦共识形成，对行业发展的推动作用是巨大的。

图 1-2：MCP 诞生的意义

1.1.1 MCP 诞生的背景

OpenAI 公司在 2022 年 11 月 30 日发布 ChatGPT 产品，开启了 AI 助手时代。让许多人第一次知道了 AI 大模型的概念。

在之后的两年多时间里，AI 大模型技术有了飞速的发展，通过聊天客户端与大模型对话，已经逐渐成了人们上网获取信息的一种主要途径。

然而大模型是通过历史数据进行训练的，这些数据在训练时就已经固定。模型训练完成后，其知识就停留在训练时的状态，无法自动获取训练之后的新信息。

为了解决大模型对训练后信息的获取问题，诞生了很多种解决方案。

模型微调

模型微调的基本原理是在预训练好的大模型基础上，使用新的数据集进行额外的训练。保持模型的基本架构不变，只调整部分参数，可以让模型学习新的知识或适应某类特定任务。

相比从头训练，模型微调需要的计算资源更少，可以快速让模型学习新的知识。

主要的局限性在于，模型微调仍然是一个先训练后使用的方案，虽然在解决某些专业领域问题时补充了新的知识，但不适用于时效性要求高的场景，比如查询互联网上的实时新闻、查询实时天气等。

记忆存储

记忆存储由大模型客户端实现，把每次用户跟大模型对话的内容存储下来，设置一定的记忆容量。每次用户提出新问题时，从记忆库中获取跟会话相关的信息，作为上下文补充给大模型，就好像是让大模型拥有了“记忆”，回复给用户的内容更加具有连贯性。

记忆存储有一定的局限性，依赖大模型支持的上下文长度。用户提出新问题时，如果把同一会话的历史内容都取出来传给大模型，容易受到大模型上下文长度的限制。如果只取跟新问题相关的历史对话内容作为上下文，则对应用侧的实现要求较高（相似度匹配技术和算法）。

RAG (Retrieval-Augmented Generation) 技术

RAG 即检索增强生成，是一种让大模型获取实时信息的重要技术。其工作原理是：当用户提出问题时，系统通过向量搜索、关键词匹配等方式，从外部知识库或实时数据源中搜索相关信息，再把检索到的信息作为上下文提供给大模型，让大模型基于补充的信息进行回答。

RAG 的运行原理如图 1-2 所示：

图 1-2：RAG 运行原理

RAG 技术的主要优势是不需要重新训练模型，成本更低，可以灵活更新知识库，保持信息的新鲜度。可以用于联网查询实时信息、跟本地文档（知识库）对话等场景。

RAG 技术的局限性在于：大模型的最终回答效果，依赖于检索到的信息质量。检索（Retrieval）步骤非常关键，需要高效的检索算法和优质的数据源，在实际应用中，这两点往往很难同时满足。

Function Calling 机制

Function Calling 是让大模型执行特定任务的一种机制。允许大模型调用外部函数或工具，将自然语言请求转换为具体的函数调用，执行特定任务并返回结果。

Function Calling 机制的工作原理为：用户提问时，应用把集成的 Functions 列表作为上下文信息提供给大模型，大模型根据用户输入判断应该调用哪个函数，并返回具体的调用参数，再由应用执行函数得到结果，作为补充上下文请求大模型做总结输出。

Function Calling 的运行原理如图 1-3 所示：

图 1-3：Function Calling 运行原理

Function Calling 跟 RAG 在外挂数据方面的主要区别在于：RAG 是由应用根据用户输入，直接查询固定的信息源，作为补充上下文提供给大模型回答问题。而 Function Calling 是应用通过工具函数提前集成多个数据源，由大模型进行调度，应用动态读取数据源，作为补充上下文提供给大模型回答问题。

Function Calling 扩大了大模型的能力边界，通过函数调用的方式，既能外挂各种类型的数据，也能执行各种类型的操作。

自 OpenAI 于 2023 年 6 月首次在其 GPT 系列模型支持 Function Calling 机制以来，各大模型厂商纷纷跟进，Function Calling 已经成为了大模型外挂数据的标配。

GPTs 应用

2023 年 11 月 7 日，OpenAI 在其首届开发者大会上发布了 GPTs。允许用户通过简单的自然语言来创建自定义的 AI 助手。

GPTs 的发布，是 AI 智能体的一个重要里程碑，推动了 AI 智能体的大众化发展。在此之后各大模型厂商纷纷跟进，推出了各自的智能体平台。

GPTs 与各大模型厂商的智能体，实现原理基本一致：由用户在模型厂商的对话产品（比如 ChatGPT、智谱清言等）自定义创建，用户可以设置系统提示词、上传知识库文件、创建工具函数集成外部 API 等。

在 ChatGPT 平台创建 GPTs 应用的界面如图 1-4 所示：

图 1-4：在 ChatGPT 平台创建 GPTs 应用

用户使用此类智能体时，给智能体发送对话，智能体带上用户输入内容、内置的系统提示词、内置的知识库文档、集成的工具函数，请求大模型调度。再根据大模型的调度参数，调用对应的工具，请求外部 API 获取结果，最后由大模型根据用户输入和补充的上下文信息做总结输出。

不难看出，此类产品的实现，是对 Function Calling 机制的进一步封装，让用户可以更方便地创建和使用智能体，在大模型的智能生成能力基础上，增加了对业务数据的获取与处理能力。

然而，随着智能体数量的增多，一些问题也逐渐暴露出来：

智能体在不同平台无法复用

比如我创建了一个用于总结文章的 GPTs，只能在 ChatGPT 上使用，如果想在智谱清言上使用，需要在智谱清言上重新创建一个智能体。对于开发者而言，增加了重复开发的成本。

智能体不方便处理本地数据

比如我本地电脑上有个客户沟通文件，我希望让大模型帮我分析一下，统计有购买意向的客户。我只能在智能体后台，上传这个文件，再让大模型分析。这里存在两个问题：

我会担心隐私泄露，不愿意把这么重要的信息上传到云端平台
每次这个文件内容更新了，我都需要重新上传，操作起来麻烦

智能体不能对外暴露能力

无论是 GPTs，还是各大模型厂商集成的智能体，基本上都是 ToC 的，也就是只面向普通用户，在模型厂商的对话类产品（ChatGPT、智谱清言等）里面使用。

从开发者的角度，我们希望智能体可以对外暴露能力。比如有人实现了一个总结文章的 GPTs，发送一篇文章的 URL 地址，得到文章的内容总结。

当我在开发”知了阅读”这类文章摘要产品时，我希望能通过 API 的形式调用这个总结文章 GPTs 的能力，而无需重复开发。

接口参数方式不统一

除了大模型厂商内置的智能体平台之外，市面上也存在着 Coze、Dify 这类的专门用于智能体创作的平台。在其平台创建的智能体，既能通过对话的形式直接使用，也可以导出 API 给其他应用接入使用。一定程度上解决了智能体对外暴露能力的问题，但是不同的智能体导出的 API 格式不统一，对于接入方而言，也是一件麻烦事。

服务/数据提供方的困扰

比如 Perplexity 作为服务提供方，开放了一套联网查询的 API，其他应用购买一个 apikey 即可接入使用。 Perplexity 肯定希望有更多的大模型应用接入它的联网 API，这样可以增加 ToB 的收入。

而 Perplexity API 的接入量，取决于大模型客户端的实现情况。只有大模型客户端写代码对接了 Perplexity API，或者由用户在大模型客户端用 Perplexity API 创建了一个智能体，才算是在这个客户端完成了接入。而这两种方式，都消耗接入方的开发/创作成本，具体有多少客户端愿意接入，这个事情不可控。

作为服务/数据提供方，肯定有这样的需求：能不能我开放的能力，不需要每个客户端单独对接，只需用户配置到客户端，即可使用？

大模型客户端的困扰

互联网上存在着海量的服务/数据提供方，通过 API 的形式开放各种能力。作为大模型客户端，比如（ChatGPT、智谱清言），如果要写代码去对接每个服务，有非常大的工作量。交给用户通过创建智能体的方式去接入服务，时间周期不可控，对智能体的质量也有很高的要求。

ChatGPT 最早推行过一段时间 Plugins，也就是 ChatGPT 客户端通过插件的方式去对接各类服务，开发成本太高，后来下架了。改为推行更轻量级的 GPTs 方案，短时间内第三方 GPTs 数量发展到几百万个。但由于大部分的 GPTs 都是简单的提示词应用，门槛太低，实用价值不高，再加上 GPTs 只能在 ChatGPT 平台使用，生态太过封闭，慢慢的也没了热度。

AI 还在迅速发展，各类智能体层出不穷。智能体的功能实现，依赖大模型的智慧能力，包括获取实时数据的能力。如何更好的解决大模型与外部数据源的集成问题，让智能体开发更简单，成了行业普遍关注的问题。

在此背景下，Anthropic 公司推出了 MCP 协议，一个开放的、基于社区共建的通信协议。定义了智能体、大模型与外部数据/服务之间的交互规范。给 AI 智能体的发展带来了新的曙光。

1.1.2 MCP 的运作原理

MCP 协议并不复杂。定义了三个角色与其互相的协作模式。

主机应用

主机应用是 MCP 协议的中心，负责接收用户输入，请求大模型生成回答。在此过程中，主机应用可以请求外挂的 MCP 服务器获取额外的数据或者执行特定的任务。

主机应用把从外挂服务器获取的数据或者执行任务的结果，作为上下文补充给大模型，让大模型生成更加符合用户需求的回答。

所有支持 MCP 协议的大模型客户端，都可以看做是主机应用。包括 Claude 桌面客户端、Cursor 编辑器、ChatMCP 网页版等。

MCP 服务器

MCP 服务器是 MCP 协议的核心组成部分，主要负责对接外部数据源或服务，通过标准的数据格式响应内容给 MCP 客户端，实现大模型外挂数据的需求。

MCP 服务器可以理解为外部数据源或服务的一个代理网关，所有的数据交互，通过代理进行。

比如，高德地图开放了其路程规划的 API，MCP 协议出来之前，大模型客户端需要通过 Function Calling 机制，自行对接高德地图的 API。

有了 MCP 协议之后，可以由数据或服务提供方（此例的高德地图）来实现一个 MCP 服务器，把自己的开放能力通过 MCP 服务器暴露，支持 MCP 协议的客户端可以直接与此 MCP 服务器通信，无需额外的对接工作。

MCP 客户端

MCP 客户端寄生于主机应用之中，由主机应用进行调度，与 MCP 服务器进行连接，实现数据交互。

MCP 协议是基于经典的 C/S （客户端/服务器）架构设计的。MCP 客户端是相对于 MCP 服务器的一个概念。主机应用要调用一个外部的 MCP 服务器，需要创建一个 MCP 客户端进行连接，MCP 客户端与 MCP 服务器是一一对应的。

而主机应用，是把大模型作为交互对象的一个客户端，称之为大模型客户端。

大模型客户端可以根据用户的输入需求，创建多个 MCP 客户端，与多个外部的 MCP 服务器进行通信，获取外部的数据，再作为补充上下文，提供给大模型进行回答。

MCP 协议的架构如图 1-5 所示：

图 1-5：MCP 协议架构

用一个具体的例子来理解 MCP 协议的运行机制。

高德地图把自己的路程规划能力，以 API 的形式开放，同时提供了一个 MCP 服务器，对接了自身的 API，提供给所有客户端使用。
用户打开 Claude 桌面客户端，配置了这个高德地图 MCP 服务器的调用方式和调用密钥。
用户在 Claude 桌面客户端发送内容：“我想下周从北京开车去上海，帮我规划一个最省时的路线。”
Claude 客户端请求大模型，告诉大模型有一个叫做高德地图的 MCP 服务器可用，其中包含一个路程规划的工具。
大模型回复给 Claude 客户端，你要请求高德地图 MCP 服务器，调用路程规划这个工具，查询参数是：出发地：北京，目的地：上海。
Claude 客户端创建一个内部的 MCP 客户端程序，请求高德地图 MCP 服务器，得到驾驶路线信息。
Claude 客户端把查到的驾驶路线，和用户最初的提问，一起发送给大模型，请求大模型回答用户问题。
有了驾驶路线作为上下文信息，大模型通过 Claude 客户端回复用户提问，给到准确的答案。

高德地图 MCP 服务器的使用流程如图 1-6 所示：

图 1-6：高德地图 MCP 服务器使用流程

在这个例子中，Claude 客户端是主机应用，通过外挂高德地图 MCP 服务器，让大模型有了路程规划能力。

同样的原理，任意提供数据或服务的第三方，都可以通过 MCP 服务器，把自身的数据和能力暴露出去，包括：互联网上的各类服务，本地电脑上的各类文件、数据库等。

任意大模型客户端，都可以实现 MCP 协议，与各类 MCP 服务器进行通信，在与大模型交互之前，获得外挂的数据作为补充上下文，让大模型的回答更加准确。

有人把 MCP 协议比喻成 AI 应用的 USB 接口，我觉得非常贴切，如图 1-7 所示：

图 1-7：USB 与扩展坞工作原理

在传统 AI 系统中，AI 模型就像一台只有有限接口的笔记本电脑，无法直接访问外部系统和数据。MCP 则扮演着”AI 扩展坞”的角色，它通过标准化的协议接口，为 AI 模型提供了连接各种外部系统的能力。

通过 MCP，AI 模型不再受限于自身的能力边界，而是能够像连接了扩展坞的笔记本电脑一样，灵活地接入各种外部系统，实现更强大的功能。

1.1.3 MCP 解决的问题

在了解完 MCP 协议的基本运作原理之后，我们再来看一下在 1.1.1 节中提到的几个问题，MCP 协议是怎么解决的。

MCP 服务器可复用

MCP 服务器只需要开发一次，即可在任意支持 MCP 协议的大模型客户端使用。用户想要使用某个 MCP 服务器时，只需要在大模型客户端添加一个配置即可。比起原来的 GPTs 或智能体应用，MCP 服务器的复用成本更低。

MCP 服务器可安全对接本地数据

MCP 服务器可以通过本地进程运行，对接用户电脑上的私有数据或文件，作为补充上下文提供给大模型回答问题。比起之前上传文件作为外挂知识库的方案，MCP 服务器的实现方式更加安全：不是把整个私有文件上传到云端，而是通过 MCP 服务器接收查询请求，最小范围内获取本地数据。

MCP 服务器可方便集成

MCP 服务器不仅可以作为外挂插件，被用户添加到大模型客户端使用。也可以作为独立的服务，被各类 AI 应用集成。

比如我要开发一个叫做：CopyWeb 的 AI 应用，其核心能力是根据用户输入的网址，快速复刻网页。

使用传统的实现方式，我需要在 CopyWeb 对接一个截图的 API，拿到 URL 地址对应的截图，再请求大模型生成复刻网页的代码。

如果使用 MCP 服务器来实现，我只需要找到一个支持网页截图的 MCP 服务器（Playwright MCP），再把 CopyWeb 作为主机应用，创建一个 MCP 客户端，请求 MCP 服务器拿到截图，再请求大模型生成复刻网页的代码。

跟在 AI 应用对接功能 API 相比，基于 MCP 协议来实现更加简单、灵活。可以把 MCP 服务器当做积木，每个 MCP 服务器集成一项或多项原子能力，开发 AI 应用，就跟搭积木一样，快速拼装，开发效率大大提升。

MCP 协议统一了对接方式

还是用上面的例子来理解，在开发 AI 应用时，如果用到外部能力，需要开发者一个个对接外部 API，不同的 API 有不同的请求地址、请求参数、鉴权方式，对接方式多样，开发工作量大。

而基于 MCP 协议来开发 AI 应用，对接多个 MCP 服务器集成各种能力时，请求和响应的格式是统一的。AI 应用创建 MCP 客户端，按照 MCP 协议约定的方式传参，MCP 服务器会按照 MCP 协议约定的格式返回数据。基于统一的格式交换数据，对接双方的实现成本都更低。

MCP 服务器，一次开发，随处运行

前面聊到了 MCP 服务器可复用的特点。对于服务/数据提供方，是一个很大的利好。

比如，Perplexity 作为服务提供方，只需要开发一次，把自己的联网搜索能力以 MCP 服务器的形式开放，等待支持 MCP 协议的客户端来对接使用。

用户可以把 Perplexity MCP 添加到任何大模型客户端使用，开发者可以在任何 AI 应用中集成 Perplexity MCP 服务器的能力。接入方没有额外的开发成本，接入意愿会大大提升。

Perplexity MCP 服务器真正做到了：一次开发，随处运行。服务调用量会大幅提升，ToB 收入也会大幅上涨。

大模型客户端，一次开发，可集成任意服务

大模型客户端接入 MCP 协议，实现对 MCP 服务器的调用功能。只需开发一次，即可集成海量的 MCP 服务器，实现任意服务/数据能力的接入。

集成新的 MCP 服务器，由用户在大模型客户端添加 MCP 服务器的配置完成。无需大模型客户端编码对接。

1.1.4 MCP 是怎么火起来的

MCP 协议于 2024 年 11 月 25 日发布，可以说是横空出世。MCP 发布的当天，国内外媒体争相报道，用”震惊，炸裂”来形容，声称 AI 行业马上要变天了。

很多人把 MCP 协议看做是 AI 应用的 HTTP 协议，其长远价值不可估量，能够给 AI 行业带来革命性的变化。

我也在第一时间阅读完了 MCP 协议的文档，我对 MCP 协议的价值和未来潜力非常看好，给出了我的几个判断：

MCP 协议是对 Function Calling 机制的升级，为大模型集成外部数据的方式定义了标准，能够有效扩充大模型的能力边界。
不管是 Function Calling 还是 MCP 协议，最大的难点还是在于大模型对用户意图的识别，如何从客户端传递的工具列表中选择最适合调用的工具，并且返回准确的调用参数，是整套机制的关键。
MCP 协议能不能成为 AI 行业的普适性标准，取决于生态的建立和共识的形成。这里面存在一个经典的”鸡蛋悖论”，也就是先有鸡还是先有蛋的问题。如果有足够多的服务/数据提供方基于 MCP 协议开放了能力，其他大模型/应用客户端会选择跟进支持；如果主流的大模型/应用客户端支持通过 MCP 协议添加服务，第三方服务/数据提供方也会愿意开放。

MCP 协议发布之初，官方实现了十几个经典的 MCP 服务器，包括网页内容抓取、时间处理、数据查询等类别，并在 Claude 客户端实现了对 MCP 服务器的接入使用。

MCP 协议在发布后的两个月时间内，都处于相对沉寂的状态，偶尔有一些新的 MCP 服务器和 MCP 客户端产品发布，但整体讨论热度不高。

直到 2025 年 1 月底，才开始有热度上升的势头。主要跟几个重要的客户端产品的功能迭代有关：

Cursor 支持 MCP

2025 年 1 月 23，知名 AI 代码编辑器产品 Cursor 发布了 0.45.x 版本，开始支持 MCP 协议，用户可以添加 MCP 服务器，读取本地数据或文件，进一步增强 Cursor 的编程辅助能力。

Windsurf 支持 MCP

2025 年 2 月 13，另一款知名的 AI 代码编辑器产品 Windsurf 发布了 Wave 3 版本，也支持了 MCP 协议。用户可以在 Windsurf 添加各类 MCP 服务器，实现各类能力的接入。

除了知名客户端产品支持 MCP 协议之外，一些知名的服务/数据提供方，包括 Perplexity、Figma 等，也把自己的部分能力，以 MCP 服务器的方式开放。进一步提升了 MCP 协议的讨论热度。

2025 年 3 月初，MCP 才迎来了真正的爆发。伴随着 AI 领域几个重量级的产品发布和几个重要的事件发生。

Manus 产品发布

Monica AI 助手团队于 2025 年 3 月 6 日发布了 Manus，这一通用 AI 智能体产品，可以模拟用户操作浏览器的行为，通过 AI 执行各类自动化任务。

Manus 一发布迅速火遍全网，成为既 DeepSeek 之后，又一个现象级的 AI 产品。

图 1-8：Manus 产品官网

Manus 火了之后，开始有人分析 Manus 的实现原理，推测用到了大量的 MCP 服务器。比如 Manus 的联网搜索、浏览器操作、文件创建、命令行调用等工具，之前都有 MCP 服务器实现了类似功能。

实现一个超级 AI 智能体，通过 MCP 服务器实现各类能力，给大模型补充上下文知识，更好的完成用户需求，是一件非常合理的事情，也是 MCP 协议发布之初的愿景之一。

据我所知，Manus 最初的功能实现，并没有用到 MCP 服务器。但 Manus 的出圈让 MCP 协议迅速火了起来，加速了 MCP 生态的发展。

OpenAI 宣布支持 MCP 协议

2025 年 3 月 27 日，OpenAI 首席执行官 Sam Altman 在推特发帖称，因为大家都很喜爱 MCP，所以 OpenAI 在其自身的产品添加了对 MCP 协议的支持，在 agents SDK 中率先接入，后续也会在 ChatGPT 桌面版和 API 中逐步支持。

图 1-9：Sam Altman 在推特上表态支持 MCP 协议

这一消息再一次拉升了 MCP 的热度。之前行业内不少人认为，OpenAI 作为 Anthropic 最主要的竞争对手，有可能会选择发布一套新的协议，而不是接入竞争对手发布的 MCP 协议。

Sam Altman 的表态，给很多之前对 MCP 协议持观望态度的人吃了一颗定心丸。之后，各类服务/数据提供方开始积极接入 MCP 协议，各大模型厂商、大模型客户端也纷纷跟进支持。

除了 Manus 的发布和 OpenAI 的表态之外，国内外 AI 圈其他几个重要的事件，也加速了 MCP 生态的发展。

2025/03/21 百度地图率先支持 MCP 协议，03/23 高德地图支持 MCP 协议，03/31 腾讯地图支持 MCP 协议
2025/03/24 Zapier 推出 MCP 全流程方案，开发者可以通过 MCP 服务器，接入 Zapier 支持的上千个 API 服务
2025/03/25 Cloudflare 推出 MCP 云托管方案，开发者可基于 Cloudflare 部署远程 MCP 服务器
2025/04/09 阿里云百炼平台上线 MCP 服务
2025/04/10 谷歌宣布将在 Gemini 和 SDK 中添加对 MCP 协议的支持
2025/04/22 Docker 推出 MCP 目录和工具包
2025/04/23 360 纳米 AI 推出 MCP 工具箱
2025/04/25 百度在 2025 AI 开发者大会上宣布全面支持 MCP 协议

MCP 的热度还在持续上升，各类服务平台、AI 应用、大模型客户端都在积极接入 MCP 协议，MCP 生态正在不断壮大。

使用谷歌搜索趋势平台（trends.google.com）查看最近半年 MCP 关键词的搜索情况，如图 1-10 所示：

图 1-10：MCP 关键词搜索趋势

可以看到，MCP 关键词在 2024 年 11 月底开始有搜索量，2025 年 1 月底开始缓慢上升，2025 年 3 月初的搜索热度开始超过 GPTs，并在接下来的一个月内迅速上升。

搜索趋势的变动，跟我们上面谈到的几个时间节点不谋而合。

1.1.5 小结

MCP 协议作为 AI 领域的”USB 接口”，通过标准化的通信协议，解决了大模型与外部数据/服务集成的核心痛点。其价值主要体现在三个方面：

标准化与统一：MCP 协议统一了 AI 应用与外部数据/服务的对接方式，降低了开发成本，提高了集成效率。MCP 为 AI 行业带来了统一的”语言”。
双边效应显著：MCP 协议创造了一个双赢的生态：

对于服务/数据提供方：一次开发，随处运行，可以有效提升服务调用量和 ToB 收入
对于大模型客户端：一次开发，可集成任意服务，无需重复对接各类 API

共识形成与生态繁荣：MCP 协议的发展，找到了”鸡蛋悖论”的破局之道：

通过 Anthropic 的示范效应，带动了首批 MCP 服务器的开发
知名客户端产品（如 Cursor、Windsurf）的支持，吸引了更多服务提供方加入
OpenAI 的公开支持，进一步推动了行业共识的形成
Manus 等爆款产品的出现，验证了 MCP 协议的实际价值

MCP 协议已经成为了 AI 领域智能体通信的事实标准。也许当前的协议设计还存在着一些问题，但共识的形成是不可逆的。随着双边效应的持续放大，MCP 的生态会越来越繁荣，协议也会越来越完善。

MCP，未来可期。