【MCP协议】AI应用开发的标准化革命——「官方解读」模型上下文协议&Agent生态构建

MCP协议详解

原视频：Building Agents with Model Context Protocol - Full Workshop with Mahesh Murag of Anthropic

模型上下文协议（MCP） 由Anthropic应用AI团队的My Hair主导开发。本文将深入探讨 MCP的理念、Anthropic构建MCP的原因、MCP的早期应用、MCP在AI应用和Agent中的应用模式 以及未来发展方向。

MCP的动机：提升模型质量的关键因素——上下文

MCP的根本动因在于提升模型质量的关键因素——上下文。 虽然为AI助手提供上下文看似理所当然，但早期AI应用主要以聊天机器人为主，用户需手动复制粘贴或输入信息以提供上下文。

近年来，系统和模型能够直接访问用户数据和上下文，显著提升了AI应用的能力和个性化程度。 MCP应运而生，旨在成为一个开放协议，实现AI应用、Agent与用户工具及数据源的无缝集成。

MCP的背景与灵感

理解MCP需先回顾既有协议和系统。 应用程序编程接口（API） 的出现 标准化了应用前端与后端之间的交互方式，充当中间层，转换请求，使前端能够访问服务器、数据库和服务等资源。

语言服务器协议（LSP） 随后兴起，标准化了集成开发环境（IDE）与编程语言工具的交互方式。 LSP是MCP的重要灵感来源。兼容LSP的IDE可与各种编程语言功能交互，例如，构建Go LSP服务器后，任何兼容LSP的IDE都能利用其了解Go语言的特性。

MCP借鉴了API和LSP的思想，标准化了AI应用与外部系统的交互方式。 MCP主要通过 提示（Prompts）、工具（Tools） 和 资源（Resources） 三种核心接口实现。

MCP的价值

在MCP之前，AI系统构建领域存在显著的碎片化。不同团队在构建AI应用时，通常采用 自定义实现、自定义提示逻辑 以及 各异的工具和数据引入方式，导致 工具和数据的访问管理方式也各不相同。 这种碎片化现象不仅存在于不同公司之间，也存在于同一公司内部的不同团队之间。

无MCP：零散的AI开发	有MCP：统一的AI开发

MCP旨在构建一个标准化的AI开发生态系统。 MCP客户端（例如Anthropic第一方应用、Cursor、Winder、Goose等）可以通过 标准接口 连接到任何 MCP服务器，无需额外适配工作。

MCP服务器 充当 封装器，管理对各种系统和工具的访问，这些系统和工具与AI应用相关。 MCP服务器可以是 数据库、数据库、ES和记录的聚合、Salesforce等CRM系统，甚至是 本地笔记本电脑或系统上的资源（如版本控制和Git）。

MCP的应用价值体现在多个方面：

• 对于应用开发者： 一旦客户端兼容MCP，即可连接到任何服务器，无需额外工作。
• 对于工具或API提供商： 只需构建一次MCP服务器，即可在众多兼容MCP的AI应用中应用。
• 解决 N x M 问题： MCP 充当应用开发者与工具和API开发者之间的中间层，简化数据访问，最终用户将获得 更强大和上下文丰富的AI应用。
• 企业层面： 明确划分开发职责。数据基础设施团队可以将向量数据库等资源转化为MCP服务器，集中维护和发布API。公司内部其他团队可以 更快速地构建AI应用，无需重复沟通数据访问需求。 MCP 促进了 微服务架构 的应用，加速产品迭代。

MCP的应用场景

MCP在过去几年中得到了快速发展，应用场景广泛：

• 集成开发环境（IDE）和编辑器： 为IDE提供工作上下文，IDE中的Agent可以访问外部系统，如GitHub、文档站点等。
• 服务器端： 社区已构建约 100个开源服务器，许多公司也构建了自用服务器，并发布了官方集成。
• 开源社区： 大量开发者为核心协议和基础设施层贡献代码。

MCP的核心概念与组件

使用MCP构建应用的核心在于客户端与服务器的交互。

• MCP客户端：调用工具，查询资源，插值提示，并使用上下文填充提示供模型使用。
• MCP服务器：公开 工具、资源和提示，供连接的客户端使用。

工具（Tools）：模型控制

• 服务器向客户端应用暴露工具，客户端应用内的模型（LLM）决定何时调用工具。
• 工具类型广泛，包括 读取工具（检索数据）、写入工具（发送数据、执行操作）、数据库交互工具、本地文件系统写入工具 等。
• 服务器定义工具描述，模型根据描述选择最佳调用时机。

资源（Resources）：应用控制

• 服务器向应用暴露数据，应用决定如何使用资源。
• 资源类型包括 图像、文本文件、JSON文件 等，也可能包含服务器端操作记录。
• 资源为应用和服务交互提供超越纯文本的丰富接口。
• 资源用例包括：静态资源、动态资源（服务器根据客户端信息生成结构化数据）。
• 资源可以作为 附件 附加到聊天中发送给模型，也可 自动附加，由模型判断资源相关性并自动发送。

提示（Prompts）：用户控制

• 用户调用的工具，而非模型调用的工具。
• 预定义模板，用于用户与服务器的常见交互。
• 例如，在Zed IDE中，使用 斜杠命令 触发预定义的提示。 /GHPR 命令会展开为更长的提示，并发送给LLM进行处理。
• 其他用例包括：标准化的文档处理方式、格式规则、数据呈现方式 等。用户选择何时调用预定义的提示。

总结而言，MCP协议旨在通过标准化的接口，提升AI应用与外部系统集成的效率和效果，最终构建更强大、上下文更丰富的AI应用生态系统。

提问环节一：MCP设计与架构讨论

问题：为什么资源不由模型控制，而工具由模型控制？

回答： MCP旨在丰富应用与服务器的交互方式，而不仅是提升模型性能。 工具由模型控制，旨在清晰划分 模型控制 和 应用控制 的界限。 兼容MCP的应用可以基于预定义规则或非LLM决策，决定何时将资源纳入上下文。 MCP的目标是在客户端和服务器构建者之间，明确区分哪些操作应由模型调用，哪些应由应用调用。

问题：工具是向模型暴露数据库的最佳方式吗？

回答： 工具适用于需要决策何时调用的场景。 例如，当需要判断LLM何时应访问向量数据库，何时已有足够上下文信息，或何时需要与用户交互以获取更多信息时，工具非常有效。 如果访问是预先确定的，则可能无需使用工具，直接调用即可。

问题：如果使用Agent框架，是否可以将MCP封装在工具中？ MCP如何与Agent框架配合使用？

回答： MCP与Agent框架是互补的。 LangGraph等Agent框架已发布连接器/适配器，可以将LangGraph Agent连接到MCP服务器。 现有Agent系统可以通过安装适配器，将MCP服务器暴露给Agent，无需修改系统本身。 MCP不会取代Agent框架，而是让以标准方式向Agent暴露服务器、提示和资源变得更简单。

问题：工具是否可以调用另一个工具？

回答： 可以。 框架可以调用通过适配器从MCP服务器暴露的工具，而该工具本身也可以是另一个工具。

问题：MCP是否取代了Agent框架？ 为什么还要使用Agent框架？

回答： MCP不取代Agent框架。 MCP可能取代了Agent框架中与上下文引入、工具调用和相关处理的部分。 Agent框架的价值主要体现在知识管理、Agent循环、以及Agent如何响应工具引入的数据。 Agent框架在 定义LLM如何在循环中运行，以及 如何决策何时调用工具和访问其他系统 方面仍然具有重要价值。 MCP更专注于成为将上下文引入Agent或Agent框架的标准层。

问题：资源和提示的目的是什么？ 为什么不都使用工具？

回答： MCP中的资源和提示可以是动态的。 它们可以根据用户或应用的上下文进行解释，服务器可以返回 动态或定制的资源或提示。 资源通知 功能允许客户端订阅资源，服务器在资源更新时通知客户端。 MCP不仅是为了给模型提供更多上下文，更是为了给应用提供更丰富的与服务器能力交互的方式。 提示可作为服务器向用户提供访问权限的标准方式，例如，提供用户与服务器交互的五步计划提示。 MCP旨在为系统的不同部分提供更多控制权，包括模型控制、应用控制和用户控制。

演示环节：MCP的应用展示

Claude for Desktop 演示

演示展示了 Claude for Desktop 作为 MCP客户端 的实际应用。 用户在Claude for Desktop中指示其处理 GitHub 应用中的 Anthropic SDK 仓库任务，并要求 Claude 从仓库中拉取 issue 并进行分类。

Claude 自动 判断并调用 list issues 工具，从 GitHub 服务器获取 issue 列表，并将结果置于上下文中进行总结。 用户进一步指示 Claude 对优先级最高的前三个 issue 进行分类，并添加到 Asana。 Claude 在未被告知 Asana 项目名称的情况下，自主调用 list workspaces 和 search projects 工具，找到目标项目，并将 issue 作为任务添加到 Asana 中。

关键点：

• 社区构建的 MCP 服务器的应用： 演示中使用的 GitHub 和 Asana 服务器均为 社区构建，代码量小，主要功能是 向服务器公开工具，构建成本低。
• 工具的协同工作： Claude for Desktop 能够 协同利用多个 MCP 服务器提供的工具 完成复杂任务。
• 上下文的中心仪表板： Claude for Desktop 成为用户 引入生活上下文的中心平台，用于管理日常工作。 Anthropic 内部也使用类似系统访问 Arctic 仓库，创建 PR 等。
• MCP作为标准层： MCP是实现上述功能的标准底层协议。

Winder 和 Goose 应用

除了 Claude for Desktop，Winder 和 Goose 等应用也展示了 MCP 的应用。 Winder 拥有自身应用层和 UI，连接到 MCP 服务器，与 MCP 工具交互。 Goose 将 MCP 工具称为 “扩展”。 如何将上下文引入应用取决于应用本身，但 MCP 提供了一种跨应用实现此目的的标准方法。

MCP 作为 Agent 的通用基础协议

MCP 不仅用于引入上下文，更将成为 Agent 的通用基础协议。 Agent系统和模型能力的提升 与 MCP 的发展相辅相成。

增强型LLM与MCP

增强型LLM 概念是构建有效Agent的核心。 增强部分 包括 检索系统、工具和记忆，使 LLM 能够 查询和写入数据、调用工具、响应工具结果、并 保持状态。

MCP 可以作为增强型 LLM 的底层协议，促进和简化 LLM 与检索系统、工具和记忆的交互，并以 标准化方式 实现。 Agent构建者无需预先构建所有功能，Agent可以在运行过程中 扩展能力，发现与世界的不同交互方式。

Agent系统的简化

Agent系统本质上是 增强型 LLM 在循环中运行。 MCP 以开放方式为 LLM 或Agent提供增强能力。 Agent构建者无需预知Agent的所有需求，Agent可以在与系统和现实世界交互过程中 动态发现需求。 用户可以自定义并引入自身上下文。 Agent构建者可以专注于核心循环、上下文管理、记忆使用和模型选择，而 MCP 负责与外部世界的交互。

MCP Agent 演示

MCP Agent 是 LastMile AI 构建的开源框架，演示了Agent系统与 MCP 的协同工作。

演示应用：研究量子计算

演示应用旨在让Agent 研究量子计算对网络安全的影响，并生成研究报告。 通过 MCP Agent 框架，定义了三个Agent：

1. 研究Agent (Research Agent)： 任务是 “作为专家级研究员上网查找信息，访问权威资源，并以 Markdown 格式返回数据”。 权限：Brave 浏览器（网络搜索）、Fetch 工具（拉取数据）、文件系统。
2. 事实核查Agent (Fact-Checking Agent)： 任务是 “验证来自研究Agent的信息”。 权限：Brave 浏览器、Fetch 工具、文件系统。
3. 研究报告撰写Agent (Research Report Agent)： 任务是 “综合数据，查看参考文献和事实核查结果，生成格式良好的报告”。 权限：文件系统、Fetch 工具。

关键点：

• MCP 作为抽象层： Agent构建者专注于 Agent任务和Agent与周围系统的交互，无需关注服务器、工具和数据本身。
• 声明式配置： 通过简洁的声明式方式定义Agent任务和可用的服务器/工具。
• 动态计划生成： MCP Agent 基于Agent任务和可用服务器，动态生成执行计划。
• 社区构建的服务器的利用： 演示中利用了社区构建的 Brave 浏览器和 Fetch 工具服务器。

演示结果：

启动 MCP Agent 后，系统自动进行研究，调用搜索Agent和事实核查Agent，并开始生成研究报告。 MCP Agent 使Agent构建者能够专注于Agent循环和核心能力，而非服务器能力和上下文提供。

提问环节二：MCP的实践与应用

问题：Agent系统是否适用于专有数据？

回答：MCP的开放性使其能够应用于专有数据。 MCP服务器可以在VPC内部运行，支持企业员工和个人系统的数据访问。

问题：将Agent本身与其能力分离的意义是什么？

回答：分离关注点，提升Agent系统开发效率和灵活性。 Agent开发可以专注于：

• 模型选择： 根据任务选择合适的模型，例如编码任务可选用Claude。
• 上下文/知识管理： 优化上下文存储和总结策略。
• 编排系统： 设计高效的Agent协同方式，例如串行或并行多Agent。
• 用户界面： 优化用户交互体验。

MCP的价值在于连接外部系统和扩展上下文。 企业可以构建定制化的MCP服务器，同时利用MCP生态系统中已有的通用服务器，无需重复构建连接外部系统的基础设施。

问题：人们是否真的在使用MCP？还是只是理论？

回答： （将在后续幻灯片中解答）

问题：MCP Agent框架的特别之处是什么？

回答：MCP Agent框架结合了Agent框架的兴起和MCP简化上下文引入的优势，提供构建Agent的组件和构建块。

• Agent概念： MCP Agent框架中的 Agent是增强型LLM在循环中运行的实体，框架负责循环管理、底层LLM交互等。
• 编排器工作流： 支持将Agent以复杂方式组合，例如 编排器Agent 负责规划和跟踪子Agent任务。
• 独特价值： 提供构建Agent的 组件化和模块化方法，降低Agent开发复杂性。

问题：资源和提示在这个例子中如何应用？

回答：本演示侧重于工具，资源和提示更多应用于用户交互环节。

• 资源的应用： 用户界面可以利用资源 呈现Agent的运行状态和结果，例如将计划步骤作为资源在UI侧边栏展示。
• 提示的应用： 提示可用于用户与Agent的交互命令，例如斜杠命令 /summary 触发服务器预定义的摘要提示，为用户生成任务总结。

问题：引入工具是否会带来新的评估挑战？

回答：评估方法与现有方法基本相同。 MCP甚至可能成为评估的标准层，例如创建MCP服务器暴露通用工具集，供不同评估系统使用。 MCP可以标准化工具接口，方便评估系统进行工具调用评估。

问题：客户端和服务端之间的逻辑分离在哪里？例如重试逻辑、身份验证等应该放在哪里？

回答：逻辑分离的关键在于服务端承担更多责任。

• 服务端职责： 重试逻辑、身份验证等业务逻辑应主要放在服务端。 服务端更接近底层系统，更适合控制系统交互细节。
• 客户端职责： MCP客户端应尽可能轻量化，无需预先了解服务器细节。 客户端主要负责按照MCP协议与服务器交互。
• Agent框架位置： Agent框架的位置取决于具体需求，服务端和客户端均可部署Agent框架。 服务端部署可以更好地控制业务逻辑，客户端部署可能更灵活。

问题：暴露给LLM的服务器数量是否有最佳实践或限制？

回答：当前模型可有效处理50-100个工具。 Claude最多可处理数百个工具。 超过一定数量，需要考虑工具管理和暴露策略。

• 工具搜索工具： 对工具进行RAG，实现模糊搜索或关键词搜索，方便模型快速找到所需工具。
• 工具分层系统： 分组管理工具，根据任务逐步暴露工具组，避免上下文过载。

工具数量本身没有技术限制，关键在于如何有效管理和利用大量工具。

问题：构建MCP服务器的最佳实践步骤是什么？

回答：构建MCP服务器非常容易。 最佳实践步骤：

1. 从工具开始构建。
2. 逐步添加提示和资源。
3. 参考 官方文档 和 示例服务器。
4. 利用 Claude等LLM辅助构建。

问题：如果服务器很简单，LLM是否可以自动生成服务器？

回答：可以。 Cursor等IDE客户端已实现MCP服务器自动生成工具。 适用于简单的API封装器服务器。 复杂服务器可能需要手动开发。

问题：你们是否与服务的实际所有者合作？

回答：是的，正在与服务所有者合作。 部分服务器已由官方发布，例如Cloudflare、Write等公司的官方集成。 正在与更多大型公司洽谈合作。

问题：如何进行版本控制？

回答：使用包版本控制。 MCP服务器通常发布为TypeScript包或Python包，自带版本信息。 版本更新应平滑过渡，避免破坏性更改。 MCP协议的灵活性允许服务器演变，即使服务器发生变化，系统仍能保持基本功能。 未来MCP注册表将有助于版本控制管理。

实用协议功能：高级特性

前文讨论了构建有效Agent的方法和 MCP Agent 框架的应用。 现在深入探讨与Agent系统相关的 实用协议功能。 这些功能尚处于早期阶段，应用方式仍在演变中。

采样 (Sampling)：强大的推理请求功能

采样是 MCP 最强大但未被充分利用的功能之一。 采样允许 MCP 服务器向客户端请求补全 (Completion) 推理调用。 服务器无需自身集成 LLM 或进行推理计算。

传统模式： 客户端与用户交互，客户端调用服务端功能。

采样模式： 服务器在需要更多用户输入时，可以向客户端请求 LLM 推理能力。 例如，服务器可以生成问题，请求客户端使用 LLM 向用户提问以获取信息。

采样的优势：

• 服务器具备智能： 服务器无需集成 LLM，即可利用 LLM 的智能。
• 请求联邦化： LLM 托管权和模型选择权归客户端。
• 服务器可指定推理参数： 模型偏好、系统/用户提示、温度、最大 token 数等。
• 客户端控制权： 客户端可 接受或拒绝 服务器的采样请求，保障隐私、控制成本，并限制请求数量。

采样的核心价值： 服务器无需自身集成 LLM，即可利用 LLM 的智能。 这符合 MCP 的设计原则，即服务器无需客户端预先了解细节，仍能请求智能服务。采样在Agent应用中至关重要。

组合顺序 (Composition Order)：构建分层系统架构

组合顺序是另一个关键构建块。 MCP 客户端和服务端是逻辑分离，而非物理隔离。 任何应用、API 或Agent都可以同时作为 MCP 客户端和 MCP 服务器。

链式调用示例：

用户与 Claude for Desktop (客户端) 交互 -> Claude for Desktop 调用研究Agent (客户端/服务器) -> 研究Agent调用文件系统服务器、Fetch 服务器、Web 搜索服务器等 (服务器) -> 数据处理和结果返回。

组合顺序的优势：

• 构建复杂分层系统架构： 每层专注于特定任务。
• 适用于Agent场景： 构建多层Agent协同系统。

提问环节三：MCP的进阶应用与考量

问题：复杂系统多层嵌套，如何处理复合错误？

回答：错误处理方法与复杂Agent系统相同，MCP 并未增加难度。 每层Agent系统负责信息处理和数据结构控制。 中间客户端-服务器节点需收集子节点响应，确保数据结构符合预期，再向上层传递。 MCP 为每层之间提供清晰接口，错误处理仍需在各层Agent系统中实现。

问题：为什么节点必须是 MCP 服务器，而不是普通 HTTP 服务器？

回答：MCP 协议内置协议功能，增强节点间交互能力，超越简单数据传递。

MCP 的优势功能：

• 资源通知
• 服务器到客户端通信
• 服务器向客户端请求信息 (采样)

MCP 支持更复杂的交互模式，例如，Agent间任务委派、数据请求、多次外部交互等。 将服务转换为 MCP 服务器，可将其视为具有自主性的Agent，而非单纯的数据暴露。

问题：谁控制速率限制？

回答：速率限制应联邦化，由客户端控制，因为 LLM 位于客户端层。 客户端可控制与 LLM 的交互方式和速率。 服务端理论上也可以控制，但示例场景中，客户端应用层控制速率和流量。

问题：如果需要用户输入，是否必须一直传递到最顶层？

回答：MCP 允许交互在层级间传递，支持将用户输入请求传递回顶层，再向下传递。

问题：如何实现决策的网络化？

回答：决策网络化取决于系统设计，MCP 协议本身不限制网络系统或逻辑。 MCP 只是为构建此类架构提供可能。

问题：如何实现可观测性？如何了解正在调用的其他系统？

回答：MCP 协议本身未规定可观测性实现方式。 应用层或用户层理论上无需了解服务器细节，系统可作为黑盒运行。 可观测性取决于系统构建者，需要了解交互过程。

问题：如何调试 MCP 服务器？特别是复杂服务器？

回答：MCP 协议未强制规定可观测性和交互方式。 服务器构建者有动力暴露有用数据以方便调试。 MCP 支持客户端和服务端之间传递元数据。 构建具备良好调试功能的服务器更有利于用户使用。 可借鉴 API 最佳实践：提供调试器、日志等。 可观测性最佳实践仍在发展中。

问题：这是否类似于微服务架构？

回答：非常相似，MCP 可视为嵌入智能的微服务架构。 可借鉴微服务在可观测性和追踪方面的模式。

问题：客户端是否可以控制或影响服务器行为？例如限制网页浏览数量？

回答：可以通过提示或工具注解实现客户端对服务器行为的控制。

• 提示： 通过提示指示服务器行为。
• 工具注解： 在工具调用中添加额外参数或元数据，影响服务器行为。 例如，限制工具使用次数、返回结果数量等。 未来可能在协议标准中添加标准字段支持工具注解。 例如，工具类型注解（“读取” vs “写入”）。

问题：如何进行调试？例如查看日志并响应错误？

回答：可以使用 Inspector 工具查看日志，确保服务器连接正常。 Inspector 已支持 MCP 授权。 也可以构建 调试服务器的服务器。

问题：关于治理和安全，谁来决定客户端可以访问什么？

回答：大部分应由服务器构建者控制。 授权是重要组成部分，协议应提供默认授权和身份验证方式。 服务器构建者负责控制客户端访问权限，防止恶意客户端滥用。

问题：结合采样和组合顺序，Agent的未来会是怎样的？

回答：采样和组合顺序的结合将推动分层Agent系统的发展。 用户与应用/聊天机器人 (编排Agent) 交互，编排Agent作为 MCP 客户端，与分析Agent、编码Agent、研究Agent等其他 MCP 服务器交互。 通过采样和组合顺序，构建多层Agent系统，实现功能模块化和协同工作。 部分Agent可部署在公共网络，部分保持私有，实现隐私、安全和控制的平衡。

注册表与发现：生态建设

目标：建立连接层，保证用户对交互的控制。

MCP 的发展现状与未来展望：

• MCP 应用于Agent
• 实用协议功能持续演进
• 远程服务器与授权 (OAuth) 功能推出

远程服务器与授权 (OAuth) 功能

Inspector 应用已支持授权功能，并加入协议和 SDK，即将全面推广。

授权流程：

1. MCP 服务器提供 URL (SSE)。
2. 客户端连接服务器，触发授权流程。
3. 服务器处理 OAuth 2.0 握手，连接 Slack 等服务，获取回调 URL。
4. 服务器将回调 URL 提供给客户端。
5. 客户端在浏览器中打开 URL，用户完成 Slack 授权。
6. 服务器持有 OAuth 令牌，并通过会话令牌管理后续交互。

远程服务器与授权的意义：

• 实现远程托管服务： 服务可部署在公共 URL，易于发现。
• 简化服务部署和使用： 无需用户了解 MCP 细节，降低使用门槛。
• 服务器完全控制交互和请求： 远程托管服务器可独立运行，Agent和 LLM 可位于不同系统。
• 促进服务数量增长： 降低复杂性，提升易用性。

提问环节四：注册表与生态系统展望

问题：OAuth 是否允许作用域控制？例如逐步增加权限？

回答： OAuth 初始版本尚不支持作用域提升，但未来会考虑发展 OAuth 支持。

问题：服务器持有 OAuth 令牌是否安全？

回答： 服务器持有 OAuth 令牌是合理的，因为服务器更接近终端应用 (如 Slack)，更适合控制与终端应用的交互。 职责分离有助于安全管理。

问题：连接服务器时是否需要谨慎？

回答： 需要谨慎对待连接的服务器，服务器信任度至关重要。 注册表将有助于提升服务器的可信度。

问题：MCP 如何与 REST API 配合使用？

回答： MCP 在 REST API 交互之上进行数据转换或添加逻辑时尤其有用。 例如，数据格式化、上下文量控制 等，使数据更适合 LLM 使用。 MCP 更侧重于进程和可操作的工具，而 REST API 更适合无状态数据交互。

问题：当服务器更改、工具描述更改时，如何处理版本控制和评估？

回答： 注册表将与版本控制相关联，支持版本固定和变更测试。 MCP 简化了版本控制，但评估体系与之前类似，MCP 并未改变评估的必要性，只是简化了评估流程。 例如，可以针对评估框架运行不同版本的 MCP 服务器并提供差异报告。

OAuth 支持已在开发分支中，Inspector 已完全实现 OAuth 支持，即将正式发布。

注册表

问题：当前 MCP 生态系统面临的最大问题是缺乏中心化的服务发现和获取方式。

解决方案：开发官方 MCP 注册表 API。

MCP 注册表 API 特点：

• 统一、托管的元数据服务，由 MCP 团队拥有和维护。
• 开放构建： 模式开放，开发过程公开透明。
• 托管服务： 提供稳定可靠的服务。
• 包管理系统集成： 兼容 NPM、PyPI 等包管理系统，未来将支持更多系统。
• 解决服务发现问题： 提供协议、连接方式、安全性、可信度、官方验证等信息。
• 简化 MCP 服务器迁移： 方便现有 MCP 服务器生态系统迁移到注册表。
• 版本控制： 支持注册表自身的版本控制，记录 API、工具、工具描述等变更。

注册表的目标：解决 MCP 服务可发现性问题，提升生态系统易用性和可管理性。

提问环节五：总结与未来展望

问题：公司是否可以在注册表上托管私有服务器？

回答： 注册表支持公共和私有服务器托管，类似 Artifactory。 注册表 API 可集成到 Cursor、VS Code 等应用市场。

问题：注册表是否只支持 NPM 包？

回答： 不限于 NPM 包，只需提供可信 URL 和身份验证信息即可。

问题：如何进行工具的执行和构建？

回答： （提问者意指工具的呈现和构建方式）

问题：是否可以使用 Docker 镜像来分发服务器？

回答： 可以使用 Docker 镜像分发服务器。 Docker 也提供类似服务列表的镜像服务。 服务器也可以完全远程托管，只需发布 URL。

问题：是否考虑过支付和权限边界？

回答： 尚未考虑支付。 权限边界 (谁可以安装或查看服务) 仍在探索最佳实践，MCP 团队没有权威答案。

MCP 的理念： 开源开放，构建最佳 MCP 客户端，但鼓励竞争和合作，与其他模型提供商合作，共同推动 MCP 生态发展。

问题：是否可以轻松地更换底层模型？

回答： 更换底层模型非常容易，MCP 本身没有模型限制。 Claude 与 MCP 配合良好是因为 Claude 本身在工具和Agent方面具有优势，而非 MCP 限制模型选择。

问题：如何考虑服务器更主动地或发起与客户端的连接？

回答： 正在考虑服务器发起连接的功能。

• 已实现：服务器发起的资源更改通知。
• 计划实现：服务器主动发起采样请求。 例如，服务器自主决策并主动联系客户端发起交互。

服务器主动联系客户端的应用场景： 系统自主决策、事件驱动、服务器接收到外部请求等。 服务器本身也可以是客户端，拥有自己的 LLM，发起连接。

问题：中心化 SSE 与去中心化 STS 的指导原则是什么？

回答： MCP 是传输无关的。 本地/内存通信使用中心化 SSE，远程通信使用去中心化 STS 是目前合理的模式。 用户可以构建自定义传输方式。

问题：模型是否必须在循环中才能与服务器交互？

回答： 否，客户端应用可以确定性地调用服务器暴露的标准 API (例如 call tools, list tools, call resources, services 等)。

问题：是否允许多个工具互相调用？

回答： 目前协议没有内置工具互相调用的方式。 交互通常需要回到客户端。 MCP 具有灵活性，理论上可以实现工具互相调用，但并非首要功能。

总结与展望：MCP的未来发展

注册表与发现的价值

MCP 服务器注册表的建立，核心价值在于赋能Agent的自我进化能力。 注册表不仅提供组织和验证功能，更重要的是，它使Agent能够动态发现和获取新的能力与数据，无需在初始化阶段进行预编程。

Agent的自我进化示例

假设一个通用编码Agent，熟悉用户工作习惯和常用系统，并具备优化的控制流程。 当用户指示 “修复微服务 final-ox 的 bug” 时，即使Agent最初不了解 Grifoni 服务器，它也能通过以下步骤实现任务：

1. 访问注册表，搜索 “Grifoni”。
2. 发现并验证 Grifoni 服务器，该服务器提供对目标仓库的访问权限。
3. 安装或调用 Grifoni 服务器 (可能位于远程服务器，通过 SSE 连接)。
4. 执行查询并修复 bug。

关键意义： Agent通过注册表实现工具的动态发现与选择，无需预先配置，从而实现自我进化。 这将显著增强 增强型 LLM 系统 的能力，Agent能够自主扩展功能，提升自身上下文感知能力。

提问环节六：总结与未来展望

问题：如何强制控制对任意服务器的访问？

回答：可以通过多种机制强制控制服务器访问，借鉴 Artifactory 的模式：

• 策划注册表： 标记批准和未批准的服务器。
• 白名单机制： 维护允许访问的服务器白名单，并设置工具进行访问控制和过滤。
• 验证机制： 注册表提供服务器验证功能，例如官方 Shopify 服务器、Cloudflare 服务器等，类似于 Artifactory 和企业工具的模式。

问题：注册表何时推出？

回答：注册表即将推出，具体日期尚未确定，但预计不会太久。

问题：你是否信任Agent能正确使用工具？

回答：从功能角度，信任Agent能够正确选择工具。 但在服务器可信度方面，由于注册表和验证机制尚不完善，目前信任度有限。 总体而言，模型在从数百个工具中选择合适工具方面表现良好。

.well-known 的服务器发现机制

.well-known 机制是对注册表的补充，提供另一种服务器发现途径。 例如，shopify.com/.well-known/mcp-services.json 可以提供 Shopify 提供的 MCP 端点信息，包括资源、工具、功能以及 OAuth 2.0 身份验证方式。

应用场景： 当用户明确指示Agent与特定域名 (如 shopify.com) 交互时，Agent可以检查该域名的 .well-known 路径，以验证方式发现该域名提供的 MCP 服务及其使用方法。

.well-known 与注册表的互补性：

• 注册表： 侧重于从零开始的通用工具发现和验证。
• .well-known： 自顶向下，适用于已知目标域名下的服务发现。

计算机视觉与 MCP 的结合

计算机视觉与 MCP 结合，为 UI 交互带来新的可能性。 Anthropic 的计算机视觉模型 (包括通用模型) 支持与无 API 的 UI 进行交互。

结合应用场景：

• .well-known 机制可用时： Agent可调用 .well-known 中预定义的 API 与目标网站交互。
• .well-known 机制不可用时 (长尾场景)： 利用计算机视觉，Agent可以模拟用户操作，点击 UI 元素、登录、与页面交互。

未来趋势： 将计算机视觉与 MCP 结合，在一个Agent系统中融合两种交互模式，提升Agent的通用性和适应性。

中期发展方向

以下是 MCP 中期发展方向，大致按优先级排序：

• 有状态与无状态连接： 当前 MCP 服务器连接保持状态。 未来考虑支持 更短生命周期的无状态连接，允许客户端断开连接后重新连接并恢复上下文，无需重新身份验证。 可能在基本功能 (客户端请求服务器) 和高级功能 (服务器请求客户端，如采样、通知) 之间实现二元性，高级功能使用长连接 (如 SSE)，基本功能使用短生命周期 HTTP 请求。
• 数据流式传输： 研究 协议层面的数据流式传输支持，允许数据分块、逐步从服务器传输到客户端。
• 命名空间： 解决多服务器同名工具冲突问题。 注册表将部分解决此问题，协议层面也考虑支持命名空间，允许创建预打包的工具逻辑组 (如特定金融服务工具包)。
• 主动服务器行为与征求用户反馈： 支持服务器事件驱动的主动行为，允许服务器主动向用户请求信息或发送通知。 探索更优模式并在协议中实现。