MCP

一、MCP 的核心设计目标是什么？

1. 建立 AI 与外部系统的标准化连接协议

MCP 旨在解决 AI 应用连接外部数据源时需要为每一个数据源单独开发集成代码的问题。通过定义统一的协议规范，使任何兼容 MCP 的 AI 应用都能以相同方式连接任意 MCP 服务端，降低集成复杂度。

2. 实现服务端与客户端的职责分离

协议设计遵循"服务端应极其易于构建"的原则，将复杂的编排职责（安全策略、用户授权、上下文聚合）交给宿主应用处理，服务端只需专注于暴露明确界定的专项能力，降低开发门槛。

3. 支持有状态的会话协议

与无状态的 HTTP API 不同，MCP 是一个有状态协议，支持会话生命周期管理，包括连接初始化、能力协商和连接终止，使服务端能够在多次调用之间维持上下文。

4. 提供跨平台、模型无关的通用接口

MCP 作为开放标准，不绑定特定厂商或模型，任何 AI 应用和任何大模型均可通过实现 MCP 协议实现互操作，避免供应商锁定。

二、MCP 的架构由哪些核心组件组成？

1. MCP 宿主（Host）

宿主是协调和管理一个或多个 MCP 客户端的 AI 应用程序（如 Claude Desktop、Visual Studio Code、Cursor）。宿主负责创建并管理多个客户端实例，控制客户端连接权限和生命周期，执行安全策略和用户授权决策，并协调 AI/LLM 集成与采样。

2. MCP 客户端（Client）

每个客户端由宿主创建，并维护一个与特定服务端的隔离连接。客户端负责处理协议协商和能力交换，双向路由协议消息，管理订阅和通知，并在服务端之间维持安全边界。每个服务端连接对应一个独立的客户端实例。

3. MCP 服务端（Server）

服务端是提供专项上下文和能力的程序，通过 MCP 原语暴露资源、工具和提示词。服务端独立运行并承担明确职责，通过客户端接口请求采样，必须遵守安全限制。服务端可以是本地进程（通过 Stdio 通信），也可以是远程服务（通过 HTTP 通信）。

4. 传输层（Transport Layer）

传输层负责管理客户端与服务端之间的通信通道和认证，处理连接建立、消息分帧和安全通信。MCP 将通信细节从协议层中抽象出来，使相同的 JSON-RPC 2.0 消息格式可以在所有传输机制中复用。

三、MCP 支持哪些通信传输方式？

1. Stdio 传输（标准输入/输出）

Stdio 传输使用标准输入/输出流进行同一机器上本地进程间的直接通信，无需网络开销，提供最佳性能。使用 Stdio 传输的本地 MCP 服务端通常只服务于单个 MCP 客户端。此方式适用于本地文件、本地数据库等需要本地访问的场景。

2. Streamable HTTP 传输

Streamable HTTP 传输使用 HTTP POST 发送客户端到服务端的请求，并结合可选的服务器发送事件（SSE）实现流式功能。此传输方式支持远程服务器通信，并支持标准 HTTP 认证方法，包括 Bearer 令牌、API 密钥和自定义标头。MCP 建议使用 OAuth 来获取身份验证令牌。

3. 已弃用的 HTTP+SSE 传输

在 2025 年 3 月 26 日的规范修订中，早期的 HTTP+SSE 传输机制被标记为已弃用，主流提供商已于 2026 年逐步停止支持。新开发的服务端应统一使用 Streamable HTTP 传输。

四、MCP 的协议工作流程是怎样的？

1. 初始化与能力协商

客户端向服务端发送 initialize 请求，包含协议版本号（protocolVersion，如 2025-06-18）、客户端能力声明（capabilities）和客户端信息（clientInfo）。服务端回应其支持的协议版本和能力。若双方无法协商出共同兼容的版本，应终止连接。

2. 原语发现

初始化完成后，客户端通过调用 tools/list、resources/list、prompts/list 等方法，动态发现服务端可用的工具、资源和提示词。list 方法的设计允许结果是动态的，服务端可在会话期间更新可用原语列表。

3. 原语调用与执行

客户端根据用户请求或 AI 模型的决策，调用服务端原语：对工具执行 tools/call，对资源执行 resources/read，对提示词执行 prompts/get。服务端执行对应逻辑后返回结果，结果以内容对象数组的形式返回，支持文本、图像、资源等多种内容类型。

4. 通知与进度跟踪

协议支持单向通知消息（不需要响应），用于服务端向客户端推送实时更新。对于长时间运行的操作，协议支持进度跟踪原语，使客户端能够了解服务端处理进度。

5. 连接终止

当会话结束或发生不可恢复的错误时，任一方可发起连接终止流程，清理会话状态并释放相关资源。

五、MCP 如何保证通信的安全性？

1. 客户端隔离与权限边界

每个 MCP 客户端与其对应的服务端保持专用连接，宿主应用强制在客户端之间执行安全边界。服务端之间无法直接通信，必须通过宿主进行协调，防止横向越权访问。

2. 用户授权与同意机制

宿主应用负责处理用户授权决策，敏感操作（如访问本地文件、发起网络请求）需要用户明确同意。服务端无法绕过宿主直接获取用户授权。

3. HTTP 传输的认证框架

对于基于 HTTP 的传输，MCP 提供了基于 OAuth 2.1 的认证与授权框架（2025-03-26 规范引入），推荐使用 OAuth 2.1 获取身份验证令牌。实现者应使用标准 HTTP 认证方法，包括 Bearer 令牌、API 密钥和自定义标头。使用 Stdio 传输的服务端应从环境变量中获取凭证，而非依赖网络认证。

4. 服务端能力约束

服务端必须遵守宿主设定的安全限制，包括可访问的目录范围、可调用的工具列表以及可请求的采样频率。宿主对服务端的能力范围拥有最终控制权。

5. 日志记录与审计

协议支持日志记录原语，使服务端能够向客户端发送日志消息，用于调试、监控和审计目的，帮助开发者及时发现异常行为。

六、MCP 支持哪些类型的能力？

1. Tools（工具）

工具是 AI 应用可以调用的可执行函数，用于执行具体操作（如文件操作、API 调用、数据库查询）。每个工具拥有名称、描述和以 JSON Schema 定义的输入参数结构。工具调用通常需要用户批准，执行结果以内容对象数组形式返回。

2. Resources（资源）

资源是为 AI 应用提供上下文信息的数据源，类似于可读的数据对象（如文件内容、数据库记录、API 响应）。资源通过 URI 进行寻址，AI 应用可以浏览和读取资源内容作为上下文。与工具不同，资源通常是只读的，不产生副作用。

3. Prompts（提示词模板）

提示词是帮助构建与语言模型交互的可复用模板，用于确保交互的一致性和高质量输出。服务端可以暴露参数化的提示词模板，客户端在获取时填入具体参数后提交给 AI 模型。

4. 客户端原语（服务端可调用）

MCP 还定义了客户端暴露给服务端的原语，包括采样（Sampling，允许服务端请求客户端从宿主 LLM 进行语言模型补全）、引导（Elicitation，允许服务端向用户请求额外信息）、日志记录（Logging，使服务端能够向客户端发送日志消息）。

5. 实验性原语：Tasks（任务）

在 2025-11-25 的规范修订中，MCP 引入了实验性的 Tasks 原语，用于封装长时间运行的操作（如昂贵的计算、工作流自动化、批处理、多步操作），支持延迟结果获取和状态跟踪。该原语仍为实验性质，不建议在生产环境中依赖。

七、MCP 与 OpenAI Function Calling 有什么区别？

1. 协议性质不同

OpenAI Function Calling 是 OpenAI API 的功能特性，函数在每次 API 调用时以内联方式定义，工具逻辑存在于应用代码之中。MCP 是独立的开放协议，基于 JSON-RPC 2.0 构建，有独立的规范文档和 SDK 支持。

2. 工具发现机制不同

Function Calling 采用静态定义方式，每次请求中明确列出可用工具，模型只能看到本次请求中提供的工具。MCP 支持运行时动态发现，客户端通过调用 tools/list 方法主动查询服务端可用的工具，工具列表可在会话期间动态更新。

3. 状态管理模式不同

Function Calling 是无状态的，每次函数调用相互独立，状态管理由应用程序负责。MCP 是有状态协议，服务端可以在多次调用之间维持连接、上下文和事务状态，适合需要保持连接或累积状态的操作。

4. 平台绑定程度不同

Function Calling 绑定特定 LLM 提供商（各家的 Function Calling 格式和行为略有差异），切换模型提供商通常需要重写工具定义。MCP 是模型无关的独立协议，同一 MCP 服务端可以与 Claude、GPT、Gemini 等不同模型配合使用。

5. 传输与部署方式不同

Function Calling 通过 HTTP 调用 LLM API，函数执行在应用进程内完成。MCP 支持独立的服务端进程，可通过 Stdio（本地）或 HTTP/SSE（远程）进行通信，服务端拥有独立部署生命周期，支持跨进程、跨网络通信。

八、MCP 与传统插件系统相比有什么优势？

1. 统一协议替代碎片化集成

传统插件系统通常为每个应用或平台单独开发，不同系统之间的插件无法复用。MCP 提供统一协议规范，一次开发的 MCP 服务端可以被任何兼容 MCP 的客户端使用，实现真正的跨平台复用。

2. 动态能力发现

传统插件系统通常在启动时静态加载插件清单，运行时难以动态更新可用功能。MCP 支持客户端在运行时动态查询服务端可用的工具、资源和提示词，并支持服务端在会话期间更新能力列表。

3. 标准化的消息格式与类型安全

MCP 基于 JSON-RPC 2.0 规范定义消息结构，并使用 JSON Schema 描述参数类型，官方 SDK（TypeScript、Python）提供类型推导和编译时检查，减少运行时错误。传统插件系统通常缺乏统一的类型安全机制。

4. 原生支持本地进程通信

传统插件系统多基于 HTTP API 实现，访问本地资源需要通过网络回环或代理转发。MCP 原生支持 Stdio 传输，可在本地机器上直接通过标准输入/输出流进行进程间通信，无需网络开销，适合访问本地文件系统和本地数据库。

5. 独立的生态与版本管理

MCP 服务端作为独立进程运行，拥有自己的依赖管理和版本生命周期，不受宿主应用升级的影响。传统插件系统通常作为宿主应用的扩展运行，版本兼容性由宿主应用控制，升级时容易出现兼容性问题。

九、MCP 与 LangChain 的 Tools 有什么区别？

1. 定位与抽象层级不同

LangChain 的 Tools 是 Python/JavaScript 框架内的编程抽象，用于在大语言模型应用中组织和调用工具函数，依赖 LangChain 框架的运行环境。MCP 是独立于任何框架的通信协议，定义了 AI 应用与外部系统之间的标准化接口，任何框架均可通过实现 MCP 协议进行互操作。

2. 跨应用复用能力不同

LangChain Tools 绑定 LangChain 框架，工具定义和调用逻辑在 LangChain 应用内部生效，难以直接被非 LangChain 应用复用。MCP 服务端是独立运行的进程，可以被任何实现了 MCP 客户端的 AI 应用连接和使用，真正实现一次开发、多处复用。

3. 工具暴露方式不同

LangChain Tools 在代码层面通过装饰器或注册函数定义，工具逻辑与应用代码共存于同一进程。MCP 服务端在协议层面暴露工具，工具的具体实现细节对客户端透明，客户端只需通过标准协议消息调用工具，无需了解服务端实现语言或内部逻辑。

4. 通信范围不同

LangChain Tools 通常运行于同一进程或同一地址空间内，工具调用是本地函数调用。MCP 支持跨进程、跨机器通信，服务端可以运行在本地机器上（通过 Stdio），也可以运行在远程服务器上（通过 HTTP），通信范围远超单一进程。

5. 生态定位不同

LangChain 定位是一站式 LLM 应用开发框架，工具调用只是其众多功能之一。MCP 专注于定义 AI 应用与外部系统之间的标准接口，定位是"AI 应用的 USB-C 接口"，生态角色更为专注和通用。

十、MCP 相比自定义 API 集成有哪些优势？

1. 大幅降低集成开发成本

自定义 API 集成需要为每个外部系统分别编写适配代码，包括认证、请求构造、响应解析、错误处理等。采用 MCP 后，只需开发一次 MCP 服务端，所有兼容 MCP 的 AI 应用均可直接连接使用，开发工作量显著降低。

2. 统一认证与安全管理

自定义 API 集成需要为每个外部系统单独配置认证凭据和权限控制。MCP 将认证与授权逻辑集中在宿主应用统一管理，服务端通过客户端接口获取已授权的采样能力，无需自行处理认证流程，减少安全风险。

3. 支持工具动态组合与编排

自定义 API 集成通常在代码层面硬编码调用逻辑，难以在运行时动态调整调用流程。MCP 的原语发现机制使 AI 应用能够在运行时了解可用工具，并根据任务需求动态组合和编排多个工具调用，实现更复杂的智能体工作流。

4. 利用成熟的开源生态

截至 2026 年中，MCP 生态已拥有超过 12,500 个互联网可访问的 MCP 服务（据 Censys 2026 年 4 月扫描数据），涵盖数据库、文件系统、开发工具、企业系统等多个类别。采用 MCP 可以直接复用现有生态成果，无需从零开发每个集成。

5. 面向未来的协议演进

MCP 作为开放标准，由社区共同维护演进，支持向后兼容和新能力协商。自定义 API 集成通常缺乏统一的版本管理和兼容性保障，随着接口变更容易产生维护负担。采用 MCP 可以将兼容性风险转移给协议层面统一处理。

十一、MCP 适合哪些应用场景？

1. AI 助手访问本地文件与数据库

通过 MCP 服务端，AI 助手可以安全访问用户的本地文件系统、本地数据库和本地开发环境，实现代码解释、文件编辑、数据库查询等本地化操作，无需将敏感数据上传至云端。

2. 企业知识库与内部系统集成

企业可以开发 MCP 服务端连接内部知识库、客户关系管理（CRM）系统、项目管理平台等内部系统，使 AI 助手能够在获得用户授权的前提下检索内部信息，辅助决策和日常工作。

3. 多工具协同的智能体工作流

MCP 支持 AI 智能体动态发现和调用多个专项工具，并通过有状态会话维持工作流上下文，适合需要多步推理、多工具协同的复杂任务场景，如自动化数据分析、多源信息整合等。

4. 开发工具与 IDE 智能化增强

代码编辑器（如 Visual Studio Code）和编程辅助工具通过 MCP 连接代码仓库、文档系统、测试框架等开发工具，使 AI 编程助手能够实时获取项目上下文，提供更为精准的代码建议和错误诊断。

5. 跨平台 AI 能力分发

工具或数据提供方只需实现一个 MCP 服务端，即可同时支持所有兼容 MCP 的 AI 应用，无需为每个平台单独开发适配版本，适合希望将自身能力开放给多种 AI 应用使用的场景。

十二、企业如何使用 MCP 连接内部数据源？

1. 评估内部数据源与集成需求

企业首先梳理需要 AI 系统访问的内部数据源，包括数据库、文件服务器、API 接口、知识库系统等，明确每个数据源的访问方式、认证机制和权限控制要求，为后续服务端开发制定方案。

2. 开发或选用合适的 MCP 服务端

对于已有标准接口的数据源（如 PostgreSQL、MySQL、Git、Google Drive），可直接使用社区开源的 MCP 服务端实现。对于专有内部系统，企业需要基于 MCP SDK 开发自定义服务端，将内部系统接口映射为 MCP 原语（Tools、Resources、Prompts）。

3. 配置宿主应用与安全策略

企业 IT 部门在员工使用的 AI 应用（宿主）中配置已部署的 MCP 服务端连接信息，并设置安全策略，包括可访问的目录范围、可调用的工具列表、用户授权流程等，确保 AI 访问内部数据的过程可控、可审计。

4. 实施认证、授权与审计机制

对于远程 MCP 服务端，企业应配置标准认证机制（如 OAuth、API 密钥），并在服务端实现细粒度的访问控制。同时开启日志记录功能，对所有 AI 发起的数据访问行为进行审计，满足合规要求。

5. 培训用户与推广使用

企业需要对相关员工进行培训，使其了解 MCP 连接内部数据源的能力边界和使用方式，并建立反馈机制，持续优化服务端功能和用户体验。

十三、MCP 在 AI 助手开发中有什么作用？

1. 扩展 AI 助手的能力边界

通过连接 MCP 服务端，AI 助手可以获得调用外部工具、读取外部数据的能力，从而超越纯语言模型的固有局限，执行实际操作（如查询数据库、调用 API、操作文件），真正成为能够"行动"的智能助手。

2. 实现上下文的动态注入

MCP 的资源（Resources）原语使 AI 助手能够在对话过程中按需读取外部数据，并将这些数据作为上下文注入到提示词中，使模型能够基于最新、最相关的信息生成回复，而不受训练数据时效性的限制。

3. 支持多轮工具调用与复杂推理

有状态的 MCP 会话支持 AI 助手在多次用户交互之间维持工具调用上下文，使助手能够进行多轮推理——先调用一个工具获取信息，基于返回结果决定下一步操作，逐步完成复杂任务。

4. 统一不同 AI 模型的工具调用接口

AI 助手开发者只需针对 MCP 协议进行一次适配，即可让助手支持任意兼容 MCP 的工具服务端，无需为每个工具单独编写集成代码，也无需受限于特定大模型提供商的工具调用格式。

5. 促进 AI 助手生态的开放与协作

MCP 使 AI 助手的能力扩展不再依赖厂商专有接口，任何开发者均可以为同一助手开发新的 MCP 服务端，形成开放的插件生态。用户也可以自由选择和组合不同的 MCP 服务端，定制符合自身需求的 AI 助手。

十四、如何使用 MCP 构建自定义 AI 工作流？

1. 明确工作流步骤与所需工具

分析目标工作流的各个环节，确定每个环节需要 AI 执行的动作和需要访问的数据源，并将这些动作和数据源映射为 MCP 原语（Tools 用于执行动作，Resources 用于读取数据，Prompts 用于规范交互格式）。

2. 选择或开发各环节的 MCP 服务端

对于工作流中涉及的每个外部系统，选择社区已有的 MCP 服务端或自行开发。开发自定义服务端时，使用官方 MCP SDK（TypeScript 或 Python），按照协议规范暴露工具、资源或提示词。

3. 在 AI 应用中配置多服务端连接

在 AI 宿主应用中配置到各个 MCP 服务端的连接（每个服务端对应一个 MCP 客户端实例）。宿主应用负责协调多个客户端，并实现工作流的逻辑编排（如顺序执行、条件分支、并行调用）。

4. 设计提示词模板规范 AI 行为

利用 MCP 的 Prompts 原语，为工作流中的每个环节设计可复用的提示词模板，确保 AI 在每个环节的输入输出格式一致，减少随机性，提高工作流的可预测性和可靠性。

5. 测试、监控与迭代优化

在工作流投入使用前，通过 MCP Inspector 等开发工具测试各服务端的能力暴露和工具调用是否正常。在生产环境中开启日志记录，监控 AI 工作流的执行情况，并根据实际效果持续优化服务端实现和提示词设计。

十五、如何开发一个 MCP Server？

1. 选择开发语言与 SDK

MCP 官方提供了 TypeScript 和 Python 两种主流语言的 SDK，此外社区也贡献了 C#、Go、Rust、Java、Swift 等语言的实现。对于大多数场景，推荐使用官方 TypeScript SDK（@modelcontextprotocol/sdk）或 Python SDK（mcp），以获得最好的协议兼容性和文档支持。截至 2026 年，MCP 已成为 Linux Foundation 旗下的开放标准，主流语言均有活跃维护的 SDK 实现。

2. 设计服务端暴露的原语

明确服务端需要暴露哪些工具（Tools）、资源（Resources）和提示词（Prompts）。为每个原语编写清晰的描述文字（description），因为 AI 模型会根据描述文字决定是否调用该原语。使用 JSON Schema（TypeScript）或 Zod（Python）定义工具输入参数的类型和约束。

3. 实现工具逻辑与错误处理

编写工具对应的实际执行逻辑，如调用外部 API、查询数据库、读取文件等。注意：基于 Stdio 传输的服务端 严禁 向标准输出（stdout）打印日志，否则会破坏 JSON-RPC 消息格式导致服务端崩溃；应使用标准错误（stderr）或文件记录日志。

4. 选择并配置传输方式

对于本地使用的服务端，使用 Stdio 传输（从标准输入读、向标准输出写 JSON-RPC 消息）。对于需要远程访问的服务端，使用 Streamable HTTP 传输，并配置相应的认证机制（如 OAuth、API 密钥）。完成实现后，使用 MCP Inspector 工具进行本地测试。

5. 打包发布与部署

将服务端打包发布到对应的包管理平台（TypeScript 发布到 npm，Python 发布到 PyPI），并在 MCP 社区目录中提交服务端信息，方便其他开发者发现和选用。对于企业内部使用的服务端，部署在内部服务器上，并配置好访问控制和安全审计机制。