MCP(Model Context Protocol)是什么?一文看懂 – AI百科知识
Model Context Protocol (MCP) 是 Anthropic 推出的开放协议,旨在统一大型语言模型 (LLM) 与外部数据源和工具之间的通信。它如同 AI 应用的“USB-C 接口”,提供标准化的接口,使 LLM 能够灵活地访问和交互各种数据与服务,从而促进 AI 的广泛应用和生态发展。
想要了解 Model Context Protocol(MCP)吗?它是由前沿人工智能公司 Anthropic 于 2024 年推出的一项开放协议。MCP 的目标是统一大型语言模型(LLM)与外部世界——各种数据源和工具——的沟通方式。设想一下,如果 AI 应用也有一个“通用接口”,能够像 USB-C 一样方便地连接不同的设备,那会怎样?MCP 正是为此而生,它为 AI 模型提供了一个标准化的“接口”,让它们可以轻松访问和调用各种数据和服务,极大地推动了 AI 技术的普及和应用。
MCP 是什么?
MCP 是一种由 Anthropic 提出的开放协议,它定义了 LLM 与外部数据源和工具交互的标准。通过提供统一的接口,MCP 使得 LLM 能够灵活地访问和利用各种数据和服务。
背景故事
随着 LLM 在人工智能领域的崛起,它们展现出了强大的能力,比如理解自然语言、生成文本、编写代码以及解决复杂问题。然而,LLM 的知识通常局限于它们所接受训练的数据,这些数据是静态的,并且停留在某个特定的时间点。这意味着 LLM 无法获取实时的信息,也无法直接访问和操作外部的私有数据源或工具。为了弥补这些不足,开发者需要将 LLM 与各种外部数据源(例如数据库、API、文件系统)和工具(例如计算器、代码执行环境、专业软件)集成。传统的集成方式,往往需要针对每个特定的数据源或工具进行定制化的接口开发,这不仅耗时费力,而且成本高昂。
举例来说,如果一个应用需要 LLM 同时访问数据库、调用外部 API 并读取本地文件,开发者可能需要编写三套不同的接口代码,分别处理不同的认证授权机制、数据格式和通信协议。这种“点对点”的集成模式,就像“M×N 问题”一样,即 M 个模型需要与 N 个工具集成,理论上需要 M×N 个连接器,导致系统变得复杂且难以维护。
这种定制化的集成方式也带来了安全风险,比如数据泄露、未经授权的访问和恶意代码执行等,因为每次新的集成都可能引入新的安全漏洞。因此,行业亟需一种标准化的、统一的协议来简化 LLM 与外部世界的连接,降低集成的复杂度和成本,并提高系统的安全性和可维护性。
起源
Anthropic 将 MCP 设计为一个开放标准,积极推动其成为行业规范,鼓励社区参与和贡献,而非将其局限于单一厂商的技术栈。从最初发布开始,MCP 提供了详细的规范文档、软件开发工具包(SDK)以及一系列参考实现,帮助开发者快速上手并参与到 MCP 生态的建设中。Anthropic 的这一举措得到了业界的积极响应,包括 Block(前身为 Square)和 Apollo 在内的公司在其发布初期就将其集成到自身的系统中,而 Zed、Replit、Codeium 和 Sourcegraph 等开发者工具提供商也开始与 MCP 合作,增强其平台的功能。MCP 的推出,标志着 LLM 应用开发进入了一个新的阶段,通过提供一种通用的“语言”和“接口”,极大地简化了 AI 模型与外部环境的交互,为构建更强大、更智能、更易于集成的 AI 应用奠定了坚实的基础。
MCP 的核心目标
简化集成流程
通过统一的协议规范,减少开发者需要编写的定制化代码量,从而简化集成流程。
提升开发效率
开发者可以复用已有的 MCP 服务器实现,或者基于标准快速开发新的 MCP 服务器,加快 AI 应用的开发周期。
增强安全性,MCP 规范中包含了安全相关的考量,比如基于 OAuth 2.1 的授权机制,有助于构建更安全的 AI 应用。
促进生态发展
通过开放标准和社区协作,鼓励更多的开发者和组织参与到 MCP 生态的建设中,开发出更多功能丰富、用途各异的 MCP 服务器,丰富 AI 模型的能力边界,推动 AI 技术的广泛应用和创新。
MCP 的形象比喻——“AI 应用的 USB-C 接口”
Model Context Protocol (MCP) 被其创造者 Anthropic 以及业界广泛比喻为 “AI 应用的 USB-C 接口”。这个比喻生动地揭示了 MCP 在 AI 生态系统中的核心作用和价值。正如 USB-C 接口通过其标准化、可逆、多功能的特性,极大地简化了各种电子设备(如笔记本电脑、智能手机、平板电脑、外围设备等)之间的连接和数据传输,取代了以往多种不同且互不兼容的接口(如 USB-A、Micro-USB、HDMI、VGA 等)
在 MCP 出现之前,AI 模型(尤其是大型语言模型)与外部世界的连接往往是零散的、定制化的,每个新的集成都需要开发特定的适配器和接口,就像在 USB-C 普及之前,用户需要为不同的设备准备不同的线缆和转换器一样不便。
MCP 的出现,如同为 AI 世界引入了 USB-C 标准,允许 AI 模型通过一种通用的协议去“即插即用”地访问各种 MCP 服务器(这些服务器封装了对特定数据或工具的访问能力)。正如 USB-C 接口能支持数据传输、视频输出、电力输送等多种功能,MCP 也支持资源访问、工具调用、提示管理、启发式交互等多种核心功能,能适应多样化的 AI 应用场景。深刻地说明了 MCP 在推动 AI 技术普及和应用创新方面所具有的潜力,有望成为连接 AI 模型与现实世界的关键桥梁。
MCP 的核心组件
Host(宿主)
Host 是用户与 AI 模型进行交互的界面或应用程序。它负责接收用户的输入(例如问题、指令),并将这些输入传递给 AI 模型进行处理。Host 也负责展示 AI 模型生成的回复或执行操作的结果给用户。在 MCP 的交互流程中,Host 扮演着协调者的角色,理解用户意图,决定何时以及如何调用 MCP Client 来获取外部数据或执行工具操作。
一个典型的 Host 例子是 Claude Desktop 应用程序,用户可以在其中直接与 Claude 模型对话,通过 MCP 访问本地文件系统或网络资源。Host 需要能管理 MCP Client 的生命周期,处理与用户交互相关的逻辑,例如权限请求、错误提示等。
Client(客户端)
MCP Client 是 Host 与 MCP Server 之间的桥梁。它负责与一个或多个 MCP Server 建立连接,将 AI 模型的请求(例如,获取特定资源、调用某个工具)封装成符合 MCP 规范的请求消息发送给相应的 Server。Client 也负责接收来自 Server 的响应消息,将结果返回给 Host 或直接传递给 AI 模型。MCP Client 需要实现 MCP 协议规范,包括消息的编码解码、传输协议(如 HTTP、WebSockets、gRPC 或 stdio)的处理、以及必要的安全机制(如 OAuth 2.1 认证)。在某些实现中,MCP Client 可能内置于 Host 应用程序中,或者作为一个的库被 Host 调用。
Server(服务器)
MCP Server 是实际提供数据或执行工具操作的组件。每个 MCP Server 封装了对特定数据源(如数据库、文件系统、API)或工具(如代码解释器、计算器、专业软件)的访问能力。当 MCP Server 收到来自 Client 的请求后,会根据请求的类型和参数,执行相应的操作(例如,查询数据库、读取文件、调用外部 API),将结果封装成符合 MCP 规范的响应消息返回给 Client。MCP Server 也需要实现 MCP 协议规范,对外暴露其支持的能力(Capabilities),例如提供了哪些资源、哪些工具、以及哪些提示模板。开发者可以根据 MCP 规范开发自定义的 MCP Server,以扩展 AI 模型的能力。
这种三组件架构清晰地将用户交互、协议通信和具体功能实现分离开来,使 MCP 系统具有很好的模块化和可扩展性。Host 专注于用户界面和体验,Client 处理协议层面的通信,Server 提供具体的业务逻辑和数据访问能力。
MCP 的交互流程示例
为了更好地理解 MCP 架构中 Host、Client 和 Server 三个组件是如何协同工作的,我们可以通过一个具体的交互示例来说明。
假设用户在 Claude Desktop(Host)中提出了一个问题:“我桌面上有哪些文档?”。以下是处理这个请求的典型 MCP 交互流程:
- 用户输入 (User Input):用户在 Claude Desktop 的界面中输入问题“我桌面上有哪些文档?”并发送。Host(Claude Desktop)接收到这个用户请求。
- Host 处理 (Host Processing):Host 将用户的原始问题传递给其内部的 AI 模型(例如 Claude 模型)进行分析和理解。AI 模型需要判断这个问题是否需要访问外部资源或工具来获取答案。
- 模型分析 (Model Analysis):AI 模型分析问题后,识别出用户意图是获取本地文件系统信息。模型决定需要调用一个能访问文件系统的外部工具。在 MCP 框架下,这意味着模型会生成一个请求,指示需要调用一个特定的 MCP Tool(例如,一个封装了文件系统浏览能力的 MCP Server 提供的工具)。
- Client 请求 (Client Request):Host 内部的 MCP Client 接收到 AI 模型发出的调用外部工具的指令。MCP Client 会根据指令,查找预先配置好的、能提供文件系统访问服务的 MCP Server。然后,Client 会按照 MCP 协议规范,将模型的请求(例如,请求列出用户桌面上的文件)封装成一个标准的 MCP 请求消息,通过指定的传输方式(例如 HTTP、WebSockets 或 stdio)发送给目标 MCP Server。
- Server 执行 (Server Execution):目标 MCP Server(例如,一个专门的文件系统 MCP Server)接收到来自 Client 的请求。Server 解析请求,验证权限(如果需要),然后执行相应的操作——在这个例子中,就是扫描用户指定的桌面目录,获取文件列表。执行完毕后,MCP Server 将获取到的文档列表(例如,一个包含文件名、路径等信息的 JSON 对象)封装成一个标准的 MCP 响应消息,通过相同的传输方式返回给 MCP Client。
- 模型响应 (Model Response):MCP Client 接收到来自 MCP Server 的响应,将其中的结果数据(即桌面文档列表)提取出来,传递给 AI 模型。AI 模型接收到这些上下文信息后,结合原始问题,生成一个自然语言的回复,例如“您桌面上有以下文档:report.docx, budget.xlsx, image.png”。
- Host 展示 (Host Display):Host(Claude Desktop)接收到 AI 模型生成的最终回复,将其在用户界面上展示给用户。
MCP 的核心功能
Resource(资源)
Resource 功能允许 MCP Server 向 AI 模型提供只读的上下文信息或数据。这些资源可以是静态数据,也可以是动态生成的数据。例如,一个 MCP Server 可以提供对公司内部知识库的访问,或者提供实时股票行情数据。AI 模型可以通过 MCP Client 请求这些资源,获取完成任务所需的信息。
Resource 的设计强调只读性,确保了数据源的安全性,防止 AI 模型意外修改原始数据。MCP 规范定义了资源发现、订阅和通知等机制,使模型能有效地获取和利用这些外部信息。
Prompt(提示)
Prompt 功能允许 MCP Server 提供预置的提示模板。模板可以帮助 AI 模型生成特定格式或内容的输出,或者引导模型以特定的方式执行任务。例如,一个 MCP Server 可以提供用于生成特定类型邮件的提示模板,或者用于代码生成的模板。
通过使用标准化的提示模板,可以提高模型输出的质量和一致性,减少在应用程序中硬编码提示的需求。MCP 允许服务器声明其提供的提示模板,客户端可以查询并使用这些模板。
Tool(工具)
Tool 功能是 MCP 的核心特性之一,允许 AI 模型调用外部的 API 或工具来执行具体的操作。工具可以执行各种任务,例如执行计算、查询数据库、发送邮件、控制外部设备等。MCP Server 可以声明提供的工具,包括工具的名称、描述、参数列表和预期的输出格式。AI 模型在分析用户请求后,如果判断需要调用某个工具,可以通过 MCP Client 向相应的 Server 发送工具调用请求。Server 执行工具并返回结果,模型再根据结果生成回复。Tool 功能极大地扩展了 AI 模型的能力边界,不再局限于文本生成,能与现实世界进行更深入的交互。
Elicitation(启发)
Elicitation 允许 MCP Server 在交互过程中主动向用户请求更多信息或澄清模糊的输入。在传统的交互模式中,如果模型或工具需要额外的信息才能继续执行任务,只能返回一个错误或提示用户重新提问。
Elicitation 提供了一种更结构化的方式来处理这种情况。当 Server 端(通过 LLM 分析)发现当前请求缺少必要参数或意图不明确时,可以返回一个 elicitationRequest
,其中包含需要用户提供的信息的描述或表单。Host 接收到这个请求后,可以向用户展示相应的界面(例如,一个包含输入框的表单),收集用户输入,然后通过 continueElicitation
请求将信息发送回 Server。使交互更加灵活和智能,能处理更复杂的、需要多轮对话才能完成的任务,例如交互式表单填写、用户意图澄清等。
Structured Output(结构化输出)
Structured Output 功能要求 MCP Server 以结构化的格式(例如 JSON)返回工具调用的结果。与返回非结构化的文本相比,结构化的输出更易于 AI 模型解析和理解。MCP 规范支持为工具的输出定义 JSON Schema,使模型可以预期返回数据的结构和类型,更准确地进行后续处理。
例如,一个查询天气的工具可能会返回一个包含温度、湿度、风速等字段的 JSON 对象,而不是一段描述天气的自然语言文本。
这种结构化的输出提高了模型处理结果的效率,增强了系统的可靠性和可维护性。
最新的 MCP 规范(如 2025-06-18 版本)进一步强化了对结构化内容和输出模式的支持,引入了类型化、经过验证的结果以及灵活的 Schema 哲学和 MIME 类型清晰度。
MCP 的特点
灵活性
MCP 支持多种传输协议和通信方式。虽然 MCP 规范本身是于传输层的,明确支持包括 Streamable HTTP、WebSockets、gRPC 以及 stdio(标准输入输出,常用于本地进程间通信)在内的多种通信机制。多样性使得 MCP 可以适应不同的部署环境和性能要求。
例如,对于需要低延迟、双向实时通信的场景,WebSockets 或 gRPC 可能是更好的选择;对于简单的本地工具调用,stdio 更为轻量级和便捷。Streamable HTTP 允许以流式方式传输数据,适用于处理大量数据或需要逐步展示结果的场景。
扩展性
协议本身定义了一套核心的消息类型和交互模式,但同时也允许通过扩展(Extensions)来引入新的功能或特性。MCP 使用基于能力协商(Capability Negotiation)的机制,客户端和服务器在初始化连接时会声明各自支持的功能(Capabilities)。如果双方都支持某个扩展功能,那么就可以在会话中使用该功能。机制确保了协议的向前兼容性和向后兼容性,新的功能可以在不破坏现有实现的基础上逐步引入。
模块化设计
MCP Server 是轻量级的程序,每个 Server 只负责暴露特定的功能或数据源。使开发者可以按需开发和部署 MCP Server,构建一个分布式的、可组合的 AI 能力网络。
例如,一个公司可以开发一个专门访问内部 CRM 系统的 MCP Server,另一个团队可以开发一个连接特定数据库的 MCP Server。
AI 应用(Host)可以通过 MCP Client 动态发现和使用这些 Server 提供的功能,像搭积木一样组合出复杂的应用。
开放性和社区驱动
作为一个开放协议,MCP 鼓励社区参与和贡献,意味着会有更多的开发者为其开发新的 MCP Server、Client 库、工具和文档。能更快地响应市场需求,催生出更多创新的应用场景。
MCP 的安全机制
基于 OAuth 2.1 的安全机制
Model Context Protocol (MCP) 在安全方面采取基于 OAuth 2.1 授权框架。OAuth 2.1 是 OAuth 2.0 的演进版本,整合了 OAuth 2.0 最佳实践和安全建议,提供更强大、更易用的授权解决方案。在 MCP 的交互流程中,当 MCP Client 需要访问受保护的 MCP Server(即提供敏感数据或执行敏感操作的 Server)时,需要进行 OAuth 2.1 认证和授权。意味着 Client 需要先从授权服务器(Authorization Server)获取一个访问令牌(Access Token),然后在向 MCP Server 发起请求时携带该令牌。MCP Server 会验证令牌的有效性(例如,通过 introspection endpoint 或 JWKS endpoint 验证签名和有效期),检查令牌是否包含执行所请求操作所需的权限(scopes)。
MCP 规范特别强调了 OAuth 2.1 中的一些关键安全特性,如 PKCE (Proof Key for Code Exchange) 用于防止授权码拦截攻击,以及 令牌受众绑定 (Token Audience Binding – RFC 8707) 用于确保访问令牌仅能被预期的 MCP Server 使用。有效地防止了令牌的跨服务器滥用,提升了整体系统的安全性。
安全最佳实践
Model Context Protocol (MCP) 的生态系统强调了一系列安全最佳实践,确保在日益复杂的 AI 应用场景中维护数据安全、隐私和系统完整性。
- MCP 服务器安全加固与部署实践:部署 MCP 服务器时,应遵循最小权限原则,仅开放必要的服务和端口。操作系统应进行加固,并考虑使用安全增强工具。所有传入的输入(如用户提示、工具参数)必须进行严格的验证和净化,以防止常见的 Web 攻击,如提示注入 (prompt injection) 和参数污染。对于本地运行的 MCP 服务器,建议将其运行在容器(如 Docker,以非 root 用户运行)或虚拟机中,以实现与主机系统的隔离。网络访问控制也应严格配置,避免将 MCP 服务器直接暴露在公共互联网,优先使用 localhost 或私有子网进行绑定。
- MCP 客户端与工具交互安全:MCP 客户端应基于 MCP 对 OAuth 2.1 的支持,使用短期、范围受限的令牌进行认证。所有交互都应进行身份验证。在工具设计方面,应为每个 Tool 提供清晰的元数据,包括其功能描述、输入参数、预期输出以及可能产生的副作用。对于可能修改数据或产生重大影响的工具,应使用如
readOnlyHint
和destructiveHint
这样的注解进行明确标记,帮助运行时环境采取适当的安全措施。 - 凭证和密钥管理:是基本要求,绝对避免在配置文件中硬编码凭证或 API 密钥。应使用环境变量或专门的密钥管理服务来存储和访问敏感信息,定期轮换密钥。
- 启用详细日志记录与监控:对于事后审计、异常行为检测和安全调查至关重要。应配置 MCP 服务器和客户端记录所有操作日志,包括请求、响应、错误以及用户交互。特别地,记录所有发送给 AI 模型的提示 (prompts) 有助于检测和防范提示注入攻击。
- 建立 MCP Server 的治理流程:组织应建立一个正式的审批流程,用于将新的 MCP Server 添加到环境中,包括安全审查和源代码验证。维护一个已批准的 MCP Server 清单,考虑建立一个内部审查过的 MCP Server 仓库,降低引入恶意或存在漏洞的 Server 的风险。
MCP 的行业应用情况
Model Context Protocol (MCP) 自推出以来,迅速获得了业界的广泛关注和积极采用。Anthropic 作为 MCP 的发起者,在其产品线中率先集成和支持 MCP,例如在其 Claude Desktop 应用和 Claude 模型中。
OpenAI 在 2025 年初宣布在其 Agents SDK、ChatGPT 桌面应用和 Responses API 中支持 MCP,
微软 (Microsoft) 积极参与 MCP 生态,推出了 Playwright-MCP 服务器,使 AI 代理能像人类一样浏览网页并与网站交互。
Google 在产品中采用 MCP。
Docker 推出了 MCP Toolkit,通过提供一键部署、包含超过 100 个安全 MCP 服务器的目录等功能,简化了 MCP 服务器的部署和管理。
MCP 的应用案例
金融科技领域应用
在金融科技(FinTech)领域,帮助金融机构和科技公司构建更智能、更高效的解决方案。例如,可以用 MCP 将 LLM 连接到实时的市场数据源、客户数据库、风险评估模型以及交易执行系统。
- 智能投顾:MCP 可以使 AI 投顾系统实时获取最新的股票价格、财经新闻、公司财报等信息(通过 Resource 功能),分析客户的风险偏好和投资目标(可能通过 Elicitation 功能与用户交互),然后调用交易执行工具(Tool 功能)为客户提供个性化的投资建议并执行交易。
- 反欺诈分析:通过连接各种数据源(如交易记录、用户行为日志、黑名单数据库),LLM 可以辅助识别可疑交易模式。
- 客户服务:MCP 可以使机器人能回答常见问题,能查询用户的账户信息(在获得授权后)、处理简单的业务请求(如转账、账单查询),提供个性化的理财建议。通过 MCP 的标准化接口,金融机构可以更安全、更便捷地利用 LLM 的强大能力,确保数据的安全性和合规性。
医疗健康领域应用
在医疗健康领域,MCP 有潜力革新患者护理、医学研究和医疗管理。LLM 可以通过 MCP 连接到电子健康记录 (EHR) 系统、医学文献数据库、医学影像分析工具以及患者监测设备。
- 临床决策支持:医生可以向 AI 助手描述患者的症状和病史,AI 助手通过 MCP 查询相关的医学知识库(Resource)、最新的临床指南(Resource),调用诊断辅助工具(Tool),为医生提供诊断建议和治疗方案参考。MCP 的 Elicitation 功能可以用于在诊断过程中向医生询问更多细节,或确认关键信息。
- 个性化医疗:MCP 可以帮助整合患者的基因组数据、生活习惯数据等,为患者提供定制化的健康管理建议和疾病预防方案。
- 医学研究:MCP 可以加速文献综述过程,帮助研究人员快速从海量文献中提取关键信息,或者辅助分析临床试验数据。
- 患者监护系统:通过连接可穿戴设备和传感器数据,实时分析患者的健康状况,在出现异常时及时预警。MCP 的安全机制,特别是基于 OAuth 2.1 的授权,对于处理敏感的医疗数据至关重要,可以确保只有经过授权的用户和应用才能访问患者信息。
科技行业应用
在科技行业,MCP 的应用几乎可以渗透到软件开发生命周期的各个环节以及各种技术驱动的产品和服务中。
- 软件开发:集成开发环境 (IDE) 可以用 MCP 将 LLM 的强大编码能力与本地开发环境、版本控制系统(如 Git MCP Server)、调试工具、API 文档等无缝集成。开发者可以通过自然语言指令让 AI 助手编写代码、解释代码、生成测试用例、查找并修复 bug,部署应用。例如,开发者可以问:“在我的当前分支上运行测试,并总结失败的原因”,AI 助手可以通过 MCP 调用 Git 工具获取代码,调用测试工具执行测试,然后分析日志并生成报告。
- IT 运维与支持:AI 运维助手可以连接到监控系统、日志服务器、配置管理数据库 (CMDB) 等,通过自然语言交互帮助运维人员诊断问题、执行维护任务、自动化故障排除流程。例如,AI 助手可以根据警报信息,自动查询相关服务器的日志(通过 MCP Server 提供的日志查询工具),分析错误原因,建议修复方案。
- 技术文档助手:帮助用户快速找到所需的技术信息,或者根据用户需求生成代码片段和配置示例。科技公司可以用 MCP 将其内部的知识库、API 服务等封装成 MCP Server,供内部员工或外部开发者通过 LLM 方便地访问和使用,提高工作效率和创新能力。
MCP 的最新协议更新日志
- 移除 JSON-RPC 批处理支持:为了简化规范并避免歧义,特别是在实现
Streamable HTTP
传输时,未发现批处理的实际需求,且 JSON-RPC 的通知/响应模型难以满足实时性和并发调用需求,因此移除此功能。 - 增强工具调用结果,新增结构化输出功能:引入了
outputSchema
和structuredContent
字段。这一改进旨在不破坏现有content
结构的前提下,为简单的 JSON 输出场景提供一个轻量级、可验证的格式化通道。对于提升与不受信任服务器交互时的数据安全性与可靠性尤为重要,使客户端可以更精确地解析和验证来自工具的响应。例如,一个网络设备状态检索工具可以定义一个包含设备 ID、状态、运行时间等字段的输出模式,确保返回数据的结构化和可验证性。 - 将 MCP 服务器归类为 OAuth 资源服务器:并添加受保护资源元数据(遵循 RFC 9728)以便发现对应的授权服务器。有助于客户端自动发现授权服务器,避免滥用访问令牌,提升整体安全性与部署一致性。
- 要求 MCP 客户端实现遵循 RFC 8707 的 Resource Indicators:以防止恶意服务器获取访问令牌。通过在授权请求和令牌请求中包含
resource
参数,客户端可以明确指定令牌所针对的目标 MCP 服务器,增强了 OAuth 2.0 授权的安全性。 - 支持 “Elicitation” 功能:允许服务器在交互过程中向用户动态请求额外信息。MCP 此前缺乏标准化的方式来支持这种运行时交互,开发者往往需要依赖多步骤工具调用或自定义协议。Elicitation 机制的引入,为工作流中的确认、澄清、登录跳转等场景提供了结构化的输入机制,完善了模型、用户与服务器三者之间的双向交互闭环。例如,在执行一个删除操作前,服务器可以通过 elicitation 请求用户确认;或者在需要用户特定信息(如时区、组织名称)时,动态向客户端发起请求。
- 工具调用结果中新增资源链接(Resource Links)类型:为了支持工具返回对外部或大型资源的引用,不是直接嵌入其内容,引入了新的
ResourceLink
类型。解决了在交互流中直接嵌入内容不可行或效率低下的场景需求,例如延迟加载、处理大文件或临时资源。 - 澄清安全注意事项及最佳实践:在授权规范中增加了相关说明,新增了“安全最佳实践”页面,指导开发者构建更安全的 MCP 应用。
MCP 的发展前景
Model Context Protocol (MCP) 作为标准化 AI 模型与外部系统和数据源交互的开放协议,未来发展将聚焦于推动更广泛的行业标准化、持续增强核心功能与安全性,以及不断扩展其生态系统和提升互操作性。随着人工智能技术的飞速发展和应用场景的不断深化,MCP 致力于解决当前 AI 集成面临的碎片化、复杂性和安全隐患等挑战,为构建更强大、更可靠、更易于集成的 AI 应用提供坚实的基础。社区和开发者正积极推动 MCP 的演进,适应日益增长的需求和不断变化的技术格局。