最近MCP很火，著名投资公司a16z的合伙人Yoko Li昨天发布了一篇对MCP的深入详解，以下是借助AI翻译后的文章。
文章较长，如果对MCP不熟悉，请先花2分钟看以下短视频理清MCP基本概念，再继续看文章。蓝色字体在文章末尾提供了链接。

WeilianD

（全文开始）
标题： A Deep Dive Into MCP and the Future of AI Tooling 深入讨论MCP与AI工具的未来
目录：

• 什么是MCP
• 常见实用案例
• MCP生态系统
• 未来可能性
• AI工具的影响
• 前方道路

正文：

自从 OpenAI 在 2023 年推出函数调用功能以来，我一直在思考如何才能解锁一个由代理和工具组成的生态系统。随着基础模型变得越来越智能，代理与外部工具、数据和 API 交互的能力却变得日益碎片化：开发者需要为每个代理所运行和集成的系统实现特定的业务逻辑。

很明显，需要有一个用于执行、数据获取和工具调用的标准接口。 API 是互联网上第一个伟大的统一器，为软件创建一种共享语言进行通信，但 AI 模型缺乏类似的标准。

模型上下文协议 （MCP，Model Context Protocol） 于 2024 年 11 月推出，作为一种潜在的解决方案，在开发人员和 AI 社区中获得了巨大的关注。在这篇文章中，我们将探讨什么是 MCP，它如何改变 AI 与工具的交互方式，开发人员已经在使用它构建什么，以及仍需要解决的挑战。

让我们开始吧。

什么是 MCP？

MCP 是一种开放协议，使系统能够以可泛化的方式向 AI 模型提供上下文信息，并适用于不同的集成场景。该协议定义了 AI 模型如何调用外部工具、获取数据以及与服务进行交互。以下是一个具体示例，展示了 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 使用方法是在一个客户端上安装多个MCP服务器，从而解锁新的工作流。例如，用户可以安装一个服务器在 Cursor 中生成前端 UI，同时让代理使用图像生成 MCP 服务器来为站点生成一个主页面图。

除了 Cursor 之外，当今的大多数用例都可以归纳为两类：以开发人员为中心的本地优先工作流、基于LLM客户端的全新体验。

以开发人员为中心的工作流程

对于每天生活在代码中的开发人员来说，一种普遍的想法是，“我不想离开我的 IDE 去做 x”。MCP 服务器是实现这个想法的好方法。

开发人员现在无需切换到 Supabase 来检查数据库状态，而是可以使用Postgres MCP 服务器来执行只读 SQL 命令，并使用 Upstash MCP 服务器直接从他们的 IDE 创建和管理缓存索引。在迭代代码时，开发人员还可以利用 Browsertools MCP 为编码代理提供对实时环境的访问权限，以进行反馈和调试。

Cursor 代理使用 Browsertools 访问控制台日志和其他实时数据并更高效地进行调试的示例

在开发者工具交互之外，MCP 服务器解锁的新用例是为编码代理提供高度准确的上下文，这可以通过爬取网页或基于文档自动生成 MCP 服务器来实现。

相比于手动编写集成代码，开发者可以直接从现有文档或 API 启动 MCP 服务器，使 AI 代理随时使用工具。这意味着花更少的时间写重复代码，更多时间来使用工具——无论是获取实时上下文、执行命令，还是动态扩展 AI 助手的能力。

全新的体验

像 Cursor 这样的 IDE 并不是唯一可用的 MCP 客户端，尽管它们因 MCP 对技术用户的强烈吸引力而受到了最多的关注。对于非技术用户，Claude 桌面客户端 是一个很好的切入点，使普通受众更易于访问 MCP 工具。很快，我们可能会看到以业务为中心的专业 MCP 客户端的出现，例如客户支持、营销文案、设计和图像编辑。因为这些领域与 AI 在识别和创意任务方面的优势密切相关。

MCP 客户端的设计以及它所支持的具体交互方式，在很大程度上决定了其功能边界。例如，一个聊天应用通常不会包含矢量渲染画布，就像一个设计工具也不太可能提供在远程机器上执行代码的能力。最终，MCP 客户端的体验决定了整体的 MCP 用户体验。在 MCP 客户端的探索和优化方面，我们仍有大量潜力等待发掘。

这方面的一个例子： Highlight 如何在其客户端实现 @command 命令来调用任何 MCP 服务器。这是一种新的 UX 模式，在该模式中，MCP 客户端可以将生成的内容导入任何选择的下游应用程序中。

Highlight的Notion MCP（插件）实现示例

另一个例子是 Blender MCP 服务器：现在，不了解 Blender 的业余用户可以使用自然语言来描述他们想要构建的模型。我们看到文本到 3D 的工作流程正在实时进行，因为开发社区为 Unity 和 Unreal Engine 等其他工具开发了服务器。

将 Claude 桌面客户端 与 Blender MCP 服务器一起使用的示例

尽管我们主要考虑服务器和客户端，但随着协议的发展，MCP 生态系统正在逐渐形成。这张市场地图涵盖了当今最活跃的领域，尽管仍有许多空白区域。我们知道 MCP 仍处于早期阶段， 随着市场的发展和成熟，我们很高兴能在地图上添加更多玩家。 （我们将在下一节中探讨其中一些未来的可能性。

在 MCP 客户端， 我们今天看到的大多数高质量客户端都是以开发代码为主 。这并不奇怪，因为开发人员通常是新技术的早期使用者，随着协议的成熟，我们预计会看到更多以业务为中心的客户端。

我们看到的大多数 MCP 服务器都是本地优先的，专注于单人玩家。这是 因为MCP 目前仅支持基于 SSE 和基于命令的连接所导致的。 但是，随着生态系统将以远程 MCP为主 ，并且 MCP 采用 Streamable 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 解决方案的过程中，还有许多尚未解决的问题。

下一版本协议需要突破的一些关键点包括：

托管和多租户 Hosting and multi-tenancy

MCP 目前支持AI 代理与多个工具之间的一对多关系，但多租户架构（如 SaaS 产品）需要支持多个用户同时访问共享的 MCP 服务器。短期来看，默认使用远程服务器可以提升 MCP 服务器的可访问性，但许多企业仍希望自托管 MCP 服务器，并分离数据和控制平面以满足安全和合规需求。

为了推动 MCP 的更广泛应用，优化 MCP 服务器的部署与维护工具链将成为下一个关键突破点。

认证 Authentication  

MCP 目前没有定义客户端如何与服务器进行身份验证的标准机制，也没有提供一个框架说明 MCP 服务器在与第三方 API 交互时应如何安全地管理和委托身份验证。当前，身份验证由具体的集成方式和部署场景自行决定。实践中，MCP 目前主要应用在本地集成场景中，在这些情况下，通常不需要显式身份验证。

随着远程 MCP 的发展，更完善的身份认证机制将成为关键突破点之一。从开发人员的角度来看，统一的认证方法应涵盖以下方面：

客户端身份验证： 用于客户端-服务器交互的标准方法，如 OAuth 或 API 令牌

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

多用户身份验证： 适用于企业部署的租户身份验证

授权 Authorization  

即使工具已通过认证，谁可以使用它，权限应该有多细化？MCP 缺乏内置的权限模型，因此目前的访问控制仅限于会话级别，这意味着工具要么可以完全访问，要么完全受限。虽然未来的授权机制可以引入更细的权限控制，但当前MCP依赖于基于 OAuth 2.1 的授权流程 ，一旦认证成功，就会授予整个对话的访问权限。随着代理和工具数量的增加，这一模式会变得更加复杂 — 每个代理通常需要具有自己的对话和独立的授权凭证，从而导致基于会话的访问管理变得愈发庞大。

网关 Gateway 

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

服务器可发现性和可用性 MCP server discoverability and usabilityMCP 

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

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

执行环境 Execution environment  

大多数 AI 工作流需要按顺序调用多个工具，但 MCP 缺乏内置的工作流管理机制。要求每个客户端都实现可恢复性和可重试性并不理想。尽管目前开发人员正在探索像 Inngest 这样的解决方案来实现这一点，但将有状态执行作为核心功能，将让开发者更清楚得理解和管理执行流程。

标准客户端体验 Standard client experience 

开发社区的一个常见问题是，在构建 MCP 客户端时如何考虑工具选择：每个人都需要开发自己的 RAG，还是有一个可以标准化的层？

除了工具选择之外，目前也没有统一 的UI/UX 交互模式来调用工具（现有方案包括斜杠命令和纯自然语言等）。如果能在客户端侧建立一个标注的工具发现、排名和执行层，将有助于创建更可预测的开发者和用户体验。

调试 Debugging 

MCP 服务器的开发人员经常发现，很难让同一个 MCP 服务器跨客户端运行。通常情况下，每个 MCP 客户端都有自己的特殊性，客户端调试信息要么缺失，要么难以获取，这使得调试 MCP 服务器变得极其困难。随着越来越多的MCP 服务器开始采用远程优先的架构，需要一套新的工具来优化本地和远程环境中的开发体验，使调试和兼容性问题更容易处理。

AI工具的影响

MCP 的开发经验让我想起了 2010 年代的 API 开发。这个范式新颖且令人兴奋，但工具链还处于早期阶段。如果我们快进到几年后，假设 MCP 成为 AI 驱动工作流程的既定标准时，会发生什么？以下是一些预测：

开发者优先（dev-first）的公司，其竞争优势将从提供最好的 API 设计演变为提供最好的工具集合供AI代理使用。如果 MCP 能够自主发现工具，那么 API 和 SDK 的提供商将需要确保他们的工具很容易从搜索中发现，并且具有足够的差异化，以便AI代理为特定任务进行选择。这可能比人类开发人员的决策更加精细和具体。 

如果每个应用程序都成为 MCP 客户端，每个 API 都成为 MCP 服务器，那么可能会出现新的定价模式：代理可以根据速度、成本和相关性等综合因素，更动态地选择工具。这可能会促使工具等采用过程更加市场化，选择性能最佳、模块化程度最高的工具，而不是当前市场上最流行的工具。 

文档将成为 MCP 基础设施的关键部分 ， 因为企业需要设计具有清晰、机器可读格式（例如 llms.txt）的工具和 API， 并基于现有文档将 MCP 服务器作为默认的交付成果。 

仅靠 API 已经不够了，但仍然是一个很好的起点。 开发者会发现，API 到工具的映射关系很少是 1：1 的。工具是一种更高的抽象，能够让AI代理在任务执行时选择最合适的方式——不是简单地调用 send_email（），而是可以选择包含多个 API 调用的 draft_email_and_send（） 函数，以最大限度地减少延迟。MCP 服务器设计将以场景和用例为中心，而不是以 API 为中心。 

如果每个软件都默认成为 MCP 客户端，将会出现一种新的托管模式，因为这类工作负载的特性将不同于传统的网站托管。每个客户端本质上都设计多步执行，并且需要提供如恢复、重试和长时间运行等执行保障。托管服务提供商还需要在不同的 MCP 服务器之间进行实时负载平衡，以优化成本、延迟和性能，从而允许 AI 代理在任何时刻选择最优的工具。

前方的道路

MCP 已经在重塑 AI 代理生态系统，而下一波进展将取决于我们如何应对并解决这些挑战。如果解决得当，MCP 可能会成为 AI 与工具交互的默认接口，从而推动新一代自主、多模式、深度集成的 AI 体验。

如果MCP得到广泛采用，它将改变工具的构建、使用和变现方式。我们很期待市场的发展防线。今年将是关键的一年：我们会看到统一的 MCP 市场的崛起吗？AI 代理的身份验证是否会变得无缝衔接？多步骤执行是否可以正式纳入协议中？

如果你在这个领域进行建设或有关于该领域发展的想法，请通过 yli@a16z.com 联系我。是时候开始建设了！

（全文结束）

以下是发布在a16z网站的原文链接🔗https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/
如果想进一步了解Anthropic对MCP的开发和未来计划，推荐看Anthropic在AI Engineer大会上关于MCP的演讲，以下是Youtube🔗https://www.youtube.com/watch?t=4927&v=kQmXtrmQ5Zg&feature=youtu.be&themeRefresh=1
文中提到的其余MCP和平台链接

• LSP协议

https://spec.modelcontextprotocol.io/specification/2024-11-05/#:~:text=MCP%20takes%20some%20inspiration%20from,the%20ecosystem%20of%20AI%20applications

• Slack MCP

https://github.com/modelcontextprotocol/servers/tree/main/src/slack

• Resend MCP

https://github.com/resend/mcp-send-email/tree/main

• Replicate MCP

https://github.com/deepfates/mcp-replicate

• Front End UI (21st Dev)

https://github.com/21st-dev/magic-mcp

• PostgreSQL MCP

https://github.com/modelcontextprotocol/servers/tree/main/src/postgres

• Upstash MCP

https://github.com/upstash/mcp-server

• Browsertools MCP

https://github.com/AgentDeskAI/browser-tools-mcp

• Firecrawl MCP

https://github.com/mendableai/firecrawl-mcp-server

• MCP Server Generator

https://mintlify.com/blog/generate-mcp-servers-for-your-docs

• Blender MCP

https://x.com/sidahuj/status/1901632110395265452

• Mintlify

https://mintlify.com/

• Smithery

https://smithery.ai/

• Opentools

https://opentools.com/

• Stanless

https://www.stainless.com/

• Speakeasy

https://www.speakeasy.com/

• OAuth 2.1-based authorization flows

https://github.com/modelcontextprotocol/specification/blob/5c35d6dda5bf04b5c8c76352c9f7ee18d22b7a08/docs/specification/draft/basic/authorization.md

• Inngest

https://www.inngest.com/