摘要：MCP是一种模型开放协议，允许系统以通用集成方式向AI 模型提供上下文。该协议定义了AI 模型如何调用外部工具，获取数据和与服务交互。作为一个具体示例，以下是Resend MCP 服务器如何与多个MCP 客户端一起工作。

MCP是一种模型开放协议，允许系统以通用集成方式向AI 模型提供上下文。该协议定义了AI 模型如何调用外部工具，获取数据和与服务交互。作为一个具体示例，以下是Resend MCP 服务器如何与多个MCP 客户端一起工作。

这个想法并不新颖；MCP从LSP(Language Server Protocol)中获取灵感。在LSP中，当用户在编辑器中键入时，客户端会查询语言服务器以自动完成建议或进行诊断。

MCP在超越LSP的地方在于它的智能体中心执行模型：LSP主要是被动的（基于用户输入响应IDE的请求），而MCP旨在支持自主的人工智能工作流程。根据上下文，AI智能体可以决定使用哪些工具，以何种顺序，并如何将它们链接在一起以完成任务。MCP还引入了人在循环中的能力，以便人们提供额外的数据并批准执行。

使用正确的一组MCP服务器，用户可以将每个MCP客户端转变为一个“一切应用程序”。

以Cursor 为例：虽然Cursor 是一款代码编辑器，但也是一个实现良好的MCP 客户端。最终用户可以将其转变为Slack 客户端，使用Slack MCP 服务器，使用Resend MCP 服务器发送电子邮件，以及使用Replicate MCP 服务器生成图像。利用MCP 的更强大方式是在一个客户端上安装多个服务器以解锁新的流程：用户可以安装一个服务器从Cursor 生成前端UI，同时要求智能体使用一个图像生成MCP 服务器为网站生成主要图像。

除了Cursor之外，今天的大多数用例可以总结为专注于开发者、本地优先的工作流程，或者使用LLM客户端进行全新的体验。

对于每天生活在代码中的开发人员来说，一个常见的感受是：“我不想离开我的集成开发环境去做x”。MCP 服务器是实现这一梦想的好方法。

而不是切换到Supabase 查看数据库状态，开发人员现在可以使用Postgres MCP 服务器执行只读SQL 命令，以及使用Upstash MCP 服务器创建和管理缓存索引，而这些都可以直接从他们的IDE 中进行。在编写代码时，开发人员还可以利用Browsertools MCP，让编码智能体可以访问实时环境，以获取反馈和进行调试。

Cursor智能体如何使用浏览器工具获取控制台日志和其他实时数据，并更有效地进行调试。

在与开发人员工具交互的工作流之外，MCP服务器解锁的一个新用途是通过爬取网页或基于文档自动生成MCP服务器，向编码智能体添加高度准确的上下文。开发人员可以直接从现有文档或API中启动MCP服务器，而无需手动连接集成，使工具可以立即访问AI智能体。这意味着不再花费时间在样板代码上，而是更多时间实际使用工具-无论是获取实时上下文，执行命令，还是即时扩展AI助手的功能。

类似Cursor这样的集成开发环境并不是唯一可用的MCP客户端，尽管由于MCP对技术用户的吸引力，它们受到最多的关注。对于非技术用户来说，Claude桌面是一个很好的入门点，使基于MCP的工具对广大用户更加易用和友好。很快，我们可能会看到针对业务中心任务的专门MCP客户端出现，例如客户支持、营销文案编写、设计和图片编辑，因为这些领域与人工智能在模式识别和创造性任务方面的优势紧密相关。

MCP客户端的设计和它所支持的具体交互在塑造其功能方面起着至关重要的作用。例如，一个聊天应用不太可能包含矢量渲染画布，就像一个设计工具不太可能提供在远程机器上执行代码的功能一样。最终，MCP客户端体验定义了整体的MCP用户体验— 当涉及到MCP客户端体验时，我们还有很多需要探索。

这方面的一个例子是Highlight 如何实现@ 命令来调用其客户端上的任何MCP 服务器。结果是一种新的UX 模式，在该模式中，MCP 客户端可以将生成的内容通过管道传输到所选的任何下游应用程序。

Highlight团队对Notion MCP（插件）的实现示例。

另一个例子是Blender MCP服务器的使用场景：现在，几乎不了解Blender的业余用户可以使用自然语言描述他们想要构建的模型。随着社区为其他工具如Unity和Unreal Engine实现服务器，我们看到了文本转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采用的重要突破之一。从开发人员的角度来看，一个统一的方法应该涵盖：

1.客户端验证：用于客户端和服务器互动的标准方法，如OAuth或API令牌。

2.工具认证：用于与第三方API进行身份验证的辅助函数或包装器。

3.多用户身份认证：适用于企业部署的租户感知认证

即使工具经过身份验证，谁应被允许使用它，他们的权限应该有多精细？MCP缺乏内置的权限模型，因此访问控制是在会话级别进行的— 这意味着一个工具要么是可访问的，要么完全受限制。虽然未来的授权机制可能会塑造更精细的控制，但当前的方法是依赖基于OAuth 2.1的授权流程，一旦经过身份验证即授予整个会话范围的访问权限。随着引入更多的智能体和工具，这会带来额外的复杂性— 每个智能体通常需要具有独特授权凭据的自己的会话，从而导致一个会话为基础的访问管理网络的不断扩大。

随着MCP的采用规模扩大，网关可以充当认证、授权、流量管理和工具选择的集中层。类似于API网关，它将执行访问控制，将请求路由到正确的MCP服务器，处理负载平衡，并缓存响应以提高效率。这对于多租户环境特别重要，不同用户和智能体需要不同的权限。标准化的网关将简化客户端-服务器交互，提高安全性，并提供更好的可观察性，使MCP部署更具可扩展性和可管理性。

目前，查找和设置MCP服务器是一个手动过程，需要开发人员定位端点或脚本，配置认证，并确保服务器和客户端之间的兼容性。集成新服务器很耗时，AI智能体无法动态发现或适应可用服务器。

根据上个月在AI工程师大会上Anthropic的讲话，听起来MCP服务器注册表和发现协议即将推出。这可能会打开MCP服务器采用的下一个阶段。

大多数AI工作流程需要按顺序调用多个工具，但MCP缺乏内置的工作流概念来管理这些步骤。要求每个客户都实现可恢复性和重试性并不理想。尽管今天我们看到开发人员正在探索类似Ingest的解决方案来实现这一目标，将有状态执行提升为一流概念将帮助大多数开发人员清晰地理解执行模型。

常见的问题是，我们从开发者社区听到的一个问题是在构建MCP客户端时如何思考工具选择：每个人是否都需要为工具实现自己的RAG，还是有一个等待标准化的层？

除了工具选择之外，也没有用于调用工具的统一UI/UX 模式（我们已经看到了从斜杠命令到纯自然语言的所有内容）。用于工具发现、排名和执行的标准客户端层有助于创建更可预测的开发人员和用户体验。

MCP服务器开发人员经常发现很难让同一个MCP服务器在不同客户端上顺利运行。往往每个MCP客户端都有自己的怪癖，客户端追踪要么缺失，要么难以找到，这使得调试MCP服务器变得极为困难。随着世界开始构建更多面向远程的MCP服务器，需要一套新的工具来使开发体验在本地和远程环境中更加流畅。

MCP的开发经验让我想起了2010年代的API开发。范式是新的和令人兴奋的，但工具链还处在早期阶段。如果我们快进到几年后，如果MCP成为AI驱动工作流程的事实标准会发生什么？一些预测：

1.开发优先公司的竞争优势将从提供最佳的API设计发展到为智能体商提供最佳工具集合。如果MCPs将有能力自主发现工具，提供API和SDK的供应商将需要确保他们的工具能够很容易地从搜索中发现，并且足够区别化，使智能体商能够针对特定任务进行选择。这可能比人类开发者寻找的要更加精细和具体。

2.如果每个应用程序都成为一个MCP客户端，每个API都成为一个MCP服务器，可能会出现一种新的定价模型：智能体可能更加动态地选择工具，基于速度、成本和相关性的组合。这可能导致更具市场驱动力的工具采用过程，选择表现最佳和最模块化的工具，而不是最广泛采用的工具。

3.文档将成为MCP 基础设施的关键部分，因为公司将需要使用清晰的、可机器读取的格式（例如llms.txt）设计工具和API，并将MCP 服务器作为一种基于现有文档的事实标准。

4.API本身已不再足够，但可以作为很好的起点。开发者会发现，从API到工具的映射很少是一对一的。工具是一个更高的抽象，对于任务执行时的智能体者来说更有意义，代替简单地调用send_email，智能体者可以选择draft_email_and_send函数，该函数包含多个API调用以最小化延迟。MCP服务器设计将以场景和用例为中心，而不是以API为中心。

5.如果每个软件默认都成为MCP客户端，那么将会有一种新的托管模式，因为工作负载特征将与传统网站托管不同。每个客户端的性质都是多步骤的，需要像可恢复性、重试和长时间运行任务管理等执行保证。托管提供商还将需要在不同的MCP服务器之间实时负载平衡，以优化成本、延迟和性能，使AI智能体在任何时刻选择最有效的工具。

MCP已经正在重塑AI智能体生态系统，但下一波进展将取决于我们如何解决基础性挑战。如果做得对，MCP可能成为AI与工具交互的默认界面，并开启一个新一代的自主、多模态和深度整合的AI体验。

如果广泛采用，MCPs 可能代表着工具构建、使用和货币化方式的转变。我们很期待市场会朝着何方发展。今年将是关键的一年：我们会看到统一的MCP市场的崛起吗？身份验证能否对AI智能体无缝进行？多步执行是否能够形式化为协议？

来源：正正杂说