Anthropic于 2024 年 11 月发布了模型上下文协议 (MCP) 。它由 Anthropic 的 Mahesh Murag 开发。在这里可以查看完整的官方文档。目前，MCP 已完全实现为Python SDK和TypeScript SDK。

上下文是关键

生成式 AI 模型的基本能力取决于其预训练细节、训练数据和模型架构。为了使这些预训练模型表现更佳，并提高其与任务的相关性和一致性，您必须为其提供良好的环境。

这里的上下文是指模型用来生成相关且连贯的响应的信息。上下文决定了模型如何理解和继续对话、完成文本或生成图像。

根据模型和任务的类型，可以通过不同的方式提供上下文：

1. 基于文本的模型（例如 GPT、DeepSeek、LLaMA）通过以下方式接收上下文：

• 提示上下文：指导模型响应的输入文本或查询。
• 令牌窗口：模型一次可以“记住”的令牌数量（例如，GPT-4-Turbo 可以处理约 128K 个令牌）。
• 对话历史：在聊天机器人中，以前的交流有助于在多轮对话中维持上下文。
• 检索增强生成 (RAG)：从外部文档中动态检索上下文以改善响应。

2. 图像和多模态模型（例如，DALL·E，Gemini）通过以下方式接收其上下文：

• 文字说明：提示引导图像生成。
• 视觉环境：如果提供了图像，模型会在生成新元素之前分析其内容。
• 跨模式上下文：当结合文本和图像时，模型会解释两者以生成有意义的输出。

3. 代码生成模型（例如 Codex、DeepSeek-Coder）通过以下方式接收其上下文：

• 以前的代码块：上下文包括现有代码、函数名称和注释。
• 编程语言语法：该模型理解特定于语言的模式。
• 外部文档：一些模型使用 API 或文档来提供更准确的建议。

4. 语音和音频模型（例如 Whisper、AudioPaLM）通过以下方式接收上下文：

• 音频片段：先前的语音或音乐告知下一个生成的部分。
• 语言和声学特征：音调、速度和语调影响转录和生成。

简而言之，语境是生成式人工智能产生相关且连贯输出的关键因素。语境管理越好，人工智能的性能就越好。

随着时间的推移，AI 模型可以自动获取数据作为上下文。对于以生成式 AI 模型为核心的 AI 代理系统来说尤其如此。这意味着 AI 代理必须搜索数据源、向数据源请求特定数据等等。

每个数据源（服务器）都有自己的实现方式（例如，作为另一个代码库中的开源包——而不是发送任何人都可以使用的消息。或者，这些消息也可以实现为 JSON RPC 消息），因此 AI 模型（客户端）没有标准的方法来搜索和请求数据。（碎片化。）

在 MCP 之前，构建 AI 系统通常涉及：

• 每个 AI 应用程序的自定义实现都需要挂接到其所需的上下文中，这会导致大量重复的工作。
• 提示逻辑不一致，不同团队和公司之间访问和联合工具和数据的方法也不同。
• “N 乘以 M 问题”是指大量客户端应用程序需要与大量服务器和工具交互，从而产生复杂的集成网络，每个集成都需要特定的开发工作。

模型上下文协议 (MCP) 解决了数据访问碎片化的问题。

MCP 提供了一个开放标准，用于连接 AI 系统与数据源和工具（存储库、业务工具、开发环境），用单一协议取代碎片化的集成。因此，MCP 提供了 AI 客户端和服务器之间的可互换性。

因此，MCP 为应用程序提供了一种标准化的方式：

• 与语言模型共享上下文信息
• 向人工智能系统展示工具和功能
• 构建可组合的集成和工作流程

该协议使用JSON-RPC 2.0 消息在以下各项之间建立通信：

• Hosts（宿主）：发起连接的 LLM 应用程序
• Clients（客户端）：主机应用程序内的连接器
• Servers（服务器端）：提供上下文和功能的服务

有许多流行的 AI 工具支持 MCP，包括：

• Cursor
• Windsurf（Codium）
• Cline（VS Code 扩展）
• Claude Desk
• Claude Code

MCP 借鉴了语言服务器协议 (Language Server Protocol)的一些灵感，该协议规范了如何在整个开发工具生态系统中添加编程语言支持。同样，MCP 也规范了如何将额外的上下文和工具集成到 AI 应用生态系统中。

MCP的架构

MCP 遵循客户端-主机-服务器架构，其中每个主机可以运行多个客户端实例。

• 该架构使用户能够跨应用程序集成 AI 功能，同时保持清晰的安全边界并隔离关注点。
• MCP 基于 JSON-RPC 构建，提供专注于客户端和服务器之间的上下文交换和采样协调的状态会话协议。

Hosts （宿主端）

宿主进程充当容器和协调器：

• 创建和管理多个客户端实例
• 控制客户端连接权限和生命周期
• 执行安全政策和同意要求
• 处理用户授权决策
• 协调 AI/LLM 集成和采样
• 管理跨客户端的上下文聚合

Clients （客户端）

每个客户端由主机创建并维护一个隔离的服务器连接：

• 每个服务器建立一个有状态会话
• 处理协议协商和能力交换
• 双向路由协议消息
• 管理订阅和通知
• 维护服务器之间的安全边界

主机应用程序创建并管理多个客户端，每个客户端与特定服务器具有 1:1 的关系。

MCP 客户端是指需要访问外部系统、工具或数据源的AI 应用程序或代理。例如，Anthropic 的第一方应用程序 Curser、Windsurf 以及 Goose 等代理。MCP 客户端的关键特性在于其MCP 兼容性，这意味着它能够使用协议定义的标准化接口进行通信：提示、工具和资源。

一旦 MCP 客户端兼容，它就可以连接到任何 MCP 服务器，只需很少或无需任何额外工作。客户端负责调用工具、查询资源以及插入提示。

在工具上下文中，客户端应用程序中的语言模型决定何时最佳地调用服务器公开的工具。对于资源，客户端应用程序可以控制如何使用服务器公开的数据。提示被视为用户通过客户端应用程序调用的用户控制工具。

Servers (服务器）

服务器提供专门的上下文和功能：

• 通过 MCP 原语公开资源、工具和提示
• 独立运作，专注负责
• 通过客户端界面请求采样
• 必须尊重安全约束
• 可以是本地进程或远程服务

MCP 服务器充当包装器或中介，提供访问各种外部系统、工具和数据源的标准化方式。MCP 服务器可以提供对数据库、CRM（如 Salesforce）、本地文件系统和版本控制系统（如 Git）的访问。服务器构建者的作用是以任何兼容客户端均可使用的方式公开工具、资源和提示。MCP 服务器构建完成后，任何 MCP 客户端都可以采用它，通过减少个性化集成的需求来解决“N 乘以 M 问题”。对于工具，服务器定义可用的功能及其描述，允许客户端的模型决定何时使用它们。对于资源，服务器定义并可能创建或检索它公开给客户端应用程序的数据。对于提示，服务器为客户端应用程序可以代表用户触发的常见交互提供预定义的模板。

MCP 协议充当这两个组件之间的通信层，标准化请求和响应的构造和交换方式。这种分离提供了几个好处，因为它允许：

• 无缝集成：客户端可以连接到各种服务器，而无需了解每个底层系统的具体细节。
• 可重用性：服务器开发人员只需构建一次集成，即可让许多不同的客户端应用程序访问它们。
• 关注点分离：不同的团队可以专注于独立构建客户端应用程序或服务器集成。例如，基础设施团队可以管理矢量数据库的 mCP 服务器，以便各个 AI 应用程序开发团队轻松使用。

本质上，MCP 客户端和服务器之间的关系是一种标准化交互关系，其中客户端通过 MCP 协议的通用语言利用服务器公开的功能，从而为构建 AI 应用程序和代理提供更高效、更具可扩展性的生态系统。

MCP 功能

MCP 服务器功能

MCP 服务器提供了通过 MCP 向语言模型添加上下文所需的基本构建块（提示、资源和工具）。这些原语支持客户端、服务器和语言模型之间进行丰富的交互：

• 提示：指导语言模型交互的预定义模板或指令
• 资源：为模型提供额外上下文的结构化数据或内容
• 工具：允许模型执行操作或检索信息的可执行函数

模型上下文协议 (MCP) 为服务器向客户端公开提示、资源和工具提供了一种标准化的方式。

提示（协议修订：2024-11-05）

提示允许服务器提供与语言模型交互的结构化消息和指令。客户端可以发现可用的提示，检索其内容，并提供参数来自定义它们。

提示被设计为由用户控制，这意味着它们从服务器暴露给客户端，目的是让用户能够明确地选择它们来使用。

通常，提示会通过用户界面中用户发起的命令触发，这允许用户自然地发现并调用可用的提示。例如，斜线命令。

支持提示的服务器必须在初始化期间声明该prompts功能：

资源：协议修订：2024-11-05

资源允许服务器共享为语言模型提供上下文的数据，例如文件、数据库架构或特定于应用程序的信息。每个资源都由URI唯一标识。

MCP 中的资源被设计为应用程序驱动，主机应用程序根据其需求确定如何合并上下文。

例如，应用程序可以：

• 通过 UI 元素公开资源，以便在树或列表视图中明确选择
• 允许用户搜索和过滤可用资源
• 根据启发式方法或 AI 模型的选择实现自动上下文包含

支持资源的服务器必须声明以下resources功能：

该功能支持两个可选特性：

• subscribe：客户端是否可以订阅单个资源变更的通知。
• listChanged：当可用资源列表发生变化时，服务器是否会发出通知。

工具 — 协议修订：2024-11-05

MCP 允许服务器公开可供语言模型调用的工具。这些工具使模型能够与外部系统交互，例如查询数据库、调用 API 或执行计算。每个工具都由一个唯一名称标识，并包含描述其架构的元数据。

MCP 中的工具被设计为模型控制的，这意味着语言模型可以根据其上下文理解和用户提示自动发现并调用工具。然而，实现者可以自由地通过任何符合其需求的接口模式来暴露工具。

支持工具的服务器必须声明以下tools功能：

listChanged指示当可用工具列表发生变化时服务器是否会发出通知。

MCP 客户端功能

客户端可以实现附加功能来丰富连接的 MCP 服务器：Roots 和 Sampling。

根

• 根定义了服务器在文件系统中可以操作的边界，使它们能够了解自己可以访问哪些目录和文件。MCP 为客户端提供了一种标准化的方式，将文件系统的“根”暴露给服务器。服务器可以向支持客户端请求根列表，并在列表发生变化时收到通知。

根定义包括：

• uri：根的唯一标识符。这必须是file://当前规范中的 URI。
• name：可选的、可读的名称，用于显示目的。

不同用例的示例根：

采样（方案修订：2024-11-05）

MCP 为服务器提供了一种标准化的方式，使其能够通过客户端向语言模型请求 LLM 采样（“完成”或“生成”）。此流程允许客户端控制模型的访问、选择和权限，同时使服务器能够利用 AI 功能——无需服务器 API 密钥。服务器可以请求基于文本或图像的交互，并可选择在其提示中包含来自 MCP 服务器的上下文。

MCP 中的采样允许服务器实现代理行为，通过使 LLM 调用嵌套在其他 MCP 服务器功能中发生。

实现可以自由地通过任何适合其需求的接口模式来公开采样——协议本身并不强制要求任何特定的用户交互模型。

可组合性

• MCP 的可组合性强调了客户端和服务器之间的区别是逻辑上的，而非物理上的。这意味着任何应用程序、API 或代理都可以同时充当 MCP 客户端和 MCP 服务器。
• 这种双重角色允许创建分层和链式系统。用户可以与主代理应用程序（客户端）交互，然后该应用程序与专门的子代理（充当服务器）通信。该子代理反过来可以充当客户端，并调用其他 MCP 服务器（例如文件系统服务器或 Web 搜索服务器）来完成其任务。
• 与代理的相关性：可组合性对于构建先进的模块化代理架构至关重要。它支持创建分层的代理系统，其中不同的代理可以专注于特定任务，并将子任务委托给其他代理。例如，协调器代理可以接收高级目标，然后将其分解为更小的任务，再将这些任务委托给研究代理、编码代理或事实核查代理，每个代理都充当 MCP 服务器，但也可能充当客户端以访问必要的工具和数据。这允许通过组合多个专用代理的功能来构建复杂的工作流和智能行为。它还允许重用和连接到其他代理构建的代理，即使这些代理最初并非主代理设计的一部分。

采样和可组合性相结合，是实现高级AI代理的强大推动力。它们可以实现：

• 在多代理系统中分布智能，客户端控制实际的 LLM 交互，而服务器（代理）可以根据需要通过采样请求这些功能。
• 构建复杂的、多层的代理系统，其中专门的代理可以作为客户端和服务器一起工作。
• 代理设计的灵活性和模块化程度有所提高，因为新功能（以 mCP 服务器的形式公开）可以集成到现有的代理工作流程中。
• 代理通过以可组合的方式与其他代理和服务进行交互而具有进化和适应的潜力。

这些概念超越了单一代理设计，转向更加分布式、协作性和适应性更强的人工智能系统。

MCP 提供的附加实用程序：

• 配置、进度跟踪、取消、错误报告、日志记录

安全与信任

MCP 通过任意数据访问和代码执行路径实现了强大的功能。这种能力伴随着重要的安全性和信任考量，所有实现者都必须谨慎处理。

MCP 安全、信任和安全的关键原则

1. 用户同意与控制：用户必须明确同意并理解所有数据访问和操作。他们必须掌控哪些数据可以共享以及哪些操作可以被执行。实施者应提供清晰的用户界面，用于审核和授权操作。

2. 数据隐私：主机在将用户数据暴露给服务器之前，必须获得用户的明确同意。未经用户同意，主机不得将资源数据传输到其他地方。用户数据应受到适当的访问控制保护。

3. 工具安全：工具可能执行任意代码，必须谨慎对待。主机在调用任何工具之前必须获得用户的明确同意。用户在授权使用每个工具之前，应了解其功能。

4. LLM 采样控制：用户必须明确批准任何 LLM 采样请求。用户应控制以下事项：采样是否进行、实际发送的提示、服务器可以看到哪些结果，以及协议是否有意限制服务器对提示的可见性

实施指南：MCP 实施者应该：

1. 在其应用程序中构建强大的同意和授权流程
2. 提供安全隐患的清晰文档
3. 实施适当的访问控制和数据保护
4. 在集成过程中遵循安全最佳实践
5. 在功能设计中考虑隐私问题

MCP 设计原则

MCP 建立在几个关键的设计原则之上，这些原则指导了其架构和实现：

1. 服务器应该非常容易构建

• 主机应用程序处理复杂的编排职责
• 服务器专注于特定的、定义明确的功能
• 简单的接口最大程度地减少实现开销
• 清晰的分离使代码可维护

2. 服务器应高度可组合

• 每个服务器单独提供重点功能
• 多台服务器可以无缝组合
• 共享协议实现互操作性
• 模块化设计支持可扩展性

3. 服务器不应该能够读取整个对话，也不应该“查看”其他服务器

• 服务器仅接收必要的上下文信息
• 完整的对话历史记录保留在主持人手中
• 每个服务器连接保持隔离
• 跨服务器交互由主机控制
• 主机进程强制执行安全边界

4. 可以逐步向服务器和客户端添加功能

• 核心协议提供所需的最少功能
• 可以根据需要协商附加功能
• 服务器和客户端独立发展
• 为未来扩展而设计的协议
• 保持向后兼容性

MCP 消息类型

MCP 基于JSON-RPC 2.0定义了三种核心消息类型：

• 请求：具有方法和参数的双向消息，期望得到响应
• 响应：与特定请求 ID 匹配的成功结果或错误
• 通知：无需回复的单向消息

每种消息类型都遵循 JSON-RPC 2.0 的结构和传递语义规范。

MCP中的能力协商系统

MCP 使用基于功能的协商系统，客户端和服务器在初始化期间明确声明其支持的功能。功能决定了会话期间可用的协议功能和原语。

• 服务器声明资源订阅、工具支持和提示模板等功能
• 客户声明诸如采样支持和通知处理等功能
• 双方必须在整个会议期间尊重声明的能力
• 可以通过协议扩展来协商附加功能

每项功能都会解锁会话期间使用的特定协议特性。例如：

• 已实现的服务器功能必须在服务器的功能中宣传
• 发出资源订阅通知需要服务器声明订阅支持
• 工具调用需要服务器声明工具功能
• 抽样需要客户声明其能力范围内的支持

这种能力协商确保客户端和服务器清楚地了解所支持的功能，同时保持协议的可扩展性。

基础 MCP 协议细节

协议修订：2024-11-05

MCP 客户端与服务器之间的所有消息必须遵循JSON-RPC 2.0规范。该协议定义了三种基本消息类型：

响应进一步细分为成功结果或错误。结果可以遵循任何 JSON 对象结构，而错误必须至少包含错误代码和消息。

协议层

模型上下文协议由几个协同工作的关键组件组成：

• 基本协议：核心 JSON-RPC 消息类型
• 生命周期管理：连接初始化、功能协商和会话控制
• 服务器功能：服务器公开的资源、提示和工具
• 客户端功能：客户提供的采样和根目录列表
• 实用程序：跨切关注点，例如日志记录和参数完成

所有实现都必须支持基础协议和生命周期管理组件。其他组件可以根据应用的具体需求进行实现。

这些协议层建立了清晰的关注点分离，同时支持客户端和服务器之间的丰富交互。模块化设计使实现能够精确支持所需的功能。

客户端-服务器连接的生命周期：

模型上下文协议 (MCP) 为客户端-服务器连接定义了严格的生命周期，以确保正确的能力协商和状态管理。

1. 初始化：能力协商和协议版本协商
2. 操作：正常协议通信
3. Shutdown：正常终止连接

生命周期阶段：

1. 初始化：初始化阶段必须是客户端与服务器之间的首次交互。在此阶段，客户端和服务器：

• 建立协议版本兼容性
• 交流和谈判能力
• 分享实施细节

客户端必须通过发送initialize包含以下内容的请求来启动此阶段：

• 支持的协议版本
• 客户端功能
• 客户端实施信息

服务器必须以其自身的功能和信息做出响应。

初始化成功后，客户端必须发送initialized通知，表明它已准备好开始正常操作。在服务器响应请求之前，客户端不应发送除ping之外的其他请求initialize。服务器在收到通知之前，不应发送除ping和日志记录之外的其他请求initialized。

2. 版本协商：在initialize请求中，客户端必须发送其支持的协议版本。该版本必须是客户端支持的最新版本。如果服务器支持请求的协议版本，则必须以相同的版本进行响应。否则，服务器必须以其支持的另一个协议版本进行响应。该版本必须是服务器支持的最新版本。如果客户端不支持服务器响应中的版本，则应该断开连接。

3. 能力协商：客户端和服务器能力确定会话期间哪些可选协议功能可用。

主要功能包括：

能力对象可以描述子能力。

4. 操作：在操作阶段，客户端和服务器根据协商好的能力交换消息。

双方应该：

• 尊重协商的协议版本
• 仅使用已成功协商的功能

5. 关闭：在关闭阶段，一方（通常是客户端）干净地终止协议连接。没有定义具体的关闭消息——而是应该使用底层传输机制来发出连接终止信号：

标准输入输出

对于 stdio传输，客户端应该通过以下方式启动关闭：

1. 首先，关闭子进程（服务器）的输入流
2. 等待服务器退出，或者SIGTERM如果服务器在合理的时间内没有退出则发送
3. SIGKILL如果服务器在合理时间内没有退出，则发送SIGTERM

服务器可以通过关闭其到客户端的输出流并退出来启动关机。

6. HTTP：对于 HTTP传输，关闭表示关闭相关的 HTTP 连接。

7. 错误处理：实现应该准备好处理这些错误情况：

• 协议版本不匹配
• 未能协商所需能力
• 初始化请求超时
• 关机超时

实现应该为所有请求实现适当的超时，以防止挂起连接和资源耗尽。

身份验证和授权目前不是核心 MCP 规范的一部分，但可能很快就会引入。

该协议的完整规范被定义为TypeScript 模式。这是所有协议消息和结构的真实来源。

还有一个JSON Schema，它是从 TypeScript 事实来源自动生成的，可用于各种自动化工具。

MCP 对利益相关者的益处

对于应用程序开发人员

对于应用程序开发人员来说，MCP 提供了几个关键优势。

• 无需额外工作即可连接服务器：一旦应用程序兼容 MCP，即可连接到任何 mCP 服务器，无需额外工作。这意味着开发人员无需为应用程序访问的每个新工具或数据源编写特定的集成逻辑，从而显著减少开发时间和精力。
• 标准化接口： MCP 通过其三个主要接口（提示、工具和资源）标准化了 AI 应用程序与外部系统的交互方式。这提供了一种一致的方式来访问和利用不同服务器提供的功能，从而简化了开发流程，并使开发人员更容易理解和集成新功能。
• 访问广泛的生态系统：通过构建 MCP 客户端，开发者可以访问日益壮大的由社区构建并由官方支持的MCP服务器生态系统。这使得他们能够轻松集成各种功能，例如访问数据库、CRM、本地文件系统等，而无需自行构建这些集成。即将推出的mCP 注册 API将通过提供一种集中式的方式来发现和引入MCP服务器，进一步增强此功能。
• 专注于核心应用逻辑： MCP 使应用开发者能够专注于 AI 应用的核心逻辑和用户体验，而无需花时间处理与各种外部系统集成的复杂性。该协议负责处理底层通信和标准化工作，使开发者能够专注于其应用的独特价值主张。正如 Mahesh 所解释的那样，开发者可以专注于“代理循环”和上下文管理，而 MCP 则负责以标准化的方式引入上下文。
• 利用模型智能实现工具使用： “工具”接口允许开发人员在其应用程序中向语言模型公开功能，从而使模型本身能够智能地决定何时以及如何调用这些工具。这减少了开发人员对与外部系统的每次交互进行显式编程的需要，从而使应用程序更加动态和响应迅速。
• 更丰富的用户交互： “资源”界面为服务器提供了一种除了简单文本之外的数据访问方式，例如图像和结构化数据。这使得应用程序开发者能够为用户打造更丰富、更具交互性的体验。

模型上下文协议 (mCP) 为工具/API 提供商、最终用户和企业提供了明显的优势：

工具/API 提供商：

• 提升采用率：只需构建一次MCP服务器，工具或 API 提供商就能在众多兼容MCP 的AI 应用中看到其服务被广泛采用。这消除了为每个客户端应用构建单独集成的需要，从而显著扩大了其潜在用户群。正如 Mahesh 所说，他们“只需构建一次 MCP 服务器，就能在所有这些不同的 AI 应用中看到它被广泛采用”。
• 简化集成： MCP 提供了一种标准化的方式，通过提示、工具和资源界面向 AI 应用程序公开其工具和数据。这简化了应用程序开发人员与其服务集成的流程，使其更有可能被采用。
• 降低集成开销：提供商不再需要处理为不同 AI 客户构建和维护大量自定义集成的“N x M 问题”。MCP 作为统一层，简化了集成流程。
• 访问智能代理： MCP 允许工具/API 提供商将其服务提供给日益智能的代理，这些代理可以自主决定何时以及如何使用其功能。这将带来其工具和数据的全新创新使用方式。
• 新用例的潜力：通过 MCP 公开其服务，提供商可以解锁他们以前可能没有考虑过的新用例和应用程序，因为 AI 代理可以以无法预见的方式利用他们的工具。

最终用户：

• 更强大、情境更丰富的人工智能应用： MCP 助力开发更强大、更个性化的人工智能应用，这些应用能够无缝访问相关数据和工具。这将带来更高效、更实用的用户体验。正如 Mahesh 所说，最终用户将受益于“更强大、情境更丰富的人工智能应用”。
• 情境感知交互：使用 MCP 构建的应用程序可以增强情境感知能力，了解用户当前情况并获取必要信息以提供相关帮助。Curser 和 Windsurf 等示例展示了 MCP 如何使系统“真正了解你，并能够在现实世界中采取行动”。
• 与熟悉工具无缝集成： MCP 允许 AI 应用程序与用户已依赖的工具和服务（例如 GitHub、Asana 等）无缝集成。这提供了更加统一、高效的工作流程。
• 更智能的辅助：由 MCP 驱动的代理可以智能地利用更广泛的工具和数据，从而在各种任务中提供更高效、更实用的辅助。代理能够通过 MCP 注册表（一旦可用）动态发现和使用新工具，这将进一步增强其智能化能力。
• 可定制和个性化的体验：用户可以通过 MCP 框架使用自己的数据源和首选工具定制AI 应用程序。

企业：

• 标准化的人工智能开发： MCP 提供了一种清晰且标准化的方法，用于在组织内部构建人工智能系统，从而减少了不同团队之间常见的碎片化和重复工作，从而实现了更具凝聚力和效率的人工智能开发方法。
• 关注点分离： MCP 能够清晰地分离负责基础设施（例如矢量数据库）的团队和构建 AI 应用程序的团队之间的关注点。这使得每个团队能够专注于各自的核心专业技能，并加快开发速度。例如，一个团队可以管理矢量数据库 mCP 服务器，而其他团队可以轻松访问它，而无需了解其底层实现。
• 更快的开发周期：借助标准化接口和随时可用的 MCP 服务器，企业团队可以更快地构建和部署 AI 应用程序。他们无需为每个数据源或工具花费时间进行自定义集成。
• 集中访问控制和治理（未来）： MCP 中有关远程服务器和身份验证（OAuth 2.0）的概念虽然仍在不断发展，但为更加集中地控制AI 应用程序的数据访问奠定了基础。未来的 mCP 注册表还可以通过提供在企业内验证和管理已批准服务器的方法，为治理做出贡献。
• 提高可扩展性和可维护性： MCP 的标准化特性可以带来更具可扩展性和可维护性的 AI 系统，因为集成是一致的，并且不易因单个 API 的变化而中断。
• 利用现有基础设施：企业可以使用MCP服务器包装其现有工具和数据源，使 AI 应用程序可以轻松访问它们，而无需进行大规模的重新架构。

MCP 注册 API（目前正在开发中）

目前正在开发的 MCP 注册 API的目的是提供一种集中的方式来发现、验证和管理 MCP 服务器。

MCP 注册表 API 旨在解决的关键挑战包括：

• 可发现性：目前，查找相关的 mCP 服务器较为分散。注册中心将提供统一的元数据服务，方便用户和应用程序查找可用的服务器及其功能。
• 协议信息：注册表将提供有关服务器使用的协议（例如，标准 IO 或 SSSE）及其位置（本地文件或远程 URL）的信息。
• 信任与验证：确定mCP 服务器的可信度和真实性是一项重大挑战。注册中心旨在通过提供验证机制来解决这个问题，例如，指定来自 Shopify 或 Grafana 等信誉良好的公司的官方服务器。
• 发布：该注册中心将简化开发人员发布其 mCP 服务器的过程，并使更广泛的受众可以访问它们。
• 版本控制：随着 mCP 服务器的演进，注册中心将提供一种方法来管理和跟踪不同版本的服务器及其功能。这将帮助用户了解哪些版本发生了变化，并在需要时锁定到特定版本。
• 元数据管理：注册中心将托管有关 mCP 服务器的元数据，包括其功能（资源和工具），从而可能更容易理解如何与它们交互。

远程服务器和 MCP 协议中的 OAuth 2.0 集成。

远程服务器的意义：

• 目前，MCP 通常依赖于使用标准 IO 的本地或内存通信，这可能会在设置和部署方面带来麻烦。借助 SSE（服务器发送事件）等协议，远程服务器允许 MCP 服务器托管在公共 URL 上，从而可通过互联网访问。
• 这项开发无需用户了解 MCP 服务器托管或构建的复杂性。就像访问网站一样，用户或应用程序只需通过 URL 即可连接到远程 mCP 服务器。
• 远程服务器将 MCP 客户端（例如 AI 代理或应用程序）的位置与 MCP 服务器解耦，允许它们在完全不同的系统上运行。这增强了架构设计和部署的灵活性。
• 服务器可用性的提高将扩大通过 mCP 可访问的功能范围。

OAuth 2.0 集成：

• OAuth 2.0 的集成为mCP 客户端和远程服务器之间的身份验证和授权提供了标准化且安全的机制。
• MCP1 现在支持 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 服务器注册表支持的自我进化代理。

MCP服务器注册表允许代理动态地发现新功能和新数据，而无需从一开始就明确地用这些知识进行编程。这意味着代理在遇到新任务或需要访问先前未知的数据源时，可以主动寻找必要的工具来满足该需求。

以一个负责检查 Grafana 日志的通用编码代理为例。如果代理最初未配置 Grafana 服务器的具体配置，它可能会与MCP 注册表进行交互。通过搜索提供必要 API 的官方且经过验证的 Grafana 服务器，代理可以安装或调用该服务器（可能通过 SSE 远程执行，如前所述），并继续查询日志并解决错误。

自我进化代理的潜在优势：

• 增强的适应性：最显著的优势是代理增强了适应新情况和新任务的能力。它不再局限于预先编程的功能，而是可以根据需要学习和扩展其功能。
• 更广泛的应用范围：自我进化的代理可以处理各种各样的任务，而无需开发人员在初始设计和编程阶段预测每一种可能的情况。
• 提升用户体验：用户可以与更通用的代理进行交互，这些代理可以处理各种请求，甚至包括那些涉及代理未明确设计的系统或数据源的请求。代理将负责查找合适的工具。
• 持续改进：代理可以通过发现和集成注册表中可用的新的、可能更高效的工具和数据源，有效地“学习”并随着时间的推移不断改进。
• 降低开发开销：开发人员可以专注于构建代理的核心推理和任务执行逻辑，并依靠注册表来访问不断增长的功能生态系统。这减少了为每个潜在数据源或服务构建定制集成的需求。

关于自我进化代理的考虑：

• 治理与安全：一个关键的考虑因素是控制代理可以访问哪些服务器和功能。如果没有适当的安全措施，自我演进的代理可能会连接到不受信任甚至恶意的服务器，从而带来安全风险或数据隐私问题。正如 Mahesh 所提到的，诸如拥有已批准服务器的自托管注册中心、白名单和验证机制等方法对于降低这些风险至关重要。正如我们之前的讨论中所强调的，服务器信任的概念变得越来越重要。
• 信任与验证：确保已发现服务器的可靠性和可信度至关重要。mCP注册表旨在通过提供验证机制来解决此问题，并可能允许官方实体（例如 Shopify 或 Grafana）对其服务器进行“授权”。
• 性能与效率：动态发现和集成新服务器的过程可能会给代理的工作流程带来延迟。优化注册搜索和服务器集成流程至关重要。
• 工具选择与推理：尽管模型在工具使用方面越来越熟练，但仍然需要确保代理能够做出明智的决策，从注册表中海量的工具选项中选择合适的工具，并有效地利用它们。过多的选项可能会让代理不知所措，也可能是一个挑战。
• 调试和可观察性：随着代理变得越来越复杂，并且依赖于动态发现的组件，调试和监控其行为可能会变得更具挑战性。需要有清晰的机制来观察代理与注册表以及被调用服务器的交互。如前所述，服务器可调试性和客户端-服务器元数据通信的最佳实践将至关重要。
• 版本控制和兼容性：随着服务器的发展及其 API 的变化，需要在注册表中建立版本控制机制，以确保与现有代理的兼容性。代理可能需要了解不同的服务器版本，并可能需要处理兼容性问题。