MCP：AI 应用与外部工具协同的标准化协议解析

2025-11-12 39

MCP：AI 应用与外部工具协同的标准化协议解析

MCP解析

文章涉及到的代码已经共享至 Github 仓库，欢迎访问交流：https://github.com/GerZhang/course-mcp-tech

前置知识

在了解 MCP 之前，我们需要对两个最基础的概念有个清楚的认知。因为这两个概念是 MCP 的底层技术原理，是我们深入了解 MCP 最重要的知识点。当掌握这两个基础概念后，MCP 的奥妙就会无所遁形。

stdio

stdio，全称为standard input and out（标准输入输出）。通常会在 C 语言中，以 stdio.h 的方式出现。顾名思义，它的功能就是提供一个信息的标准通道，使得程序可以有效和其他程序进行"打交道"。

stdio 通常包含三个标准流（standard streams）：

| 名称 | 全称 | 缩写 | 作用简述 | 常见用途（C/C++） | | ---------- | ------------------- | -------- | -------------------------------------------------- | ----------------------------------- | | stdin | standard input | 标准输入 | 程序用来接收输入 的地方，通常是键盘 | 比如scanf()读取键盘输入内容 | | stdout | standard output | 标准输出 | 程序用来输出正常信息 的地方，通常是屏幕 | 比如 printf打印的内容 | | stderr | standard error | 标准错误 | 程序用来输出错误信息或警告的地方，通常也是屏幕 | 用 fprintf(stderr, ...)打印错误信息 |

在操作系统，以及多种编程语言中，都遵循 stdio 这个"标准三流"模型来实现程序与外部（终端、键盘、屏幕等）之间的通信。这也就意味着，我们所编写程序的所有输入输出，其底层都通过这三个默认通信管道进行数据交互。

场景举例

我们可以借助 node.js 来模拟一个标准的 stdio 场景。

1.构建一个 node 环境

mkdir stdio-demo npm init

2.创建 server.js，并通过 stdout 输出当前 server 的进程 id。

// server.js

process.stdout.write(process.pid + '\n')

3.在终端运行 server.js，查看输出内容

node server.js

当我们在终端输入命令 node server.js时，我们会在终端中看到 node 运行起来的 server 进程所拥有的进程 id。这是一个习以为常的场景，但是不知你有没有好奇过，为什么终端进程可以看到其他进程的数据信息呢？

答案就在 stdio 中。因为终端进程在开启一个新进程（node）的时候，顺手监听了新进程的标准输入（stdin）与标准输出（stdout）。

我们可以修改 server.js，增加对 stdin 的处理，这样就能实现一个最基础的 AI 对话场景：

// server.js

process.stdin.on('data', (data) => {
  const resp = `AI 复述： ${data.toString().trim()}`
  process.stdout.write(resp + '\n')
})

当然，除了终端，我们也可以使用程序来自行实现 client 的逻辑。例如：

// client.js

import { spawn } from 'child_process'

// 启动服务端进程
const serverProcess = spawn('node', ['server.js'])

// 监听服务端进程的标准输出
serverProcess.stdout.on('data', (data) => {
  console.log(data.toString().trim())
})

// 测试消息发送
const messages = [
  "明月几时有？",
  "把酒问青天。",
  "不知天上宫阙，",
  "今夕是何年。"
]

messages.forEach((message, index) => {
  setTimeout(() => {
    console.log(`-->：${message}`)
    serverProcess.stdin.write(message + '\n')
  }, index * 1000) // 每秒发送一条数据
})

JSON-RPC

JSON-RPC，一种轻量级的远程过程调用（Remote Procedure Call，简称 RPC）协议，它使用 JSON（JavaScript Object Notation）作为数据格式，用于客户端与服务器之间的通信。一个标准 MCP 应用，其传输数据的规范，就是 JSON-RPC。

JSON-RPC 定义了一套规则，让调用者可以通过发送一个请求，来申请服务器执行对应的函数，再把结果返回给调用者。

数据格式

假设服务器端提供了两个可供外部调用的方法：

// server.js

import fs from 'fs'

export default {
  // 方法 1：求和
  sum({ a, b }) {
    return a + b
  },
  // 方法 2：创建文件
  createFile({ filename, content }) {
    try {
      fs.writeFileSync(filename, content)
      return `文件 ${filename} 已创建`
    } catch (err) {
      return `创建文件 ${filename} 失败：${err.message}`
    }
  }
}

作为客户端，我们希望调用其中的求和方法，发起的请求消息格式如下：

{
  "jsonrpc": "2.0",
  "method": "sum",
  "params": {
    "a": 2,
    "b": 3
  },
  "id": 1
}

| 字段名 | 必填 | 说明 | | ------- | ---- | ------------------------------------------------------------ | | jsonrpc | 是 | 协议版本，固定为 "2.0"（目前主流都用 2.0） | | method | 是 | 要调用的远程方法/函数名 ，比如 "sum" | | params | 是 | 传给这个方法的参数，可以是数组或对象，比如 {"a":2,"b":3} | | id | 是 | 请求的唯一标识符，用于匹配请求和响应，可以是数字或字符串，自行构建 |

当服务器处理完请求后，会返回类似如下的响应结果：

{
  "jsonrpc": "2.0",
  "result": 5,
  "id": 1
}

| 字段名 | 说明 | | ------- | ------------------------------------------- | | jsonrpc | 协议版本，同样是 "2.0" | | result | 方法执行后返回的结果，这里是 2 + 3 = 5 | | id | 和请求中的 id一致，用于标识是哪个请求的响应 |

如果服务器在执行过程中报错，则会返回：

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32601,
    "message": "Method not found"
  },
  "id": 1
}

| 字段 | 说明 | | ------- | ------------------------------------------------------------ | | error | 是一个对象，包含错误详情 | | code | 错误码，比如 -32601表示"方法未找到"（这是 JSON-RPC 标准错误码之一） | | message | 错误的可读描述 | | id | 和请求中的 id 对应，用来匹配是哪个请求出错了 |

场景举例

我们将上述示例构建一个标准的服务器并启动：

// util.js

import fs from 'fs'

export default {
  // 方法 1：求和
  sum({ a, b }) {
    return a + b
  },
  // 方法 2：创建文件
  createFile({ filename, content }) {
    try {
      fs.writeFileSync(filename, content)
      return `文件 ${filename} 已创建`
    } catch (err) {
      return `创建文件 ${filename} 失败：${err.message}`
    }
  }
}

//=====================================================

// server.js

import utils from './utils.js'

process.stdin.on('data', (data) => {
  // 解析 stdin 输入的内容
  const req = JSON.parse(data)
  // 提取请求消息体中指定的调用方法名
  const funcName = req.method
  // 提取请求消息体中调用方法所提供的参数
  const params = req.params
  // 在工具库中调用对应的方法并获得结果
  const result = utils[funcName](params)
  
  const resp = {
    jsonrpc: '2.0',
    id: req.id,
    result
  }
  
  process.stdout.write(JSON.stringify(resp) + '\n')
})

MCP

MCP（Model Context Protocol，模型上下文协议）的本质，就是规定了一个应用程序之间如何通信的标准协议。

AI 大模型作为人工智能应用程序，可以使用 MCP ，连接到数据源、工具以及工作流程，从而能够访问关键信息并执行任务。

MCP 使用 JSON-RPC 来编码消息。该协议目前定义了两种用于客户端-服务器通信的标准传输机制：

stdio，标准输入和标准输出的通信（推荐，高效、简洁、本地）
Streamable HTTP（可远程）

协议明确标注，客户端应该在尽可能的情况下支持 stdio。

基本规范（Lifecycle）

MCP 定义了严格的生命周期：

Initialization（初始化）：功能协商和协议版本协议
Operation（操作）：正常协议通信
Shutdown（关闭）：连接的优雅终止

初始化阶段

这个阶段必须是客户端和服务器之间的第一个交互。在此阶段，客户端和服务器：

建立协议版本兼容性
交换和协商功能
共享实现细节

1. Initialization

客户端必须发送一个 initialize 请求来启动此阶段，该请求包括：

支持的协议版本
客户端功能
客户端实现信息

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize", // 值固定
  "params": {
    "protocolVersion": "2025-06-18", // 协议版本需一致
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {},
      "elicitation": {}
    },
    "clientInfo": { // 告知客户端信息
      "name": "warp terminal client",
      "title": "warp terminal",
      "version": "1.0.0"
    }
  }
}
服务器必须响应其自身功能和信息：
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "mcp-demo-server",
      "version": "1.0.0"
    }
  }
}
初始化成功后，客户端必须发送 initialized 通知，以表示它已准备好开始正常操作：
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

2. tools/list

关于 Tools 列表相关的消息结构内容，可参考：Server Features - Tools

客户端可以发送请求，来查询服务器上有哪些工具函数可以供客户端调用

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}
服务器收到请求后的响应：
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "sum",
        "title": "两数求和",
        "description": "计算两个数字的和",
        "inputSchema": {
          "type": "object",
          "properties": {
            "a": {
              "type": "number",
              "description": "第一个数字"
            },
            "b": {
              "type": "number",
              "description": "第二个数字"
            }
          },
          "required": [
            "a",
            "b"
          ]
        }
      },
      {
        "name": "createFile",
        "title": "创建文件",
        "description": "创建一个文本文件",
        "inputSchema": {
          "type": "object",
          "properties": {
            "filename": {
              "type": "string",
              "description": "文件名（如：note.txt）"
            },
            "content": {
              "type": "string",
              "description": "文件内容"
            }
          },
          "required": [
            "filename",
            "content"
          ]
        }
      }
    ]
  }
}

操作阶段

在操作阶段，客户端和服务器根据协商的能力交换消息。在符合协议版本的基础上，客户端必须仅调用协商成功的能力。调用方式使用 tools/call。

客户端调用请求：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "sum",
    "arguments": {
      "a": 2,
      "b": 3
    }
  }
}

服务器会在调用成功后，将处理结果返回：

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "计算结果：2 + 3 = 5"
      }
    ]
  }
}

MCP Inspector

MCP Inspector 是一个用于测试和调试MCP服务器的交互式开发工具。我们可以用其来连接测试基本规范中构建的 MCP server。

MCP SDK

日常开发中，我们可以使用官方提供的 MCP SDK 来进行 MCP 相关的开发。

上述的全生命周期流程的代码用 SDK 重构后：

// server.js

import { McpServer} from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// 创建 MCP 服务器
const server = new McpServer({
  name: "mcp-sdk-server",
  version: "1.0.0"
});

// 注册工具
server.registerTool("sum",
  {
    title: '两数求和',
    description: '计算两个数字的和',
    inputSchema: {
      a: z.number().describe('第一个数字'),
      b: z.number().describe('第二个数字')
    }
  },
  async ({ a, b }) => ({
    content: [{
      type: "text",
      text: String(`计算结果：${a} + ${b} = ${a + b}`)
    }]
  })
)

server.registerTool("createFile",
  {
    title: '创建文件',
    description: '创建一个文本文件',
    inputSchema: {
      filename: z.string().describe('文件名（如：note.txt）'),
      content: z.string().describe('文件内容')
    }
  },
  async ({ filename, content }) => {
    const fs = await import('fs/promises');
    try {
      await fs.writeFile(filename, content);
      return {
        content: [{ type: "text", text: `文件 "${filename}" 创建成功，内容已写入。` }]
      }
    } catch (err) {
      return {
        content: [{ type: "text", text: `创建文件 "${filename}" 失败：${err.message}` }]
      }
    }
  }
)

// 创建 stdio 传输层，正确传入 stdin 和 stdout
const transport = new StdioServerTransport();
  
// 连接服务器和传输层
await server.connect(transport);

需要留意，在 tools 的相关说明中，MCP SDK 明确需要使用 zod 作为数据格式校验工具。请确保同 SDK 一同安装。

npm install @modelcontextprotocol/sdk, zod

对接 AI 应用程序

所有能与大模型交互的应用，都可以看作是 AI 应用程序。可以说，AI 应用程序是 AI 智能体的超集。

实战演练

我们可以选择 Trae 来对接上一步开发好的 MCP 服务。

{
  "mcpServers": {
    "MCP-SDK-服务器": {
      "command": "node",
      "args": [
        "/Users/gerald/Develop/Projects/Study/mcp-tech/mcp-sdk-demo/server.js"
      ]
    }
  }
}

配置成功后，我们可以看到 Trae 会自动拉取 MCP 服务所支持的 tools。

现在大模型会在解决我们问题的过程中，自行从 tools 选择并调用。

对于创建文件工具的测试调用：

其他补充

除了 MCP Server 以外，还有两个核心概念需要了解：

MCP Host：协调和管理一个或多个 MCP 客户端的 AI 应用
MCP Client：一个维护与 MCP 服务器连接的组件，并从 MCP 服务器获取上下文供 MCP 主机使用

MCP 遵循 Client - Server 架构，其中 MCP Host------如 Claude Code 或 Trae 或活字格等 AI 应用------建立与一个或多个 MCP Server 的连接。MCP Host 通过为每个 MCP Server 创建一个 MCP Client 来实现这一点。每个 MCP Client 与其对应的 MCP Server 保持一对一的专用连接。

MCP 相关资源

Model Context Protocol：MCP 的官方网站，详细介绍了 MCP 的相关说明。其中 Sepcification 需要重点关注。
Model Context Protocol servers：这个 github 仓库是官方整理的 MCP 的参考实现，以及社区构建的服务器和额外资源的引用

场景示例代码

Github: https://github.com/GerZhang/course-mcp-tech

MCP和 FunctionCalling的区别

既然有了 MCP，那么 FunctionCalling 是不是就没有价值了？

要解答这个问题，我们还是需要回到本质上去分析。下图是一个查询天气的标准对话，使用的应用程序是 ChatGPT Desktop。

用户询问纽约的天气，ChatGPT 通过调用美国气象局的 API 查询结果并进行答复。借助于这个基础场景，我们可以看下，用户通过 AI 大模型调用外部能力获得需求结果的链路是怎么样的：

这里有两个概念，我们需要明确：

我们正常认知的大模型，其实是由大模型 API 和模型本身组成。OpenAI 的服务对接的也仅仅是大模型 API。模型本身与外部的所有交互，统一通过 API 进行。当然，模型本身的相关研究完全由大模型厂商负责，开发者一般都不会关注，所以一般大家默认大模型就是 API 和模型本身的聚合体。
我们正常理解的 AI 大模型服务，同样是由大模型和与其配套的标准服务（通常由大模型厂商提供，也可以自行开发）整合在一起的集成服务，例如这个场景所使用的 ChatGPT，用户直接对接的反而是由 OpenAI 提供的标准对外服务，GPT 仅和 OpenAI 的服务进行沟通。

在这个链路中，查询天气函数这样的具体功能，其本质就是函数，而 OpenAI 服务器，则扮演着中间人的角色，作为大模型的代理人，这个服务既负责和最终用户沟通，也负责对接和管理各种各样的工具函数。如果我们希望能够在 AI 侧做更多的工作，就需要将工作中心放在 AI 服务器的开发和管理上。

了解了调用链路后，我们结合 MCP 与 FunctionCalling 的定义，就能很好的理解二者的价值点与区别。

FunctionCalling 就是模型调用函数的一种能力。老实说，这个能力的命名很容易造成歧义。大模型本身并不会也不能调用外部函数。大模型只能判断什么样的场景，需要调用哪些函数而已。当大模型判断出结果后，会给出调用意图。具体的调用动作会由 AI 服务服务器来执行。AI 服务器调用完成后，再将结果返回给大模型，由大模型进行二次组装并返回最终答复结果。

MCP 本质上就是一套函数的发现和调用协议，它只作用在服务器和函数之间。和大模型一点关系都没有，尽管这个协议名称中包含了 Modle 这个单词，但没有大模型这个协议一样可以正常使用。它提供的所有行为都在 AI 服务器上进行，旨在维护一个更加完善且丰富的上下文（context）。AI 服务器通过 MCP 来维护工具箱，以及执行内部的工具调用。然后通过 API 和大模型进行沟通。

此时，我们发现，MCP 和 FunctionCalling 并不重叠，二者分别作用在链路的两个环节，发挥的作用也各不相同。

总结

MCP 并非一项革命性技术，甚至严格来说，它本身并算是一种"技术"。尽管被称为"协议"，却更像是一种约定俗成的规范化接口标准。事实上，在 MCP 出现之前，大语言模型（LLM）与各类 AI 工具或服务之间的协作早已存在------开发者完全可以手动对接 API、定制调用逻辑、处理上下文传递，完成今天 MCP 所支持的各类任务。

但问题在于，这种"能干"往往代价高昂：每个服务都有自己的调用格式、认证方式和上下文管理逻辑，开发者需要为不同工具重复造轮子；模型与工具之间的信息传递缺乏统一语义，容易出错且难以调试；生态之间互不兼容，限制了组合创新的可能性。

MCP 的价值，正是在这些"能干但不好干"的地方体现出来。它通过定义一套轻量、通用、可扩展的协议，让 LLM 与外部服务的对接变得更简单、更一致、更可靠。它没有带来全新的能力，却显著降低了协同成本，提升了开发效率和系统稳定性。

因此，我们应当以理性务实的态度看待 MCP：它不是魔法，而是一种务实的工程共识，是一种推动行业标准化、促进生态协同的重要基础设施。理解它、善用它，才能在日益复杂的 AI 应用生态中游刃有余。

扩展链接

低代码+MCP实战三大案例，企业如何通过MCP构建专属AI智能体？（上）

低代码+MCP实战案例，企业如何通过MCP构建专属AI智能体？（下）

微信关注我们

原文链接：https://my.oschina.net/powertoolsteam/blog/18711209

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

面向 LLM 的 GPU 系统工程方法论

编者按：我们今天为大家带来的文章，作者的观点是：GPU 工程的核心不在于手写内核的能力，而在于构建系统设计思维 ------ 理解从模型定义到硬件层的完整技术栈如何协同工作。作者提出了一个五层渐进式调试框架：从模型定义（Model Definition）入手，识别计算与内存瓶颈；进入并行化（Parallelization）阶段，解决多卡同步问题；深入运行时编排（Runtime Orchestration），优化集群资源利用率；通过编译与优化（Compilation & Optimization）提升生产环境性能；最终触及硬件层的物理极限。文章阐释了每一层级的典型瓶颈与解决思路，强调 80% 的问题可通过前三层的系统设计解决，内核工程仅在边缘场景中才真正发挥作用。作者 | Abi Aryan 编译 | 岳扬最近有条推文在 X 平台爆火------ 大多数人看到后的想法是：我得学会 CUDA 内核开发才能体现自身价值。但事实并非如此。即便投入毕生精力，你大概率也挤不进那个百人左右的精英圈子。内核开发固然重要，但不应作为入门起点。首要的是理解整个系统应该如何协同运作。 ...

2025-11-12

36

从混沌中见你所见------文生图的逆向浪漫缘起一直以来，我都希望能拍一组日照金山的照片，向往那种巍峨雪山的寂寥与金光漫射的神圣，因缘际会一直未能如愿。看着朋友圈的AI整的手办图，咱也试试生成一个。你别说，你还真别说，有那么点意思。我们考虑一个问题，如何让计算机学会画画？我们可能第一时间想到人类画画的过程：现实世界中有大量不同主体的摄影作品和美术作品，但美术作品大多不会有中间过程的披露，而摄影作品则完全没有(和我的快门说去吧)。所以，学习的出发点一定是现有的优秀作品。**人类学习通过反复练习内化技巧，计算机则是从数据中提取规律。**如果我们有一种可逆的操作，输入图片=>输出特征（学习过程），输入特征=>输出图片（工作过程），那么计算机画画的问题就解决了。扩散高斯噪声对于学习过程，需要一个提取图像特征的步骤（需要可逆），换个说法就是遮蔽掉非特征的部分，这个遮蔽过程应该具备什么样的特征呢? 随机: 为了避免遮蔽本身对特征的影响，遮蔽需要随机（无结构、不可预测），否则最后提取的特征会包含这种遮蔽的特征。我们将随机的这种遮蔽，称为噪声（区别于"信号"）。看到随机我...

2025-11-12

34

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。