摘要：该协议由 Anthropic 公司的 Mahesh Murag 开发。您可以查阅完整的官方文档。目前，MCP 已通过 Python SDK 和 TypeScript SDK 实现了完整支持。
这是一篇无聊但是可能有用的文章，能对MCP（model context Protocol）有一个了解了。
文章出处： 。我只是文章的搬运工，同时将这片文章翻译成了中文。
Anthropic 公司于 2024 年 11 月发布了模型上下文协议 (Model Context Protocol, MCP)。
该协议由 Anthropic 公司的 Mahesh Murag 开发。您可以查阅完整的官方文档。目前，MCP 已通过 Python SDK 和 TypeScript SDK 实现了完整支持。
Mahesh Murag 在 AI 工程师峰会 (AI Engineer Summit) 期间，主持了一场主题为“使用模型上下文协议构建智能体 (BUIlding Agents with Model Context Protocol)”的精彩研讨会。
一、上下文是关键一个生成式 AI 模型的基础能力取决于其预训练细节、训练数据和模型架构。为了让这些预训练模型表现更好，并提升其响应与您任务的相关性和连贯性，您必须为其提供良好的上下文。
这里的上下文，指的是模型用于生成相关且连贯响应的信息。上下文决定了模型如何理解并继续对话、补全文本或生成图像。
根据模型类型和任务的不同，可以通过多种方式提供上下文：
基于文本的模型 (例如 GPT, DeepSeek, LLaMA) 通过以下方式接收上下文： 提示词上下文 (Prompt Context): 指导模型响应的输入文本或查询。Token 窗口 (Token Window): 模型一次能“记住”的 Token 数量（例如，GPT-4-Turbo 可处理约 128K Token）。对话历史 (Conversation History): 在聊天机器人中，之前的交流有助于在多轮对话中维持上下文。检索增强生成 (RAG): 动态检索外部文档获取上下文，以改进模型响应。2. 图像和多模态模型 (例如 DALL·E, Gemini) 通过以下方式接收上下文：
文本描述 (Text Descriptions): 通过提示词指导图像生成。视觉上下文 (Visual Context): 如果提供了图像，模型会先分析其内容，然后再生成新的元素。跨模态上下文 (Cross-Modal Context): 当结合文本和图像时，模型会同时解读两者以生成有意义的输出。3. 代码生成模型 (例如 Codex, DeepSeek-Coder) 通过以下方式接收上下文：
先前的代码块 (Previous Code Blocks): 上下文包括已有的代码、函数名和注释。编程语言语法 (Programming Language Syntax): 模型理解特定语言的语法模式。外部文档 (External Documentation): 部分模型会利用 API 或文档来提供更准确的代码建议。4. 语音和音频模型 (例如 Whisper, AudioPaLM) 通过以下方式接收上下文：
音频片段 (Audio Segments): 先前的语音或音乐片段为后续生成的部分提供信息。语言学和声学特征 (Linguistic and Acoustic Features): 音调、语速、韵律等特征会影响语音转录和生成任务。简而言之，上下文是生成式 AI 能够产生相关且连贯输出的关键因素。上下文管理得越好，AI 的表现就越好。
随着时间的推移，AI 模型可以自动获取数据来充当上下文。这对于 AI Agents 来说尤其如此，因为 AI agents 正是以生成式 AI 模型为核心的系统。这意味着 AI Agents 必须搜索数据源，向这些数据源请求特定数据，等等。
每个数据源（服务器）都有其自己的实现方式（例如，有些实现为另一个代码库中的开源包，而不是发出可供任何人使用的消息；有些则可能实现为用于消息传递的 JSON RPC），因此，AI 模型（客户端）没有标准化的方式来搜索和请求数据。（这导致了碎片化。）
在 MCP 出现之前，构建 AI 系统通常涉及：
为每个 AI 应用定制实现，以接入所需的上下文，导致大量重复工作。不同团队和公司之间存在不一致的提示逻辑，以及访问和联合 (federating) 工具与数据的不同方法。“N x M 问题”，即大量客户端应用需要与大量服务器和工具交互，形成了一个复杂的集成网络，每个集成都需要特定的开发工作。模型上下文协议 (Model Context Protocol, MCP) 解决了这种碎片化的数据访问问题。 MCP 提供了一个开放标准，用于将 AI 系统与数据源和工具（如代码仓库、业务工具、开发环境）连接起来，用单一协议取代了碎片化的集成。因此，MCP 实现了 AI 客户端和服务器之间的可互换性 (fungibility)。
因此，MCP 为应用程序提供了一种标准化的方式来：
与语言模型共享上下文信息向 AI 系统暴露工具和能力构建可组合的集成和工作流该协议使用 JSON-RPC 2.0 消息在以下各方之间建立通信：
主机 (Hosts): 发起连接的 LLM 应用客户端 (Clients): 主机应用内部的连接器服务器 (Servers): 提供上下文和能力的服务目前已有许多流行的 AI 工具支持 MCP，包括：
CursorWindsurf (Codium)Cline (VS Code 扩展)Claude 桌面版Claude codeMCP 的一些灵感来源于语言服务器协议 (Language Server Protocol, LSP)，LSP 标准化了如何在整个开发工具生态系统中为编程语言添加支持。类似地，MCP 标准化了如何将额外的上下文和工具集成到 AI 应用的生态系统中。
二、MCP 架构MCP 遵循客户端-主机-服务器 (client-host-server) 架构，其中每个主机 (Host) 可以运行多个客户端 (Client) 实例。
这种架构使用户能够在不同应用程序之间集成 AI 能力，同时保持清晰的安全边界并隔离关注点 (isolating concerns)。 MCP 基于 JSON-RPC 构建，提供了一个有状态会话协议 (stateful session protocol)，专注于客户端和服务器之间的上下文交换和采样协调 (sampling coordination)。
主机 (Host)
主机进程充当容器和协调者：
创建并管理多个客户端实例控制客户端连接权限和生命周期强制执行安全策略和同意要求处理用户授权决策协调 AI/LLM 集成和采样管理跨客户端的上下文聚合客户端 (Clients)
每个客户端由主机创建，并维护一个隔离的服务器连接：
为每个服务器建立一个有状态会话处理协议协商和能力交换双向路由协议消息管理订阅和通知维护服务器之间的安全边界一个主机应用程序创建并管理多个客户端，每个客户端与特定的服务器保持 1:1 的关系。
MCP 客户端是那些希望访问外部系统、工具或数据源的 AI 应用或智能体 (agents)。例如 Anthropic 的第一方应用、Curser、Windsurf，以及像 Goose 这样的智能体。MCP 客户端的关键特征是其 MCP 兼容性，这意味着它是按照协议定义的标准化接口（提示、工具和资源）构建的，用于通信。
一旦 MCP 客户端兼容，它就可以连接到任何 MCP 服务器，几乎不需要或完全不需要额外的工作。客户端负责调用工具、查询资源和整合提示 (interpolating prompts)。
在工具方面，客户端应用内的语言模型决定何时最适合调用服务器暴露的工具。对于资源，客户端应用控制如何使用服务器暴露的数据。提示则被视为用户通过客户端应用调用的、由用户控制的工具。
服务器 (Servers)
服务器提供专门的上下文和能力：
通过 MCP 原语 (primitives) 暴露资源、工具和提示独立运行，职责明确通过客户端接口请求采样必须遵守安全约束可以是本地进程或远程服务MCP 服务器充当包装器 (wrappers) 或中介 (intermediaries)，提供访问各种外部系统、工具和数据源的标准化方式。一个 MCP 服务器可以提供对数据库、像 Salesforce 这样的 CRM、本地文件系统以及像 Git 这样的版本控制系统的访问。服务器构建者的角色是以任何兼容客户端都能使用的方式暴露工具、资源和提示。一旦 MCP 服务器构建完成，任何 MCP 客户端都可以采用它，通过减少对个性化集成的需求来解决“N x M 问题”。对于工具，服务器定义可用的函数及其描述，允许客户端的模型决定何时使用它们。对于资源，服务器定义并可能创建或检索它暴露给客户端应用的数据。对于提示，服务器为常见的交互提供预定义的模板，客户端应用可以代表用户触发这些模板。
MCP 协议充当这两个组件之间的通信层，标准化了请求和响应的结构化与交换方式。这种分离带来了几个好处，因为它允许：
无缝集成： 客户端可以连接到各种各样的服务器，而无需了解每个底层系统的具体细节。可重用性： 服务器开发者可以构建一次集成，然后让许多不同的客户端应用程序访问。关注点分离： 不同的团队可以独立地专注于构建客户端应用程序或服务器集成。例如，一个基础设施团队可以管理一个用于向量数据库 (vector database) 的 MCP 服务器，然后各种 AI 应用开发团队可以轻松地使用它。本质上，MCP 客户端和服务器之间的关系是一种标准化的交互关系，客户端通过 MCP 协议这一通用语言来利用服务器暴露的能力，从而为构建 AI 应用和智能体带来一个更高效、更具可扩展性的生态系统。
MCP 特性
MCP 服务器特性
MCP 服务器通过 MCP 提供了向语言模型添加上下文的基础构建块（提示、资源、工具）。这些原语使得客户端、服务器和语言模型之间能够进行丰富的交互：
提示 (Prompts): 预定义的模板或指令，用于指导与语言模型的交互。资源 (Resources): 结构化的数据或内容，为模型提供额外的上下文。工具 (Tools): 可执行的函数，允许模型执行操作或检索信息。模型上下文协议 (MCP) 为服务器向客户端暴露提示、资源和工具提供了一种标准化的方式。
提示 (Prompts) (协议修订版: 2024–11–05)提示允许服务器提供用于与语言模型交互的结构化消息和指令。客户端可以发现可用的提示，检索其内容，并提供参数来自定义它们。提示被设计为用户控制的，这意味着它们从服务器暴露给客户端，意图是让用户能够明确选择使用它们。通常，提示会通过用户在用户界面中发起的命令来触发，这使得用户可以自然地发现和调用可用的提示。例如，通过斜杠命令 (slash commands)。支持提示的服务器必须在初始化期间声明 prompts 能力：
资源允许服务器共享为语言模型提供上下文的数据，例如文件、数据库模式或特定于应用程序的信息。每个资源都由一个唯一的 URI 标识。MCP 中的资源被设计为应用程序驱动的，由主机应用程序根据其需求决定如何整合上下文。例如，应用程序可以： 通过 UI 元素（如树状或列表视图）暴露资源供用户明确选择。允许用户搜索和过滤可用的资源。基于启发式规则或 AI 模型的选择，实现自动上下文包含。支持资源的服务器必须声明 resources 能力：该能力支持两个可选特性： subscribe: 客户端是否可以订阅以接收单个资源变化的通知。listChanged: 当可用资源列表发生变化时，服务器是否会发出通知。
MCP 允许服务器暴露可由语言模型调用的工具。工具使模型能够与外部系统交互，例如查询数据库、调用 API 或执行计算。每个工具都由一个唯一的名称标识，并包含描述其模式 (schema) 的元数据。MCP 中的工具被设计为模型控制的，这意味着语言模型可以根据其上下文理解和用户提示自动发现和调用工具。但是，实现可以自由地通过任何适合其需求的接口模式来暴露工具。支持工具的服务器必须声明 tools 能力：listChanged 表明当可用工具列表发生变化时，服务器是否会发出通知。
MCP 客户端特性
客户端可以实现额外的特性来丰富连接的 MCP 服务器：根目录 (Roots) 和采样 (Sampling)。
根目录 (Roots)根目录定义了服务器可以在文件系统中操作的边界，使它们能够理解自己有权访问哪些目录和文件。MCP 提供了一种标准化的方式，让客户端向服务器暴露文件系统的“根目录”。服务器可以向支持此功能的客户端请求根目录列表，并在列表更改时接收通知。一个根目录定义包括： uri: 根目录的唯一标识符。在当前规范中，这必须是一个 file:// URI。name: 可选的、人类可读的名称，用于显示目的。不同用例的根目录示例：
结合起来，采样和可组合性是高级 AI 智能体的强大推动力。它们允许：
跨多智能体系统分配智能，客户端控制实际的 LLM 交互，而服务器（智能体）可以通过采样根据需要请求这些能力。构建复杂的多层智能体系统，其中专业智能体可以通过同时充当客户端和服务器来协同工作。提高智能体设计的灵活性和模块化，因为新的能力（作为 MCP 服务器暴露）可以集成到现有的智能体工作流中。智能体通过以可组合的方式与其他智能体和服务交互，具有进化和适应的潜力。这些概念超越了单体式 (monolithic) 智能体设计，朝着更分布式、协作和适应性强的 AI 系统发展。
MCP 提供的额外实用功能： 配置、进度跟踪、取消、错误报告、日志记录
安全与信任与安全 (Security and Trust & Safety)
MCP 通过任意数据访问和代码执行路径实现了强大的能力。伴随这种能力而来的是重要的安全和信任考量，所有实现者都必须仔细应对。
MCP 安全、信任与安全的关键原则
用户同意和控制： 用户必须明确同意并理解所有的数据访问和操作。他们必须保留对共享哪些数据和执行哪些操作的控制权。实现者应提供清晰的 UI 来审查和授权活动。数据隐私： 主机在向服务器暴露用户数据之前必须获得明确的用户同意。未经用户同意，主机不得将资源数据传输到别处。用户数据应受到适当的访问控制保护。工具安全： 工具代表任意代码执行，必须谨慎对待。主机在调用任何工具之前必须获得明确的用户同意。用户应在授权使用之前了解每个工具的作用。LLM 采样控制： 用户必须明确批准任何 LLM 采样请求。用户应控制——是否进行采样、将发送的实际提示、服务器可以看到哪些结果。协议有意限制服务器对提示的可见性。实施指南： MCP 的实现者应：
在其应用程序中构建健壮的同意和授权流程。提供关于安全影响的清晰文档。实施适当的访问控制和数据保护措施。在其集成中遵循安全最佳实践。在其功能设计中考虑隐私影响。三、MCP 设计原则MCP 建立在几个关键的设计原则之上，这些原则指导了其架构和实现：
服务器应该极易构建主机应用程序处理复杂的编排职责。服务器专注于特定的、定义明确的能力。简单的接口最大限度地减少了实现开销。清晰的分离使得代码易于维护。2. 服务器应该高度可组合
每个服务器独立提供专注的功能。多个服务器可以无缝组合。共享协议实现了互操作性。模块化设计支持可扩展性。3. 服务器不应能够读取整个对话，也不能“窥视”其他服务器
服务器仅接收必要的上下文信息。完整的对话历史保留在主机端。每个服务器连接保持隔离。跨服务器交互由主机控制。主机进程强制执行安全边界。4. 特性可以逐步添加到服务器和客户端
核心协议提供最少必需的功能。可以根据需要协商额外的能力。服务器和客户端独立发展。协议设计考虑了未来的可扩展性。保持向后兼容性。四、MCP 消息类型MCP 基于 JSON-RPC 2.0 定义了三种核心消息类型：
请求 (Requests): 带有方法和参数、期望响应的双向消息。响应 (Responses): 匹配特定请求 ID 的成功结果或错误。通知 (Notifications): 无需响应的单向消息。每种消息类型都遵循 JSON-RPC 2.0 规范的结构和传递语义。
MCP 中的能力协商系统 (Capability Negotiation System)
MCP 使用基于能力的协商系统，客户端和服务器在初始化期间明确声明其支持的特性。能力决定了会话期间可用的协议特性和原语。
服务器声明诸如资源订阅、工具支持和提示模板等能力。客户端声明诸如采样支持和通知处理等能力。双方必须在整个会话期间遵守声明的能力。可以通过协议扩展来协商额外的能力。每个能力都会在会话期间解锁特定的协议特性以供使用。例如：
已实现的服务器特性必须在其能力中声明。发出资源订阅通知要求服务器声明订阅支持。工具调用要求服务器声明工具能力。采样要求客户端在其能力中声明支持。这种能力协商确保客户端和服务器对支持的功能有清晰的理解，同时保持协议的可扩展性。
基础 MCP 协议详情 协议修订版: 2024–11–05
MCP 客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。该协议定义了三种基本类型的消息：
响应进一步细分为成功结果或错误。结果可以遵循任何 JSON 对象结构，而错误必须至少包含错误代码和消息。
协议层 (Protocol Layers)
模型上下文协议由几个协同工作的关键组件组成：
基础协议 (Base Protocol): 核心 JSON-RPC 消息类型。生命周期管理 (Lifecycle Management): 连接初始化、能力协商和会话控制。服务器特性 (Server Features): 服务器暴露的资源、提示和工具。客户端特性 (Client Features): 客户端提供的采样和根目录列表。实用功能 (Utilities): 跨领域的关注点，如日志记录和参数补全。所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的具体需求来实现。
这些协议层建立了清晰的关注点分离，同时实现了客户端和服务器之间的丰富交互。模块化设计允许实现仅支持它们所需的功能。
五、客户端-服务器连接的生命周期 (Life Cycle)模型上下文协议 (MCP) 为客户端-服务器连接定义了一个严格的生命周期，以确保正确的能力协商和状态管理。
初始化 (Initialization): 能力协商和协议版本约定。操作 (Operation): 正常的协议通信。关闭 (Shutdown): 连接的优雅终止。生命周期阶段：
1. 初始化 (Initialization): 初始化阶段必须是客户端和服务器之间的第一次交互。在此阶段，客户端和服务器：
建立协议版本兼容性。交换和协商能力。共享实现细节。客户端必须通过发送包含以下内容的 initialize 请求来启动此阶段： 支持的协议版本。客户端能力。客户端实现信息。服务器必须用其自身的能力和信息进行响应。成功初始化后，客户端必须发送 initialized 通知，以表明它已准备好开始正常操作。在服务器响应 initialize 请求之前，客户端不应发送除 ping 之外的请求。在收到 initialized 通知之前，服务器不应发送除 ping 和日志记录之外的请求。2. 版本协商 (Version Negotiation): 在initialize请求中，客户端必须发送它支持的协议版本。这应该是客户端支持的最新版本。如果服务器支持请求的协议版本，它必须以相同的版本响应。否则，服务器必须以它支持的另一个协议版本响应。这应该是服务器支持的最新版本。如果客户端不支持服务器响应中的版本，它应该断开连接。3. 能力协商 (Capability Negotiation): 客户端和服务器的能力确定了会话期间哪些可选的协议特性将可用。
关键能力包括：4. 操作 (Operation): 在操作阶段，客户端和服务器根据协商的能力交换消息。
双方应该： 遵守协商的协议版本。仅使用成功协商的能力。5. 关闭 (Shutdown): 在关闭阶段，一方（通常是客户端）干净地终止协议连接。没有定义特定的关闭消息——相反，应使用底层的传输机制来发出连接终止信号：
stdio: 对于 stdio 传输，客户端应该通过以下方式启动关闭： 首先，关闭到子进程（服务器）的输入流。等待服务器退出，如果服务器在合理时间内未退出，则发送 SIGTERM。如果在发送 SIGTERM 后合理时间内服务器仍未退出，则发送 SIGKILL。服务器可以通过关闭其到客户端的输出流并退出，来启动关闭。HTTP: 对于 HTTP 传输，关闭通过关闭相关的 HTTP 连接来指示。6. 错误处理 (Error Handling): 实现应该准备好处理这些错误情况：
协议版本不匹配。未能协商所需的能力。initialize 请求超时。关闭超时。实现应该为所有请求实现适当的超时，以防止连接挂起和资源耗尽。身份验证和授权目前不是核心 MCP 规范的一部分，但可能很快会引入。
协议的完整规范被定义为一个 TypeScript 模式 (schema)。这是所有协议消息和结构的事实来源 (source of truth)。
还有一个 JSON Schema，它是从 TypeScript 事实来源自动生成的，用于各种自动化工具。
MCP 协议思维导图 (Mindmap)
对于应用程序开发者
对于应用程序开发者而言，MCP 提供了几个关键好处：
连接服务器无需额外工作： 一旦应用程序与 MCP 兼容，它就可以连接到任何 MCP 服务器，而无需任何额外工作。这意味着开发者不需要为他们希望应用程序访问的每个新工具或数据源编写特定的集成逻辑，从而显著减少开发时间和工作量。标准化的接口： MCP 通过其三个主要接口（提示、工具和资源）标准化了 AI 应用程序与外部系统的交互方式。这提供了一种一致的方式来访问和利用不同服务器提供的能力，简化了开发过程，使开发者更容易理解和集成新功能。访问广泛的生态系统： 通过构建 MCP 客户端，开发者可以访问一个不断增长的、由社区构建和官方支持的 MCP 服务器生态系统。这使他们能够轻松集成广泛的功能，例如访问数据库、CRM、本地文件系统等，而无需自己构建这些集成。即将推出的 MCP 注册表 API (registry API) 将通过提供发现和引入 MCP 服务器的集中方式来进一步增强这一点。专注于核心应用逻辑： MCP 允许应用程序开发者专注于其 AI 应用的核心逻辑和用户体验，而不是花费时间处理与各种外部系统集成的复杂性。该协议处理底层的通信和标准化，使开发者能够专注于其应用程序的独特价值主张。正如 Mahesh 所解释的，开发者可以专注于“智能体循环 (agent Loop)”和上下文管理，而 MCP 则负责以标准化的方式引入上下文。利用模型智能进行工具使用： “工具”接口允许开发者向其应用程序中的语言模型暴露功能，使模型本身能够智能地决定何时以及如何调用这些工具。这减少了开发者为与外部系统的每次交互进行显式编程的需求，使应用程序更加动态和响应迅速。更丰富的用户交互： “资源”接口为服务器提供了一种暴露除简单文本之外的数据（例如图像和结构化数据）的方式。这使应用程序开发者能够为其用户创建更丰富、更具交互性的体验。模型上下文协议 (MCP) 也为工具/API 提供商、最终用户和企业带来了明显的好处：
对于工具/API 提供商：
提高采用率： 通过构建一次 MCP 服务器，工具或 API 提供商可以看到他们的服务在广泛的 MCP 兼容 AI 应用程序中被采用。这消除了为每个客户端应用程序构建单独集成的需要，显著扩大了他们的潜在用户群。正如 Mahesh 所说，他们可以“构建一次你的 MCP 服务器，然后在所有这些不同的 AI 应用程序中看到它被广泛采用”。简化集成： MCP 提供了一种标准化的方式，通过提示、工具和资源接口将其工具和数据暴露给 AI 应用程序。这简化了应用程序开发者与其服务集成的过程，使它们更有可能被采用。减少集成开销： 提供商不再需要处理为不同 AI 客户端构建和维护大量自定义集成的“N x M 问题”。MCP 充当统一层，简化了集成过程。接触智能体： MCP 允许工具/API 提供商使其服务能够被日益智能化的智能体访问，这些智能体可以自主决定何时以及如何利用其能力。这可能导致其工具和数据以新的、创新的方式被使用。潜在的新用例： 通过 MCP 暴露其服务，提供商可以解锁他们以前可能没有考虑过的新用例和应用程序，因为 AI 智能体可以以意想不到的方式利用他们的工具。对于最终用户：
更强大、上下文更丰富的 AI 应用： MCP 促进了更强大、更个性化的 AI 应用的开发，这些应用能够无缝访问相关数据和工具。这带来了更有效、更有用的用户体验。正如 Mahesh 提到的，最终用户受益于“更强大、上下文更丰富的 AI 应用”。上下文感知交互： 使用 MCP 构建的应用程序可以更好地感知上下文，理解用户的当前情况并访问必要的信息以提供相关帮助。像 Curser 和 Windsurf 这样的例子展示了 MCP 如何使系统能够“真正了解你，并能在现实世界中采取行动”。与熟悉工具的无缝集成： MCP 允许 AI 应用程序与用户已经依赖的工具和服务（如 GitHub、Asana 等）无缝集成。这提供了更统一、更高效的工作流程。更智能的辅助： 由 MCP 驱动的智能体可以智能地利用更广泛的工具和数据，从而在各种任务中提供更有能力、更有帮助的辅助。智能体通过 MCP 注册表（一旦可用）动态发现和使用新工具的能力将进一步增强这一点。可定制和个性化的体验： 用户可能会受益于可以通过 MCP 框架使用自己的数据源和首选工具进行定制的 AI 应用程序。对于企业：
标准化的 AI 开发： MCP 提供了一种清晰、标准化的方式在组织内构建 AI 系统，减少了不同团队之间常见的碎片化和重复工作。这有助于实现更具凝聚力、更高效的 AI 开发方法。关注点分离： MCP 实现了负责基础设施（如向量数据库）的团队与构建 AI 应用程序的团队之间的明确关注点分离。这使得每个团队都能专注于其核心专业知识并更快地行动。例如，一个团队可以管理一个向量数据库 MCP 服务器，而其他团队可以轻松访问它，而无需了解其底层实现。更快的开发周期： 借助标准化的接口和现成的 MCP 服务器，企业团队可以更快地构建和部署 AI 应用程序。他们不需要为每个数据源或工具花费时间进行自定义集成。集中式访问控制和治理（未来）： 虽然仍在发展中，但 MCP 中围绕远程服务器和身份验证 (OAuth 2.0) 的概念为更集中地控制 AI 应用程序的数据访问奠定了基础。未来的 MCP 注册表也可以通过提供在企业内验证和管理经批准的服务器的方式来促进治理。提高可扩展性和可维护性： MCP 的标准化特性可以带来更具可扩展性和可维护性的 AI 系统，因为集成是一致的，并且不易因单个 API 的更改而中断。利用现有基础设施： 企业可以用 MCP 服务器包装其现有的工具和数据源，使它们易于被 AI 应用程序访问，而无需进行重大的重新架构。MCP 注册表 API (MCP Registry API) (目前正在开发中)
目前正在开发的 MCP 注册表 API 的目的是提供一种集中化的方式来发现、验证和管理 MCP 服务器。
MCP 注册表 API 旨在解决的关键挑战包括：
可发现性 (Discoverability): 目前，查找相关的 MCP 服务器是碎片化的。注册表将作为一个统一的元数据服务，使用户和应用程序更容易定位可用的服务器及其能力。协议信息 (Protocol Information): 注册表将提供有关服务器使用的协议（例如，标准 IO 或 SSE）及其位置（本地文件或远程 URL）的信息。信任与验证 (Trust and Verification): 一个重大挑战是确定 MCP 服务器的可信度和真实性。注册表旨在通过可能提供验证机制来解决这个问题，例如标明来自信誉良好公司（如 Shopify 或 Grafana）的官方服务器。发布 (Publication): 注册表将简化开发者发布其 MCP 服务器并使其可供更广泛受众访问的过程。版本控制 (Versioning): 随着 MCP 服务器的发展，注册表将提供一种管理和跟踪不同版本服务器及其能力的方法。这将帮助用户了解发生了什么变化，并可能在需要时固定到特定版本。元数据管理 (Metadata Management): 注册表将托管有关 MCP 服务器的元数据，包括其能力（资源和工具），这可能使其更容易理解如何与它们交互。远程服务器和 OAuth 2.0 在 MCP 协议中的集成
远程服务器的重要性：
目前，MCP 通常依赖于使用标准 IO 的本地或内存中通信，这在设置和部署方面可能会带来不便。远程服务器，通过像 SSE (Server-Sent Events) 这样的协议实现，允许 MCP 服务器托管在公共 URL 上，使其可以通过互联网访问。这一发展消除了用户理解 MCP 服务器托管或构建复杂性的需要。就像访问网站一样，用户或应用程序可能只需通过 URL 即可连接到远程 MCP 服务器。远程服务器将 MCP 客户端（例如 AI 智能体或应用程序）的位置与 MCP 服务器解耦，允许它们在完全不同的系统上运行。这增强了架构设计和部署的灵活性。服务器可用性的提高将扩大通过 MCP 可访问的能力范围。OAuth 2.0 的集成：
OAuth 2.0 的集成提供了一种标准化且安全的机制，用于 MCP 客户端和远程服务器之间的身份验证和授权。MCP 现在支持 OAuth 2.0 握手，其中服务器协调身份验证流程，与 OAuth 提供商（例如 Slack）交互。客户端（用户）通常通过熟悉的基于 Web 的流程授权连接。一旦通过身份验证，服务器将持有 OAuth 令牌，然后可以为后续交互向客户端提供会话令牌。这种方法使服务器能够更好地控制与底层服务（如 Slack）的交互。这种安全的身份验证机制对于实现对远程服务器提供的敏感数据和功能的访问至关重要。它建立了信任，并提供了一个管理权限的框架。对可访问性和可用性的影响：
这些进步很可能对 MCP 服务器的可访问性和可用性产生深远的积极影响：
降低入门门槛： 通过 URL 连接到远程服务器的简便性显著降低了希望在其应用程序中利用 MCP 功能的开发者以及与这些应用程序交互的最终用户的技术门槛。用户甚至可能不需要意识到他们正在与 MCP 服务器交互。更广泛的应用范围： 远程托管服务器的能力为更广泛的应用利用 MCP 开辟了可能性。基于 Web 的应用程序、移动应用程序和云服务现在可以更容易地与 MCP 服务器集成，而无需复杂的本地设置。提高服务器可用性： 开发和部署摩擦的减少可能会导致提供多样化功能的 MCP 服务器激增。这个扩展的生态系统将为 AI 应用程序提供更丰富的工具和资源集。增强安全性和信任： 采用 OAuth 2.0 为安全访问远程资源提供了一个健壮且广泛认可的标准。这对于建立用户信心和鼓励使用与个人或敏感数据交互的 MCP 服务器至关重要。正如您之前在关于注册表背景下的信任和验证的讨论中指出的那样，安全的身份验证机制是可信生态系统的基本构建块。简化开发： 开发者可以更多地专注于构建其应用程序和服务器的核心逻辑，而不是处理本地通信和自定义身份验证方法的复杂性。标准化的 OAuth 2.0 流程简化了集成过程。由 MCP 服务器注册表赋能的自进化智能体 (Self-evolving agents)
MCP 服务器注册表允许智能体动态地发现新的能力和数据，而无需在最初就被明确编程告知这些知识。这意味着智能体可以遇到新任务或需要访问以前未知的数据源，并主动寻找必要的工具来满足该需求。
考虑一个通用编码智能体的例子，其任务是检查 Grafana 日志。如果该智能体最初没有配置 Grafana 服务器的具体信息，它可以与 MCP 注册表交互。通过搜索提供必要 API 的官方且经过验证的 Grafana 服务器，智能体随后可以安装或调用该服务器（可能通过 SSE 远程进行，如前所述），然后继续查询日志并解决问题。
自进化智能体的潜在优势：
增强的适应性： 最显著的优势是智能体适应新情况和任务的能力增强。它不再局限于其预编程的能力，而是可以根据需要学习和扩展其功能。更广泛的应用范围： 自进化智能体可以处理更多种类的任务，而无需开发者在初始设计和编程阶段预测所有可能的情况。改善的用户体验： 用户可以与更通用的智能体交互，这些智能体可以处理各种请求，即使是涉及智能体最初未明确构建用于使用的系统或数据源的请求。智能体承担了寻找正确工具的责任。持续改进： 智能体可以通过发现和集成注册表中可用的新的、可能更高效的工具和数据源，随着时间的推移有效地“学习”和改进。减少开发开销： 开发者可以专注于构建智能体的核心推理和任务执行逻辑，依靠注册表来提供对不断增长的能力生态系统的访问。这减少了为每个潜在的数据源或服务构建定制集成的需要。围绕自进化智能体的考量：
治理与安全： 一个关键的考虑因素是控制智能体可以访问哪些服务器和能力。没有适当的保障措施，自进化智能体可能会连接到不受信任甚至恶意的服务器，从而带来安全风险或数据隐私问题。正如 Mahesh 提到的，诸如带有经批准服务器的自托管注册表、白名单和验证机制等方法对于减轻这些风险至关重要。服务器的信任概念变得越来越重要，正如我们之前的讨论所强调的那样。信任与验证： 确保发现的服务器的可靠性和可信度至关重要。MCP 注册表旨在通过提供验证机制来解决这个问题，可能允许官方实体（如 Shopify 或 Grafana）“认证 (bless)”其服务器。性能与效率： 动态发现和集成新服务器的过程可能会给智能体的工作流带来延迟。优化注册表搜索和服务器集成过程将非常重要。工具选择与推理： 虽然模型在工具使用方面变得越来越熟练，但仍需要确保智能体能够就从注册表中可能存在的众多选项中选择哪些工具以及如何有效地利用它们做出明智的决策。用过多的选项压垮智能体也可能是一个挑战。调试与可观察性： 随着智能体变得更加复杂并依赖于动态发现的组件，调试和监控其行为可能会变得更具挑战性。需要清晰的机制来观察智能体与注册表以及被调用服务器的交互。如前所述，服务器可调试性和客户端-服务器元数据通信的最佳实践将非常重要。版本控制与兼容性： 随着服务器的发展及其 API 的变化，注册表中需要版本控制机制来确保与现有智能体的兼容性。智能体可能需要了解不同的服务器版本，并可能需要处理兼容性问题。来源：后两间汇金超市一点号