AI大模型领域，最近比较火的一个词是MCP（MCP：Model Context Protocol）。
比如，Tripo推出Tripo3D MCP，允许Blender/Cursor/Claude直接集成；Claude桌面客户端内置了MCP服务器；还出现了MCP做的“App Store” Fleur，以及MCP导航网站mcp.so/ ，收录了近3000个MCP Server。
那么什么是MCP，它到底对AI生态发展有什么价值，小编边学边整理了这个材料，供大家参考。
目前大语言模型的局限在于，无法直接连接外部真实环境，比如不知道今天是哪一天，不知道外面天气如何，不能用计算器，不能搜索、访问网页。
就像你有台电脑，除了键盘鼠标显示器啥都没有，不能上网，不能接扫描仪、摄像头等等。
API是互联网的第一个伟大统一者——为软件通信创建了一种共享语言——但 AI模型缺乏相应的等价物。
2024年11月推出的 Model Context Protocol (MCP)在开发者和 AI 社区中获得了显著关注，被视为一种潜在的解决方案。
MCP是一种开放协议，允许系统以可跨集成推广的方式，为AI模型提供上下文。该协议定义了AI模型如何调用外部工具、获取数据以及与服务交互。
有了这个协议，你的电脑就可以连接各种外界设备——比如通过USB接口的摄像头，可以录视频；通过USB接口的扫描仪，可以扫描文档等。
可以说，MCP就是大语言模型的USB协议——开发者们可以基于这套协议，开发各种服务，比如连接本地微信聊天记录的服务、天气预报的服务等。
作为一个具体示例，以下是Resend MCP服务器与多个MCP客户端协同工作的方式。
这个想法并不新鲜；MCP从LSP（Language Server Protocol）中获得了灵感。在LSP中，当用户在编辑器中输入时，客户端会查询语言服务器以获取自动补全建议或诊断信息。
MCP超越LSP之处在于其以代理为中心的执行模型：LSP主要是反应式的（基于用户输入响应IDE的请求），而MCP则旨在支持自主的AI工作流。根据上下文，AI代理可以决定使用哪些工具、按什么顺序使用以及如何将它们串联起来以完成任务。MCP还引入了人在回路的能力，使人类能够提供额外数据并批准执行。
借助合适的MCP服务器，用户可以将每个MCP客户端转变为“全能应用”。
以Cursor为例：尽管Cursor是一个代码编辑器，但它也是一个实现良好的MCP客户端。
终端用户可以通过Slack MCP服务器将其转变为Slack客户端，通过Resend MCP服务器作为邮件发送器，以及通过Replicate MCP服务器作为图像生成器。
更强大的利用MCP的方式是在一个客户端上安装多个服务器，以解锁新的流程：用户可以安装一个服务器从Cursor生成前端UI，同时让代理使用图像生成 MCP服务器为网站生成主图。
除了Cursor，当今大多数用例可以总结为以开发人员为中心的本地优先工作流，或使用LLM客户端的新网络体验。
对于每天沉浸在代码中的开发者来说，一个普遍的感受是，“我不想离开我的 IDE去做 x”。MCP服务器是实现这一梦想的绝佳方式。
开发者现在无需切换到Supabase来检查数据库状态，而是可以直接在IDE中使用Postgres MCP 服务器执行只读SQL命令，并通过Upstash MCP服务器创建和管理缓存索引。在代码迭代过程中，开发者还可以利用Browsertools MCP为编码代理提供实时环境访问，以便获取反馈和进行调试。
Cursor代理如何使用Browsertools访问控制台日志和其他实时数据并更高效调试的示例。
在与开发者工具交互的工作流之外，MCP服务器开启的新用途是能够通过爬取网页或基于文档自动生成MCP服务器，为编码代理添加高度准确的上下文。开发者无需手动配置集成，可以直接从现有文档或API启动MCP服务器，使AI代理即时访问工具。
这意味着减少在样板代码上的时间，更多时间实际使用工具——无论是拉取实时上下文、执行命令，还是动态扩展AI助手的能力。
像Cursor这样的IDE并不是唯一的MCP客户端，尽管由于MCP对技术用户的强大吸引力，它们受到了最多的关注。对于非技术用户来说，Claude Desktop是一个极佳的入门选择，它使MCP驱动的工具对普通用户更加易用和友好。很快，我们可能会看到针对以业务为中心的任务（如客户支持、营销文案、设计和图像编辑）的专门 MCP 客户端出现，因为这些领域与 AI 在模式识别和创造性任务方面的优势密切相关。
MCP 客户端的设计及其支持的特定交互在塑造其功能方面起着至关重要的作用。例如，聊天应用程序不太可能包含矢量渲染画布，就像设计工具不太可能提供在远程机器上执行代码的功能一样。最终，MCP 客户端体验定义了整体 MCP 用户体验——在 MCP 客户端体验方面，我们还有更多潜力待发掘。
一个例子是 Highlight 如何在其客户端上实现@command来调用任何 MCP 服务器。结果是一种新的用户体验模式，其中 MCP 客户端可以将生成的内容传输到任何选定的下游应用程序中。
Highlight 实现 Notion MCP（插件）的一个示例
另一个例子是 Blender MCP 服务器的使用场景：现在，几乎不了解 Blender 的业余用户也能用自然语言描述他们想要构建的模型。随着社区为 Unity 和 Unreal 引擎等其他工具实现服务器，我们正实时见证文本到3D工作流程的展开。
使用 Claude Desktop 与 Blender MCP 服务器的示例
尽管我们主要考虑的是服务器和客户端，但随着协议的演进，MCP 生态系统正逐渐成形。这份市场地图涵盖了当前最活跃的领域，尽管仍有许多空白。鉴于 MCP 尚处于早期阶段，我们期待随着市场的发展和成熟，将更多参与者纳入地图。（我们将在下一节探讨其中一些未来的可能性。）
在MCP客户端方面，目前我们看到的大多数高质量客户端都是以编程为中心的。这并不令人惊讶，因为开发者通常是新技术的早期采用者，但随着协议的成熟，我们预计会看到更多以业务为中心的客户端。
我们所见的大多数MCP服务器都是本地优先，专注于单人玩家。这是目前MCP仅支持基于SSE和命令连接的一种表现。然而，随着生态系统将远程MCP提升为一级支持，以及MCP采用可流式 HTTP 传输，我们预计会看到更多MCP服务器的采用。
也有一波新的MCP市场和服务器托管解决方案正在兴起，使得MCP服务器发现成为可能。像Mintlify的mcpt、Smithery和OpenTools这样的市场正在使开发者更容易发现、分享和贡献新的MCP服务器——就像npm改变了 JavaScript 的包管理方式，或者RapidAPI扩展了API发现一样。这一层对于标准化访问高质量MCP服务器至关重要，使AI代理能够动态选择和按需集成工具。
随着MCP的采用率增长，基础设施和工具将在使生态系统更具可扩展性、可靠性和可访问性方面发挥关键作用。诸如Mintlify，Stainless和Speakeasy等服务器生成工具正在减少创建MCP兼容服务的摩擦，而Cloudflare和Smithery等托管解决方案则正在应对部署和扩展的挑战。与此同时，像Toolbase这样的连接管理平台正开始简化本地优先的MCP密钥管理和代理。
然而，我们仍处于代理原生架构演进的早期阶段。尽管今天MCP引发了大量关注，但在使用MCP构建和交付时，仍存在许多未解决的问题。
MCP支持AI代理与其工具之间的一对多关系，但多租户架构（例如SaaS产品）需要支持多个用户同时访问共享的MCP服务器。默认情况下拥有远程服务器可能是短期内使MCP服务器更易于访问的解决方案，但许多企业也希望托管自己的MCP服务器，并分离数据平面和控制平面。
支持大规模MCP服务器部署和维护的简化工具链是推动更广泛采用的下一个关键环节。
MCP目前并未定义客户端如何与服务器进行认证的标准机制，也未提供MCP服务器在与第三方API交互时应如何安全管理和委派认证的框架。认证目前由各个实现和部署场景自行决定。在实践中，MCP迄今为止的采用似乎主要集中在本地集成上，这些场景下并不总是需要显式认证。
更好的认证范式可能是远程MCP采用的一大关键。从开发者的角度来看，统一的方法应涵盖：
· 客户端认证：用于客户端与服务器交互的标准方法，如OAuth或API tokens
· 工具认证：用于与第三方API进行身份验证的辅助函数或封装器
即使工具经过认证，谁应被允许使用它以及他们的权限应有多细粒度？MCP缺乏内置的权限模型，因此访问控制在会话级别——意味着工具要么可访问，要么完全受限。虽然未来的授权机制可能会形成更细粒度的控制，但目前的方法依赖于基于OAuth 2.1的授权流程，一旦认证，便授予整个会话的访问权限。随着更多代理和工具的引入，这带来了额外的复杂性——每个代理通常需要其自己的会话和唯一的授权凭证，导致基于会话的访问管理网络不断扩展。
随着MCP的采用规模扩大，网关可以作为认证、授权、流量管理和工具选择的集中层。类似于API网关，它将强制执行访问控制，将请求路由到正确的MCP服务器，处理负载均衡，并缓存响应以提高效率。这对于多租户环境尤为重要，因为不同的用户和代理需要不同的权限。标准化的网关将简化客户端与服务器的交互，提高安全性，并提供更好的可观测性，使MCP部署更具可扩展性和可管理性。
目前，寻找和设置MCP服务器是一个手动过程，要求开发者定位端点或脚本、配置身份验证，并确保服务器与客户端之间的兼容性。集成新服务器耗时，且AI代理无法动态发现或适应可用服务器。
根据Anthropic在上个月的AI工程师大会上的发言，听起来MCP服务器注册与发现协议即将推出。这可能会开启MCP服务器采用的下一个阶段。
大多数 AI 工作流程需要依次进行多个工具调用——但MCP缺乏内置的工作流程概念来管理这些步骤。要求每个客户端实现可恢复性和可重试性并不理想。尽管如今我们看到开发者探索如 Inngest 等解决方案来实现这一点，但将状态执行提升为一等概念将为大多数开发者理清执行模型。
开发者社区中一个常见的问题是如何在构建MCP客户端时考虑工具选择：每个人都需要为自己的工具实现RAG，还是存在一个等待标准化的层面？
除了工具选择之外，调用工具也没有统一的 UI/UX 模式（我们见过从斜杠命令到纯自然语言的各种方式）。一个标准的客户端层用于工具发现、排序和执行，有助于创造更可预测的开发者与用户体验。
MCP服务器的开发者们常常发现，很难让同一个MCP 服务器轻松地跨客户端工作。通常情况下，每个MCP客户端都有其独特的问题，而客户端追踪信息要么缺失，要么难以找到，这使得调试MCP服务器成为一项极其困难的任务。随着世界开始构建更多远程优先的MCP服务器，需要一套新的工具来使本地和远程环境中的开发体验更加流畅。
MCP的开发体验如同2010年代的API开发。范式新颖且令人兴奋，但工具链尚处于早期阶段。如果我们快进到几年后，如果MCP成为AI驱动工作流程的事实标准，会发生什么？一些预测：
·以开发者为先的公司的竞争优势将演变。从提供最佳 API 设计扩展到提供最佳工具集合供代理使用。如果MCP能够自主发现工具，API和SDK的提供者需要确保他们的工具易于通过搜索被发现，并且足够差异化，以便代理为特定任务选择。这可能比人类开发者寻找的内容更加细化和具体。
·可能会出现一种新的定价模式。如果每个应用都成为 MCP 客户端，每个 API 都成为MCP服务器，可能会出现一种新的定价模式：代理可能会根据速度、成本和相关性的组合更动态地选择工具。这可能导致一个更加市场驱动的工具采用过程，选择性能最佳和模块化程度最高的工具，而不是最广泛采用的工具。
·文档将成为 MCP 基础设施的关键部分。因为企业需要设计具有清晰、机器可读格式（例如llms.txt）的工具和 API，并基于现有文档使 MCP 服务器成为事实上的工件。
· 仅靠API已不再足够，但它们可以成为很好的起点。开发者会发现，从 API 到工具的映射很少是 1:1 的。工具是一种更高层次的抽象，在任务执行时对代理最有意义——代理可能选择 draft_email_and_send()函数，而不是简单地调用 send_email()，该函数包含多个 API 调用以最小化延迟。MCP 服务器设计将以场景和用例为中心，而不是以 API 为中心。
· 将会有一种新的托管模式。如果每个软件默认都成为 MCP 客户端，将会出现一种新的托管模式，因为工作负载特征将与传统网站托管不同。每个客户端本质上都是多步骤的，并且需要执行保证，如可恢复性、重试和长时间运行的任务管理。托管提供商还需要在不同 MCP 服务器之间进行实时负载平衡，以优化成本、延迟和性能，使 AI 代理能够在任何给定时刻选择最高效的工具。
MCP已经在重塑AI代理生态系统，但下一波进展将取决于我们如何应对基础性挑战。如果处理得当，MCP可能成为AI与工具交互的默认接口，并开启新一代自主、多模态、深度集成的AI体验。
如果MCP被广泛采用，它可能代表工具构建、消费和货币化方式的转变。我们期待看到市场将它们带向何方。今年将是关键的一年：我们会看到一个统一的 MCP市场崛起吗？AI 代理的认证会变得无缝吗？多步执行能否被正式纳入协议？
（文：AI先锋官）
