Anthropic在2024年11月发布了MCP（模型上下文协议）详情请见此处。
这是由 Mahesh Murag 在 Anthropic 开发的。请参阅完整官方文档。目前，MCP 目前已完全实现为Python SDK 和 TypeScript SDK。
Mahesh Murag（https://x.com/MaheshMurag）在AI工程师峰会期间做了精彩的关于‘用模型上下文协议构建代理’（https://www.youtube.com/watch?v=kQmXtrmQ5Zg）的工作坊。
背景才是关键生成式AI模型的基本能力受到其预训练过程、训练数据和模型架构的影响。为了让这些预训练模型更好地为你服务，并提高它们与你任务的相关性和连贯性，你需要给它提供一个良好的环境。
这里，上下文指的是模型生成相关且连贯回复所依赖的信息。上下文决定了模型如何理解并继续对话，完成文本或生成图像。
上下文可以通过不同的方式提供，具体如下：这主要取决于模型的类型和任务。
- 基于文本的模型（比如GPT、DeepSeek、LLaMA）通过以下方式获取上下文信息：
- 提示上下文：引导模型回复的输入文本或查询内容。
- 令牌窗口：模型一次可以处理的令牌数量（例如，GPT-4-Turbo 可以处理 ~128K 个令牌）。
- 对话历史：在聊天机器人中，之前的对话有助于在多轮对话中保持上下文。
- 基于检索的生成（RAG）：从外部文档动态检索上下文以改进回复内容。
2. 图像和多模态的模型（例如，DALL·E，Gemini）会通过以下方式接收上下文：
- 文本描述：提示引导图像生成。
- 视觉上下文：如果提供了一张图片，模型会先分析其内容，然后再生成新的元素。
- 跨模态上下文：当结合文本和图像时，模型会理解两者以生成有意义的输出。
- 代码生成模型（如 Codex 和 DeepSeek-Coder）是通过以下方式接收上下文的：
- 之前的代码块：上下文包括当前代码、函数名和注释。
- 编程语言语法：模型理解特定语言的语法结构。
- 外部文档：某些模型会利用API或文档来提供更准确的建议。
4. 语音和音频模型（例如，Whisper，AudioPaLM）通过输入的上下文接收信息：
- 音频片段：之前的讲话或音乐将告知接下来生成的部分。
- 语言和声学特性：音调、速度和语调都会影响转录和生成的过程。
简单来说，上下文是使生成式AI生成相关且连贯输出的关键因素。上下文管理得越好，AI的表现就越出色。
随着时间的推移，AI 模型可以自动获取数据作为上下文。这尤其适用于 AI 代理，它们的核心是生成式 AI 模型。这意味着 AI 代理需要搜索数据源，请求特定数据等。
点击此处访问Anthropic公司关于构建有效代理的工程页面：https://www.anthropic.com/engineering/building-effective-agents
每个数据源（服务器）都以自己的方式实现（例如，作为另一个代码库中的开源包——而不是提供可以被任何人使用的消息接口。或者它们可以实现为 JSON RPC 消息）。因此，AI 模型（客户端）没有统一的方式来寻找和请求数据。（碎片化现象。）
在MCP之前，构建AI系统通常包括：
- 为每个AI应用都需要定制实现以适应其所需的上下文，导致了大量的重复工作负担。
- 不同的提示逻辑和访问及集成工具及数据的方法不一致。
- “N乘M”问题，即大量客户端应用需要与大量服务器和工具进行交互操作，导致了一个复杂的集成网络，每个集成都需要特定的开发工作。
因此，MCP 给软件应用提供了一个标准的方式来。
- 与语言模型共享上下文
- 让AI系统使用工具和能力
- 构建可组合的集成和工作流程
这个协议通过JSON-RPC 2.0消息来建立通信之间：
- 发起连接的LLM应用：发起连接的LLM应用程序
- 客户端应用：主机应用程序内的客户端应用
- 服务器：提供上下文和功能的服务器
有许多流行的AI工具支持MCP，其中一些包括：
- Cursor
- Windsurf (Codium)
- Cline (VS Code 插件)
- Claude 桌面应用
- Claude 代码工具
MCP 借鉴了 语言服务器协议，该协议标准化了如何在开发工具生态系统中添加对编程语言的支持方式。以类似的方式，MCP 标准化了如何将额外的上下文和工具整合进 AI 应用程序的生态系统中。
MCP的架构
MCP 采用的是客户端-主机-服务器架构，即每个主机都可以运行多个客户端程序连接到服务器。
- 此架构让用户可以在应用程序间集成AI能力，同时确保安全边界的清晰性，并隔离不同方面的关注。
- MCP基于JSON-RPC，提供了一个侧重于客户端与服务器之间上下文交换和采样协调的状态会话机制。
模型上下文协议规范页面: https://spec.modelcontextprotocol.io/specification/2024-11-05/architecture/
主持人主进程，既担任容器又起协调作用：
- 创建和管理多个客户端实例
- 管理客户端连接权限和生命周期
- 实施安全策略和同意要求
- 处理用户授权决定
- 协调AI/LLM的集成和采样过程
- 管理跨客户端的上下文
每个客户端程序都是由主机创建的，并保持一个独立的服务器连接状态。
- 为每个服务器建立一个状态会话
- 处理协议协商和能力交换
- 双向传递协议消息
- 管理订阅和发送通知
- 维护服务器间的安全边界
应用程序会作为主机，创建并管理多个客户端应用，每个客户端应用都一对一地连接到特定服务器。
MCP 客户端主要指的是那些希望访问外部系统、工具或数据源的 AI 应用程序或代理。这些应用程序或代理包括 Anthropic 的第一方应用 Curser 和 Windsurf，以及代理 Goose。最关键的是它们的 MCP 兼容性，这意味着它们能够根据协议定义的标准接口进行通信：提示、工具和其他资源。
一旦MCP客户端软件兼容，它可以连接到任何MCP服务器，几乎不需要做任何额外工作。客户端负责调用工具，查询资源，并插入提示。
在工具的上下文中，客户端应用内的语言模型 决定了何时调用由服务器暴露的工具最为合适。对于资源，客户端应用程序决定如何使用服务器提供的数据。提示被视为用户通过客户端应用调用的工具，由用户控制。
服务器服务器提供了特定的环境和服务。
- 通过MCP原语来暴露资源、工具和提示信息
- 独立运作并明确各自的职责
- 通过客户端接口请求采样数据
- 必须遵守安全限制
- 既可以是本地进程也可以是远程服务
MCP 服务器就像一个中介，帮助以标准方式访问各种外部系统、工具和数据源。MCP 服务器可以提供对数据库、如 Salesforce 这样的 CRM 系统、本地文件系统和 Git 等版本控制系统进行访问。服务器构建者的工作是将工具、资源和提示以任何兼容客户端可以使用的标准方式呈现出来。一旦构建了 MCP 服务器，它可以被 任何 MCP 客户端 所采用，通过减少个体化集成需求来解决“N 乘以 M”的问题。对于 工具，服务器定义可用的功能及其描述，让客户端决定何时使用这些工具。对于 资源，服务器不仅定义这些数据，还会根据需要创建或检索这些数据，以便向客户端应用展示。对于 提示，服务器提供一些预设模板，客户端应用可以代表用户触发这些常见的交互。
MCP协议充当这两个组件之间的通信桥梁，定义了请求和响应的格式及交换规则。这种分离带来了许多好处，因为它允许更灵活的组件交互。
- 无缝集成: 客户可以轻松连接到各种服务器，而无需了解每个系统的技术细节。
- 复用性: 服务器开发人员可以一次构建集成，让多个客户端应用都能使用。
- 职责分离: 不同的团队可以独立专注于开发客户端应用或服务器集成。例如，一个基础设施团队可以管理一个向量数据库的mCP服务器，该服务器可以被各种AI开发团队轻松使用。
本质上，MCP客户端与服务器之间的关系是一种标准的互动，客户端通过共同的MCP协议语言利用服务器提供的能力，这导致一个更高效、可扩展的人工智能应用和代理环境。
MCP 功能 MCP 服务器特性MCP 服务器提供了基本构建模块（提示、资源、工具），通过 MCP 向语言模型添加上下文。这些元素使得客户端、服务器和语言模型之间能够进行互动交流：
- 提示消息：预定义的模板或指令，用于引导语言模型的交互
- 提供额外上下文信息的结构化数据或内容：结构化数据或内容，为模型提供额外的上下文信息
- 执行功能，让模型能够执行操作或检索信息的工具：可执行的功能，允许模型执行操作或检索信息的工具
https://spec.modelcontextprotocol.io/specification/2024-11-05/server/
模型上下文协议（MCP）为服务器提供了一种标准的方式，以便让客户端能够访问提示、资源和工具。
提示信息（修订版：2024年11月5日）
提示信息允许服务器提供结构化的消息和指令来与语言模型互动。客户端可以找到并查看可用的提示，并用参数来自定义这些提示。
提示信息设计让用户能够控制，以便它们从服务器传给客户端，让用户能够明确选择使用。
通常，提示会通过用户在用户界面中发起的命令来触发，这允许用户轻松发现和调用可用的提示。例如，像通过输入 /help 这样的斜线命令。
支持提示功能的服务器 必须在 初始化时声明 prompts 功能：
https://spec.modelcontextprotocol.io/specification/2024-11-05/server/prompts/ 该链接指向模型上下文协议服务器端提示的规范。
资源：协议修订：2024年11月5日
资源允许服务器共享为语言模型提供上下文的数据，例如文件、数据库模式或架构，以及特定应用的信息。每个资源都通过一个URI标识。
MCP中的资源设计为以应用为中心，由应用程序根据自身需求决定如何使用上下文。
例如，应用程序可以做到的有：
- 让资源通过树状或列表视图供用户明确选择
- 让用户能够搜索和筛选可用资源
- 实现自动上下文包含功能，依据启发式算法或AI模型的选择
支持资源的服务器 必须 声明 resources 特性。
https://spec.modelcontextprotocol.io/specification/2024-11-05/server/resources/ （该链接指向模型上下文协议规范的服务器资源页面）
该功能具备两个可选选项。
subscribe：客户端是否能订阅收到单个资源更改的更新。listChanged：服务器在可用资源列表发生变化时是否会通知。
工具 — 协议更新：2024–11–05
MCP 允许服务器提供可以由语言模型调用的工具。这些工具让模型能与外部系统互动，比如查询数据库、调用 API 或进行计算。每个工具通过名称进行唯一标识，并包含描述模式的元数据。
MCP 中的工具被设计为 模型驱动，这意味着模型可以根据上下文和用户的指令自动发现并调用工具。不过，实现时可以根据需求自由选择任何适合的接口模式来展示工具。
支持工具的服务器必须声明tools能力标志：
https://spec.modelcontextprotocol.io/specification/2024-11-05/server/tools/ (模型上下文协议规范的服务器工具页面)
listChanged 用来表示服务器是否会变化时发送通知，当可用工具的列表发生变化时。
客户端可以添加更多功能来增强连接的MCP服务器：根及采样。
根源
- 根 定义了服务器在文件系统中可以操作的范围，让服务器知道它们可以访问哪些目录和文件。MCP 为客户端提供了一种标准方式，让它们能够向服务器展示文件系统的根。服务器可以从支持的客户端获取根列表，当列表更新时也会收到通知。
根定义包括如下：
uri: 根的唯一标识符。在当前规范中，这必须是一个file://URI。name：可选的人类可读的名字，用于显示。
不同用例的示例根：
访问此链接以查看详细信息：https://spec.modelcontextprotocol.io/specification/2024-11-05/client/roots/
取样（修订协议：2024年11月05日）
MCP 提供了一种标准方法，让服务器通过客户端请求大规模语言模型的抽样（“完成”或“生成”）。这种流程允许客户端保持对模型访问、选择和权限的控制，同时让服务器能够利用这些AI功能——无需服务器API密钥。服务器可以请求文本或图像相关的交互，并可在提示中选择性地包含来自MCP服务器的上下文信息。
MCP中的采样可以让服务器通过在其他MCP功能中的嵌套调用实现类似代理的行为，其中LLM调用可以嵌套在这些功能内。
实现可以自由选择通过任何适合其需求的接口来实现采样功能——协议本身并不规定任何特定的用户界面模式。
可组合性
- 在MCP中，客户端和服务器之间的区别是逻辑上的而非物理上的。也就是说，任何应用、API或代理都可以同时作为MCP客户端和MCP服务器运行。
- 这种双重身份允许构建多层次和链状系统。用户可能与一个主要代理（作为客户端）交互，该代理随后与一个专门的子代理（作为服务器）进行通信。这个子代理可以作为客户端并调用其他MCP服务器（如文件系统服务器或网络搜索服务器）来完成其任务。
- 与代理的相关性： 组合性对于构建高级别的模块化代理架构至关重要。它使得构建分层的代理架构成为可能，在这种架构中，不同的代理可以专门从事特定任务，并将子任务委托给其他代理。例如，一个编排代理可以接收一个高层次的目标，然后将其分解为更小的任务，并将这些任务委托给研究代理、编码代理或事实核查代理，每个代理既可以作为MCP服务器运行，也可以作为客户端访问所需工具和数据。这允许通过结合多个专业化代理的能力来构建复杂的流程和智能行为模式。它还允许重用和连接由其他人构建的代理，即使这些代理最初并非为主代理设计。
结合来看，采样和可组合性是高级AI代理的强大助力。它们使得以下成为可能：
改为：
结合来看，采样和可组合性是高级AI代理的强大助力。
- 智能在多代理系统中的分配方式，其中客户端控制实际的LLM互动，而服务器（代理）可以根据需要通过采样来请求这些功能。
- 构建复杂且多层次的代理系统架构，其中专门代理可以作为客户端和服务端协同工作。
- 在代理设计中增加更高的灵活性和模块化，因为新的功能（以mCP服务器的形式暴露）可以集成到现有的代理工作流程中。
- 通过与其他代理和服务以可组合的方式进行交互，代理可能进化和适应。
这些概念超出了单一的代理设计，转向了更为分布化、协作化且更具适应性的AI系统。
MCP 提供的一些额外功能：- 设置，进度追踪，取消操作，错误提示，记录日志
MCP 通过任意的数据访问和代码执行路径提供强大的功能。然而，伴随着这种强大的能力，所有开发者必须谨慎处理重要的安全和信任问题。
MCP 安全和信任的保障原则- 用户同意和控制权: 用户必须明确同意并理解所有数据访问和操作的内容。他们必须保留控制分享哪些数据以及采取哪些行动的权利。开发者或实施者应提供清晰的界面让用户审查并授权活动。
2. 数据隐私: 主机必须明确获得用户的同意后才能向服务器展示用户数据。未经用户同意，主机不得将资源数据传输到其他地方。用户数据应当受到适当的访问控制保护。
3. 工具安全： 工具代表执行任意代码，必须小心处理。计算机系统在运行任何工具前必须获得用户的明确同意。用户在使用工具前应了解每个工具的具体功能。
4. 大语言模型采样控制: 用户必须明确批准任何大语言模型采样请求。用户需要控制什么时候进行采样、发送的实际提示信息，以及服务器能看到的结果。协议有意限制服务器能查看到的提示内容。
实现指南：实现 MCP 时，开发者应遵循：- 在其应用程序中构建稳健的同意和授权流程
- 提供安全影响的清晰说明
- 实施适当的访问控制和数据保护
- 在其集成中遵循安全最佳实践
- 在功能设计中考虑隐私影响
MCP 是根据几个关键的设计准则构建的，这些原则指导了其架构和实现。
服务器搭建应该非常简单。
- 主机应用程序处理复杂的编排责任
- 服务器专注于特定和明确定义的功能
- 简单的接口减少了实现的负担
- 清晰的分离使代码更易于维护
2. 服务器应高度模块化
- 每个服务器都专注于提供单一功能。
- 多个服务器可以无缝集成。
- 共享协议确保了互操作性。
- 模块化设计支持扩展。
3. 服务器不应该能够读取整个会话，也不应该窥视其他服务器
- 服务器仅获取必要的上下文信息
- 完整的对话记录保存在主机端
- 每个服务器连接保持独立
- 跨服务器的交互由主机控制
- 主机进程强制实施安全边界
4. 功能可以逐步地添加到服务器端和客户端中
- 核心协议提供最基本的功能需求
- 可以根据需要添加额外功能
- 服务器和客户端各自独立发展
- 设计时就考虑到了未来的扩展性
- 保持向后的兼容性
MCP 定义了三种核心消息种类，基于 JSON-RPC 2.0：
- 请求：带有方法和参数的双向请求，期望收到响应
- 响应：匹配特定请求 ID 的成功结果或错误
- 通知：单向消息，无需回应
每个消息类型都遵循 JSON-RPC 2.0 规范中的结构和传递语义要求。
MCP中的能力协商机制MCP 使用基于能力的协商机制，在初始化时，客户端和服务器会明确声明其支持的功能。能力决定了会话期间可用的协议特性和操作。
- 服务器声明其能力，例如资源订阅、工具支持和应答模板
- 客户端声明其能力，例如采样支持和通知处理
- 双方在会话期间必须遵守彼此声明的能力
- 双方可以通过协议的扩展来协商其他的特性
每个功能都会在会话中解锁特定的协议特性，例如：
这种能力协商过程确保客户端和服务器清楚支持的功能性，同时确保协议的可扩展性。
https://spec.modelcontextprotocol.io/specification/2024-11-05/architecture/
MCP协议的基础信息修订协议 : 2024年11月5日
所有MCP客户端和服务器之间的消息都必须遵循JSON-RPC 2.0规范。该协议定义了三种基本的消息类型：
https://spec.modelcontextprotocol.io/specification/2024-11-05/basic/
响应分为两类：成功响应或错误。结果可以遵循任何JSON对象结构，而错误必须至少包含错误码以及错误信息。
协议层模型上下文协议（Model Context Protocol）由几个关键的组件组成，这些组件相互协作。
- 基本协议：核心 JSON-RPC 消息类型
- 生命周期管理：连接初始化、功能协商以及会话控制
- 服务器特性：资源、提示和工具
- 客户端特性：采样和根目录列表
- 实用工具：日志记录和参数补全等功能
所有实现必须支持基础协议和生命周期管理组件。其他组件可根据应用程序的具体需求来实现。
这些协议层清晰地划分了职责，同时使客户端和服务器之间能够进行丰富多样的互动。模块化设计使得实现可以仅支持所需的特性。
客户端-服务器连接的生命周期:
模型上下文协议（MCP）定义了一个严格的生命周期，用于客户端-服务器连接，确保能力协商和状态管理的正确性。
- 初始化：能力协商与协议版本协商
- 操作：正常的协议交互
- 关闭：优雅地关闭连接
生命周期的不同阶段:
- 初始化阶段： 初始化阶段一定得是客户端和服务器之间的第一次接触。双方需要完成初始化任务，在这个环节，客户端和服务器：
- 确定协议版本的兼容性
- 交换并协商各自的能力
- 分享具体的实现细节
客户必须通过发送一个initialize请求来开始这一阶段。
- 支持的协议版本号
- 客户端特性
- 客户端实现详情
服务器必须用它自己的能力和信息，包括相关详情，来回应。
成功初始化后，客户端必须发送一个initialized通知，表明它已经准备好开始正常的运作。在服务器还没有回应initialize请求之前，客户端不应该发送除pings之外的请求。在收到initialized通知之前，服务器不应该发送除pings和日志记录之外的请求。
2. 版本协商： 在 initialize 请求中，客户端 必须 发送其支持的协议版本。最好是客户端支持的 最新 版本。如果服务器支持客户端请求的协议版本，它 必须 用同样的版本回应。否则，服务器 必须 用它支持的另一个版本回应。最好是服务器支持的 最新 版本。如果客户端不支持服务器回复的版本，客户端 应该 断开连接。
3. 能力协商: 客户端和服务器通过协商来确定在会话期间将使用哪些可选协议特性。
主要的能力有：
查看这个链接：https://spec.modelcontextprotocol.io/specification/2024-11-05/basic/lifecycle/
能力对象可以描述次能力。
4. 操作: 在操作过程中，客户端和服务器根据协商的功能互相传递消息。
双方应该：
- 遵守商定的协议版本
- 只用那些成功谈妥的功能
5. 关闭： 在关闭过程中，一方（通常是客户端）会干净地终止协议的连接。并没有特定的关闭消息——而是应利用底层传输机制来结束连接。
stdio对于 stdio 传输，客户端 应当 通过以下方式发起关闭：
- 首先，关闭子进程（服务器）的输入流
- 等待服务器自行退出，如果在合理的时间内服务器没有退出，则发送
SIGTERM信号 - 如果在发送
SIGTERM信号后，服务器仍然没有在合理时间内退出，则发送SIGKILL信号
服务器可能通过终止与客户端的连接并退出来关闭。
6. HTTP: 对于 HTTP 连接来说，关闭相关的 HTTP 连接即表示关闭。
7. 错误应对: 实现应该准备好处理这些错误情况：
- 协议版本不匹配
- 所需功能协商失败
- 启动请求超时
- 关闭超时等待
实现应该为所有请求设置适当的超时，以防止阻塞连接和资源枯竭。
身份验证和授权目前还不属于核心MCP规范，但可能会很快被引入。
该协议的完整规范描述定义为一个[TypeScript]。这是所有协议消息和结构的唯一真实来源。
还有一个JSON Schema的版本，它是从TypeScript源代码自动生成的版本，适用于各种自动化工具。
MCP 协议的思维导图
MCP给利益相关方的好处 给应用开发者对于应用开发人员来说，MCP 提供了几个关键的重要好处。
- 无需额外工作即可连接到任何mCP服务器： 一旦应用程序是兼容MCP的，它可以连接到任何mCP服务器而无需额外的开发工作。这意味着开发人员无需为每个新工具或数据源编写特定的集成逻辑，从而大大减少了开发时间和工作量。
- 标准化接口： MCP通过其三个主要接口提示、工具和资源，标准化了AI应用程序与外部系统的交互方式。这提供了一种一致的方式来访问和利用不同服务器提供的功能，简化了开发流程，并使开发人员更容易理解和集成新功能。
- 访问广泛的生态系统： 通过构建MCP客户端，开发人员可以访问一个不断增长的生态系统，包括由社区开发和官方支持的MCP服务器。这使他们能够轻松地集成各种功能，例如访问数据库、CRM、本地文件系统等，而无需自己构建这些集成。即将推出的mCP注册API功能将进一步增强这一点，通过提供一种集中化的方式来发现和整合MCP服务器。
- 专注于核心应用逻辑： MCP允许应用程序开发人员专注于AI应用的核心逻辑和用户体验开发，而不是花费时间在与各种外部系统的集成复杂性上。协议处理底层通信和标准化，使开发人员能够专注于应用程序的独特价值主张。正如Mahesh所解释的，开发人员可以专注于“代理循环机制”和上下文管理，而MCP则处理引入上下文的标准方式。
- 利用模型智能进行工具使用： “工具”接口允许开发人员在应用程序中暴露功能给语言模型，使模型可以智能地决定何时调用这些工具。这减少了开发人员需要明确编程每个与外部系统的交互的需求，从而使应用程序更加动态和响应。
- 更丰富的用户交互体验： “资源”接口为服务器提供了一种方式，用以暴露不仅仅是简单文本的数据，例如图像和结构化数据。这使应用程序开发人员能够为用户创建更丰富和更具互动性的用户体验。
模型上下文协议（mCP）也为工具和API的提供者、实际使用者和企业带来了显著的优势
工具/API供应商:
- 提高采用率： 通过建立一个MCP服务器，工具或API提供商们可以看到他们的服务被广泛应用于各种MCP兼容AI应用程序。这消除了为每个客户端应用程序单独开发集成的需求，从而扩大了他们的潜在用户群体。正如马哈什所说，他们可以“建立一个MCP服务器一次，并看到它在所有这些不同的AI应用程序中被采用”。
- 简化集成： MCP为工具和数据通过提示、工具和资源接口向AI应用程序提供标准方法。这简化了应用程序开发人员与他们的服务集成的过程，使其更有可能被采用。
- 减少集成负担： 提供商不再需要处理为不同AI客户端构建和维护众多自定义集成的“N乘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服务器。
MCP 注册表 API 所要解决的关键挑战包括：
- 发现性: 当前，查找相关的mCP服务器比较分散。注册表将作为一个统一的相关元数据服务，使用户和应用程序更容易找到可用的服务器及其功能。
- 协议信息: 注册表将提供关于服务器所使用的协议（例如标准IO或SSSE），及其位置（本地文件或远程URL）的信息。
- 信任与验证: 一个重要的挑战是确定mCP服务器的可信度和真实性。注册表旨在通过提供验证机制来解决这个问题，例如，表明来自Shopify或Grafana等知名公司的官方的服务器。
- 发布: 注册表将简化开发人员发布其mCP服务器并将其提供给更广泛受众的过程。
- 版本管理: 随着mCP服务器的演变，注册表将提供一种管理和跟踪服务器及其功能的不同版本的方法。这将帮助用户了解发生了哪些变化，并在必要时锁定到特定版本。
- 元数据管理: 注册表将托管关于mCP服务器的元数据，包括其功能，如资源和工具，这可能使理解如何与其交互变得更加容易。
远程服务器的意义：
- 当前，MCP 通常依赖于本地或内存中的通信，使用标准 IO，这可能会在设置和部署方面带来一些不便。通过类似 SSE（服务器发送事件）这样的协议支持的远程服务器，MCP 服务器可以在公共 URL 上托管，从而可以通过互联网访问它们。
- 这种变化让用户无需了解 MCP 服务器托管或构建的复杂性。就像访问网站一样，用户或应用程序通过 URL 就可以连接到远程 MCP 服务器。
- 远程服务器将 MCP 客户端（如 AI 代理或应用程序）与其服务器的位置解耦，允许它们在完全不同的系统上运行。这增强了架构设计和部署的灵活度。
- 服务器可用性的提高将使 MCP 能访问到的功能种类更多。
OAuth 2.0的整合如下:
- OAuth 2.0 的集成提供了 mCP（或类似缩写）客户端与远程服务器之间的一种 标准化和安全的身份验证和授权机制。
- 现在，MCPl 支持一个 OAuth 2.0 握手，其中服务器协调身份验证流程，与 OAuth 提供方（如 Slack）进行交互。用户通常通过一个熟悉的基于 Web 的流程授权连接。
- 身份验证成功后，服务器持有 OAuth 令牌，然后可以为客户端提供会话令牌以供后续交互。这种方法 使服务器对与底层服务（如 Slack）的互动有更多的控制。
- 这种安全的身份验证机制对于访问远程服务器提供的敏感数据和功能至关重要。它 建立信任，并提供了一个管理权限的框架。
在可访问性和易用性方面的影响：
这些进展可能会对mCP服务器的可访问性和易用性产生积极的影响。
- 降低入门门槛: 通过 URL 连接到远程服务器的简便性大大降低了技术门槛，使希望在其应用程序中利用 MCP 功能的开发人员和使用这些应用程序的最终用户都能轻松上手。用户甚至可能不知道他们正在与 mCP 服务器互动。
- 更广泛的应用范围: 远程托管服务器的能力为更广泛的应用程序利用 MCP 开辟了可能性。网络应用、移动应用和云服务现在可以更容易地与 MCP 服务器集成，而无需复杂的本地配置。
- 提升服务器可用性: 开发和部署方面的摩擦减少可能会导致提供多种功能的 MCP 服务器数量增多。这种扩展的生态系统将为 AI 应用程序提供更丰富的工具和资源库。
- 提高安全性和信任度: 采用 OAuth 2.0 提供了访问远程资源的强大且广泛认可的标准。这对于建立用户信心和鼓励他们使用与个人或敏感数据相关的 MCP 服务器至关重要。正如您之前提到的，安全的认证机制是建立信任生态系统的基石。
- 简化开发: 开发人员可以更多地专注于构建应用程序和服务器的核心逻辑，而无需担心处理复杂的本地通信和自定义认证方法。标准的 OAuth 2.0 流程使集成过程更加简单。
一个 MCP 服务器注册表允许代理程序可以动态地发现新的功能和数据，而无需预先编程。这意味着代理程序可以遇到新任务或需要访问新的或未知的数据源，并主动寻找满足这些需求的工具。这可以让他们更好地应对新的任务。
考虑一个负责检查Grafana日志的通用编码代理程序。如果该代理最初未配置特定的Grafana服务器信息，它可以通过与MCP注册表交互。通过查找提供所需API的官方和已验证的Grafana服务器，该代理可以安装或调用该服务器（如前所述，可能通过SSE远程执行），然后继续查询日志并解决错误。
自演化代理的可能好处：
- 增强适应性：最显著的优势在于代理程序适应新情况和任务的能力更强。它不再局限于其预编程的能力，而是能够根据需要进行学习并扩展其功能。
- 更广泛的应用范围：自我进化的代理程序能够处理更广泛的任务，而无需开发人员在初始设计和编程阶段就预见到所有可能的场景。
- 改进的用户体验：用户可以与更多用途广泛的代理程序进行交互，这些代理程序能够处理多样化的请求，即使这些请求涉及代理程序未明确构建使用过的系统或数据源，代理程序也会负责找到合适的工具和手段。
- 持续改进：代理程序能够“学习”并随着时间不断改进，通过发现并整合在注册表中可用的新工具和数据源，这些工具和数据源可能更加高效。
- 减少开发负担：开发人员可以专注于构建代理程序的核心推理和任务执行逻辑，依赖于注册表提供对不断增长的能力生态系统的访问。这样可以减少为每个潜在的数据源或服务构建专用接口的需求。
关于自我演化的代理，我们的一些思考:
- 治理与安全: 一个关键的考虑是控制代理可以访问哪些服务器及其功能。如果没有适当的保护措施，一个自我演进的代理可能会连接到不可信甚至恶意的服务器，从而带来安全风险或数据隐私问题。正如 Mahesh 所提到的，自托管注册表、白名单和验证机制等方法将是缓解这些风险的重要措施。
- 信任与验证: 确保发现的服务器的可靠性和可信赖度至关重要。mCP 注册表旨在通过提供验证机制来解决这个问题，可能允许官方实体（如 Shopify 或 Grafana）来“验证”它们的服务器。
- 性能和效率: 动态发现和集成新服务器的过程可能会给代理的工作流程带来延迟。优化注册表搜索和服务器集成过程将非常重要。
- 工具选择与推理: 尽管模型在工具使用方面变得越来越熟练，但仍需要确保代理能够明智地选择工具并有效地利用它们，从注册表中的众多选项中进行选择。提供过多的选择也可能会成为一种挑战。
- 调试与可观测性: 随着代理变得越来越复杂，并依赖于动态发现的组件，调试和监控其行为可能会变得更加复杂。需要明确的机制来观察代理与注册表和调用服务器之间的交互。正如之前讨论的，针对服务器可调试性和客户端与服务器之间元数据通信的最佳实践将非常重要。
- 版本控制与兼容性: 随着服务器的演变和 API 的变化，注册表内需要版本控制机制以确保与现有代理的兼容性。代理可能需要知道不同的服务器版本，并可能需要处理兼容性问题。
[1]. Mahesh Murag的MCP研讨会，在AI工程师峰会上举行的 - 观看https://www.youtube.com/watch?v=kQmXtrmQ5Zg
[2]. 访问 https://supabase.com/docs/guides/getting-started/mcp，参见 Supabase 的入门指南和 MCP 介绍.
请参见[3]. （构建有效代理的工程方法）https://www.anthropic.com/engineering/building-effective-agents （点击链接访问）
[4]. https://www.anthropic.com/news/model-context-protocol （这链接是关于模型上下文协议的新闻页面）
[5]. https://spec.modelcontextprotocol.io/specification/2024-11-05/
-
Python SDK:软件开发工具包：https://github.com/modelcontextprotocol/python-sdk
- TypeScript SDK 仓库: https://github.com/modelcontextprotocol/typescript-sdk
共同学习，写下你的评论
评论加载中...
作者其他优质文章
