MCP火了！3月新建服务器数量暴涨300%，揭秘最真实的MCP生态

今年以来，MCP彻底火了。

过去一个月内，OpenAI、谷歌、微软和亚马逊四大顶级AI科技公司陆续宣布支持MCP协议。

同时，谷歌和思科也各自推出了MCP的“补充”：Agent2Agent(A2A)协议和Agent Connect协议(ACP)。

截至目前，MCP Server 代码库的GitHub 星标已飙升至25000以上，并且还在快速增长。仅在3月份，Smithery

（MCP服务器“集散地”）

种种迹象显示，MCP正加速成为下一代智能体系统的基础设施标准。

那么，现在MCP生态究竟发展到了什么地步？

昨天，美国风投机构Madrona合伙人Jon Turow 和Baxter Black发布了一篇文章《MCP 的崛起真正体现了什么：两个生态系统的故事》。

在这篇文章中，两位大佬分析MCP服务器目录和软件包仓库的数据，试图用最真实的数据，来揭示MCP生态系统演进的真实位置，以及所催生的创业机会。

打通AI代理外部交互的“最后一公里”

在分析数据之前，先来说说MCP存在的意义以及它要解决的问题。

对AI代理来说，最重要的并不是与用户对话，而是与外部服务交互，以访问实时信息、处理数据并代表用户采取行动。这些才是让AI转化为真正有用代理的关键。

传统上，API一直是服务之间交互的标准方式，他们需要精确的参数格式、严格的错误处理协议以及精准的响应解析，这些结构化和确定性的特征与大模型的运行方式存在根本冲突。

Toolformer和Gorilla等早期研究项目表明，大型语言模型可以学习与API交互，但却暴露出一个根本性的问题：AI 型的概率性质不太适合传统API的确定性要求。

由于AI模型存在概率输出，经常会出现参数错乱、响应格式错误或无法正确处理错误的情况。这使得AI代理几乎无法大规模地使用可靠的工具。

而MCP为AI模型提供了一种标准化方法来解决此问题，使其能够发现可用的工具、了解如何正确使用它们，并在不同工具之间切换时保持对话上下文。它为代理与工具的交互带来了确定性和结构性，从而实现了可靠的集成，无需为每个新工具编写自定义代码。

为了理解这在实践中造成的差异，我用一个具体案例进行说明：请考虑当用户要求AI助手“在我的Figma设计中添加一个红色按钮”。

在没有MCP的情况下，AI可能会尝试生成代码来调用Figma的API，它可能会出现各种各样的错误，比如参数错误，又或者错过身份验证步骤，最终导致工作流程崩溃。

使用MCP时，当Cursor连接到Figma的MCP服务器，AI会确切知道有哪些可用的方法，这些方法需要哪些参数，以及如何正确格式化请求。Figma的MCP服务器则会告诉Cursor，“这是添加红色按钮的确切方法”，然后该操作就能一致成功执行。

也就是说，用户无需了解底层的技术细节就能得到他们所要求的结果。这种确定性的交互正是MCP如此令人兴奋的原因——它将不可预测的AI实验转化为可靠的生产工具。

这不仅仅是一种便利，而是一项根本性的转变，让AI代理在现实世界中切实可用。正因如此，整个行业都对此充满期待。

MCP的真实现状：

需求仍然集中在基础模块构建

当前的需求集中在搜索工具和命令行实用程序等基础构建块

从原始数据来看，MCP的爆炸式增长显然主要源于新服务器和开发工具的创建。

我们可以将这些新的服务器和工具，称为生态系统的“供应方”，它们为AI代理提供的构建模块：搜索工具、API 连接器、数据访问层等等。

从数据上看可用的MCP服务器数量正在快速增长。官方MCP TypeScript SDK正在快速增长，npm 的每周下载量约为70万次。

（NMP是一个Node.js包管理和分发工具，NPM上面有许许多多公用的模块，都由来自世界各地的Node.js开发者贡献的）

仅在3月份，Smithery

（MCP服务器“集散地”）

虽然服务器创建很多，但实际使用量仍然高度集中在几个服务器。

在Smithery的2500多台MCP服务器中，只有8台的安装量超过50000。其分布遵循经典的幂律：

有趣的是，虽然“网页搜索”的服务器数量最多，但在实际使用中，“文件搜索”和“代码/开发”服务器的平均每台服务器安装量却高得多——分别为3096台和3239台。

这表明早期用户是寻求实用工具的技术构建者，而不是大众市场的体验者。这也说明了一件事情：这仍然是一个以技术为中心、面向开发者的生态系统。

1）网络搜索

（529台服务器）

（323台服务器）

• 流行的网络搜索选项包括集成网络和本地搜索的Brave Search和使用其Sonar Pro模型进行网络查询的Perplexity Search。

• 安装最多的代码/开发工具服务器通过结构化的思维过程实现动态、反思性的问题解决：顺序思维和思考工具。

2）文件搜索工具的使用集中度较高，平均安装量排名第二

（3096）

Desktop Commander服务器是Smithery平台上安装数量第二多的服务器；该服务器用于执行终端命令和管理具有差异编辑功能的文件。

3）通讯工具的服务器数量排在第三低，为57台，但平均安装数量高达1165台，此类别中的顶级服务器均与Google套件兼容：

VeyraX服务器是安装最多的通信服务器，它兼容70多种工具，其中最著名的是 Gmail。通信类别中的其他顶级服务器专注于支持 Gmail 管理，其中四个服务器的名称中包含“Google Workspace”。

我们还跟踪了从npm下载可直接与桌面主机一起使用的MCP服务器包的活动。

在npm生态系统中，总共发现了53个MCP SDK包和751个MCP服务器包。SDK的下载量增长速度显著快于服务器的下载量，这表明了一个由供应主导的动态。开发者们正在为那些尚未实现的应用做准备。

其中，“AI/工具”类别在原始下载量方面领先。在已发布156台服务器中，平均每台服务器的安装量超过1万次。然而，就每台服务器的吸引力而言，一些规模较小的类别却表现得远超预期。

“文件搜索”类别仅有13台服务器，但平均安装量达2万次，这些工具正在为代理工作流程带来真正的价值。同样，“CLI 命令”软件包也悄然占据了下载量的主导地位：虽然只有39个，但其平均安装量却超过了其他更受欢迎的类别。

npm每周下载数据也揭示了有趣的分类趋势。“CLI 命令”以13.1万的总下载量领先

（其中用于从该平台安装软件包的Smithery-CLI占了大部分）

“AI/工具”和“网页搜索”紧随其后，下载量分别为8.7万和8.4万，不过“AI/工具”的下载量处于稳定状态，而“网页搜索”则保持稳步增长。

总体而言，安装数据反映出开发者群体技术水平极高，但仍处于实验阶段。

安装数据反映出目前AI代理的开发者群体技术底蕴深厚，但大都在进行非常底层的工作，这表明他们目前处于早期试验阶段。当前的需求集中在搜索工具和命令行实用程序等基础构建块上，而这些基本功能将成为未来更复杂工作流程的基础。

和应用的“飞轮效应”开始显现

让我们来理解一下数据所揭示的供需不匹配和不一致现象：

1.应用程序正在推动基础设施优先级的提升：当前的需求大多集中在桌面应用程序和单用户场景上。以代码为核心的AI助手Cursor已成为MCP需求的主要来源之一，这与那些最受开发者欢迎的工具的发展趋势相吻合。

随着用户对其应用程序功能的需求不断增长，他们对新型基础设施的需求也随之增加。当ChatGPT或者Operator引入MCP支持，这可能会为一系列新的多用户代理应用奠定坚实的基础。

2.基础设施集中化正在赋能新的应用：我们在推理工具

（例如Smithery的“顺序思维”）

Smithery的“顺序思维”服务器的流行并非偶然——它解决了我们之前概述的根本问题。

与期望AI模型能够概率性地学习API使用模式（像Toolformer尝试的那样）不同，它直接将结构化的推理编码到工具中，使得交互更加确定和可靠。这种模式表明，未来成功的工具也将类似地编码知识和结构，而不是依赖AI模型自己去摸索出来。

这不是一个“基础设施阶段”与“应用阶段”的故事——而是两者之间持续的相互作用，正如 Union Square Ventures 在2018年所描述的那样。MCP服务器的供应正在响应早期的应用需求，同时也为应用程序开发人员创造了新的可能性。

/ 04 /

MCP的机会在哪？

根据我们的研究，这种相互作用使得基础设施和应用端都存在不同的机会：

对于基础设施和工具提供商：

如果你正在构建或增强代理可以利用的工具和服务，那么数据表明有三个明确的必要条件：

1）不要对MCP孤注一掷。

MCP的价值在于，它解决了概率性AI模型与确定性API需求之间的根本不匹配问题。固然相比于集成其他东西，MCP服务器是当前帮助开发者可靠集成服务的一个更好选择。但这些协议的未来存在很大变数。正如一位基础设施提供商所说，今天的开发者‘被困在一个尚未成熟的框架中’。所以在使用MCP进行构建的同时，但要注意保持灵活性以适应标准的发展。”

2）注意阻碍因素的变化。

现在，有一些关键问题阻碍了更广泛的MCP采用。其中，安全性和治理是最核心的问题，特别是对于那些需要强权限、可审计性和风险控制的应用场景来说，这一点很关键。

另外，发现和认证

（AuthN/AuthZ）

信任也是一个问题。随着数千个MCP服务器上线，开发者和代理需要更好的方法来识别可靠的工具并剔除存在风险的工具。除了存在风险的工具外，缺少防护措施意味着你的IDE可能会在某个时刻尝试删除关键文件。

组成和协作是当今环境中的另外两个阻碍因素。最强大的代理应用程序需要能够利用其他工具的工具——包括在执行过程中调用LLM（大型语言模型）或其他服务。目前的MCP规范并不容易支持这种级别的组合，从而限制了开发者在MCP上能构建的应用复杂性。

在这种情况下，创始人可以通过参与扩展MCP、采用Google A2A 或 Cisco ACP的部分功能，或构建自己的解决方案来弥补这些差距。找到正确方案来弥补这些差距的人不仅能改进自己的产品，还能推动整个生态系统的发展。

3）积极响应实际的代理开发需求。

最成功的基础设施提供商应该密切观察代理用户的实际构建需求，并不断改进其产品以解决他们遇到的具体痛点。这种响应能力，而非任何特定功能，将决定哪些基础设施提供商能够蓬勃发展。

对于代理开发者：

这里蕴含着变革性的机遇。AI代理代表着一种全新的应用形态，所有互联网公司都会展开竞争。正如移动互联网创造了应用程序一样，代理也提供了类似的重新洗牌的机会。

MCP供应热潮有机会创造出比以往更强大的工具。简单来说，利用这个不断扩展的工具包，你能实现以前不切实际或不可能完成的任务。

数据显示，即使目前应用范围有限，推理、Web 交互、数据访问和通信工具也在快速成熟。这意味着代理开发者可以专注于通过组合和编排来创造价值，而无需从头构建核心功能。

数据显示，一些服务不足的类别可能蕴含着机遇，包括生产力工具、分析能力、商务解决方案和旅行服务。但与其追逐类别，不如找到一个你真正感兴趣的客户问题，并利用MCP和代理堆栈不断扩展的功能，找到切实可行的解决方案。

MCP 仍是一项新兴技术，存在诸多局限性，例如我们上文提到的身份验证、发现和安全方面的局限性。但它凸显了一个不容置疑的趋势：代理的功能正在扩展到远超聊天的范畴。

因此，应用程序开发者应该考虑的是，随着基础设施的不断完善，哪些功能是可行的/实用的。比起技术热情，解决客户生产过程中的实际问题，让客户满意，才是最重要的事情。

/ 05 /

被压缩的AI周期

固然，MCP生态系统的发展轨迹与互联网有着诸多相似之处，但有一个关键的不同点：

AI进步的时间线被大大压缩了，这意味着基础设施与应用程序之间的相互作用比以往任何时候发生得更快。

诚然，尽管MCP早期曾令人兴奋不已，但任何事情都可能发生。历史上，OpenStack的协议曾经在市场上引发热议，最终却毫无进展。而现在MCP的“补充”，比如Google A2A 和 Cisco ACP，未来也不排除可能成为更成熟的应用方案。

不过，这些细节并不重要。最重要的是，代理应用程序的开发者对能够扩展其代理功能（超越聊天功能）的基础设施的明确需求。那些能够识别出以前难以解决、现在可解决的问题的创始人，将真正定义AI时代的产品。

还记得可口可乐吗？工业制冷技术花了几十年才成熟到足以大规模分销冷饮。可口可乐的产品创新与基础设施建设之间的关系历经几代人的发展。在人工智能代理的世界里，我们看到了类似的相互作用模式，只不过是以月为单位，而不是以十年为单位。

与工业基础设施、互联网的缓慢演进不同

（iOS 应用商店于2008年推出，但 Uber 和 Airbnb 直到2010年才出现）

无论是构建基础设施还是应用程序，那些现在就准备好驾驭这波互动浪潮的建设者，都将定义下一代人工智能软件。

文/林白

PS：如果你对AI大模型领域有独特的看法，欢迎扫码加入我们的大模型交流群。