Anthropic于2024年11月发布了其模型上下文协议（Model Context Protocol, MCP），旨在实现工具和平台的模型无关性。MCP通过定义服务器和客户端来运作。MCP服务器是定义工具和资源的本地或远程端点。例如，GitHub发布了一个MCP服务器，允许大型语言模型（LLM）对GitHub进行读写操作。MCP客户端则是AI应用程序与MCP服务器之间的连接，它们允许LLM与来自不同服务器的上下文和工具进行交互。Claude Desktop就是一个MCP客户端的例子，它允许Claude模型与数千个MCP服务器进行交互。
1. MCP协议的实践应用
在相对较短的时间内，MCP已成为数百个AI管线和应用程序的支柱。Anthropic和OpenAI等主要参与者已将其整合到自身产品中。Cursor（一款专注于编码的文本编辑器或IDE）和Raycast等生产力应用程序也使用MCP。此外，数千名开发者正利用它集成AI模型并访问外部工具和数据，而无需从头构建整个生态系统。
在与《AI Frontiers》合作发表的早期工作中，研究认为MCP能够有效解耦“上下文”——即帮助AI应用程序为消费者提供更相关答案的数据。通过这种方式，它有助于分散AI市场。研究强调，为使MCP真正实现其目标，需要以下方面的支持：
- 开放API：使MCP应用程序能够访问第三方工具以实现代理使用（写入操作）和获取上下文（读取）。
- 流式记忆：可互操作的LLM记忆标准，通过类似MCP的开放协议访问，确保在OpenAI和其他领先开发者处积累的记忆上下文不会被困于特定平台，从而阻碍下游创新。
针对这两点，一份近期政策说明进行了更深入的阐述，供读者进一步探讨。
更普遍地，文章指出，像MCP这样的协议实际上是AI市场的基本“道路规则”，通过将开放披露和通信标准内置于网络本身，而非由监管机构事后强制实施。协议从根本上是市场塑造工具，通过网络本身的权限、规则和互操作性来构建市场。它们对建立在其之上的商业市场的运作方式也可能产生重大影响。
1.1 MCP生态系统如何演进？
然而，目前对于MCP生态系统目前的具体形态缺乏清晰的认识。MCP最常见的用例是什么？MCP服务器提供了何种访问权限，MCP客户端又使用了哪些访问权限？通过MCP访问的数据是仅用于上下文的“只读”模式，还是允许代理进行“写入”和交互操作，例如编辑文件或发送电子邮件？
为初步回答这些问题，本文将探讨AI代理通过MCP服务器使用的工具和上下文。这提供了关于正在构建什么以及哪些内容受到关注的线索。在本文中，分析不涉及MCP客户端——即使用MCP服务器的应用程序。相反，分析仅限于MCP服务器所提供的可构建内容。
研究人员收集了一个大型MCP服务器数据集（n = 2,874），数据来源于Pulse。随后，利用GitHub的星标数量数据对每个服务器进行了丰富。在GitHub上，星标类似于Facebook的“赞”，开发者会使用它们来表达赞赏、收藏项目或表示使用情况。
实际上，尽管存在大量MCP服务器，但研究发现，排名前几位的服务器吸引了大部分关注，并很可能由此获得了大部分使用量。仅排名前10的服务器就获得了MCP服务器所有GitHub星标的近一半。
研究的主要发现包括：
- MCP的使用似乎高度集中。这意味着，如果不加以干预，少数服务器以及（由此延伸的）API可能会对正在形成的MCP生态系统产生过大的控制力。
- MCP的使用（所访问的工具和数据）主要集中在三个类别：数据库与搜索（RAG）、计算机与网络自动化，以及软件工程。这三类合计获得了GitHub上近四分之三（72.6%）的星标（作为使用量的代理指标）。
- 大多数MCP服务器同时支持读取（访问上下文）和写入（更改上下文）操作，这表明开发者希望其代理能够对上下文采取行动，而不仅仅是消费信息。
2. 研究发现
首先，研究人员分析了MCP生态系统的集中风险。
2.1 MCP服务器使用高度集中
研究发现，通过每个仓库获得的GitHub星标数量判断，MCP的使用集中在几个关键的MCP服务器上。
尽管存在数千个MCP服务器，但排名前10的服务器占据了MCP服务器所有GitHub星标的近一半（45.7%）（见下图饼状图），而排名前10%的服务器则占据了88.3%的星标（未显示）。
在包含2,874个服务器的数据集中，排名前10的服务器获得了45.7%的GitHub星标。图片来源：本文作者。
这意味着大多数实际的MCP用户可能依赖于少数几个通过少量API提供的服务。这种集中化可能源于网络效应和实际效用：所有开发者都倾向于选择解决通用问题（如网页浏览、数据库访问）以及与GitHub、Figma、Blender等广泛使用平台集成的服务器。这种集中模式在开发者工具生态系统中似乎很常见。少数执行良好、适用性广泛的解决方案往往占据主导地位，而更专业的工具则占据较小的利基市场。
2.2 排名前10的MCP服务器至关重要
接下来，下表展示了排名前10的MCP服务器及其星标数量和功能描述。
在排名前10的MCP服务器中，GitHub、Repomix、Context7和Framelink旨在辅助软件开发：Context7和Repomix通过收集上下文提供帮助，GitHub允许代理与项目交互，而Framelink则将Figma的设计规范直接传递给模型。Blender服务器允许代理使用流行的开源Blender应用程序创建任何3D模型。最后，Activepieces和MindsDB通过一个标准化的接口将代理连接到多个API：MindsDB主要用于从数据库读取数据，而Activepieces用于自动化服务。
排名前10的MCP服务器及其简要描述，设计由Claude提供。图片来源：本文作者。
以浏览器使用（Browser Use）（61,000星标）和Playwright MCP（18,425星标）形式出现的代理式浏览（agentic browsing）的支配地位引人注目。这反映了AI系统与网络内容交互的根本需求。这些工具允许AI像人类一样导航网站、点击按钮、填写表单和提取数据。尽管代理式浏览的令牌效率远低于调用API，但其使用量却大幅增长。浏览代理通常需要翻阅多页的样板文件才能提取出少量数据，而这些数据通过单个API请求即可返回。由于许多服务缺乏可用的API或对其进行严格限制，基于浏览器的代理通常是最简单——有时是唯一——的集成方式，这凸显了当前API的局限性。
一些排名靠前的服务器是非官方的。Framelink和Blender MCP服务器都只与单个应用程序交互，但它们都是“非官方”产品。这意味着它们并未获得所集成应用程序（即拥有底层服务或API，如GitHub、Slack、Google的开发者）的官方认可。相反，它们由独立开发者构建，通过逆向工程API、封装非官方SDK或使用浏览器自动化来模拟用户交互，在AI客户端和服务之间搭建桥梁。
第三方开发者能够构建自己的MCP服务器是健康的，因为这种开放性鼓励创新。但它也引入了用户和API之间的中间层，这带来了信任、验证甚至潜在滥用的风险。对于开源本地服务器，代码是透明的，可以经过审查。相比之下，远程第三方服务器更难以审计，因为用户必须信任他们无法轻易检查的代码。
从更深层次来看，目前主导MCP服务器的仓库突出了MCP生态系统的三个令人鼓舞的事实：
- 首先，几个知名的MCP服务器支持多种第三方服务以实现其功能。MindsDB和Activepieces充当了通往多个（通常是竞争性的）服务提供商的单一网关。MindsDB允许开发者通过一个接口查询PostgreSQL、MongoDB和MySQL等不同的数据库，而Taskmaster则允许代理将任务委托给OpenAI、Anthropic和Google的各种AI模型，所有这些都无需更改服务器。
- 其次，代理式浏览MCP服务器正被用来规避可能具有限制性的API。如上所述，浏览器使用和Playwright通过网页浏览器访问互联网服务，有助于绕过API限制，但它们转而面临反爬虫保护。这规避了API可能对开发者构建能力施加的限制。
- 第三，一些MCP服务器在开发者计算机上（本地）进行处理，使其较少依赖供应商维护API访问。审查的10个MCP服务器中，有些可以完全在本地计算机上运行，而无需将数据发送到云端——这意味着没有任何守门人有权切断连接。在这10个MCP服务器中，只有Framelink、Context7和GitHub依赖于单个无法在本地端到端运行的纯云API依赖。Blender和Repomix是完全开源的，不需要任何互联网访问即可工作，而MindsDB、浏览器使用和Activepieces都具有本地开源实现。
2.3 主导MCP使用的三大类别
接下来，研究人员根据功能将MCP服务器分为不同的类别。
在分析最受欢迎的服务器类型时，研究发现有三类占据主导地位：计算机与网络自动化（24.8%）、软件工程（24.7%）和数据库与搜索（23.1%）。
软件工程、计算机与网络自动化以及数据库与搜索共获得了MCP服务器所有星标的72.6%。图片来源：本文作者。
软件工程（24.7%）MCP服务器的广泛使用与Anthropic的经济指数一致，该指数发现AI交互的很大一部分与软件开发相关。
计算机与网络自动化（24.8%）和数据库与搜索（23.1%）的流行也合乎情理。在MCP出现之前，网页抓取和数据库搜索在ChatGPT、Perplexity和Gemini等平台中是高度集成的应用程序。然而，有了MCP，用户现在可以以最小的努力访问相同的搜索功能，并将其代理连接到任何数据库。换句话说，MCP的解耦效应在这里表现得非常明显。
2.4 代理与其环境交互
最后，研究人员分析了这些服务器的功能：它们是仅允许AI应用程序访问数据和工具（读取），还是允许它们执行代理操作（写入）？
在除了两个MCP服务器类别之外的所有类别中，最受欢迎的MCP服务器都支持读取（访问上下文）和写入（代理）操作——如青绿色所示。普遍存在的读写结合访问的服务器表明，代理的构建不仅是为了根据数据回答问题，也是为了代表用户采取行动并与服务交互。
按类别展示MCP服务器。虚线红色表示10,000个星标（赞）。最受欢迎的服务器支持代理的读写操作。相比之下，几乎没有服务器仅支持写入操作。图片来源：本文作者。
两个例外是数据库与搜索（RAG）和金融MCP服务器，其中只读访问是一种常见的权限。这可能是因为数据完整性对于确保可靠性至关重要。
3. 多重访问点的重要性
此次初步分析可得出以下几点启示。
首先，MCP服务器使用的集中化加剧了API访问受限的风险。正如先前文章《协议与权力》中所讨论的，MCP仍然受到“特定服务（如GitHub或Slack）通过其API所暴露的内容”的限制。少数强大的数字服务提供商有权关闭对其服务器的访问。
应对API守门限制的一个重要对策是，许多顶级服务器都试图不依赖单一提供商。此外，以下两个保障措施也至关重要：
- 尽可能提供用户机器上的数据本地处理，而不是将数据发送到第三方服务器进行处理。本地处理确保功能不会受到限制。
- 如果无法在本地运行服务（例如电子邮件或网页搜索），服务器仍应支持通过竞争性API获取所需上下文的多种途径。例如，MindsDB充当了多个数据源的网关，因此它不依赖于单个数据库进行读写操作，而是竭尽全力在一个统一界面中支持多个数据库，从而使后端工具本质上可互换。
其次，分析表明，当前限制性的API访问政策是不可持续的。通过MCP服务器进行的网页抓取和机器人操作，可能（至少部分）被用于规避过于严格的API访问限制，这使得日益普遍的禁止机器人做法变得复杂。甚至OpenAI也正在“越界”使用第三方服务通过网页抓取访问Google搜索结果，从而规避其限制性API。
以有意义的方式扩展结构化API访问至关重要。这确保了合法的AI自动化通过稳定、有文档记录的端点运行。否则，开发者将不得不求助于脆弱的浏览器自动化，而其中隐私和授权问题尚未得到妥善解决。监管指导（如美国开放银行的经验所示）可以推动市场向这个方向发展。
最后，鼓励提高透明度和披露可以帮助识别MCP生态系统中的瓶颈所在。
- 运营热门MCP服务器（达到特定使用阈值以上）或提供顶级服务器所使用的API的开发者应报告使用统计数据、访问拒绝情况和速率限制策略。这些数据将帮助监管机构在瓶颈固化之前识别它们。例如，GitHub可以鼓励这些披露。
- 此外，达到特定使用阈值以上的MCP服务器应清晰列出其对外部API的依赖，以及当主要API不可用时存在的备用选项。这不仅有助于确定市场结构，而且对于下游应用程序的安全性和鲁棒性也是必不可少的信息。
目标并非消除网络中的所有集中化，而是确保MCP生态系统保持竞争性，为创新和用户选择提供多种可行的路径。通过同时解决技术架构和市场动态问题，这些建议的调整有助于MCP实现其作为AI开发民主化力量的潜力，而不是简单地将瓶颈从一层转移到另一层。
附录
数据集
本次分析中，研究人员使用GPT-5 mini将PulseMCP.com上发现的MCP服务器分为15个类别之一。随后，人工审查并编辑了排名前50的服务器，这些服务器约占数据集中总星标数量的70%。
完整数据集以及类别描述可在此处找到（由Sruly Rosenblat构建）：
https://huggingface.co/datasets/sruly/MCP-In-Practice
局限性
这项初步研究存在一些局限性：
- GitHub星标并非下载量甚至仓库受欢迎程度的衡量标准。
- 在使用LLM对仓库进行分类时，仅使用了名称和描述。
- 分类可能存在人工和AI错误，且许多服务器可能适用于多个类别。
- 本次分析仅使用了PulseMCP列表作为数据集；其他列表包含不同的服务器（例如，mcpmarket.com上没有Browser Use）。
- 研究人员从分析中排除了一些仓库，例如那些每个代码仓库包含多个服务器的，以及无法获取星标数量的仓库。此外，分析仅限于PulseMCP上列出的服务器，服务器列表并非详尽无遗。
MCP服务器随时间的使用情况
