MCP：为模型建立能力的接口标准

本系列文章将从提示词工程出发，逐步讨论人类如何提升对大模型行为的控制能力：从优化提问方式，到设计输入环境，再到连接外部能力，最终形成可复用的能力单元。

换句话说，我们关注的不只是"如何让模型回答更好"，而是"如何让模型稳定地完成工作"。
当我们能够稳定地控制模型的输入之后，一个新的需求自然出现：模型如何与真实系统交互？

单纯依靠文本生成已经无法满足复杂任务，我们需要为模型提供可调用的能力，例如查询数据、执行操作或访问服务。

本篇是系列第三篇，将介绍 MCP 的思想：通过标准化接口，让模型不再只是回答问题，而是能够可靠地调用外部能力。

前面三篇文章，我们已经介绍了上下文对于大模型的重要性，今天这篇文章，将介绍什么 MCP.

MCP 全称为 Model Context Protocol，翻译成中文叫做"模型上下文协议"。没错，你从名字就能看出，这个也是属于上下文知识体系的一部分。

为什么需要 MCP？

那么 MCP 解决了什么问题呢？

首先你需要理解"协议"，我们作为前端开发者，最熟悉的就是 HTTP 协议。

🤔HTTP 协议存在的意义是什么？

没错，只要两台设备遵循 HTTP 协议，那么这两台设备就能通信。

那么这里的 MCP 是服务于哪两者的呢？

没错，就是"模型"和"上下文"，只要一段上下文遵循 MCP，那么这段上下文就能够提供给模型。

在没有 MCP 之前，模型要想获取外部能力，采用的是一个叫做 Function Calling 的解决方案。

这套方案看上去没什么问题，有效的让大模型通过 Function Calling 调用外部工具，然后拿到外部工具的调用结果作为上下文。但是背后却存在一个标准的问题。不同厂商的模型，Function Calling 的格式是不一致的。

下面是一些不同厂商的模型，所支持的 Function Calling 格式：

deepseek

js 复制代码

tools = [{
  "type": "function",
  "function": {
      "name": "get_weather",
      "description": "Get weather of an location",
      "parameters": {
          "type": "object",
          "properties": {
              "location": {
                  "type": "string",
                  "description": "The city and state, e.g. San Francisco, CA",
              }
          },
          "required": ["location"]
      },
  }
}]

GPT

js 复制代码

const tools = [{
    type: "function",
    name: "get_weather",
    description: "Get current temperature for provided coordinates in celsius.",
    parameters: {
        type: "object",
        properties: {
            latitude: { type: "number" },
            longitude: { type: "number" }
        },
        required: ["latitude", "longitude"],
        additionalProperties: false
    },
    strict: true
}];

claude

js 复制代码

"tools": [{
  "name": "get_weather",
  "description": "Get the current weather in a given location",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "The city and state, e.g. San Francisco, CA"
      }
    },
    "required": ["location"]
  }
}],

这就是没有标准化所带来的痛苦，一个 Agent 应用开发者，可能为了适配不同的模型厂商，业务代码里面得写很多用于适配不同模型的代码。这有没有让你想起以前适配不同浏览器厂商的往事？

而有了 MCP 之后，一切就变简单了。只要上下文是遵循的 MCP 协议，模型也遵循的是 MCP 协议，那么该上下文就能提供给该模型。

MCP核心组件

理解了 MCP 的意义之后，接下来看一下 MCP 的核心组件，主要有这么几块：

MCP Client
MCP Server
MCP Host

我们可以先回顾一下常见的网络模型：

1. Client-Server 模型

中文称之为"客户端/服务器端模型"，其中客户端负责"发请求"，服务器负责"处理并响应"

特点：

有一个（或多个）中心服务器
客户端不能直接互相通信（通常）
所有数据/逻辑集中在服务器

2. Peer-to-Peer 模型

中文称之为"对等网络模型"，简称 P2P 模型，每个节点既是"客户端"，也是"服务器"。

特点：

没有中心服务器
节点之间直接通信
数据分散在各个节点

那么 MCP 采用的是哪一种模型呢？

没错，其实就是 Client-Server 网络模型。

其中 MCP Server 是提供"上下文"的一端，而 MCP Client 则是连接某个 MCP Server，从上面获取"上下文"的一端。

MCP Server

前面说了，MCP Server 是提供上下文的一端，那么作为一个 MCP Server，可以提供哪些内容作为上下文呢？

主要有这么几类：

Tools
Resources
Prompts

1. Tools工具

工具这一块儿的工作原理，其实和 Function Calling 是类似的，唯一的区别在于现在是基于统一的协议标准来定义和调用，因此具备更好的通用性和可复用性。

比如我遵循 MCP 协议标准，写了一个 MCP Server，并在上面定义了一系列工具，那么这些工具就不再是"某个模型专用的能力"，而是可以被任何支持 MCP 协议的模型直接发现、调用和复用。

比如：

查询天气
查询数据库
下订单
调用第三方 API
执行代码

原本大语言模型只能根据训练的数据来回答问题，现在有了工具，就可以临时新增一段上下文。

比如用户说：帮我查一下北京今天的天气

模型本身并不知道天气，但它可以：

识别出需要调用 get_weather
通过 MCP Client 调用 MCP Server 上的这个工具
拿到结果
再组织成自然语言返回给用户

2. Resources资源

模型可以"读取"的数据，这一类上下文和上面的"工具"的区别在于：

Tools 是"执行动作"
Resources 是"提供信息"

常见的资源比如：

文档（公司制度、产品说明）
数据库内容
文件（PDF / Markdown / JSON）
外部知识源

举个例子，用户问：公司报销标准是多少？

模型本身并不知道，但可以：

从 MCP Server 提供的资源中
找到"报销制度文档"
把相关内容作为上下文
再进行回答

🤔这和 RAG 有什么区别？

MCP Server Resources 是一种数据源
RAG 是一种数据检索策略

MCP Server Resources 是可以作为 RAG 的数据来源的。

3. Prompts提示词

这也是上下文的一种类型，提供可复用的提示词模板，这一类很多人容易忽略，但其实非常重要。因为"提示词本身"也可以被复用、管理和标准化，比如：

分析报告模板
代码生成模板
总结模板
特定业务流程的提示结构

举个例子，你可以在 MCP Server 中定义一个 Prompt：

diff 复制代码

请根据以下信息，生成一份结构化分析报告：
- 背景
- 问题
- 解决方案
- 风险评估

那么模型在需要时，可以直接"调用这个模板"，而不是每次都重新写 prompt。

MCP Client

MCP Client 主要用于：

连接某个 MCP Server
完成协议握手
发送请求，接受 MCP Server 的响应
获取 MCP Server 暴露出来的能力

一个标准 MCP Client 的抽象骨架：

js 复制代码

class MCPClient {
  // 连接
  connect(transport)

  // 生命周期
  initialize()

  // 能力发现
  listTools()
  listResources()
  listPrompts()

  // 能力调用
  callTool()
  readResource()
  getPrompt()

  // 通信
  request()
  notify()

  // 会话管理
  close()
  reconnect()
}

1. 连接层

建立和 MCP Server 的连接，transport 可以是：

stdio
http
websocket

2. 生命周期

初始化会话
获取 server 能力
协议握手

本质上是Client 和 Server 的"第一次对话"

3. 能力发现

用于查询 MCP Server 提供了什么能力。

4. 能力使用

真正去"使用能力"，调用 MCP Server 所提供的方法，拿到对应的上下文内容。

5. 会话管理

用于管理连接生命周期，处理断连 / 重连等场景。

MCP Host

除了 MCP Client 和 MCP Server，你可能还听过 MCP Host，这是什么呢？

这其实就是真实和用户做交互的应用，比如：

Claude Desktop
Cursor / VS Code 这类 IDE
你自己写的聊天应用
你自己的 Agent 系统

因此三者之间的关系如下图所示：

也就是说，MCP host 是一个 Agent 应用，而 MCP client 是整个 Agent 应用里面的其中一个模块。

通信方式

最后，我们来看一下 MCP 协议中的通信方式，这里涉及到两个东西：

通信的格式是什么
通信的方式是什么

通信格式

通信涉及到数据传输，数据传输的格式有多种：

xml
json
字符串

MCP 中的通信格式采用的是 JSON-RPC2.0，英语全称为 JSON Remote Procedure Call，远程函数调用。简单来讲，就是用 JSON 格式来描述"远程调用"的协议。

一个典型的请求，大致长这样：

json 复制代码

{
  "jsonrpc": "2.0",
  "method": "callTool",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Beijing"
    }
  },
  "id": 1
}

MCP Server 收到之后，会返回：

json 复制代码

{
  "jsonrpc": "2.0",
  "result": {
    "temperature": 25,
    "condition": "sunny"
  },
  "id": 1
}

可以看到，在 MCP 协议中，调用工具其实就是一次标准化的远程请求，工具的执行是在 MCP Server 上，然后通过 JSON 的形式返回工具执行的结果。

通信方式

理解了通信格式，接下来再来看一下通信方式。在 MCP 中，常见的通信方式主要有两类：

stdio：本地进程通信
http：网络通信

1. stdio

这是一种常见的方式，如果 MCP Client 和 MCP Server 运行在同一台机器上，那么通过标准输入 / 输出（stdin / stdout）可以直接进行通信。

这种通信方式的特点是：

高效
简洁
无网络开销
非常适合本地开发

2. http

当 MCP Server 不在本地时，就需要通过网络通信，MCP Client 通过 HTTP 请求去调用 MCP Server.

这种方式的特点在于：

支持远程部署
可以做成服务化
更适合生产环境

Streamable http 是 MCP 中基于 http 的通信方式，主要用于远程和 Web 场景。

客户端基于 HTTP POST 发送 JSON-RPC 请求，例如：

initialize
callTool
listResources

sequenceDiagram participant Client participant Server Client->>Server: POST /mcp（initialize / callTool） Server-->>Client: JSON一次性响应或者 SSE 流响应

服务端可以根据场景返回：

普通 JSON 响应（application/json）
流式 SSE 响应（text/event-stream）

除了请求响应之外，客户端还可以通过 GET 请求建立 SSE 连接，用于接收服务端的通知：

sequenceDiagram participant Client participant Server Client->>Server: GET /mcp（建立 SSE） Server-->>Client: 推送 notifications（如 list_changed）

常见通知包括：

notifications/resources/list_changed
notifications/tools/list_changed

SSE 主要用于"服务端主动推送"，而不是替代请求调用。

StreamableHTTP 使用场景

通过 HTTP 接收远程请求（如前端网页、API 网关）
需要支持 多客户端 并发访问
浏览器与 MCP Server 通信
流式响应（如 SSE 推送）需求

写在最后

回顾本篇的内容，其实我们解决的是一个非常核心的问题：模型如何连接真实世界的能力？

在没有 MCP 之前，我们虽然可以通过 Function Calling 调用工具，但始终存在一个问题：

不同模型，格式不一致
不同系统，接入成本高
能力无法复用

而 MCP 做的事情，其实很简单：用一套统一的协议，把"能力"标准化。

从结构上来看，本篇介绍了 MCP 的几个关键组成：

MCP Server：提供能力（Tools / Resources / Prompts）
MCP Client：连接并调用这些能力
MCP Host：真正与用户交互的应用

以及它背后的通信方式：

JSON-RPC：统一调用格式
stdio / HTTP：统一通信通道

但如果再往深一层看，你会发现 MCP 的意义并不只是"多了一套协议"，它真正带来的变化是：

模型不再只是"生成文本"
而是开始"调用能力"
甚至可以参与到系统运行中

换句话说：MCP 让模型，从"会回答问题"，走向"可以完成任务"。

如果说前面几篇文章，我们一直在解决：如何让模型"说得更好"，那么从这一篇开始，我们进入了另一个阶段：如何让模型"做得更多"。

不过接下来，一个更关键的问题就自然出现了：这些能力，应该什么时候用？怎么组合使用？由谁来决策？

这，就是下一步要解决的问题。我们下一篇文章见 👋

-EOF-