⚠️ Alpha内测版本警告：此为早期内部构建版本，尚不完整且可能存在错误，欢迎大家提Issue反馈问题或建议
Vibe Vibe

主题

MCP：它是什么以及为什么重要 ​

摘要 ​

创建 AI 与应用程序之间通用语言的标准

1. ELI5 – 理解 MCP ​

想象一下，你有一个适配所有设备的通用插头 —— 这本质上就是 模型上下文协议（MCP） 对于 AI 的意义。MCP 是一个**开放标准**（可以理解为"AI 集成的 USB-C"），它允许 AI 模型以一致的方式连接到许多不同的应用程序和数据源。简单来说，MCP 让 AI 助手使用通用语言与各种软件工具对话，而不是每个工具都需要不同的适配器或自定义代码。

那么，这在实践中意味着什么？如果你正在使用像 Cursor 或 Windsurf 这样的 AI 编码助手，MCP 就是让该助手代表你使用外部工具的共享协议。例如，通过 MCP，AI 模型可以从数据库获取信息、在 Figma 中编辑设计或控制音乐应用 —— 所有这些都通过标准化接口发送自然语言指令来完成。你（或 AI）不再需要手动切换上下文或学习每个工具的 API**；MCP "翻译器"在人类语言和软件命令之间架起了桥梁**。

简而言之，MCP 就像给你的 AI 助手一个万能遥控器来操作你所有的数字设备和服务。你的 AI 不再被困在自己的世界里，现在可以伸手安全而智能地按下其他应用程序的按钮。这个通用协议意味着一个 AI 可以与数千个工具集成，只要这些工具有 MCP 接口 —— 消除了为每个新应用程序定制集成的需要。结果是：你的 AI 助手变得更加强大，不仅能够聊天，还能在你使用的真实软件中采取行动。

🧩 构建了一个让 Claude 直接与 Blender 对话的 MCP。它帮助你仅使用提示就能创建美丽的 3D 场景！

这是我用几句话创建"守护宝藏的低多边形龙"场景的演示👇

视频：Siddharth Ahuja

2. 历史背景：从文本预测到工具增强代理 ​

要理解 MCP，回顾 AI 助手的演变会有所帮助。早期的大型语言模型（LLM）本质上是聪明的文本预测器 —— 给定一些输入，它们会根据训练数据中的模式生成延续。它们在回答问题或写作文本方面很强大，但功能上是孤立的 —— 它们没有内置的方式来使用外部工具或实时数据。如果你问 2020 年代的模型检查你的日历或获取文件，它做不到；它只知道如何生成文本。

2023 年是一个转折点。像 ChatGPT 这样的 AI 系统开始集成"工具"和插件。OpenAI 引入了函数调用和插件，允许模型执行代码、使用网页浏览或调用 API。其他框架（LangChain、AutoGPT 等）出现了，实现了多步"代理"行为。这些方法让 LLM 更像一个可以规划行动的代理：例如搜索网络、运行一些代码，然后回答。然而，在这些早期阶段，每个集成都是一次性和临时的。开发人员必须分别连接每个工具，通常使用不同的方法：一个工具可能需要 AI 输出 JSON，另一个需要自定义 Python 包装器，还有一个需要特殊的提示格式**。没有标准方式**让 AI 知道有哪些工具可用或如何调用它们 —— 一切都是硬编码的。

到了 2023 年末，社区意识到要完全释放 AI 代理的潜力，我们需要超越将 LLM 视为孤立的神谕。这催生了工具增强代理的想法 —— 可以通过软件工具观察、规划和行动的 AI 系统。面向开发者的 AI 助手（如 Cursor、Cline、Windsurf 等）开始将这些代理嵌入到 IDE 和工作流程中，让 AI 除了聊天之外，还能读取代码、调用编译器、运行测试等。每个工具集成都非常强大，但痛苦地分散：一个代理可能通过生成 Playwright 脚本来控制网页浏览器，而另一个可能通过执行 shell 命令来控制 Git。这些交互没有统一的"语言"，这使得很难添加新工具或切换 AI 模型。

这就是 Anthropic（Claude AI 助手的创建者）在 2024 年末引入 MCP 的背景。他们认识到，随着 LLM 变得更加强大**，瓶颈不再是模型的智能，而是它的连接性**。每个新的数据源或应用程序都需要定制的粘合代码，减缓了创新。MCP 的出现源于标准化 AI 与广泛软件世界之间接口的需求 —— 就像建立通用协议（HTTP）促成了网络的爆炸式增长一样。它代表了 LLM 演化的自然下一步：从纯文本预测，到带有工具的代理（每个都是定制的），再到带有通用工具接口的代理。

3. MCP 解决的问题 ​

没有 MCP，将 AI 助手与外部工具集成有点像拥有一堆电器，每个都有不同的插头，却没有通用插座。开发人员到处都在处理分散的集成。例如，你的 AI IDE 可能使用一种方法从 GitHub 获取代码，另一种方法从数据库获取数据，还有另一种方法来自动化设计工具 —— 每个集成都需要一个自定义适配器。这不仅劳动密集，而且脆弱且不可扩展。正如 Anthropic 所说：

"即使是最复杂的模型也受到数据隔离的限制 - 被困在信息孤岛后面……每个新数据源都需要自己的自定义实现，使真正连接的系统难以扩展。"

MCP 正面解决了这种分散问题，为所有这些交互提供一个通用协议。开发人员可以实现 MCP 规范，而不是为每个工具编写单独的代码，并立即使他们的应用程序可被任何使用 MCP 的 AI 访问。这大大简化了集成矩阵：AI 平台只需要支持 MCP（而不是数十个 API），工具开发人员可以一次性公开功能（通过 MCP 服务器），而不是与每个 AI 供应商单独合作。

另一个大挑战是工具之间的"语言不匹配"。每个软件或服务都有自己的 API、数据格式和词汇表。试图使用它们的 AI 代理必须知道所有这些细微差别。例如，告诉 AI 获取 Salesforce 报告、查询 SQL 数据库或编辑 Photoshop 文件，在 MCP 之前的世界中是完全不同的过程。这种不匹配意味着 AI 的**"意图"必须被翻译成每个工具的独特方言** —— 通常通过脆弱的提示工程或自定义代码。MCP 通过强加结构化的、自描述的接口来解决这个问题：工具可以以标准化方式声明其能力，AI 可以通过 MCP 服务器解析的自然语言意图调用这些能力。实际上，MCP 教会所有工具一点相同的语言，因此 AI 不需要一千本短语手册。

结果是一个更加健壮和可扩展的架构。我们不再构建 N×M 集成（N 个工具乘以 M 个 AI 模型），而是有一个协议统治所有。正如 Anthropic 的公告所述，MCP "用单一协议取代分散的集成"，产生了一种更简单、更可靠的方式来让 AI 访问它需要的数据和操作。这种统一性还为跨工具维护上下文铺平了道路 —— AI 可以将知识从一个启用 MCP 的工具传递到另一个，因为交互共享一个共同的框架。简而言之，MCP 通过引入通用的连接组织来解决集成噩梦，使 AI 代理能够像笔记本电脑接受 USB 设备一样轻松地插入新工具。

4. MCP 的架构：客户端、协议、服务器和服务 ​

MCP 在底层实际上是如何工作的？其核心是，MCP 遵循客户端-服务器架构，并针对 AI 到软件的通信进行了调整。让我们分解一下各个角色：

  • MCP 服务器： 这些是与特定应用程序或服务一起运行的轻量级适配器。MCP 服务器以标准化方式公开该应用程序的功能（其"服务"）。将服务器视为嵌入应用程序中的翻译器 —— 它知道如何接受自然语言请求（来自 AI）并在应用程序中执行等效操作。例如，Blender MCP 服务器知道如何将"创建一个立方体并应用木质纹理"映射到 Blender 的 Python API 调用。类似地，GitHub MCP 服务器可以接受"列出我的开放拉取请求"并通过 GitHub API 获取。MCP 服务器通常实现几个关键功能：

  • 工具发现： 它们可以描述应用程序提供的操作/能力（以便 AI 知道它可以请求什么）。

  • 命令解析： 它们将来自 AI 的传入指令解释为精确的应用程序命令或 API 调用。

  • 响应格式化： 它们从应用程序获取输出（数据、确认消息等）并以 AI 模型可以理解的方式格式化回来（通常作为文本或结构化数据）。

  • 错误处理： 它们捕获异常或无效请求，并返回有用的错误消息供 AI 调整。

  • MCP 客户端： 另一方面，AI 助手（或托管它的平台）包含一个 MCP 客户端组件。该客户端维护与 MCP 服务器的1:1 连接。简单来说，如果 AI 想要使用特定工具，它将通过 MCP 客户端连接到该工具的 MCP 服务器。客户端的工作是处理通信（打开套接字、发送/接收消息）并将服务器的响应呈现给 AI 模型。许多 AI "主机"程序充当 MCP 客户端管理器 —— 例如，Cursor（一个 AI IDE）可以启动一个 MCP 客户端来与 Figma 的服务器或 Ableton 的服务器对话，如配置的那样**。MCP 客户端和服务器使用相同的协议**，来回交换消息。

  • MCP 协议： 这是客户端和服务器用于通信的语言和规则。它定义了诸如消息格式、服务器如何宣传其可用命令、AI 如何提问或发出命令以及如何返回结果等内容。该协议是传输无关的：它可以通过HTTP/WebSockets 用于远程或独立服务器，甚至可以通过标准 IO 流（stdin/stdout）用于本地集成。消息的内容可能是 JSON 或另一种结构化模式（规范使用 JSON Schema 进行定义）。本质上，该协议确保无论 AI 是在与设计工具还是数据库对话**，握手和查询格式**都是一致的。这种一致性是为什么 AI 可以从一个 MCP 服务器切换到另一个而无需自定义编码的原因 —— "交互语法"保持不变。

  • 服务（应用程序/数据源）： 这些是 MCP 服务器与之交互的实际应用程序、数据库或系统。我们称它们为"服务"或数据源 —— 它们是 AI 最终想要利用的最终目标。它们可以是本地的（例如，你的文件系统、计算机上的 Excel 文件、正在运行的 Blender 实例）或远程的（例如，通过 API 访问的 SaaS 应用程序，如 Slack 或 GitHub）。MCP 服务器负责代表 AI 安全地访问这些服务。例如，本地服务可能是文档目录（通过文件系统 MCP 提供），而远程服务可能是第三方 API（如 Zapier 的 Web API，用于数千个应用程序，我们稍后会讨论）。在 MCP 的架构图中，你经常会看到本地数据源和远程服务 —— MCP 旨在处理两者，这意味着 AI 可以无缝地从你的本地上下文（文件、应用程序）和在线上下文中提取。

为了说明流程：想象你在 Cursor 中问你的 AI 助手 "嘿，从我们产品的数据库中收集用户统计数据并生成条形图。" Cursor（作为 MCP 主机）可能有一个用于数据库的 MCP 客户端（比如 Postgres MCP 服务器）和另一个用于可视化工具的客户端。查询发送到 Postgres MCP 服务器，它运行实际的 SQL 并返回数据。然后 AI 可能将该数据发送到可视化工具的 MCP 服务器以创建图表图像。这些步骤中的每一步都由 MCP 协议调解，它处理发现 AI 可以做什么（"此服务器提供 run_query 操作"）、调用它并返回结果。在整个过程中，AI 模型不必知道 SQL 或绘图库的 API —— 它只使用自然语言**，MCP 服务器将其意图转化为行动**。

值得注意的是**，安全和控制是架构考虑的一部分。MCP 服务器以某些权限运行 —— 例如，GitHub MCP 服务器可能有一个授予对某些仓库读取访问权限的令牌。目前，配置是手动的，但架构预计将来会添加标准化身份验证以提高健壮性（稍后会详细介绍）。此外，通信通道**是灵活的：一些集成在应用程序进程内运行 MCP 服务器（例如，打开本地端口的 Unity 插件），其他则作为单独的进程运行。在所有情况下，架构都清晰地分离了关注点：应用程序端（服务器）和 AI 端（客户端）通过"中间"的协议相遇。

5. 为什么 MCP 对 AI 代理和开发工具来说是游戏规则改变者 ​

MCP 是一个根本性的转变，可能重塑我们构建软件和使用 AI 的方式。对于 AI 代理来说，MCP 具有变革性，因为它大大扩展了它们的范围，同时简化了它们的设计。AI 代理现在可以通过 MCP 动态发现和使用新工具，而不是硬编码能力。这意味着我们可以通过启动 MCP 服务器轻松地赋予 AI 助手新的能力，而无需重新训练模型或更改核心系统。这类似于向智能手机添加新应用程序突然为你提供新功能 —— 在这里，添加新的 MCP 服务器会立即教会你的 AI 一套新技能。

从开发工具的角度来看，影响是巨大的**。开发者工作流程通常跨越数十个工具** —— 在 IDE 中编码、使用 GitHub 管理代码、使用 Jira 管理工单、使用 Figma 进行设计、CI 管道、用于测试的浏览器等。通过 MCP，AI 协作开发者可以无缝地在所有这些工具之间跳转，充当粘合剂。这解锁了"可组合"工作流程，其中复杂任务通过 AI 跨工具链接操作来自动化。例如，考虑将设计集成到代码：通过 MCP 连接，你的 AI IDE 可以从 Figma 提取设计规范并生成代码，消除手动步骤和潜在的误解。

"不再有上下文切换，不再有手动翻译，不再有设计到代码的摩擦" - AI 可以直接读取设计文件、创建 UI 组件，甚至导出资产，所有这些都不需要离开编码环境。

这种摩擦减少对生产力来说是游戏规则的改变者。

MCP 至关重要的另一个原因：它实现了供应商无关的开发。你不会被锁定在一个 AI 提供商的生态系统或单一工具链中。由于 MCP 是一个开放标准，任何 AI 客户端（Claude、其他 LLM 聊天机器人或开源 LLM）都可以使用任何 MCP 服务器。这意味着开发人员和公司可以混合搭配 —— 例如，对某些任务使用 Anthropic 的 Claude，稍后切换到开源 LLM —— 他们的基于 MCP 的集成保持完整。这种灵活性降低了采用 AI 的风险：你不是为 OpenAI 的插件格式编写一次性代码，而这些代码在其他地方变得无用。这更像是构建一个任何未来 AI 都可以调用的标准 API。事实上，我们已经看到多个 IDE 和工具采用 MCP（Cursor、Windsurf、Cline、Claude Desktop 应用程序等），甚至像 LangChain 这样的模型无关框架也为 MCP 提供适配器。这种势头表明 MCP 可能成为 AI 代理的事实上的互操作性层。正如一位观察者所说，有什么能阻止 MCP 演变成连接一切的 "真正的代理互操作性层"？

MCP 对工具开发人员也是一个福音。如果你今天正在构建一个新的开发工具，使其具有 MCP 能力会大大增加其功能。你不仅拥有人类使用的 GUI 或 API，还可以"免费"获得AI 接口。这个想法导致了**"MCP 优先开发"的概念，你在 GUI 之前或与 GUI 一起为你的应用程序构建 MCP 服务器。通过这样做，你从第一天起就确保 AI 可以驱动你的应用程序。早期采用者发现这非常有益。"通过 MCP，我们可以通过简单地要求 Claude 执行它们来测试复杂的游戏开发工作流程"，Unity MCP 服务器的创建者 Miguel Tomas 说。这不仅加快了测试速度（AI 可以快速尝试 Unity 中的操作序列），而且还表明了一个未来，其中AI 是软件的一等用户**，而不是事后的想法。

最后，考虑 AI 代理的效率和能力提升。在 MCP 之前，如果 AI 代理需要来自第三方应用程序的某些信息，除非开发人员预见到该需求并构建了自定义插件，否则它会被卡住。现在，随着 MCP 服务器生态系统的增长，AI 代理可以通过利用现有服务器开箱即用地处理更广泛的任务。需要安排会议？可能有一个 Google Calendar MCP。分析客户工单？也许有一个 Zendesk MCP**。多步骤、多系统自动化的障碍大大降低。这就是为什么 AI 社区中的许多人感到兴奋：MCP 可以解锁跨我们工具的新一波"AI 编排"。我们已经看到演示，其中单个 AI 代理通过 MCP 连接器流畅地从给某人发电子邮件到更新电子表格再到创建 Jira 工单。将这些操作组合**成复杂工作流程（由 AI 处理逻辑）的潜力可能会开启智能自动化的 "新时代"，正如 Siddharth Ahuja 在通过 MCP 连接 Blender 后描述的那样。

总之，MCP 很重要，因为它将开发者通用 AI 助手的梦想变成了实际现实。它是使我们的工具具有上下文感知能力并与 AI 互操作的缺失部分，具有即时的生产力收益（减少手动粘合工作）和战略优势（面向未来、灵活的集成）。接下来的部分将通过介绍 MCP 实现的一些令人瞩目的演示和用例来使这一点具体化。

6. 真实世界的 MCP 用例和演示 ​

为了真正理解 MCP 的影响,让我们深入研究一些已经在实践中展示其潜力的真实世界用例。这些例子跨越了从创意工具到开发工作流程的各个领域,展示了 MCP 如何将 AI 从被动助手转变为主动协作者。

Figma + AI:从设计到代码的无缝转换 ​

设计师和开发者之间的交接一直是软件开发中的痛点。设计师在 Figma 中创建模型,然后开发者必须手动将这些视觉效果转换为代码——这个过程容易出现误解和不一致**。Figma MCP 服务器**通过允许 AI 直接读取和解释 Figma 设计来改变这一点。

一个引人注目的演示来自 Sonny Lazuardi,他构建了一个 MCP 服务器,让 Cursor(AI IDE)与 Figma 对话。通过这种集成,开发者可以简单地要求 AI "从 Figma 文件中获取登录屏幕设计并生成 React 组件"。AI 通过 MCP 连接到 Figma,提取设计规范(颜色、字体、布局、间距),然后生成匹配的代码。正如 Sonny 所说:

"不再有上下文切换,不再有手动翻译,不再有设计到代码的摩擦。"

这种工作流程的影响是巨大的。报告显示,使用 Figma MCP 的开发者看到 UI 实现速度提高了 5 倍。以前可能需要一个小时的工作(测量像素、匹配颜色、调整布局)现在可以在几分钟内完成。AI 本质上充当了一个完美的翻译器,将设计意图转换为功能代码。

从技术角度来看,Figma MCP 服务器使用 Figma 的 REST API 来获取设计数据。它公开了诸如"获取文件"、"列出组件"、"导出资产"等工具。当 AI 调用这些工具时,服务器会获取相关的设计信息并以结构化格式返回(通常是 JSON)。然后 AI 解析这些数据并生成代码。关键的创新是 AI 不仅仅是复制粘贴——它理解设计的语义("这是一个按钮"、"这是一个输入字段")并生成适当的组件代码,包括样式和结构。

这个用例也展示了 MCP 的双向性质。AI 不仅可以从 Figma 读取,理论上还可以写回(如果 MCP 服务器实现了这一点)。想象一下要求 AI "在 Figma 中创建一个新的按钮变体,使用我们的设计系统颜色"——AI 可以通过 MCP 在 Figma 中生成该设计元素。虽然大多数当前的实现侧重于读取,但写入能力正在探索中,这可能会导致 AI 辅助设计工作流程(AI 根据反馈迭代设计)。

Blender + AI:通过自然语言进行 3D 建模 ​

3D 建模传统上需要陡峭的学习曲线和对复杂软件的深入了解**。Blender MCP** 通过让 AI 控制 Blender(流行的开源 3D 创作套件)来民主化这一过程。由 Siddharth Ahuja 创建的 Blender MCP 服务器允许用户通过自然语言描述来创建 3D 场景。例如,你可以告诉 AI:

"创建一个守护宝藏的低多边形龙,周围有岩石和戏剧性的照明。"

AI(通过 MCP)将指示 Blender 生成龙模型、放置岩石、添加光源并设置场景。这个演示在社交媒体上疯传,许多人对 AI 能够处理如此复杂的创意任务感到惊讶。

然后,AI 可以发出高级命令,如"在龙上方添加一个红色点光源",服务器将执行相应的 Blender API 调用来创建光对象、设置其颜色为红色、定位它等。重要的是,Blender MCP 支持双向通信以获得实时反馈——AI 可以查询场景(例如,"场景中有多少个对象?"或"龙的多边形数量是多少?")并通过服务器获得答案。这允许迭代细化:AI 可以检查它制作的内容并在需要时进行调整。

结果非常显著。用户报告说能够仅通过描述就生成相当复杂的场景。一位用户评价说:"我能够仅通过描述就创建一个具有适当材质的复杂低多边形场景。原本需要我几个小时的工作只用了几分钟。" 这突显了巨大的生产力提升——AI 处理重复或技术方面(插入对象、调整滑块),而用户专注于创意方向。它有效地降低了 3D 建模的入门门槛。

从开发者的角度来看,Blender MCP 的架构展示了如何集成复杂的桌面应用程序。它使用 Blender 自己的脚本引擎(在 Blender 内部运行 MCP 服务器脚本或通过套接字连接)。因为 Blender 可以在内部运行 Python,所以 MCP 服务器可以作为一个监听请求的插件存在。这里的通信是通过套接字完成的(不需要外部 API),Siddharth 提到这意味着 "没有 API 这样的东西——它让 Claude 通过套接字与 Blender 对话"。这种直接控制非常强大——本质上是远程控制 Blender。安全性本质上是本地的(这是你的 Blender),所以不用担心将其暴露在互联网上。

Blender 用例令人兴奋,不仅对 3D 艺术家而言,还因为它暗示的内容:通过 MCP 在任何复杂的创意软件(想想 Photoshop、CAD 工具、视频编辑器)中进行 AI 驱动的创作。我们现在有了一个蓝图,说明 AI 如何与此类应用程序交互:使用它们的脚本 API 作为 MCP 服务器的支柱。其含义是,未来设计师可能会通过与能够操纵其工具的 AI 代理对话来构建整个场景、动画或模型。这是一个与点击和拖动根本不同的范式——更像是与智能共同创作者合作。MCP 以标准化、可重复的方式使这成为可能。

AI + Unity:使用自然语言进行游戏开发 ​

转向游戏开发,Unity MCP 展示了 AI 如何协助构建游戏或交互式模拟。Unity 像 Blender 一样,拥有丰富的 API(C#)和开发者花费大量时间的编辑器。Unity 的 MCP 服务器(由 Miguel Tomas 等人创建)允许 AI 驱动 Unity 编辑器:它可以创建对象、配置组件、运行编辑器菜单命令等。实际上,"Unity MCP 为 AI 模型提供了对 Unity 编辑器的直接访问"。这意味着游戏开发者可以说类似这样的话:"向场景添加一个 NPC 角色,给它一个巡逻脚本,并在地图周围生成 5 个生命值拾取物",AI 通过 MCP 将执行这些步骤。

Unity MCP 服务器实现的操作包括:

  • 执行菜单项(通过自然语言):例如,"Assets -> Import Package -> AI.unitypackage"可以通过简单的请求触发
  • 选择和操纵游戏对象:AI 可以按名称或属性引用对象并移动它们、更改其属性等。
  • 运行测试或播放模式并检索控制台日志:可以要求 AI 播放场景并查看是否发生任何错误,MCP 服务器可以捕获 Unity 的控制台输出以返回它。
  • 管理包和资产:从包管理器安装新包或创建资产文件夹可以通过命令完成。

对于开发者来说,这就像在 Unity 编辑器中拥有一个语音控制(或聊天控制)助手,可以完成平凡或重复的任务。游戏开发者报告说,一旦他们有了一个 AI 来卸载任务,就能够自动化重复的琐事并更多地专注于创造力。例如,手动排列包含数十个对象的场景可能很繁琐,但 AI 可以系统地完成("在这个地形区域随机放置 100 棵树")。或者运行测试场景(如生成一个角色、模拟一些输入、看看会发生什么)可以由 AI 编排,节省 QA 时间。

Unity 中一个特别有趣的用例是使用 AI 进行快速原型设计。由于 AI 可以创建对象并附加脚本,非程序员理论上可以描述游戏机制并让工作原型出现。Unity MCP 降低了为每个操作导航编辑器 UI 的需要;AI 本质上直接调用函数。对于有经验的开发者来说,在处理大型场景或执行批量操作时(如"将所有名称中包含'temp'的对象重命名为'enemy'"),这也是一个福音,AI 可以快速处理。

从集成的角度来看,Unity MCP 必须处理强类型的编译环境。解决方案是使用 Unity 的 C# 反射和脚本在 Unity 进程内部实现服务器。该 MCP 服务器监听(通过网络端口或 stdio)命令。这展示了 MCP 如何嵌入到即使不是 Python 友好的环境中——C# SDK 或插件可以完成这项工作。Unity MCP 还必须确保操作在主线程上完成(因为 Unity 的 API 必须从其主循环调用),引入了一些服务器透明处理的复杂性。这种细节对 AI 客户端是隐藏的——它只看到一个可以做 X、Y、Z 的工具。由于这一点,我们看到了 AI 驱动的 Unity 测试示例,其中 Claude 被告知执行一个序列,它这样做了,在过程中捕获了一个错误。很容易看出这如何扩展到自动关卡设计、智能 NPC 脚本(AI 动态调整行为树)或其他高级游戏设计任务,所有这些都通过对话界面完成。

Cursor + 浏览器工具:AI 驱动的网页调试和自动化 ​

网页浏览和调试是 AI 代理的另一个肥沃土壤,MCP 为其提供了标准化的网关。这里有几个相关的用例:一个是网页调试(使用 AI 检查或操纵实时网页或 Web 应用程序),另一个是一般的网页自动化(指示 AI 浏览网站、抓取数据或测试工作流程)。在这两种情况下,将 AI 连接到浏览器或爬虫通常涉及大量设置(Selenium、Playwright 脚本等),但通过 MCP,开发者创建了使其即插即用的服务器。

一个例子是 FireCrawl MCP 服务器,一个开源服务器,向 AI 代理公开网页爬取和抓取功能。它连接到无头浏览器(使用 FireCrawl 库,该库本身使用 Chromium)并允许 AI 发送诸如"打开 URL X"、"在页面上查找文本 Y"、"点击按钮 Z"等命令,并提取内容或截图。在像 Cursor 这样启用 MCP 的 IDE 中,你可以问:"在 example.com 上找到第一个标题并复制其文本",AI 通过 FireCrawl 将导航并返回标题文本。在底层,FireCrawl MCP 提供诸如 JavaScript 渲染、批量 URL 处理和内容搜索等功能作为 AI 的服务。本质上,它为 AI 提供了具有超能力的网页浏览器工具集(并行获取等),以一个整洁的协议打包。

对于网页调试,考虑这样一个场景:你有一个 Web 应用程序,遇到了 UI 错误。你可以询问你的 AI 助手(在 Cursor 或 Windsurf 中):"检查我们的登录页面是否有任何控制台错误并截图 UI。"如果你有一个浏览器 MCP 服务器(例如,基于 Puppeteer 的服务器,Anthropic 提供了一个参考),AI 可以启动无头浏览器加载登录页面、收集控制台日志并截图页面——然后将该信息返回给你。这对于诊断问题或验证 UI 更改非常有用。事实上,一个演示展示了一个 AI 代理使用浏览器 MCP 导航网站,然后使用 GitHub MCP 打开一个包含发现的问题——全部自动完成。

Cursor + 浏览器工具的组合暗示了一个未来,其中大部分网页 QA 和自动化可以是对话式的。Cursor(IDE)已经支持连接到 MCP 服务器,因此开发者可以指示代理,比如说,爬取他们的文档网站以查找损坏的链接或模拟用户旅程。

代理可以跟随链接、填写表单并报告任何问题。

对于纯网页自动化,MCP 在可扩展性和简单性方面提供了巨大优势。Zapier(我们接下来会讨论)是一种方法,但即使没有它,带有浏览器 MCP 的 AI 理论上也可以操作任何网站。这包括诸如:从多个网站抓取产品价格、测试竞争对手的网页表单,甚至将数据填充到传统 Web 系统中等场景。今天,这些需要编写自定义脚本或使用 RPA(机器人流程自动化)工具。明天,你可能只需告诉你的 AI 目标是什么,它将通过 MCP 控制浏览器来执行。

Zapier + AI 代理:通过 MCP 连接到 8,000+ 个应用程序 ​

如果控制一个网站很有用,那么通过单个集成访问 8,000+ 个应用程序和 30,000+ 个操作怎么样?这就是 Zapier MCP 带来的。Zapier 以其连接应用程序的自动化平台而闻名,在 2024 年末推出了其生态系统的 MCP 接口——有效地将其庞大的应用程序集成目录转变为 AI 可以使用的工具。这是巨大的:AI 代理现在可以执行 Zapier 支持的任何操作,从发送 Slack 消息、创建 Google 日历事件、更新 CRM 记录到发起电子商务订单,无需为每个服务编写自定义 API 代码。

Zapier MCP 的工作原理是为 AI 提供一个 单一的 MCP 服务器端点(URL),AI 可以将其作为工具调用。在该端点后面,Zapier 动态处理到 AI 请求的特定应用程序和操作的路由。例如,AI 可能会说(通过 MCP 内部):"触发 Gmail 操作向 customer@example.com 发送主题为'跟进'的电子邮件。"Zapier MCP 服务器接收到这个请求,通过用户链接的 Gmail 集成进行身份验证,并执行发送电子邮件操作。从 AI 的角度来看,这只是一个无缝的命令。正如 Zapier 所描述的,"现在你的 AI 可以执行真实任务,如发送消息、管理数据、安排事件和更新记录——将其从对话工具转变为应用程序的功能扩展。"

这本质上为实际业务和生产力任务增强了 AI 代理。以前,即使你有一个可以很好地推理或生成文本的 AI,将其连接到你的团队使用的所有服务是令人生畏的(每个都需要 API 密钥、插件等)。通过 Zapier MCP,AI 可以即时执行诸如:向 Salesforce 添加潜在客户、在 Teams 中发布状态、在 Asana 中创建任务,甚至连接多个步骤("当客户电子邮件到达时,总结它并将其存储在 Notion 中")。它将 AI 从知识工作者转变为行动工作者。

对于开发者来说,Zapier MCP 提供了一条将 AI 集成到复杂工作流程的快速路径。你不必编写粘合代码,而是依赖 Zapier 经过实战检验的连接器。此外,Zapier 处理了许多混乱的部分,如每个应用程序的身份验证和 API 速率限制。MCP 服务器是安全和集中的:作为开发者,你获得一个唯一的端点并控制它可以做什么。

总之,Zapier MCP 展示了像 MCP 这样的标准的网络效应:它一夜之间将数千个现有集成变成了AI 可访问的。插入 Zapier 的 AI 代理变得非常多才多艺,本质上能够与那里的大多数流行软件交互。这就是为什么许多人对 MCP 感到兴奋:它不仅仅是关于一个 AI 和一个应用程序,而是关于创建一个AI 驱动的网格,连接我们所有的数字工具。Zapier 对 MCP 的早期采用为该协议提供了可信度,并可能加速了其在企业环境中的使用和可信度。

其他值得注意的 MCP 集成 ​

除了上述主要用例外,MCP 生态系统正在快速扩展,涵盖各种工具和服务。以下是一些值得注意的集成:

  • GitHub MCP:允许 AI 代理读取仓库、创建问题、管理拉取请求和执行代码审查。开发者可以要求 AI"在我的仓库中创建一个关于这个 bug 的问题"或"总结最近的提交"。

  • Slack MCP:使 AI 能够发送消息、创建频道和管理工作区。这对于自动化团队通信和通知特别有用。

  • Google Drive/Docs MCP:让 AI 访问和操作文档、电子表格和演示文稿。AI 可以总结文档、更新电子表格或根据模板创建新文件。

  • 数据库 MCP(Postgres、MySQL 等):为 AI 提供查询和操作数据库的能力。开发者可以用自然语言请求数据分析,AI 将生成并执行适当的 SQL 查询。

  • Spotify/音乐 MCP:一些实验性集成允许 AI 控制音乐播放、创建播放列表或根据心情推荐歌曲。

这些集成的多样性展示了 MCP 的灵活性和广泛适用性。从创意工具到生产力应用,从开发工具到娱乐服务,MCP 正在成为连接 AI 与数字世界的通用桥梁。

7. 开发者如何开始使用 MCP ​

对于想要利用 MCP 的开发者来说,入门相对简单。以下是主要步骤:

使用现有的 MCP 服务器 ​

最简单的方法是使用社区已经构建的 MCP 服务器。Anthropic 维护着一个官方 MCP 服务器目录,包括用于常见服务的服务器。要使用现有服务器:

  1. 选择支持 MCP 的客户端:像 Claude Desktop、Cursor、Windsurf 或 Cline 这样的工具原生支持 MCP。

  2. 配置 MCP 服务器:大多数客户端都有配置文件(通常是 JSON),你可以在其中指定要连接的 MCP 服务器。例如,在 Claude Desktop 中,你会编辑 claude_desktop_config.json 文件。

  3. 安装服务器依赖项:许多 MCP 服务器是 Node.js 或 Python 包。使用 npm 或 pip 安装它们。

  4. 提供凭据:如果服务器需要 API 密钥或身份验证令牌(例如,用于 GitHub 或 Slack),你需要在配置中提供这些。

  5. 测试连接:启动你的 AI 客户端并尝试使用新功能。例如,如果你配置了 GitHub MCP,尝试询问"列出我的仓库"。

构建自定义 MCP 服务器 ​

对于更高级的用例,你可能想要构建自己的 MCP 服务器。Anthropic 提供了 SDK 和文档来简化这一过程:

  1. 选择语言:MCP SDK 可用于 TypeScript/JavaScript 和 Python。选择你最熟悉的。

  2. 定义工具:在你的服务器代码中,定义 AI 可以调用的工具(函数)。每个工具都应该有清晰的描述和参数。

  3. 实现处理程序:编写实际执行工具功能的代码。这可能涉及调用 API、操作文件或与应用程序交互。

  4. 处理身份验证:如果你的服务器需要访问受保护的资源,实现适当的身份验证机制。

  5. 测试和调试:使用 MCP Inspector 工具或直接与 AI 客户端测试你的服务器。

  6. 发布和分享:考虑将你的 MCP 服务器开源,以便其他人可以受益。

最佳实践 ​

在使用 MCP 时,请记住以下最佳实践:

  • 清晰的工具描述:为每个工具提供详细、清晰的描述,以便 AI 知道何时以及如何使用它。
  • 错误处理:实现健壮的错误处理并返回有用的错误消息。
  • 安全性:小心处理凭据和敏感数据。使用环境变量而不是硬编码密钥。
  • 速率限制:如果你的服务器调用外部 API,要注意速率限制并适当处理。
  • 文档:为你的 MCP 服务器提供良好的文档,包括设置说明和使用示例。

8. MCP 的当前限制和挑战 ​

虽然 MCP 很有前景,但它仍处于早期阶段,面临一些挑战:

标准化身份验证 ​

目前,每个 MCP 服务器都以自己的方式处理身份验证。没有标准化的方法来管理凭据、OAuth 流程或权限。这意味着:

  • 用户必须为每个服务器单独配置身份验证
  • 没有集中的凭据管理
  • 安全最佳实践因实现而异

Anthropic 已经承认这一限制,并表示未来版本的 MCP 将包括标准化的身份验证机制。

生态系统成熟度 ​

MCP 于 2024 年末推出,生态系统仍在发展中:

  • 有限的服务器可用性:虽然增长迅速,但许多流行的工具和服务还没有官方的 MCP 服务器。
  • 文档差距:一些服务器缺乏全面的文档或使用示例。
  • 版本控制:随着协议的发展,可能会出现兼容性问题。
  • 社区规模:与更成熟的生态系统相比,MCP 社区仍然相对较小。

性能考虑 ​

MCP 引入了额外的通信层,这可能会影响性能:

  • 延迟:通过 MCP 服务器路由请求会增加延迟,特别是对于远程服务。
  • 可扩展性:运行多个 MCP 服务器可能会消耗大量资源。
  • 网络依赖:远程 MCP 服务器需要可靠的网络连接。

安全和隐私问题 ​

让 AI 代理访问强大的工具会带来安全风险:

  • 过度权限:AI 可能会被授予超出必要的权限。
  • 意外操作:AI 可能会误解指令并执行意外操作。
  • 数据泄露:敏感数据可能会通过 MCP 连接暴露。
  • 审计和日志记录:跟踪 AI 通过 MCP 执行的操作可能具有挑战性。

开发者需要仔细考虑他们授予 AI 代理的权限,并实施适当的保护措施。

用户体验挑战 ​

对于非技术用户来说,设置和配置 MCP 服务器可能很复杂:

  • 技术设置:需要编辑配置文件、安装依赖项和管理凭据。
  • 故障排除:当出现问题时,诊断 MCP 连接问题可能很困难。
  • 发现性:用户可能不知道哪些 MCP 服务器可用或如何找到它们。

未来的改进可能包括图形配置工具、更好的错误消息和集中的服务器目录。

9. MCP 的未来:下一步是什么? ​

尽管存在当前的限制,MCP 的未来看起来很光明。以下是一些可能的发展方向:

企业采用 ​

随着 MCP 的成熟,我们可能会看到更多的企业采用:

  • 企业 MCP 服务器:用于 Salesforce、SAP、Oracle 等企业系统的官方服务器。
  • 治理和合规性:用于审计、访问控制和合规性的工具。
  • 私有 MCP 注册表:组织可以托管自己的内部 MCP 服务器目录。

改进的开发者工具 ​

工具生态系统可能会扩展以包括:

  • MCP 调试器:用于测试和调试 MCP 服务器的专用工具。
  • 代码生成器:从 API 规范自动生成 MCP 服务器的工具。
  • 监控和分析:跟踪 MCP 使用情况、性能和错误的仪表板。

跨平台标准化 ​

MCP 可能会演变成一个真正的跨平台标准:

  • 多供应商支持:不仅仅是 Anthropic,更多的 AI 供应商采用 MCP。
  • 标准化扩展:用于常见模式(如身份验证、文件处理)的官方扩展。
  • 互操作性测试:确保不同实现之间兼容性的测试套件。

AI 代理编排 ​

MCP 可能成为复杂 AI 系统的基础:

  • 多代理系统:多个 AI 代理通过 MCP 协作完成复杂任务。
  • 工作流引擎:编排跨多个 MCP 服务器的多步骤工作流程的系统。
  • 代理市场:预配置的 AI 代理的市场,每个代理都专门用于特定任务并通过 MCP 连接。

新的用例和应用 ​

随着生态系统的增长,我们可能会看到创新的用例:

  • 物联网集成:通过 MCP 控制智能家居设备和物联网系统的 AI。
  • 机器人技术:使用 MCP 与物理机器人和自动化系统交互的 AI。
  • 增强现实:通过 MCP 操纵 AR/VR 环境的 AI 助手。
  • 科学研究:通过 MCP 控制实验室设备和分析数据的 AI。

10. 结论:MCP 为什么重要 ​

模型上下文协议代表了 AI 集成方式的根本转变。通过提供标准化的方式让 AI 与应用程序和服务交互,MCP 解决了长期存在的分散和复杂性问题。

对开发者来说,MCP 意味着更少的集成工作、更多的可重用性和更大的灵活性。你可以构建一次 MCP 服务器,它就可以与任何支持 MCP 的 AI 客户端一起工作。

对用户来说,MCP 实现了更强大、更有能力的 AI 助手,可以跨工具无缝工作并自动化复杂的工作流程。

对 AI 行业来说,MCP 可能成为互操作性的关键标准,使 AI 代理能够真正成为我们数字生活中的一等公民。

虽然 MCP 仍处于早期阶段,面临挑战,但其潜力是不可否认的。随着生态系统的成熟、更多工具采用该标准以及社区构建创新集成,MCP 可能会成为 AI 驱动的软件开发和自动化的基础层。

就像 HTTP 实现了网络,USB 标准化了设备连接一样,MCP 可能成为连接 AI 与我们使用的无数应用程序和服务的通用协议。这不仅仅是一个技术标准——它是朝着真正集成的、AI 增强的计算体验迈出的一步。

对于开发者和组织来说,现在是开始探索 MCP 的时候了。无论是使用现有服务器、构建自定义集成,还是简单地了解该技术,早期采用者将在 AI 驱动的工具和工作流程的下一波浪潮中处于有利地位。

MCP 的旅程才刚刚开始,但方向很明确:一个 AI 不仅可以思考和交谈,还可以在我们的数字世界中行动和创造的未来。这就是 MCP 重要的原因。