MCP 入门到实践：用统一协议构建企业级 Agent 工具生态

---

1. 标题 (Title)

这里提供 5 个兼顾技术深度、读者吸引力与关键词覆盖的标题选项：

• 《从 Agent 调用混乱到工具生态标准化：MCP 模型上下文协议入门到企业级实践》
• 《MCP 实战指南：告别 100 种工具适配代码，1 个协议连起企业所有 AI Agent 与业务系统》
• 《Anthropic 官方主推的 MCP 到底牛在哪？手把手教你把 GitHub、Jira、飞书接给你的 LLM Agent》
• 《Model Context Protocol (MCP) 入门：技术原理、架构拆解与企业落地全流程》
• 《重构 Agent 工具调用体系：用 MCP 统一协议解决企业级 LLM 应用的最后一公里》

---

2. 引言 (Introduction)

2.1 痛点引入 (Hook)

如果你是一名正在开发企业级 LLM 应用的前端/后端工程师、AI 产品经理或者 DevOps 负责人，你大概率遇到过这些让人头疼到挠墙的问题：

1. 工具适配的“重复造轮子”地狱：公司里有 10 个不同的业务部门，分别在用 GitHub 管理代码、Jira 追踪需求、飞书/钉钉做协作、MongoDB 存业务数据、Prometheus 监控服务器状态、Salesforce 管客户……每个部门都想自己做一个专属 Agent，但你要为每个 Agent 适配 10 种完全不同的工具 SDK——光是飞书的机器人开放平台接口文档就有 100+ 页，GitHub 的 GraphQL API 更是晦涩难懂，Jira Cloud 和 Jira Server 的 API 还不兼容！上周你刚为市场部的 Agent 适配了飞书的消息发送和 Salesforce 的客户查询，这周产品部的 Agent 又要同样的功能，你只能复制粘贴一堆代码，改改配置变量，简直是在“用代码搬运工的身份做架构师的梦”。
2. Agent 上下文管理的“信息孤岛”困境：好不容易把 10 种工具都适配完了，你发现更大的问题来了——每个工具给 Agent 返回的数据格式千差万别！比如 Jira 给的是复杂的 JSON 嵌套对象，里面有 issueKey、summary、assignee.emailAddress 等几十个字段；飞书给的消息查询结果是数组，数组元素的字段名是中文拼音首字母缩写（比如 msgId 是 msg_id，senderId 是 sender_id，甚至还有部门信息在 dept_info_list 里）；Prometheus 给的监控数据是 CSV 格式或者带时间戳的 PromQL 查询结果数组。LLM 虽然强大，但面对这些格式混乱、字段冗余甚至语义不明确的数据，要么完全理解不了，要么会提取错误的信息——比如上周市场部的 Agent 本来要查“2024年Q1销售额超过100万的北京客户”，结果因为 Salesforce 返回的客户字段 region 有时候是“Beijing”有时候是“北京”，飞书的客户对接群消息查询字段里“区域”写在“备注”里，它居然只查到了 3 个客户，而实际有 27 个！
3. 工具调用权限的“失控风险”：为了让 Agent 能顺利调用工具，很多团队一开始都是“一上来就给最高权限”——比如给飞书机器人的权限是“读取所有部门的所有消息、修改所有成员的日程、发送群公告@所有人”，给 GitHub Personal Access Token (PAT) 的权限是“读取所有仓库的代码、提交 PR、合并 PR、删除仓库”，给 MongoDB 的连接字符串是直接暴露的 root 用户密码！这简直是在“给 AI 一把开金库的钥匙，还告诉它‘随便用，用完记得锁门’”——上周网上就爆出来过一个新闻：某创业公司的内部 Agent 因为被黑客攻击了提示词，居然用 GitHub PAT 删除了公司核心仓库的所有代码，用 MongoDB root 用户密码清空了所有业务数据，损失超过 500 万！
4. 工具生态维护的“不可持续”问题：你好不容易花了 3 个月的时间，把 10 种工具都适配完了，把上下文管理的逻辑写好了，把权限控制的代码加上了，以为终于可以松口气了——结果飞书机器人开放平台更新了 API 接口（原来的 send_group_message 接口改成了 send_message_to_group，参数顺序也变了），Jira Cloud 推出了新的 OAuth 2.0 认证方式（原来的 API Token 要在 6 个月后过期），市场部又提出要新增一个“对接抖音企业号后台”的工具！这时候你发现，之前写的 10000+ 行工具适配代码、5000+ 行上下文管理代码、3000+ 行权限控制代码，全都是紧耦合的“意大利面代码”——改飞书的一个接口，可能会影响到市场部、产品部、销售部 3 个 Agent；加一个抖音的工具，可能要重新写认证逻辑、数据格式转换逻辑、权限控制逻辑，甚至还要修改 Agent 的提示词工程！这时候你才明白：原来自己之前做的不是“架构设计”，而是“临时补丁”，这个“临时补丁”随着业务的发展，只会越来越大、越来越破，最终导致整个项目的崩溃。

2.2 文章内容概述 (What)

如果你正在被这些问题困扰，那么恭喜你——Anthropic 在 2024 年 6 月推出的 Model Context Protocol (MCP) 就是专门为了解决这些问题而生的！

MCP 是一个开源的、标准化的、轻量级的双向通信协议，它的核心目标是：用一套统一的协议，连接起所有的 LLM Agent（无论是 Claude、GPT-4o、Gemini，还是你自己微调的开源模型）和所有的外部工具/数据源（无论是 GitHub、Jira、飞书、MongoDB，还是你自己开发的内部业务系统），让 Agent 调用工具、获取上下文、管理权限变得简单、安全、高效、可维护。

本文将带你从 0 到 1，再到企业级落地，全面学习 MCP：

1. MCP 入门篇：我们会先搞清楚 MCP 到底是什么、它的核心设计理念是什么、它和传统的工具调用方式（比如 OpenAI Functions/Tools、LangChain Tools）有什么区别、它为什么能解决我们刚才提到的那些痛点。
2. MCP 技术原理篇：我们会深入拆解 MCP 的技术架构（包括 Agent 端、MCP Server 端、工具端三层）、核心通信协议（基于 JSON-RPC 2.0 的双向通信）、核心概念（比如 Resource、Tool、Prompt、Capability、Authentication）。
3. MCP 实战入门篇：我们会用 Python 从零开始搭建一个最简单的 MCP Server，然后把它连接到 Anthropic 的 Claude Desktop 客户端（这是目前最好用的 MCP Agent 测试工具），让 Claude 能调用我们自己写的“查询当前时间”、“生成随机数”、“读取本地文件”这三个简单的工具。
4. MCP 实战进阶篇：我们会在入门篇的基础上，把企业常用的三个工具（GitHub、Jira Cloud、飞书）接给 MCP Server，并加入权限控制逻辑、数据格式标准化逻辑、上下文缓存逻辑，最后把这个 MCP Server 部署到 Docker 容器里，方便企业内部所有 Agent 调用。
5. MCP 企业级落地篇：我们会探讨一些企业级落地时必须考虑的问题，比如如何封装一个通用的 MCP Server 框架、如何对接多个 MCP Server（多 Server 编排）、如何监控 MCP Server 的运行状态、如何处理 MCP Server 的高并发请求、如何进行 MCP 的安全审计。
6. MCP 行业发展与未来趋势篇：我们会回顾一下 Agent 工具调用体系的发展历史，分析一下 MCP 的优势和不足，展望一下 MCP 的未来发展方向。

2.3 读者收益 (Why)

读完本文，你将能够：

1. 全面理解 MCP：搞清楚 MCP 的核心概念、技术原理、架构设计，能准确判断 MCP 是否适合你的项目。
2. 独立搭建 MCP Server：用 Python 从零开始搭建一个 MCP Server，能把任何外部工具/数据源（无论是开源的、商业的，还是你自己开发的）接给 MCP Server。
3. 对接 Claude/GPT 等 Agent：能把自己搭建的 MCP Server 连接到 Claude Desktop、OpenAI GPT-4o（通过第三方工具如 LangChain MCP 集成）、甚至你自己开发的 Agent。
4. 构建企业级 MCP 工具生态：掌握 MCP 的权限控制、数据格式标准化、上下文缓存、多 Server 编排、监控审计等企业级功能，能为公司构建一个统一的、标准化的、可维护的、安全的 Agent 工具生态。
5. 大幅提升开发效率：告别“重复造轮子”的工具适配工作，原来需要 3 个月才能完成的 10 种工具适配，现在可能只需要 1 周就能完成！

---

3. 准备工作 (Prerequisites)

在开始学习 MCP 之前，你需要具备以下知识和环境：

3.1 技术栈/知识

1. Python 基础：本文的所有实战代码都是用 Python 写的，你需要熟悉 Python 的基本语法（变量、函数、类、模块、异常处理）、异步编程（async/await、asyncio）、JSON 处理（json 模块）。
2. API 开发基础：你需要熟悉 RESTful API 或 GraphQL API 的基本概念（请求方法、请求参数、响应状态码、响应数据格式）、认证方式（API Token、OAuth 2.0）。
3. LLM Agent 基础：你需要了解 LLM Agent 的基本概念（什么是 Agent、什么是工具调用、什么是上下文）、最好用过 OpenAI Functions/Tools 或 LangChain Tools。
4. Docker 基础（可选，企业级落地篇需要）：你需要了解 Docker 的基本概念（镜像、容器、Dockerfile、docker-compose）。

3.2 环境/工具

1. Python 环境：你需要安装 Python 3.10 或更高版本（因为 MCP 的 Python SDK 依赖 asyncio 的新特性），你可以从 Python 官网 下载安装。
2. Claude Desktop 客户端：这是目前最好用的 MCP Agent 测试工具，你可以从 Anthropic 官网 下载安装（支持 macOS、Windows、Linux）。
3. 代码编辑器：推荐使用 VS Code 或 PyCharm，VS Code 可以安装 Python 插件和 MCP 相关的插件（比如 Anthropic MCP Helper）。
4. GitHub 账号（实战进阶篇需要）：你需要一个 GitHub 账号，用来生成 Personal Access Token (PAT)，测试 GitHub 工具的调用。
5. Jira Cloud 账号（实战进阶篇需要）：你需要一个 Jira Cloud 账号（可以免费注册一个试用版），用来生成 API Token，测试 Jira Cloud 工具的调用。
6. 飞书开放平台账号（实战进阶篇需要）：你需要一个飞书开放平台账号（可以用个人飞书账号登录），用来创建一个企业自建应用，获取 App ID 和 App Secret，测试飞书工具的调用。

---

4. MCP 入门篇：搞清楚 MCP 到底是什么

4.1 什么是 MCP？

Model Context Protocol (MCP) 是 Anthropic 在 2024 年 6 月正式发布的一个开源的、标准化的、轻量级的双向通信协议，它的官方定义是：

Model Context Protocol (MCP) is an open protocol for connecting AI assistants (agents) to external tools, data sources, and systems. It provides a standardized way for agents to discover, authenticate with, and interact with external resources, making it easier to build powerful, secure, and maintainable AI applications.

简单来说，MCP 就是AI Agent 和外部工具/数据源之间的“通用翻译官”和“统一调度中心”：

1. 通用翻译官：它把 Agent 发出的“统一格式的工具调用请求”翻译成每个工具/数据源能理解的“特定格式的 API 请求”，再把每个工具/数据源返回的“特定格式的 API 响应”翻译成 Agent 能理解的“统一格式的上下文数据”。
2. 统一调度中心：它负责管理所有外部工具/数据源的发现、认证、权限控制、请求路由、响应处理、上下文缓存等核心功能，让 Agent 不需要关心每个工具/数据源的具体实现细节，只需要通过 MCP 协议调用它们即可。

4.2 MCP 的核心设计理念

MCP 的核心设计理念可以用 “三个统一、两个分离、一个轻量” 来概括：

4.2.1 三个统一

1. 统一的通信协议：MCP 基于 JSON-RPC 2.0 这个成熟的、标准化的远程过程调用协议，实现了 Agent 和外部工具/数据源之间的双向通信——Agent 可以向外部工具/数据源发送请求（比如调用工具、读取资源），外部工具/数据源也可以主动向 Agent 推送通知（比如 GitHub 的 PR 合并通知、Jira 的需求状态变更通知）。
2. 统一的工具/资源描述格式：MCP 定义了一套标准化的 JSON Schema，用来描述外部工具/数据源的所有信息——比如工具的名称、描述、输入参数、输出结果，资源的类型、URI、权限要求，Prompt 的模板、变量、触发条件等。Agent 可以通过 MCP 协议自动发现这些信息，不需要手动编写工具/资源的调用代码，也不需要修改 Agent 的提示词工程（当然，适当的提示词优化还是有必要的）。
3. 统一的上下文数据格式：MCP 定义了一套标准化的上下文数据格式（叫做 ContextItem），用来统一表示所有外部工具/数据源返回的信息——比如文本、图片、音频、视频、JSON 对象、Markdown 文档等。Agent 可以直接理解这些标准化的 ContextItem，不需要再写复杂的数据格式转换逻辑。

4.2.2 两个分离

1. Agent 与工具/数据源的分离：Agent 不需要关心每个工具/数据源的具体实现细节（比如用的是什么 API、怎么认证、数据格式是什么），只需要通过 MCP 协议调用它们即可——这就意味着，你可以随时更换 Agent（比如从 Claude 换成 GPT-4o，再换成 Gemini），而不需要修改任何工具/数据源的适配代码；你也可以随时更换工具/数据源（比如从 GitHub 换成 GitLab，再换成 Gitee），而不需要修改任何 Agent 的代码。
2. 工具/数据源适配逻辑与 MCP Server 核心逻辑的分离：MCP 把工具/数据源的适配逻辑（比如 API 请求的封装、API 响应的解析、数据格式的转换）封装在 MCP Server 的插件（Plugin） 里，而 MCP Server 的核心逻辑（比如通信协议的处理、工具/资源的发现、认证的管理、权限的控制、请求的路由、响应的处理、上下文的缓存）是通用的——这就意味着，你可以像搭积木一样，快速添加或删除 MCP Server 的插件，而不需要修改 MCP Server 的核心代码；你也可以把自己写的插件分享给别人，或者使用别人分享的插件（Anthropic 已经在 GitHub 上开源了一个官方的 MCP Server 插件仓库，里面有 GitHub、Jira、Google Drive、Slack 等常用工具的插件）。

4.2.3 一个轻量

MCP 是一个非常轻量级的协议：

1. 通信开销小：MCP 基于 JSON-RPC 2.0，每个请求/响应的大小通常只有几 KB 到几十 KB，比 RESTful API 或 GraphQL API 的通信开销还要小。
2. 部署成本低：MCP Server 可以部署在任何环境里——比如本地电脑、Docker 容器、云服务器、甚至边缘设备；MCP Server 的资源消耗也非常小，一个普通的 MCP Server 只需要占用几十 MB 的内存和几 MB 的磁盘空间。
3. 学习曲线平缓：MCP 的核心概念非常少（只有 Resource、Tool、Prompt、Capability、Authentication 这几个），技术原理也非常简单（基于 JSON-RPC 2.0 的双向通信），你只需要花几个小时的时间，就能完全理解 MCP 的核心内容。

4.3 MCP 和传统工具调用方式的区别

在 MCP 出现之前，主流的 Agent 工具调用方式主要有两种：OpenAI Functions/Tools（以及后来兼容它的 LangChain Tools、LlamaIndex Tools 等）和自定义 API 调用。下面我们用一个 “表格对比” 和一个 “ER 实体关系图” 来详细分析一下 MCP 和这两种传统工具调用方式的区别。

4.3.1 MCP 与传统工具调用方式的核心属性维度对比

核心属性维度	OpenAI Functions/Tools	自定义 API 调用	Model Context Protocol (MCP)
协议标准化程度	半标准化（只有 OpenAI 及其兼容模型支持，其他模型如 Claude、Gemini 需要自己适配）	无标准化（每个项目都有自己的一套协议）	完全标准化（基于 JSON-RPC 2.0，任何模型、任何工具都可以支持）
工具发现机制	无自动发现（需要手动在 Agent 的提示词里或代码里定义工具的描述、输入参数、输出结果）	无自动发现（完全需要手动编写代码）	有自动发现（Agent 可以通过 MCP 协议自动获取所有工具/资源的标准化 JSON Schema 描述）
数据格式标准化	无标准化（工具返回的 JSON 对象格式由开发者自己定义，Agent 需要理解不同的格式）	无标准化（工具返回的任何格式都有可能，需要手动编写数据格式转换逻辑）	完全标准化（所有工具/资源返回的信息都统一表示为 ContextItem，Agent 可以直接理解）
双向通信能力	单向通信（只有 Agent 可以调用工具，工具不能主动向 Agent 推送通知）	单向通信（通常只有 Agent 可以调用工具，工具主动推送通知需要用 WebSocket 等额外技术）	双向通信（基于 JSON-RPC 2.0 的通知机制，工具可以主动向 Agent 推送通知）
权限控制机制	无内置权限控制（需要手动在工具适配代码里实现）	无内置权限控制（完全需要手动实现）	有内置权限控制（MCP 协议定义了一套标准化的权限模型，支持基于角色的访问控制 RBAC、基于资源的访问控制 ABAC 等）
上下文缓存机制	无内置上下文缓存（需要手动在 Agent 代码里实现）	无内置上下文缓存（完全需要手动实现）	有内置上下文缓存（MCP Server 可以缓存常用的上下文数据，减少 API 调用次数，提升响应速度）
多 Server 编排能力	无（只能连接一个工具集，多个工具集需要手动在 Agent 代码里编排）	无（完全需要手动编排）	有（MCP 定义了一套多 Server 编排的标准，Agent 可以同时连接多个 MCP Server，自动发现所有工具/资源）
Agent 与工具的耦合度	中高（Agent 需要知道工具的具体描述、输入参数、输出结果，更换工具需要修改 Agent 的提示词或代码）	极高（Agent 需要知道工具的具体 API 接口、认证方式、数据格式，更换工具需要重写 Agent 的代码）	极低（Agent 只需要知道 MCP 协议，不需要知道工具的任何具体实现细节，更换 Agent 或工具都不需要修改对方的代码）
生态成熟度	较高（有很多开源的工具库，比如 LangChain Tools、LlamaIndex Tools）	极低（每个项目都有自己的工具库，难以复用）	快速增长（Anthropic 已经开源了官方的 MCP Server 框架和常用工具的插件，社区也在积极贡献）

4.3.2 MCP 与传统工具调用方式的 ER 实体关系图

为了更直观地理解 MCP 和传统工具调用方式的区别，我们用 Mermaid ER 架构图 来分别展示它们的实体关系：

（1）OpenAI Functions/Tools 的 ER 实体关系图

从这个 ER 图可以看出，OpenAI Functions/Tools 的耦合度非常高：

1. Agent 需要手动定义每个 OpenAI Tool 或 LangChain Tool 的名称、描述、输入参数 JSON Schema。
2. OpenAI Tool 或 LangChain Tool 的实现需要手动封装每个 External API 的调用逻辑、认证逻辑、数据格式转换逻辑。
3. 更换 Agent（比如从 GPT-4o 换成 Claude）需要重写 Agent 的系统提示词（因为 Claude 不直接支持 OpenAI Functions/Tools 的格式）。
4. 更换 External API（比如从 GitHub REST API 换成 GitHub GraphQL API）需要重写 OpenAI Tool 或 LangChain Tool 的实现代码。

（2）自定义 API 调用的 ER 实体关系图

从这个 ER 图可以看出，自定义 API 调用的耦合度是最高的：

1. 所有的工具调用逻辑、认证逻辑、数据格式转换逻辑、权限检查逻辑、上下文缓存逻辑都耦合在 Agent 的自定义代码里，形成了大量的“意大利面代码”。
2. 更换 Agent、更换 External API、甚至修改 External API 的一个参数，都可能需要重写大量的自定义代码。
3. 代码的可复用性、可维护性、可扩展性都极差。

（3）Model Context Protocol (MCP) 的 ER 实体关系图

从这个 ER 图可以看出，MCP 的耦合度是最低的：

1. Agent 与 MCP Server 完全分离：Agent 只需要通过 MCP Client 发送 JSON-RPC 2.0 请求，不需要知道任何工具/资源的具体实现细节；系统提示词也非常简单，只需要说明“你可以通过 MCP 协议调用外部工具、读取外部资源、使用外部 Prompt”即可。
2. MCP Server 核心逻辑与 MCP Plugin 完全分离：MCP Server 的核心逻辑（通信协议处理、插件管理、认证管理、权限管理、上下文缓存、请求路由）是通用的，不需要修改；工具/资源的适配逻辑、认证逻辑都封装在 MCP Plugin 里，可以像搭积木一样快速添加或删除。
3. MCP Plugin 之间完全分离：每个 MCP Plugin 都是独立的，修改一个 Plugin 的代码不会影响其他 Plugin 的运行。
4. 代码的可复用性、可维护性、可扩展性都极高：你可以把自己写的 MCP Plugin 分享给别人，也可以使用别人分享的 MCP Plugin；更换 Agent、更换 MCP Server、更换 MCP Plugin、甚至更换 External API，都不需要修改太多的代码。

4.4 MCP 为什么能解决我们之前提到的痛点？

现在我们已经搞清楚了 MCP 的核心概念、设计理念和与传统工具调用方式的区别，接下来我们再来看看 MCP 为什么能解决我们在引言部分提到的那些让人头疼到挠墙的痛点：

4.4.1 解决“工具适配的重复造轮子地狱”

MCP 通过 “统一的通信协议” 和 “插件化的架构设计” 解决了这个痛点：

1. 统一的通信协议：所有的 Agent 和所有的工具/数据源都通过 MCP 协议通信，不需要为每个 Agent 适配每个工具/数据源的 SDK。
2. 插件化的架构设计：工具/数据源的适配逻辑封装在 MCP Plugin 里，你只需要写一次 Plugin，就可以让所有的 Agent 调用这个 Plugin 里的工具/资源；Anthropic 已经在 GitHub 上开源了一个官方的 MCP Server 插件仓库（mcp-protocol/servers），里面有 GitHub、Jira、Google Drive、Slack、PostgreSQL、MySQL 等常用工具/数据源的 Plugin，你可以直接拿来用，不需要自己写！

比如之前提到的市场部、产品部、销售部都要用到的飞书消息发送和 Salesforce 客户查询工具——你只需要写一个“飞书 Plugin”和一个“Salesforce Plugin”，或者直接使用社区开源的 Plugin，然后把这两个 Plugin 加载到公司的 MCP Server 里，三个部门的 Agent 就都可以通过 MCP 协议调用这两个工具了，不需要再复制粘贴任何代码！

4.4.2 解决“Agent 上下文管理的信息孤岛困境”

MCP 通过 “统一的工具/资源描述格式” 和 “统一的上下文数据格式” 解决了这个痛点：

1. 统一的工具/资源描述格式：Agent 可以通过 MCP 协议自动获取所有工具/资源的标准化 JSON Schema 描述，不需要手动编写工具/资源的调用代码，也不需要修改 Agent 的提示词工程（当然，适当的提示词优化还是有必要的）。
2. 统一的上下文数据格式：所有工具/资源返回的信息都统一表示为 ContextItem，ContextItem 支持文本、图片、音频、视频、JSON 对象、Markdown 文档等多种格式，Agent 可以直接理解这些标准化的 ContextItem，不需要再写复杂的数据格式转换逻辑！

比如之前提到的市场部 Agent 查询“2024年Q1销售额超过100万的北京客户”的问题——你可以在“Salesforce Plugin”和“飞书 Plugin”里，把所有返回的客户信息都统一转换为标准化的 ContextItem，ContextItem 里的字段名都是统一的英文（比如 customer_id、customer_name、region、sales_amount_q1_2024、contact_group_link），region 字段的值也统一转换为英文（比如“Beijing”），这样 Agent 就可以准确地提取到所有符合条件的客户信息了！

4.4.3 解决“工具调用权限的失控风险”

MCP 通过 “内置的权限控制机制” 和 “插件化的认证机制” 解决了这个痛点：

1. 内置的权限控制机制：MCP 协议定义了一套标准化的权限模型，支持基于角色的访问控制 RBAC、基于资源的访问控制 ABAC 等；你可以在 MCP Server 里为每个 Agent 配置不同的权限，比如市场部的 Agent 只能调用飞书的消息发送工具和 Salesforce 的客户查询工具（只能查询北京地区的客户），产品部的 Agent 只能调用 Jira 的需求查询和创建工具，技术部的 Agent 才能调用 GitHub 的代码读取和 PR 提交工具。
2. 插件化的认证机制：每个 MCP Plugin 都可以有自己独立的认证实现（比如 API Token、OAuth 2.0、SAML 等）；你不需要把认证信息（比如 GitHub PAT、飞书 App Secret、MongoDB 连接字符串）直接暴露给 Agent，只需要把认证信息配置在 MCP Server 或 MCP Plugin 的环境变量里，或者通过 OAuth 2.0 流程让 Agent 的使用者（比如市场部的员工）自己授权，这样就大大降低了权限失控的风险！

比如之前提到的给飞书机器人最高权限的问题——你可以在“飞书 Plugin”里配置 OAuth 2.0 认证，让市场部的员工自己用飞书账号授权，授权的权限只能是“读取本部门的群消息、发送本部门的群消息、修改自己的日程”，这样即使 Agent 被黑客攻击了提示词，它也只能访问授权用户的权限范围内的资源，不会给公司造成太大的损失！

4.4.4 解决“工具生态维护的不可持续问题”

MCP 通过 “插件化的架构设计” 和 “完全标准化的协议” 解决了这个痛点：

1. 插件化的架构设计：工具/数据源的适配逻辑封装在 MCP Plugin 里，修改一个 Plugin 的代码不会影响 MCP Server 的核心逻辑，也不会影响其他 Plugin 的运行；比如飞书机器人开放平台更新了 API 接口，你只需要修改“飞书 Plugin”的代码，不需要修改市场部、产品部、销售部三个 Agent 的代码；加一个抖音的工具，你只需要写一个“抖音 Plugin”，或者直接使用社区开源的 Plugin，然后把它加载到公司的 MCP Server 里，不需要修改任何 Agent 的代码！
2. 完全标准化的协议：MCP 是一个完全标准化的协议，不会因为某个公司的政策变化而停止维护（Anthropic 已经把 MCP 捐给了 Linux Foundation，成为了一个开源社区项目）；你不需要担心 MCP 会像某些商业工具的 SDK 一样，突然停止更新或者收费！

4.5 MCP 的核心概念

在进入技术原理篇之前，我们先来搞清楚 MCP 的几个最核心的概念：

4.5.1 MCP Client（MCP 客户端）

MCP Client 是运行在 Agent 端的组件，它的主要功能是：

1. 与 MCP Server 建立连接（支持 stdio、WebSocket、HTTP 等多种传输方式）。
2. 向 MCP Server 发送 JSON-RPC 2.0 请求（比如调用工具、读取资源、列出工具/资源、使用 Prompt）。
3. 处理 MCP Server 返回的 JSON-RPC 2.0 响应。
4. 处理 MCP Server 主动推送的 JSON-RPC 2.0 通知（比如 GitHub 的 PR 合并通知、Jira 的需求状态变更通知）。

目前，Anthropic 官方已经为 Claude Desktop 客户端内置了 MCP Client，你只需要在 Claude Desktop 的配置文件里添加 MCP Server 的配置，就可以让 Claude 调用 MCP Server 里的工具/资源了；另外，LangChain、LlamaIndex 等主流的 Agent 框架也已经或正在集成 MCP Client，你可以用这些框架来开发自己的 Agent，并连接到 MCP Server。

4.5.2 MCP Server（MCP 服务端）

MCP Server 是运行在工具/数据源端的组件（或者运行在一个中间服务器上），它的主要功能是：

1. 与 MCP Client 建立连接（支持 stdio、WebSocket、HTTP 等多种传输方式）。
2. 加载并管理 MCP Plugin。
3. 处理 MCP Client 发送的 JSON-RPC 2.0 请求（比如调用工具、读取资源、列出工具/资源、使用 Prompt）。
4. 向 MCP Client 返回 JSON-RPC 2.0 响应。
5. 主动向 MCP Client 推送 JSON-RPC 2.0 通知（比如 GitHub 的 PR 合并通知、Jira 的需求状态变更通知）。
6. 管理认证、权限、上下文缓存等核心功能。

目前，Anthropic 官方已经开源了一个用 Python 写的 MCP Server 框架（mcp-protocol/python-mcp），你可以用这个框架来快速搭建自己的 MCP Server；另外，社区也已经开源了用 TypeScript、Go、Rust 等语言写的 MCP Server 框架。

4.5.3 MCP Plugin（MCP 插件）

MCP Plugin 是封装了工具/数据源适配逻辑的组件，它的主要功能是：

1. 向 MCP Server 注册工具、资源、Prompt。
2. 实现工具的调用逻辑、资源的读写逻辑、Prompt 的渲染逻辑。
3. 实现插件的认证逻辑（可选）。

MCP Plugin 是 MCP 生态的核心，Anthropic 已经在 GitHub 上开源了一个官方的 MCP Server 插件仓库（mcp-protocol/servers），里面有很多常用工具/数据源的 Plugin，你可以直接拿来用，也可以参考这些 Plugin 来写自己的 Plugin。

4.5.4 Resource（资源）

Resource 是MCP Server 可以提供给 Agent 访问的任何数据或信息，比如：

1. 本地资源：本地文件、本地目录、本地环境变量、本地数据库等。
2. 远程资源：GitHub 仓库的代码、Jira 的需求、飞书的消息、Google Drive 的文档、Salesforce 的客户数据等。

Resource 有一个唯一的 URI（Uniform Resource Identifier，统一资源标识符），Agent 可以通过 URI 来读取或写入 Resource；Resource 还可以有元数据（比如文件的大小、修改时间、权限，Jira 需求的状态、创建时间、负责人等）。

4.5.5 Tool（工具）

Tool 是MCP Server 可以提供给 Agent 调用的任何功能或操作，比如：

1. 本地工具：查询当前时间、生成随机数、执行本地命令（需要谨慎使用）等。
2. 远程工具：GitHub 的创建 PR、合并 PR、删除文件，Jira 的创建需求、修改需求状态、添加评论，飞书的发送消息、创建日程、发起会议等。

Tool 有一个唯一的名称、一个描述、一个输入参数 JSON Schema、一个输出结果 JSON Schema（可选）；Agent 可以通过 MCP 协议自动获取 Tool 的这些信息，然后根据用户的请求调用对应的 Tool。

4.5.6 Prompt（提示词）

Prompt 是MCP Server 可以提供给 Agent 使用的标准化提示词模板，比如：

1. 代码审查提示词模板：用于审查 GitHub 仓库的 PR。
2. 需求分析提示词模板：用于分析 Jira 的需求。
3. 客户跟进提示词模板：用于跟进 Salesforce 的客户。

Prompt 有一个唯一的名称、一个描述、一个变量列表（可选）；Agent 可以通过 MCP 协议自动获取 Prompt 的这些信息，然后根据用户的请求填充变量，生成最终的提示词。

4.5.7 Capability（能力）

Capability 是MCP Server 或 MCP Plugin 可以提供的功能类型，目前 MCP 协议定义了以下几种核心 Capability：

1. tools：提供 Tool 调用功能。
2. resources：提供 Resource 读写功能。
3. prompts：提供 Prompt 使用功能。
4. logging：提供日志记录功能（MCP Server 可以把日志发送给 MCP Client，MCP Client 可以把日志显示给用户）。
5. sampling：提供 LLM 采样功能（MCP Server 可以请求 MCP Client 调用 LLM 生成文本，比如 MCP Server 需要生成一个代码审查报告，它可以请求 MCP Client 调用 Claude 生成）。

4.5.8 Authentication（认证）

Authentication 是MCP Server 或 MCP Plugin 用来验证 MCP Client（或 Agent 的使用者）身份的机制，目前 MCP 协议支持以下几种常见的认证方式：

1. None：无需认证（适用于本地 MCP Server，提供的工具/资源都是安全的）。
2. API Token：通过 API Token 认证（适用于大多数公共 API，比如 GitHub REST API）。
3. OAuth 2.0：通过 OAuth 2.0 流程认证（适用于需要用户授权的 API，比如飞书开放平台 API、Google Drive API）。
4. SAML：通过 SAML 流程认证（适用于企业内部的单点登录 SSO）。

---

（未完待续，下一章节将深入拆解 MCP 的技术原理、架构设计、核心通信协议 JSON-RPC 2.0）