AI

大模型调用 MCP（Model Context Protocol 模型上下文协议）原理

Posted Cola🌀

前言 🔖

当大模型从文本生成走向工具调用、多模态交互的实用化阶段，模型与外部工具的兼容难题、上下文管理的效率瓶颈，成了制约 AI 落地的关键痛点。而 Anthropic 在 2024 年推出的 MCP（Model Context Protocol，模型上下文协议），正是为解决这一行业痛点而生的标准化方案。它被业内称为大模型领域的 “USB-C 通用接口”，重构了大模型与外部资源的交互逻辑，让不同大模型、各类工具实现 “即插即用”，为大模型的工程化落地和生态协同打开了新空间。本文将从核心定义、核心价值、落地架构三个维度，带你读懂 MCP 协议的核心逻辑。

在 MCP 协议出现之前，大模型的工具集成和上下文管理一直存在两大行业难题：

  • 是生态碎片化， GPT 、Claude、开源大模型等各有专属的工具交互接口，开发者对接不同模型时，需要重复开发适配代码，效率极低。
  • 是上下文管理低效，传统大模型的 上下文窗口 固定，长文本处理时易出现信息丢失，且外部工具调用的上下文无法与模型原生上下文高效协同。

MCP 协议的核心定义，是为大模型设计的开放式、标准化上下文管理与工具交互协议，它通过统一的接口规范，实现了 “大模型 – 上下文 – 外部工具” 的全链路标准化协同。简单来说，只要遵循 MCP 协议，任何大模型都能直接对接任何符合标准的外部工具（数据库、云服务、本地应用等），同时实现上下文的高效压缩、动态调度和分布式管理，让大模型的上下文能力不再受限于硬件，实测可支持 1M tokens 以上的有效 上下文长度 ，大幅提升长文本处理和复杂任务执行能力。

　　

一、先搞懂基础定义 🔖

🔹1. MCP 是什么

MCP = Model Context Protocol，模型上下文协议，Anthropic 推出、现已捐给 Linux 基金会的开源标准化协议，定位是大模型与外部工具 / 文件 / 数据库 / API 的统一通信标准，业内比喻为 AI 世界的 USB‑C，一套协议对接所有外部能力，不再为每个工具写私有对接代码。

　　

🔹2. 三层核心架构（决定调用底层逻辑）

整套调用不是模型直接发起网络请求，而是三层解耦结构：

  1. MCP Host（宿主层） 承载大模型的应用程序：Claude Desktop、Cursor、VSCode 插件、自研 Agent 后端、llm 封装服务。 职责：调度全局、安全校验、管理多 MCP 连接、把工具结果喂回 LLM、最终给用户输出答案。大模型只运行在 Host 内部。
  2. MCP Client（客户端代理，内嵌在 Host 里） Host 内置的协议通信模块，模型完全不感知 MCP 协议细节，由 Client 做格式翻译：
    • 和远端 MCP Server 握手、能力发现；
    • LLM 输出的 function call → 翻译成标准 JSON‑RPC 2.0 MCP 请求；
    • Server 返回结果 → 转回模型可识别的上下文消息。
  3. MCP Server（能力提供端） 独立进程 / 远程服务，封装真实能力，对外只暴露 MCP 标准接口，分为三类可被模型调用的原语：
    • Tools（工具调用）：可执行动作（查天气、SQL 查询、执行命令、发接口）；
    • Resources（只读资源）：读取文件、日志、知识库、数据库数据，纯读取；
    • Prompts（预设提示模板）：可复用任务指令模板。

　　

🔹3. 底层通信载体（两种传输）

所有消息基于 JSON‑RPC 2.0 封装：

  • 本地调用：Stdio 标准输入输出（MCP Server 作为子进程拉起，进程间管道通信，最常用）；
  • 远程调用：Streamable HTTP（新版规范），替代旧版 SSE，支持跨机器、跨网络调用 MCP 服务。

　　

二、大模型「发现 / 探查 MCP」原理 🔖

模型不会主动扫描网络、进程，全部由 Host + MCP Client 完成能力发现，模型只被动接收工具清单做意图判断，分两步：

🔹步骤 1：Host 预先配置 MCP Server 地址

在配置文件写入要对接的所有服务：

  • 本地：命令行启动路径（如 python weather_mcp_server.py）；
  • 远程：HTTP 服务地址 http://xxx/mcp。

　　

🔹步骤 2：Client 发起协议握手，探查全部可用能力（核心 “调查” 动作）

  1. 旧版 MCP（有状态） Client 发送 initialize JSON‑RPC 握手请求，协商协议版本、双方支持能力； Server 返回完整工具列表 + JSON Schema 参数定义 + 工具描述。
  2. 2026‑07‑28 新版无状态 MCP 取消强制握手，用 server/discover 方法主动探测 Server 暴露的 Tools/Resources/Prompts，一次性拉取所有可调用能力清单。

　　

🔹步骤 3：Host 把工具描述注入大模型上下文

Host 将探查得到的所有工具名称、功能说明、入参格式，以系统提示词（System Prompt）+ 工具定义 JSON 塞进 LLM 输入窗口。

👉 至此模型才算 “知道有哪些 MCP 能力可以调用”，探查动作结束。

关键点：模型本身没有任何网络 / 进程探查能力，MCP 服务发现完全是应用层（Host/Client）完成，模型只做语义理解与调用决策。

　　

三、大模型完整调用 MCP 全链路 7 步原理（最核心） 🔖

以用户提问：“帮我查北京今天天气” 举例：

🔹1. 用户输入 → Host 接收，携带已发现的 MCP 工具集

Host 把用户问题 + 前面探测到的 get_weather 工具 Schema 一起发给 LLM。

　　

🔹2. LLM 做意图判断，输出结构化工具调用（Function Calling）

大模型理解需要外部数据，不直接回答文本，输出规范结构化调用指令（OpenAI/Claude 标准 tool_call）：

{
  "tool_calls": [
    {
      "name": "get_weather",
      "arguments": {"city": "北京"}
    }
  ]
}

模型只输出要调用哪个工具、传什么参数，完全不知道 MCP、JSON‑RPC、进程通信。

　　

🔹3. MCP Client 做协议转译：LLM 调用 → MCP 标准 JSON‑RPC 请求

Host 拦截模型输出的 tool_call，由内置 MCP Client 翻译成协议报文：

{
  "jsonrpc":"2.0",
  "id":1,
  "method":"call_tool",
  "params":{
    "name":"get_weather",
    "arguments":{"city":"北京"}
  }
}

通过 Stdio / HTTP 发给对应的 MCP Server。

　　

🔹4. MCP Server 解析请求，执行真实业务逻辑

Server 收到 call_tool 方法，匹配内部注册的函数，调用天气第三方接口拿到数据。

　　

🔹5. Server 将执行结果按 MCP 规范原路返回给 Client

{
  "jsonrpc":"2.0",
  "id":1,
  "result":{
    "temperature":28,
    "condition":"晴"
  }
}

　　

🔹6. Host 把工具执行结果二次封装成对话消息，回填给 LLM

Host 把返回数据包装成 tool 角色消息，追加到对话上下文，再次送入大模型。

　　

🔹7. LLM 结合原始问题 + 工具返回数据，生成最终自然语言答案

北京今日晴天，气温 28 摄氏度。

循环机制（多轮调用）：如果一次调用不够（比如查数据库→再计算→再查文件），模型会重复步骤 2–6，Host 循环调度 MCP 调用，直到无需外部工具。

　　

四、关键底层技术细节（容易混淆点） 🔖

🔹1. MCP vs 原生 Function Calling 区别

  • Function Calling：是大模型输出结构化调用格式的能力（模型侧能力）；
  • MCP：是调用之后，应用层如何标准化转发给外部服务的通信协议（应用层通信标准）； 二者是上下游关系：LLM 输出 FC → MCP 负责跨进程 / 跨网络路由执行。

　　

🔹2. 权限与安全隔离设计（MCP 内置）

  1. Host 统一管控 MCP Server 启停、访问权限；
  2. Server 可对 Tools 做权限校验、参数白名单、执行审批；
  3. 本地 Stdio 子进程天然做进程沙箱隔离，防止模型越权操作本地文件；
  4. 新版无状态请求自带签名、参数校验，防篡改。

　　

🔹3. 双向反向调用：Server 也可通过 MCP 调用大模型

MCP 不止是模型调用工具，Server 可发送 sampling/createMessage 请求，反向让 Host 调度 LLM 做二次推理，适合复杂 Agent 嵌套场景Model Cont…。

　　

五、一句话总结 🔖

  • 探查 / 调查 MCP：由应用端 Host+MCP Client 通过 initialize/discover 协议握手，拉取所有服务能力列表，注入给大模型，模型仅做意图识别；
  • 调用 MCP 原理：LLM 原生 Function Calling 输出调用意图 → MCP Client 转 JSON‑RPC 协议 → MCP Server 执行真实逻辑 → 结果回灌模型生成最终回答，全程模型只负责思考，通信执行由协议层完成。