MCP是什么？一文看懂

AI 2025-08-01 12:24:08

经验

Model Context Protocol（MCP）是人工智能公司 Anthropic 于 2024 年 11 月推出的一个开放协议，标准化大型语言模型（LLM）与外部数据源和工具之间的通信。MCP 被比喻为 AI 应用的 USB-C 接口，通过提供统一的接口，使 LLM 能灵活地访问和交互各种数据和服务，促进了 AI 的广泛应用和生态发展。协议推出，解决了传统集成方式的复杂性和安全隐患，提升了开发效率和数据安全性，已被 Microsoft、OpenAI、Google 等公司采用。MCP 的出现标志着 AI 模型与外部世界交互方式的一个重要进步，为构建更强大、更智能的 AI 应用提供了坚实的基础，有望推动整个 AI 行业的标准化进程。通过简化集成流程，MCP 降低了开发门槛，使更多的开发者能利用 LLM 的强大能力，创造出更多有价值的应用。

MCP是什么

Model Context Protocol（MCP）是 Anthropic 推出的开放协议，标准化大型语言模型（LLM）与外部数据源和工具之间的通信。通过提供统一的接口，使 LLM 能灵活地访问和交互各种数据和服务。

背景

随着大型语言模型（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 的风险。