MCP（模型上下文协议）是一套让AI应用以统一方式发现、读取和调用外部能力的开放协议。它解决了外部能力接入AI应用时的重复适配问题，通过规范工具描述、调用请求和结果返回，使同一套业务能力可以支持多个AI应用。本文以“查询订单”为例，详细解析了MCP的工作流程，包括工具定义、模型生成调用意图、应用路由并发送MCP调用请求、服务端执行工具返回结果等步骤，帮助开发者更好地理解和应用MCP协议。

日常讨论中，常有人把 MCP 与传统 API 画上等号，或认为MCP只是多套了一层壳，直接调用API会比MCP来得快。产生这种印象并不奇怪：主流开发框架和客户端已经屏蔽了底层协议细节，开发者往往只需填一段 JSON 配置，工具就自动出现在 Agent 列表里了。

01MCP 统一了什么

如果一个 AI 应用只需要连接一个固定工具，开发者直接阅读接口文档、编写调用代码即可，并不需要额外协议。

但当工具数量增多，且同一套业务能力需要接入不同 AI 应用时，重复适配的工作就会增多：

• 描述格式不一：不同应用各自约定工具的定义结构和注册方式；
• 调用方式各异：有的请求远程 HTTP 接口，有的拉起本地脚本；
• 交互细节碎片化：工具清单获取、参数校验和错误处理缺乏统一标准。

MCP 为 AI 应用（客户端）和能力提供方（服务端）约定了共同的通信规则：如何发现能力、如何描述工具、如何发送调用、如何返回结果。能力提供方实现 MCP Server，AI 应用通过内置的 MCP Client 访问它。

从广义上看，MCP 本身也是一组程序接口。因此讨论“MCP 与 API 的区别”时，通常是在比较两个层面的事情：

• 业务 API：针对具体业务设计的接口，回答“这项业务怎么调用”；
• MCP 协议：面向 AI 应用的能力暴露与访问标准，额外统一了“可用能力如何被发现、参数如何向模型描述、请求与结果如何标准化组织”。

接下来，我们结合一个具体的业务场景，看看这两者是如何配合的。

02用查询订单的例子，把 MCP 放进来

假设公司有一套订单系统，提供如下查询接口：

●●●CODE

GET /api/orders/123

返回结果：

●●●CODE

{ "order_id": "123", "status": "已发货"}

在传统软件中，开发者在程序中处理请求地址、参数、认证方式和返回值，就能完成调用。

但如果现在要让 AI Agent 回答“帮我查一下订单 123 发货了吗”，会发生什么？

大模型并不会因为读懂了这句话，就自动知道公司内部接口的地址，也不会天然持有接口凭据。应用程序必须先告诉模型：当前有一个名为get_order的工具，可用于查询订单状态，调用时需传入 order_id。模型据此生成调用意图，再由应用程序代为执行。

这一基本机制与是否使用 MCP 无关。即便完全不用 MCP，应用也可以把 API 包装成模型可识别的工具：

模型负责表达调用意图，外围程序负责执行操作并回填结果。

在这个流程中引入 MCP，改变的是“应用程序如何访问外部工具”这一段——将其从私有对接改为按统一协议通信：

在这里，订单 API 依然负责处理核心业务，而 MCP Server 则负责把“查询订单”这项能力按 MCP 规范对外暴露。

注：封装现有 HTTP API 只是常见实现方式之一。MCP 工具内部完全可以直接查询数据库、读写本地文件或执行本地计算，并不要求背后一定存在一个 HTTP 接口。

03把模型、应用和服务端分开看

日常交流中，我们常把整个 AI 应用统称为“客户端”。但在 MCP 架构下，还需要区分模型、Host、Client 和 Server 各自的职责：

它们之间的连接关系可以分为两条独立链路：

可以看到，模型 API 的工具格式与 MCP 的协议消息格式分别用于两条不同的通信链路。

Host 负责在两条链路之间搭桥。 严格来说，工具格式的转换属于 Host 的模型适配层，而 MCP Client 专注于与 Server 的协议通信。工程实现上两者常被封装在一起，但理解架构时应当区分清楚。正因如此，MCP 与具体的大模型厂商解耦，也不绑定任何特定的 Agent 推理循环（如 ReAct）。

04一次工具调用，完整走一遍

下面我们沿着用户提问“帮我查一下订单 123 发货了吗？”，完整走一遍底层的五步流转过程（本文协议报文均基于 MCP 2026-07-28 版本）。

第一步应用获取工具定义

Host 通过 MCP Client 向服务端发送tools/list请求，获取当前可用的工具清单：

●●●CODE

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientCapabilities": {} } }}

• tools/list用于拉取清单，无需指定具体工具名或业务参数。
• params._meta用于携带协议版本与客户端能力声明（空对象{}表示本次请求未声明额外的客户端能力）。
• 若服务端工具较多并启用了分页，响应中会包含 nextCursor；客户端拉取下一页时将其作为 params.cursor 传回（首次请求可省略），同时保留 _meta。

服务端返回的单个工具定义如下：

●●●CODE

{ "name": "get_order", "description": "根据订单编号查询订单状态", "inputSchema": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单编号" } }, "required": ["order_id"], "additionalProperties": false }}

其中，name在单个服务端内唯一标识工具，description帮助模型理解工具用途，inputSchema则通过 JSON Schema 严格定义入参结构。

拿到这份定义后，Host 会将其转换为当前大模型 API 所需的工具格式（不同模型厂商的字段结构略有差异）。当可用工具很多时，Host 可以自行缓存、筛选或按需加载，MCP 并不要求每次都将全部工具塞进模型上下文。

第二步模型生成调用意图

Host 将用户问题与转换后的工具定义一并传给大模型。模型判断需要调用工具，返回如下结构的信息（此处为原理示意）：

●●●CODE

{ "call_id": "call_order_01", "name": "get_order", "arguments": { "order_id": "123" }}

需要注意，此时订单查询尚未发生。模型只是通过 Function Calling表达了“打算调用哪个工具、传入什么参数”的意图。

第三步应用路由并发送 MCP 调用请求

Host 识别到模型的调用意图后，先确认该工具归属哪个 MCP Server，完成参数与权限检查，再通过对应的 MCP Client 发送 tools/call 请求。

Host 是如何知道工具归属的？在第一步向各个服务端拉取 tools/list 时，Host 就已经记录了每个工具与所属 MCP Server（及其对应 Client 连接）的映射关系，即路由表。如果同时连接了多个 MCP Server，还可能遇到同名工具冲突。例如订单服务和物流服务都提供了 search 工具，Host 可以在传给模型前加上不同的前缀：

当模型请求调用orders__search 时，Host 查表定位到订单 MCP Server，通过对应的 Client 连接，还原为原始名称search发起调用。前缀是应用可采用的一种区分方式，并非 MCP 强制规定。

第四步服务端执行工具并返回结果

订单 MCP Server 解析调用请求，找到 get_order 对应的处理函数，内部调用订单系统 API，最后将结果封装为 MCP 标准格式返回。

在这个过程中，接口凭据和访问权限仍由服务端或宿主程序管理。工具定义不应包含底层密钥，服务端也需要校验请求者是否有权访问对应订单。

第五步应用将结果回填给模型

Host 收到 MCP 响应后，将其转换为大模型 API 要求的工具结果消息，并通过 call_order_01 与第二步的调用请求关联起来。

模型读取到“已发货”的状态后，就可以据此回答用户：“订单 123 已发货。”如果当前信息仍不足以回答问题，模型还可以发起下一轮工具调用（例如继续调用物流明细工具）。

回顾整条链路，Host 在中间完成了三次关键适配：

Function Calling 解决模型如何表达调用意图，MCP 解决应用如何标准化地发现与调用外部能力，而 Host 负责把整套流程串联起来。

05 MCP消息的内容格式

理解了流转过程，我们再直接看看通信管道里实际传输的报文。MCP 采用 JSON-RPC 2.0 作为消息格式，一次标准请求主要包含四个核心字段：

以第三步的工具调用请求为例，实际传输的 JSON 报文如下：

●●●CODE

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": { "name": "get_order", "arguments": { "order_id": "123" }, "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientCapabilities": {} } }}

服务端收到这条消息后，会经历两次分发：

执行成功后，服务端返回的 JSON-RPC 响应如下：

●●●CODE

{ "jsonrpc": "2.0", "id": 7, "result": { "resultType": "complete", "content": [ { "type": "text", "text": "订单 123 已发货。" } ], "structuredContent": { "order_id": "123", "status": "已发货" }, "isError": false }}

阅读这段响应时，可以留意以下细节：

1. 结果承载方式：content 支持文本、图片等多种内容块，适合直接供模型阅读；structuredContent 则可携带结构化 JSON，方便宿主程序做后续处理或 UI 渲染。

2. 双层 ID 映射：请求和响应的 id: 7 用于 MCP 客户端与服务端之间的配对；它与模型侧生成的call_order_01 属于两套独立的标识，由 Host 负责维护映射。

3. 两类错误区分：

• 协议层错误（如方法名不存在、JSON 格式非法）：直接通过 JSON-RPC 顶层的 error 字段返回；
• 工具执行错误（如调用上游接口失败）：仍在 result 中返回，并将 isError 设为true，以便模型感知业务失败并决定如何向用户解释或重试。

MCP Server 要完成的工作包括收消息、校验请求、分发方法、执行业务和返回结果。SDK 封装了其中许多重复的协议处理，业务函数仍然需要开发者编写。

06消息怎样传递：stdio 与 HTTP

前文介绍的是 MCP 消息的内容格式，而消息如何从客户端送达服务端，则取决于传输方式。MCP 最常用的两种传输方式是 stdio 和 Streamable HTTP，它们底层承载的都是同一套 JSON-RPC 消息。

1.stdio：通过子进程的标准输入输出通信

采用 stdio 时，Agent 应用（Host）会先将 MCP Server 作为本地子进程启动，随后通过操作系统的标准输入（stdin）和标准输出（stdout）管道收发消息：

这里有一个常见误区：业务调用参数并不是每次通过命令行参数传入的。 命令行参数仅用于启动和初始化进程，运行期的所有工具调用请求，都是在进程启动后通过 stdin/stdout 管道持续流转的。

Node.js 读取 stdin 的核心代码如下（仅展示读取过程，并非完整服务端实现）：

●●●CODE

import { createInterface } from "node:readline"; const reader = createInterface({ input: process.stdin, crlfDelay: Infinity}); reader.on("line", line => { const request = JSON.parse(line); // 接下来：校验请求，根据 method 和工具名分发执行});

处理完成后，服务端将响应序列化并加上换行符写回 stdout：

●●●CODE

process.stdout.write(JSON.stringify(response) + "/n");

• 为什么必须加换行符？ 因为操作系统管道传输的是连续字节流，单次读取可能只拿到半条消息，也可能粘连了多条消息。stdio 模式约定以换行符作为消息边界，readline 模块正是据此完成缓冲与切分的。
• 为什么日志要与协议消息分开？ 在 stdio 模式下，客户端会逐行读取服务端的 stdout，并把每一行当作 MCP 的 JSON 消息解析。Node.js 的console.log() 默认也写入这个通道；如果打印一句“服务启动成功”，客户端就会把这句话当作 JSON 解析，因而报错。所以，协议消息写入 stdout，运行日志则用 console.error() 等方式写入独立的 stderr 通道。虽然叫“标准错误流”，stderr 也可以承载普通日志，并不代表程序发生了错误。

2.npx 示例：启动进程，再走 stdio 通信

日常配置中常见的 npx 写法，可以结合上面的 stdio 过程理解：

●●●CODE

{ "command": "npx", "args": ["-y", "@your-scope/order-mcp@1.0.0"]}

这是启动配置示意，包名为占位符，具体字段以所用应用为准。Host 通过 npx 运行指定 npm 包的程序入口，npx 会在需要时获取该包。假设程序采用 stdio，Host 随后就通过它的 stdin/stdout 收发 MCP 消息。

因此，npx 只负责启动程序，stdio 才负责协议通信。 你完全可以换成 node、python 或编译好的二进制文件来启动本地进程并使用 stdio；反过来，npx 也可以用来启动一个监听端口的 HTTP 服务——两者并没有绑定关系。

3.Streamable HTTP：向远程服务地址发送消息

当工具服务需要独立部署或供多端远程访问时，通常会采用 Streamable HTTP。此时 MCP Server 作为独立的 Web 服务运行，对外暴露一个端点（如 https://example.com/mcp）。

客户端将 JSON-RPC 请求放入 HTTP POST 请求体中发送。在 MCP 2026-07-28 版中，一次工具调用的典型请求头如下：

●●●CODE

POST /mcp HTTP/1.1Content-Type: application/jsonAccept: application/json, text/event-streamMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: get_order

服务端从请求体解析出 method、name 和 arguments，同时按规范校验请求头与正文的一致性，执行函数后返回结果。

需要注意两点：

• 普通 HTTP 接口 ≠ MCP Server：仅仅提供一个/mcp 路由接收任意 JSON 并不构成 MCP 服务端。其消息结构、能力发现、Schema 描述以及结果与错误语义，都必须严格遵循对应版本的 MCP 规范。
• 单次响应与流式响应：Streamable HTTP 允许服务端直接返回单个 application/json 响应（适合简单查询），也允许返回 text/event-stream（SSE）流式响应。通用客户端需同时支持这两种形式；此外，协议层的 SSE 响应流可以承载进度通知等消息和最终响应。

stdio 通过本地进程管道通信，常用于本地工具；HTTP 通过服务地址通信，适合独立部署与远程访问。两者在传输和运行方式上有所不同，协议解析、工具分发和业务逻辑则可以复用。

07 MCP配置文件，为什么看起来什么都做了

回到文章开头的问题：为什么平时我们只写了几行 JSON 配置，工具就能直接用了？

因为 Host 和Server SDK 已经实现了相应的连接和协议处理。

当你在客户端配置文件里填入启动命令或服务地址后，Host 会在后台自动拉起进程或建立连接、确认协议版本、发送 tools/list 获取工具清单，并筛选出合适的工具注入模型上下文；当模型发起调用时，Host 又自动完成了路由查找、权限拦截、组装 tools/call 请求以及回填执行结果。配置文件只是告诉应用“去哪里找服务”的入口。

同理，在服务端使用 FastMCP 或官方 SDK 时，你只需写一个业务函数并加上装饰器，框架就会自动根据类型注解生成 JSON Schema、注册 tools/list 与 tools/call 处理器并处理请求响应关联和底层传输。如果脱离框架手写，还需要自行处理参数校验、超时控制、子进程生命周期管理以及版本兼容等一系列工程问题。

08MCP 不只有工具

本文之所以围绕“工具（Tools）”展开，是因为它在 Agent 开发中最常用。实际上，MCP Server 还可以对外提供另外两类核心原语：

除此之外，MCP 规范还涵盖授权（Authorization）、进度通知（Progress）等机制。但在实际落地时，完全不需要一次性实现所有特性，按业务需求从 Tools 切入即可。

从这些能力也能理解“模型上下文协议”这个名称：外部系统提供的既有可执行的工具，也有可以放进模型上下文的数据和指令模板。至于这些内容何时加载、如何拼装进模型的上下文窗口，最终仍由 Host 统一调度。

09总结

回看一次工具调用，各部分的职责可以这样区分：

• 大模型：理解意图，决定调用哪个工具、传什么参数；
• Host（AI 应用）：管理执行流程，负责模型格式转换、工具路由与权限管控；
• MCP Client / Server：按统一的 JSON-RPC 协议发现能力、交换调用请求与结果；
• stdio / HTTP：负责把协议消息从客户端搬运到服务端；

最后，再回应开头关于“MCP 与 API”的两个常见争论：

• 直接调 API 比走 MCP 更快？

MCP 多了协议处理和额外的网络跳转，延迟开销在多数场景下可观测，减少协议处理或额外通信，可能降低延迟。但差距并非恒定，需在相同条件下测量；在需要结构化数据处理的复杂任务上，MCP 反而可能更快。同时，不能把模型推理耗时都算到 MCP 头上。是否采用 MCP，还要看工具需要被多少应用复用——工具只服务单一应用时直接 API 更简单高效，需被多个异构应用复用时 MCP 的标准化封装才摊薄成本、显现长期收益，不能只比较一次调用的快慢。

• MCP 只不过把 API 又封装了一层？

“封装 API”只是 MCP Server 的一种常见实现方式，它背后同样可以直接连接数据库或本地文件，协议本身并不限定后端形态。MCP 的核心在于运行时能力发现：客户端连接后获取工具列表及其参数描述（JSON Schema），并按统一规范发起调用，而非在调用方代码中预先硬编码接口定义。如果你的应用只对接两三个固定接口，直接写代码调用完全够用；但当一套业务能力需要被多个团队、多种 AI 客户端共同接入和复用时，MCP 的标准化封装可以减少重复适配，让一套 Server 被多种兼容客户端直接复用。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？