[AIGC/Agent] MCP := 模型上下文协议 := AI Agent应用与外部系统集成的标准协议
0 引言
火爆 AI 编程圈的 MCP 到底是个什么东西？
-
最近，如果你经常使用 AI 编程的话，肯定听到过 MCP 这个概念
-
那到底什么是 MCP 呢？
-
AI 应用层的开发并没有多少新的东西，大体还是老三样：
Prompt、RAG、Agent。
但是自从 2024 年 11 月底 Claude (Anthropic) 主导发布了 MCP(Model Context Protocol 模型上下文协议) 后，AI 应用层的开发算是进入了新的时代。
MCP 就是以更标准的方式让 LLM Chat 使用不同工具，更简单的可视化如下图所示
这样你应该更容易理解“中间协议层”的概念了。Anthropic 旨在实现 LLM Tool Call 的标准。
1 概述：MCP
MCP 定义
- 先从专业角度讲，
MCP就是Anthropic(Claude) 主导发布的一个AI Agent框架领域的、开放的、通用的、有共识的协议标准。 Model Context Protocol(MCP)
MCP 功能与作用
- MCP 是一个标准协议，就像给 AI 大模型装了一个 “万能接口”，让 AI 模型能够与不同的数据源和工具进行无缝交互。
- MCP 旨在替换碎片化的 Agent 代码集成，从而使 AI 系统更可靠，更有效。
- 通过建立通用标准，服务商可以基于协议来推出它们自己服务的 AI 能力，支持开发者更快的构建更强大的 AI 应用。
- 开发者也不需要重复造轮子，通过开源项目可以建立强大的 AI Agent 生态。
- MCP 可以在不同的应用 / 服务之间保持上下文，增强整体自主执行任务的能力。
MCP 是一个标准协议，如同电子设备的
Type C协议(可以充电也可以传输数据)，使 AI 模型能够与不同的 API 和数据源无缝交互。
MCP 的必要性
- 举例：目前不能同时通过某个 AI 应用做到联网搜索、发送邮件、发布博客等，MCP 可解决集成问题。
为什么需要 MCP？
-
在深入 MCP 之前，我们需要先回顾其技术前置——Function Calling（工具调用）。
-
我们知道，LLM 本质上是一个运行在受限计算环境中的『概率预测引擎』 ，核心工作机制是『文字接龙』，这决定了它具备极强的意图识别能力，却无法直接操作现实世界的工具。
-
为了打破这个限制，Function Calling 应运而生，它的基本逻辑为：
大模型负责识别用户意图，基于现有的工具列表，决定是否使用工具，使用哪个工具及参数，最终输出一段符合规范的 JSON Schema 指令。应用程序负责向模型声明具备哪些工具及参数（JSON Schema）；在收到大模型的工具调用指令后，去执行真实的业务逻辑（如 SQL 查询、 HTTP 请求等），并将执行结果反馈给模型。
-
这一流程解决了基本的工具调用需求，但随着 AI 应用复杂度的提升，逐渐暴露出以下工程痛点：
-
接入成本高：工具的具体使用方法被耦合在
应用程序中，导致：- 每接入一个新工具或增加新参数，开发者都需要在业务代码中手动编写详尽的 JSON Schema 描述。当工具库日益庞大时，维护这些描述的质量将耗费大量精力。
- 由于缺乏统一的行业标准，最熟悉工具用法的提供方无法直接提供一份「自描述」规范，接入方必须反复查阅文档并进行二次封装，造成了极大的心智负担。
-
生态系统割裂：每一个应用开发者在接入第三方工具时，都必须从头编写一套属于自己的适配代码，形成了严重的工程重复。
-
-
为了解决上述痛点，Model Context Protocol（MCP） 应运而生。
-
MCP 的出现，就像在混乱的充电接口世界中引入了 USB-C，或者在计算机网络中引入了 TCP/IP 协议。
它定义了一套通用的、与模型无关的通信协议，让应用程序和底层工具实现了彻底解耦。 -
引入 MCP 之后，维护工具 Schema 的『脏活累活』被交还给了最熟悉它的工具提供方。AI 应用程序只需要进行简单配置，就能以标准化的方式获取工具描述并发起调用。这样存在以下优势：
- 一次开发，到处可用：工具提供方只需实现一次 MCP 协议，所有支持该协议的 AI 应用都能直接接入。工具的『使用说明书』由提供方编写和维护，AI 应用只需按照协议进行订阅，极大地降低了集成门槛。
- 架构解耦合：应用程序与第三方工具不再硬编码绑定。业务逻辑被封装在独立的 Server 进程中，开发者可以像拼乐高积木一样，自由组合来自不同供应商的 MCP 服务，各组件独立演进，互不干扰。
- 动态发现与按需加载 ：客户端通过标准接口实时获取 Server 端的工具能力。开发者只需修改配置文件指向不同的 MCP Server 地址，即可实现工具的动态拔插，无需修改核心业务代码。
MCP 优势
- 标准化：MCP 提供了一种统一的通信协议，使得不同的 AI 应用可以更容易地集成和扩展。
- 灵活性：通过 MCP，AI 应用可以连接到各种数据源和工具，增强了其功能和适用性。
- 安全性：MCP 确保了数据传输的安全性，保护了用户的隐私和数据安全。
生活化例子
- 假设班长使用 MCP 处理班级事务，如查成绩、收集反馈、安排值日表，高效且安全。
- 举个通俗易懂的例子:假设你正在使用一个 AI 编程助手来帮助你写代码。这个 AI 助手就是一个 MCP 主机。
它需要访问一些外部资源，比如代码库、文档或者调试工具。
MCP 服务器就像是一个中介，它连接了这些资源和 AI 助手。
- 当你需要查找某个函数的用法时，AI 助手通过 MCP 客户端向 MCP 服务器发送请求。
- MCP 服务器接收到请求后，去代码库或文档中查找相关信息。
- 找到信息后，MCP 服务器将结果返回给 AI 助手。
- AI 助手根据返回的信息，生成一段代码或解释，展示给你。
- 再举个生活化的例子：假设你是一个班长，每天要处理很多班级事务：查班级成绩表（Excel 文件存在电脑里），收集同学反馈（微信群里聊天记录），安排值日表（在线文档）。
- 传统方式：你需要自己打开 Excel、翻微信记录、编辑在线文档，手动整理信息，耗时费力。
- 使用 MCP 后，你直接对 AI 说：“帮我查一下最近数学考试的平均分，把不及格的同学名单整理到值日表里，并在微信群提醒他们补考。”AI 会自动完成：用 “万能插头” MCP 连接你的电脑，读取 Excel 成绩。用 MCP 连接微信，找到相关聊天记录。用 MCP 修改在线文档，更新值日表。整个过程不需要你手动操作，数据也不会离开你的设备，安全又高效。
所以，MCP 厉害的地方在于，不用重复造轮子。过去每个软件（比如微信、Excel）都要单独给 AI 做接口，现在 MCP 统一了标准，就像所有电器都用 USB-C 充电口，AI 一个接口就能连接所有工具。
而且，数据不用上传到云端，AI 直接在本地处理。比如你的成绩单只存在自己电脑里，AI 通过 MCP 读取分析，但数据不会外泄。
MCP 会让 AI 更 “懂” 上下文，比如你让 AI “总结上周班会的重点”，它能自动调取会议录音、聊天记录、笔记文档，综合这些信息给你答案，而不是凭空编造。
所以，MCP 为 AI 应用提供了一个强大的工具，使其能够更灵活、更安全地与外部世界交互。
为什么 MCP 是一个突破？
- 过去一年时间(2024年)，AI 模型的发展非常迅速，从 GPT 4 到 Claude Sonnet 3.5 到 Deepseek R1，推理和幻觉都进步的非常明显。
新的 AI 应用也很多，但我们都能感受到的一点是，目前市场上的 AI 应用基本都是全新的服务，和我们原来常用的服务和系统并没有集成，换句话说，AI 应用和我们已有系统集成发展的很缓慢。
MCP没有出现前，在开发的过程中，将 AI 模型集成现有的系统或者第三方系统确实挺麻烦。
虽然市面上有一些框架支持 Agent 开发，例如 LangChain Tools, LlamaIndex 或者是 Vercel AI SDK。
LangChain 和 LlamaIndex 虽然都是开源项目，但是整体发展还是挺混乱的，首先是代码的抽象层次太高了，想要推广的都是让开发人员几行代码就完成某某 AI 功能，这在 Demo 阶段是挺好用的，但是在实际开发中，只要业务一旦开始复杂，糟糕的代码设计带来了非常糟糕的编程体验。还有就是这几个项目都太想商业化了，忽略了整体生态的建设。
还有一个就是 Vercel AI SDK，尽管个人觉得 Vercel AI SDK 代码抽象的比较好，但是也只是对于前端 UI 结合和部分 AI 功能的封装还不错，最大的问题是和 Nextjs 绑定太深了，对其它的框架和语言支持度不够。
所以 Claude 推动 MCP 可以说是一个很好的时机，首先是 Claude Sonnet 3.5 在开发人员心中有较高的地位，而 MCP 又是一个开放的标准，所以很多公司和社区都愿意参与进来，希望 Claude 能够一直保持一个良好的开放生态。
---- from https://guangzhengli.com/blog/zh/model-context-protocol/
例如，我们目前还不能同时通过某个 AI 应用来做到联网搜索、发送邮件、发布自己的博客等等
这些功能单个实现都不是很难，但是如果要全部集成到一个系统里面，就会变得遥不可及。
- 如果你还没有具体的感受，我们可以思考一下日常开发中，想象一下在 IDE 中，我们可以通过 IDE 的 AI 来完成下面这些工作。
- 询问 AI 来查询本地数据库已有的数据来辅助开发
- 询问 AI 搜索 Github Issue 来判断某问题是不是已知的bug
- 通过 AI 将某个 PR 的意见发送给同事的即时通讯软件(例如 Slack)来 Code Review
- 通过 AI 查询甚至修改当前 AWS、Azure 的配置来完成部署
上述这些功能通过
MCP目前正在变为现实，大家可以关注 Cursor MCP 和 Windsurf MCP 获取更多的信息。
可以试试用 Cursor MCP + browsertools 插件来体验一下在 Cursor 中自动获取 Chrome dev tools console log 的能力。
- 为什么 AI 集成已有服务的进展这么缓慢？
这里面有很多的原因，一方面是企业级的数据很敏感，大多数企业都要很长的时间和流程来动。
另一个方面是技术方面，我们缺少一个开放的、通用的、有共识的协议标准。
MCP就是Claude(Anthropic) 主导发布的一个开放的、通用的、有共识的协议标准。
如果你是一个对 AI 模型熟悉的开发人员，想必对 Anthropic 这个公司不会陌生
他们发布了 Claude 3.5 Sonnet 的模型，到目前为止应该还是最强的编程 AI 模型(就在2025年2月底，发布了更震撼的3.7)。这类协议的发布最好机会应该是属于 OpenAI 的，如果 OpenAI 刚发布 GPT 时就推动协议，相信大家都不会拒绝。
但是 OpenAI 变成了 CloseAI，只发布了一个封闭的 GPTs
这种需要主导和共识的标准协议一般很难社区自发形成，一般由行业巨头来主导。
Claude发布了 MCP 后，官方的Claude Desktop就开放了 MCP 功能，并且推动了开源组织Model Context Protocol，由不同的公司和社区进行参与，例如下面就列举了一些由不同组织发布 MCP 服务器的例子。
为什么是 MCP？Function Calling、AI Agent、MCP 这三者之间有什么区别？(必读)
- 看到这里你可能有一个问题，在 23 年 OpenAI 发布 GPT function calling 的时候，不是也是可以实现类似的功能吗？
我们之前博客介绍的 AI Agent，不就是用来集成不同的服务吗？为什么又出现了 MCP。
- 推荐文献
MCP 对于开源社区生态的贡献
- 开放标准给服务商，服务商可以针对 MCP 开放自己的 API 和部分能力。
- 不需要重复造轮子，开发者可以用已有的开源 MCP 服务来增强自己的 Agent。
MCP 的适用场景 (必读)
- MCP是Agent与外部系统、数据源、工具之间的标准化连接协议，定位AI世界的USB‑C接口，解决M×N集成爆炸；Function Calling是模型调用能力，MCP是上层通信标准，二者配合使用。
核心判断：需要Agent对接外部异构系统、希望工具一次开发多Agent复用、需要动态发现能力、本地/私有数据安全访问，优先MCP；简单单场景原型、仅单一平台使用，直接Function Calling即可。
- MCP包含三类核心资源：Tools工具函数、Resources数据资源、Prompts提示模板，不只是工具调用。
- 传输模式的选型：本地开发用
stdio；线上生产优先Streamable HTTP模式；SSE模式用于兼容旧版本客户端。
0. 最高原则：相比其底层的 Function-Calling，MCP(Tool原语) 更适合跨平台/应用/团队的工具调用场景 （必读）
- MCP vs Function‑Calling vs Skill 快速选型参考
| 方案 | 定位 | 选型时机 |
|---|---|---|
| Function‑Calling | 模型能力，生成调用指令 | 简单原型、单平台、少量工具 |
| MCP | 协议层连接标准 | 对接异构外部系统、工具复用、本地私有数据源、多工具协同（跨平台/应用/团队） |
| Skill | 业务流程封装 | 固化业务流程、领域工作流，内部编排逻辑（内部调用/编排：MCP或FC/Tool、或其他Skill） |
1. 开发IDE / 代码Agent（本地优先）
- Agent安全访问本地文件、Git仓库、终端、数据库、项目文档，敏感数据不上传到大模型云端。
- 场景：代码审查、自动改代码、运行单元测试、读取项目配置、查询框架文档。
- 传输：本地STDIO模式，IDE插件、Claude Code广泛采用。
2. 企业内部多源数据&知识库Agent（最主流企业场景）
企业数据分散飞书、钉钉、Confluence、CRM、数据库、ERP，不想全部灌入向量库做RAG。
- MCP Server对接各个业务系统，Agent按需实时拉取数据，保留原有鉴权、权限控制。
- 场景：内部问答助手、业务查询Agent、工单处理、财务发票处理、招投标数据查询。
对比传统RAG：RAG是复制数据入库；MCP是原位访问原始系统，数据实时、权限继承，适合权限复杂、数据频繁变更的企业系统。
3. 多工具协同复杂工作流Agent
任务需要串联多个异构工具，多步推理、动态选择工具：
- 数据分析Agent：数据库查询→读取CSV→Python计算→绘图→输出报告，每个能力封装独立MCP Server。
- 科研助手：学术库检索→PDF解析→文献提取→生成参考文献。
- 运维Agent：查询K8s集群、日志、执行命令、告警推送。
4. 工具能力生态化复用（一次开发多处Agent调用）
同一个MCP Server，可以被不同Agent、不同大模型客户端直接接入，不用重复开发适配。
- 对外输出业务能力：企查查、法律检索、文档解析封装MCP服务，任意Agent配置即可调用。
- 团队内部公共能力：把公司通用查询、审批接口包装MCP，所有业务Agent直接复用。
5. 本地私有数据、隐私敏感场景
数据不能出本地/内网：本地文档、本地数据库、内网业务系统。
- Agent运行在本地，MCP Server本地进程通信，原始数据不经过第三方大模型服务商。
- 金融、医疗场景，支持操作审计、权限拦截，高风险动作需要人工确认。
6. 云原生生产Agent服务（SSE/HTTP传输）
多用户并发访问，容器部署：
- MCP Server部署后端服务，SSE/HTTP对外提供，多个Agent客户端远程调用。
- 适合B端SaaS产品，多租户Agent平台，统一管理所有外部连接器。
7. Agent访问异构软硬件、IoT设备
打通数字世界与实体设备：
- MCP服务对接IoT网关，Agent控制设备、读取传感器实时数据。
- 多模态：调用图像识别、语音合成等外部能力。
❌ 不适合MCP的场景（避免过度工程）
- 一次性简单Demo、原型验证：少量固定工具，直接Function Calling开发更快。
- 只给单一Agent/单一平台使用的简单工具，没有复用诉求。
- 极简单调用，例如仅获取当前时间，没必要搭建MCP服务。
- 业务流程高度固化，适合封装为Skill，而不是MCP Server。
2 MCP 架构与原理
核心部分（必读）
- MCP 主机（MCP Hosts）：发起请求的 AI 应用程序，比如聊天机器人、AI 驱动的IDE等。
- MCP 客户端（MCP Clients）：在主机程序内部，与MCP 服务器保持 1:1 的连接。
- MCP 服务器（MCP Servers）：为 MCP 客户端提供上下文、工具和提示信息。
- 本地资源（Local Resources）：本地计算机中可供 MCP 服务器安全访问的资源，如文件、数据库。
- 远程资源（Remote Resources）：MCP 服务器可以连接到的远程资源，如通过 API 提供的数据。
MCP Server可暴露的能力 := MCP Server 原语 ={ Tool 【高频】 / Resource 【中频】 / Prompt 【低频】 }（必读）
带着问题来理解本章节：MCP Server 提供的tool、prompt、resources有什么区别？实际企业项目中，三种都有在高频使用吗？
MCP协议里的 tool、resource、prompt 是3种职责完全不同的"原语"。
可以理解为：tool 是"动手做"(模型是决策方)，resource 是"拿来看"，prompt 是"按模板说"（多为特定/固化的场景）。
企业项目里真正高频到几乎必备的是 tool，resource 视场景而定，prompt 的实际使用频率相对低很多。
本质区别
- MCP 官方把
MCP Server可暴露的能力分为3类原语 ：
| 维度 | Tool | Resource | Prompt |
|---|---|---|---|
| 本质 | 可执行函数（基于Function Calling机制构建） | 可读数据源 | 可复用的消息模板 |
| 控制权 | 【模型】决定何时调用 | 【宿主应用】/【用户】主动加载 | 【用户】或【宿主】显式选择 |
| 副作用 | 可以有（写库、发消息、调 API） | 无，纯只读 | 无，只生成文本 |
| 类比 | POST / action | GET / data | 模板库 |
| 寻址 | 按名字+参数调用 | 按 URI 寻址 （如: policy://xxx/...,db://schema/order） |
按模板名+参数 |
-
tool占 80% 以上的设计与开发工作量，resource补充上下文，prompt则是锦上添花 -
举个具体的企业例子——1个 PostgreSQL MCP 服务器 ：
- Tools：
query(sql)、insert(...)、update(...)——【模型】自主决定调用，能改状态- Resources：
table schemas、column types——【客户端】按 URI 拉取，只读上下文- Prompts："Explain this table's relationships" ——【用户】从App应用的菜单里选某个选项，【App应用】将获得一段结构化开场消息后，再二次喂给【模型】
关键认知：prompt 不是普通聊天里的"提示词"，它是服务器暴露出来的、带参数的【可复用】的模板，本身不执行任何操作，只是帮用户/模型把"开场白"结构化 。
Function Calling 与 MCP Tool 的联系: 地基 vs 可选层、MCP Tool 基于FC构建、工具调用默认选FC、跨团队复用时选MCP （必读）
- 推荐文献
-
MCP 的 Tool 最终都要转成
function calling给模型，这一环确实建立在 FC 机制之上 -
MCP 除了 Tool 原语，还包含 Resources（资源）、Prompts（模板）、Sampling、Elicitation 等原语，这些 Function Calling 根本不覆盖；
-
MCP解决的是工具的【发现】与调用、分发、跨应用复用（协议层），Function Calling解决的是 "怎么调"（更底层的地基）。 -
既然 MCP Tool 是基于 Function Calling 了，是否还有必要再单独写 Function Calling。AI Agent 领域，写 Function Calling 的多，还是写 MCP Tool 的多？
- 仍有必要写 Function Calling。二者不是替代关系，是 "【地基:FC】 vs 【可选层:MCP】"：
- FC 是必写层：模型调用工具的底层机制，MCP 落地也依赖它；单应用、工具少、路径明确时直接用
FC最轻量（零服务器、零协议、零额外依赖）；- MCP 是可选层：只有 "多个客户端 / 多个团队要复用同一批工具" 时才值得引入协议开销。
- FC 和 MCP 的业界，写哪个多？—— 目前直接写
Function Calling的仍是绝对多数，但生产里两者混用。
- 大厂 Agent 团队原话："【工具调用】全走原生
Function Call，灵活、轻量、没额外依赖"，痛点只在 "【跨团队复用】" 时暴露，此时才上MCP；- 2026 年业界共识是分层混用：共享工具走
MCP、模型原生推理走FC，二者互补而非二选一；MCP生态增长快，但主要覆盖 "跨客户端复用" 通道；单个 Agent 内部的工具定义仍以 FC 直连为主流。
企业项目里的真实使用频率
纠正一常见误解：三者并非同等高频。
- Kong 的企业 MCP 指南和 LeanMCP 的最佳实践都指出，
tool几乎被所有LLM提供商和客户端广泛支持，而resource和prompt依赖【客户端】实现，很多MCP客户端并没有完整支持 。
Tool ：几乎必备，绝对高频
企业生产环境的 MCP 部署，主流模式是把已有的 REST API 包一层 MCP Server，让 AI 应用能调用 。这意味着：
- 查询订单、创建工单、调用 ERP、发邮件、查数据库——全部走 tool
- tool 是模型唯一能"自主发起动作"的入口，也是企业把 AI 接到业务系统的核心载体
- 企业项目里 tool 的数量通常远多于 resource 和 prompt
Resource：视场景，中频
resource 适合暴露稳定、可缓存、只读的上下文 ：
- 数据库 schema、配置文件、API 文档、企业制度、知识库文档、产品说明书
- 客户端可以按 URI 拉取一次然后缓存，减少服务器压力
但要注意2个现实约束：
- resource 不支持参数，【动态查询】不能用它（那是 tool 的活）
- 依赖客户端支持，Cursor、Claude Desktop 这类宿主支持，但不是所有 MCP 客户端都实现完整 resource 订阅机制
所以企业里 resource 的高频程度取决于客户端能力——如果你们用的是 Claude Desktop、Cursor 这类完整支持 MCP 的宿主，
resource会很常用；如果是自研的轻量客户端，可能就直接全用tool代替了。
Prompt：相对低频，特定场景才用
prompt 在企业里远不如 tool 高频，主要原因：
- 它本质是"消息模板"，用户需要从 UI 菜单里手动选
- 大多数企业 AI 助手的交互是自由对话驱动，而不是"用户去选一个模板来启动任务"
- 它的价值场景比较窄：代码审查模板、周报生成模板、SQL 优化模板、需求分析模板这类高度标准化、可复用的工作流
LeanMCP 明确指出：prompts 在很多 MCP 客户端里支持有限，而且"LLM 把它们当作上下文建议而非硬约束"，不能用来做权限控制 。
企业落地经验：如果你的场景是"让 AI 接业务系统干活"，90% 的精力会花在tool设计上；resource用来喂稳定的背景知识（如：产品说明书、库表的元数据等）；prompt只在有强标准化工作流时才值得做。
三者协同的典型企业案例 （必读）
假设企业 AI 助手接到任务："分析本月销售情况并生成管理层汇报" ：
用户提问
↓
Prompt "销售分析报告"（定义分析框架和输出格式）
↓
Tool query_sales()（获取实时业务数据）
Tool query_customer()（获取客户数据）
↓
Resource 销售指标说明.md（提供业务规则、指标定义）
↓
AI 整理分析 → 输出完整汇报
这个案例里：
- Prompt 定流程框架
- Tool 拉实时数据（高频、核心）
- Resource 提供背景知识（中频、辅助）
选型判断口诀
如果你在设计 MCP Server 时拿不准一个功能该做成哪种【原语】 ：
- 会改变状态 / 需要参数 / 调用外部系统 →
Tool（发邮件、写库、查 API） - 只读、稳定、可缓存、按 URI 寻址 →
Resource（配置文件、schema、文档） - 标准化工作流 / 可复用的开场模板 →
Prompt（代码审查、报告生成）
工作流程、主要使用场景（必读）
- 连接：MCP 主机连接到一个或多个 MCP 服务器。
- 请求：主机发送请求以获取数据或执行工具。
- 处理：服务器处理请求，访问相关数据源或外部服务。
- 返回：服务器将结果返回给主机。
- 生成响应：主机将信息提供给 AI 模型，用于生成用户响应。
按 "三个正交维度" 选了三个代表性场景来画 —— 分别覆盖传输方式（本地 stdio）、部署位置（远程 HTTP + 鉴权）、交互模式（多 Server + 三大原语编排），这样基本覆盖了 MCP 的全部调用形态
场景 1：本地工具调用（stdio 传输）—— 终端应用/入门经典场景
- 特征：MCP Server 以子进程方式跑在【本地】，通过
stdin/stdout与 Client 通信；
Claude Desktop、Trae、Cursor 桌面版默认走这条路。
注意: 初始化握手（initialize → initialized）是每个会话的必经步骤。
要点：
tools/list是动态发现—— 工具清单在运行时获取，而非硬编码，这是 MCP 与 "直接把工具塞进 prompt" 的本质差异；- 图中的
tool_use → tools/call恰好印证了结论：MCP 的工具最终仍通过Function Calling机制呈现给模型。
场景 2：远程工具调用（Streamable HTTP + OAuth）—— 企业生产/网络交互场景
- 特征：MCP Server 部署在云端，Client 通过单一
POST /mcp端点调用（2025-03 新规范，Streamable HTTP传输模式取代已废弃的SSE），以OAuth 2.1+PKCE做鉴权。
这是企业级、跨网络、多租户场景的首选形态。
要点：
- 与场景 1 的唯一差别在传输层与鉴权—— 握手、发现、调用的协议语义完全一致，这正是 MCP"一次实现、处处可用" 的体现；
- 鉴权是远程 MCP 从 "本地玩具" 走向 "企业级" 的关键一步：没有 OAuth，任何远程 MCP 都是公网大洞；
- 支持
chunked streaming（工具结果边生成边返回），配合session id维持会话。
场景 3：多 Server + 三大原语编排 —— Agent 完整任务场景
- 特征：一个 Agent 同时对接多个 MCP Server，并完整使用 MCP 的三大原语——
Tools（模型控制）、Resources（应用注入）、Prompts（用户选择）。
这是 MCP 生态价值的最高形态：工具跨应用、跨 Server 复用。
要点：
- 三大原语的控制权不同：Prompts 由用户触发、Resources 由应用注入、Tools 由模型决策 —— 分工清晰，这是 MCP 设计最巧妙的地方；
- 多 Server 无感协作：Agent 只关心 "能力"，不关心工具来自哪个 Server；数据库和邮件工具分属两个 Server，调用方式完全一致；
- 图中隐藏了一层可选的 Sampling（Server 反向请求 Host 调 LLM），以及 2025-06 新增的 Elicitation（Server 向用户询问确认），多用于复杂交互场景。
综合对比
| 维度 | 场景 1：本地 stdio | 场景 2：远程 HTTP | 场景 3：多 Server 编排 |
|---|---|---|---|
| 传输层 | stdio（子进程） | Streamable HTTP | 两者皆可 |
| 鉴权 | 无（本地信任） | OAuth 2.1 + PKCE | 视 Server 而定 |
| Server 数量 | 1 | 1 | 多个协同 |
| 主要原语 | Tools | Tools | Tools + Resources + Prompts |
| 典型宿主 | Claude Desktop、Trae 桌面版 | 云端 SaaS、企业内网服务 | Agent 应用、自研产品 |
| 定位/总结 | 入门、离线、最快跑通 | 生产、跨网络、企业级 | 生态复用、复杂任务 |
- 选型建议：
- 做本地工具（文件、数据库、脚本）先用场景 1 跑通；
- 要接云端能力（SaaS、远程库）走场景 2；
- 要构建自己的 Agent 产品，场景 3 才是常态 —— 多 Server + 三大原语组合使用。
3 MCP 传输机制
传输机制：STDIO / SSE
- Model Context Protocol（MCP）支持两种主要的传输机制，用于 Cline 和 MCP 服务器之间的通信：标准输入/输出 (Standard Input/Ouput，
STDIO) 和服务器发送事件 (Server Send Event，SSE)。- 每种机制都有其独特的特点、优势和适用场景。
STDIO 传输模式
STDIO 传输在您的本地机器上运行，并通过标准输入/输出流进行通信。
工作原理
- 客户端 (Client) 将 MCP 服务器作为子进程启动
- 通信通过进程流进行：客户端写入服务器的 STDIN，服务器通过 STDOUT 响应
- 每条消息以换行符分隔
- 消息格式：
JSON-RPC 2.0
客户端 服务器
| |
|<---- JSON消息 ----->| (通过STDIN)
| | (处理请求)
|<---- JSON消息 ------| (通过STDOUT)
| |
STDIO 特性
- 本地性：与 Cline 在同一台机器上运行
- 性能：非常低的延迟和开销（不涉及网络栈）
- 简单性：无需网络配置的直接进程通信
- 关系：客户端和服务器之间是一对一关系
- 安全性：由于没有网络暴露，因此本质上更安全
何时使用 STDIO
STDIO 传输适用于：
- 在同一机器上运行的本地集成和工具
- 安全敏感操作
- 低延迟需求
- 单客户端场景（每个服务器一个 Client 实例）
- 命令行工具或 IDE 扩展
STDIO 实现示例
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
const server = new Server({name: 'local-server', version: '1.0.0'});
// 注册工具...
// 使用 STDIO 传输
const transport = new StdioServerTransport(server);
transport.listen();
SSE 传输模式（双端点）
- 服务器发送事件 (SSE) 传输在远程服务器上运行，并通过 HTTP/HTTPS 进行通信。
SSE 传输的工作原理
-
客户端 (Cline) 通过 HTTP GET 请求连接到服务器的 SSE 端点
-
这建立了一个持久连接，服务器可以通过该连接向客户端推送事件
-
对于客户端到服务器的通信，客户端向单独的端点发出 HTTP POST 请求
-
通信通过两个通道进行：
-
- 事件流 (GET)：服务器到客户端的更新
- 消息端点 (POST)：客户端到服务器的请求
客户端 服务器
| |
|---- HTTP GET /events ----------->| (建立 SSE 连接)
|<---- SSE 事件流 --------------| (持久连接)
| |
|---- HTTP POST /message -------->| (客户端请求)
|<---- 带响应的 SSE 事件 ---------| (服务器响应)
| |
SSE 特性
- 远程访问：可以托管在与您的 Cline 实例不同的机器上
- 可扩展性：可以同时处理多个客户端连接
- 协议：通过标准 HTTP 工作（不需要特殊协议）
- 持久性：为服务器到客户端的消息维持持久连接
- 认证：可以使用标准 HTTP 认证机制
何时使用 SSE
SSE 传输更适合：
- 跨网络的远程访问
- 分布式系统架构 / 微服务之间的通信
- 多客户端场景
- 云部署环境
- 公共服务
- 许多用户需要访问的集中式工具
- 与 Web 服务集成
SSE 实现示例
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
import express from 'express';
const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// 注册工具...
// 使用 SSE 传输
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
console.log('MCP server listening on port 3000');
});
Streamable HTTP 传输模式（单端点 / 当前主流）
自2026年以来已成主流，SSE逐渐被废。
- 推荐文献
本地与托管：部署方面
STDIO 和 SSE 传输之间的选择直接影响您将如何部署和管理 MCP 服务器。
STDIO：本地部署模型
STDIO 服务器在与 Client 相同的机器上本地运行，这有几个重要的影响：
- 安装：服务器可执行文件必须安装在每个用户的机器上
- 分发：您需要为不同的操作系统提供安装包
- 更新：每个实例必须单独更新
- 资源：使用本地机器的 CPU、内存和磁盘
- 访问控制：依赖本地机器的文件系统权限
- 集成：与本地系统资源（文件、进程）轻松集成
- 执行：随 Cline 启动和停止（子进程生命周期）
- 依赖：任何依赖项都必须安装在用户的机器上
实际示例
使用 STDIO 的本地文件搜索工具将：
- 在用户的机器上运行
- 直接访问本地文件系统
- 在 Cline 需要时启动
- 不需要网络配置
- 需要与 Cline 一起安装或通过包管理器安装
SSE：托管部署模型
SSE 服务器可以部署到远程服务器上，并通过网络访问：
- 安装：在服务器上安装一次，由多个用户访问
- 分发：单一部署服务于多个客户端
- 更新：集中更新立即影响所有用户
- 资源：使用服务器资源，而非本地机器资源
- 访问控制：通过认证和授权系统管理
- 集成：与用户特定资源的集成更复杂
- 执行：作为独立服务运行（通常是持续的）
- 依赖：在服务器上管理，而非用户机器上
实际示例
使用 SSE 的数据库查询工具将：
- 在中央服务器上运行
- 使用服务器端凭据连接到数据库
- 持续可用于多个用户
- 需要适当的网络安全配置
- 使用容器或云技术部署
混合方法
某些场景受益于混合方法：
- 具有网络访问的 STDIO：充当远程服务代理的本地 STDIO 服务器
- 具有本地命令的 SSE：可以通过回调触发客户端机器上操作的远程 SSE 服务器
- 网关模式：用于本地操作的 STDIO 服务器，连接到用于专门功能的 SSE 服务器
在 STDIO 和 SSE 之间选择
| 考虑因素 | STDIO | SSE |
|---|---|---|
| 位置 | 仅本地机器 | 本地或远程 |
| 客户端 | 单客户端 | 多客户端 |
| 性能 | 更低延迟 | 更高延迟（网络开销） |
| 设置复杂性 | 更简单 | 更复杂（需要 HTTP 服务器） |
| 安全性 | 本质上安全 | 需要明确的安全措施 |
| 网络访问 | 不需要 | 必需 |
| 可扩展性 | 限于本地机器 | 可以分布在网络上 |
| 部署 | 每用户安装 | 集中安装 |
| 更新 | 分布式更新 | 集中式更新 |
| 资源使用 | 使用客户端资源 | 使用服务器资源 |
| 依赖 | 客户端依赖 | 服务器端依赖 |
参考文献
4 MCP 社区项目
项目结构
MCP SDK
- Java : https://modelcontextprotocol.io/sdk/java/mcp-overview
- Python : https://github.com/modelcontextprotocol/python-sdk
- TypeScript : https://github.com/modelcontextprotocol/typescript-sdk
- Kotlin : https://github.com/modelcontextprotocol/kotlin-sdk
MCP 官方集成
数据库和文件管理
-
文件系统 - 具有可配置访问控制的安全文件操作
-
PostgreSQL - 只读数据库查询。
-
SQLite - 数据库交互和商业智能功能
-
Slack - Slack 消息发送和查询。
-
Google Drive - Google Drive 的文件访问和搜索功能
-
Google Maps - 集成 Google Map 获取位置信息。
开发者工具
- Git - 用于读取、搜索和操作 Git 仓库的工具
- GitHub - 仓库管理、文件操作和 GitHub API 集成
- GitLab - 支持项目管理的 GitLab API 集成
- Sentry - 从 Sentry.io 获取和分析问题
Web 和浏览器自动化
- Brave Search - 使用 Brave 的搜索 API 进行网络和本地搜索
- Fetch - 为 LLM 使用优化的网络内容获取和转换
- Puppeteer - 浏览器自动化和网页抓取功能
生产力和通信
- Slack - 频道管理和消息功能
- Google Maps - 位置服务、路线和地点详情
- Memory - 基于知识图谱的持久记忆系统
AI 和专业工具
- EverArt - 使用各种模型的 AI 图像生成
- Sequential Thinking - 通过思维序列进行动态问题解决
- AWS KB Retrieval - 使用 Bedrock Agent Runtime 从 AWS Knowledge Base 检索
MCP 官方集成的其他工具
- Axiom - 使用自然语言查询和分析日志、跟踪和事件数据
- Browserbase - 在云端自动化浏览器交互
- Cloudflare - 在 Cloudflare 开发者平台上部署和管理资源
- E2B - 在安全的云沙箱中执行代码
- Neon - 与 Neon 无服务器 Postgres 平台交互
- Obsidian Markdown Notes - 读取和搜索 Obsidian 知识库中的 Markdown 笔记
- Qdrant - 使用 Qdrant 向量搜索引擎实现语义记忆
- Raygun - 访问崩溃报告和监控数据
- Search1API - 用于搜索、爬虫和网站地图的统一 API
- Tinybird - 与 Tinybird 无服务器 ClickHouse 平台交互
第三方/社区支持的集成
由第三方平台构建的 MCP 服务器。
-
Docker - 管理容器、镜像、卷和网络
-
Kubernetes - 管理 pod、部署和服务
-
Linear - 项目管理和问题跟踪
-
Snowflake - 与 Snowflake 数据库交互
-
Spotify - 控制 Spotify 播放和管理播放列表
-
Todoist - 任务管理集成
-
Grafana - 在 Grafana 中搜索查询数据。
-
JetBrains – JetBrains IDEs。
-
Stripe - 与Stripe API交互。
更多的可以查看社区服务器列表：
社区 MCP 服务器
下面是一些由开源社区开发和维护的 MCP 服务器。
- AWS - 用 LLM 操作 AWS 资源。
- Atlassian - 与 Confluence 和 Jira 进行交互，包括搜索/查询 Confluence 空间/页面，访问 Jira Issue 和项目。
- Google Calendar - 与 Google 日历集成，日程安排，查找时间，并添加/删除事件。
- Kubernetes - 连接到 Kubernetes 集群并管理 pods、deployments 和 services。
- X (Twitter) - 与 Twitter API 交互。发布推文并通过查询搜索推文。
- YouTube - 与 YouTube API 集成，视频管理、短视频创作等。
MCP 客户端(汇总)
| 客户端 | Resources | Prompts | Tools | Sampling | Roots | 说明 |
|---|---|---|---|---|---|---|
| Claude Desktop App | ✅ | ✅ | ✅ | ❌ | ❌ | 完全支持 MCP 所有特性 |
| 5ire | ❌ | ❌ | ✅ | ❌ | ❌ | 支持工具。 |
| BeeAI Framework | ❌ | ❌ | ✅ | ❌ | ❌ | 支持代理工作流中的工具。 |
| Cline | ✅ | ❌ | ✅ | ❌ | ❌ | 支持工具和资源。 |
| Trae | -- | -- | -- | -- | -- | -- |
| Continue | ✅ | ✅ | ✅ | ❌ | ❌ | 完全支持 MCP 所有特性 |
| Cursor | ❌ | ❌ | ✅ | ❌ | ❌ | 支持工具。 |
| Emacs Mcp | ❌ | ❌ | ✅ | ❌ | ❌ | 支持 Emacs 中的工具。 |
| Firebase Genkit | ⚠️ | ✅ | ✅ | ❌ | ❌ | 支持通过工具进行资源列表和查找。 |
| GenAIScript | ❌ | ❌ | ✅ | ❌ | ❌ | 支持工具。 |
| Goose | ❌ | ❌ | ✅ | ❌ | ❌ | 支持工具。 |
| LibreChat | ❌ | ❌ | ✅ | ❌ | ❌ | Supports tools for Agents |
| mcp-agent | ❌ | ❌ | ✅ | ⚠️ | ❌ | 支持工具、服务器连接管理和代理工作流程。 |
| Roo Code | ✅ | ❌ | ✅ | ❌ | ❌ | 支持工具和资源。 |
| Sourcegraph Cody | ✅ | ❌ | ❌ | ❌ | ❌ | 通过 OpenCTX 支持资源 |
| Superinterface | ❌ | ❌ | ✅ | ❌ | ❌ | 支持工具 |
| TheiaAI/TheiaIDE | ❌ | ❌ | ✅ | ❌ | ❌ | 支持 Theia AI 和 AI 驱动的 Theia IDE 中的 Agent 工具 |
| Windsurf Editor | ❌ | ❌ | ✅ | ❌ | ❌ | 支持带有 AI Flow 的工具以进行协作开发。 |
| Zed | ❌ | ✅ | ❌ | ❌ | ❌ | Prompts appear as slash commands 提示符显示为斜杠命令 |
| OpenSumi | ❌ | ❌ | ✅ | ❌ | ❌ | 支持 OpenSumi 中的工具 |
Y 推荐文献
-
Model Context Protocol 官方
- 主导厂商 : MCP 协议及开源社区，主要由 Claude 背后的厂家 Anthropic 主导，而非大名鼎鼎的 CloseAI
- 官方组织 Model Context Protocol
- 官方文档
- 官方的 MCP Server 列表
- Claude Blog
-
社区的 MCP Servers
X 参考文献
本文链接： https://www.cnblogs.com/johnnyzen
关于博文：评论和私信会在第一时间回复，或直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
日常交流：大数据与软件开发-QQ交流群: 774386015 【入群二维码】参见左下角。您的支持、鼓励是博主技术写作的重要动力！
浙公网安备 33010602011771号