目录

1. 为什么需要 MCP？
2. MCP 协议是什么？
3. MCP 的核心特点
4. 项目实战：构建一个 MCP Server
   • 4.1 项目初始化
   • 4.2 核心依赖解析
   • 4.3 MCP Server 代码详解
5. MCP 的通信机制
6. MCP Tool 的本质
7. 总结与展望

1. 为什么需要 MCP？

先说一个现实问题。在传统的 AI Agent 开发中，工具（Tool）往往与 LLM 紧紧绑在一起，这就带来了两个让人头疼的痛点：

1. 工具无法跨项目复用 —— 在一个项目里写好的 Tool，想拿到另一个项目直接用？基本上得重写一遍。
2. 语言绑定限制 —— 用 Node.js 写的工具，Ja va、Python、Rust 等语言的项目怎么调用？每个语言都得自己实现一套 HTTP 客户端，想想就头大。

这些问题的本质是什么？说白了，就是Tool 与 LLM 之间缺乏一个标准化的通信协议。

MCP 正是为了解决这些问题而生的。它的核心理念其实很朴素：

2. MCP 协议是什么？

2.1 定义

MCP（Model Context Protocol，模型上下文协议） 是一种标准化 LLM 与外部工具和资源之间通信的协议。它的目标直指两个关键点：

• 解耦 LLM 和 Tool，让工具可以独立开发、独立部署、跨项目复用，互不干扰。
• 为 Model 扩展 Context（上下文），让它能做更多（Tool）、知道更多（Resource）。

2.2 MCP 的定位

MCP 不是一种传统的 API 调用方式，它和常见的 HTTP Fetch 有本质区别：

简单来说，MCP 的目标是：不管是本地工具还是远程工具，Agent 想跨进程调用某个工具，通过 MCP 协议就行。

3. MCP 的核心特点

3.1 跨进程调用

MCP 最让人兴奋的一点就是跨进程调用工具：

• 本地跨进程 → 使用 stdio（标准输入输出流）
• 远程跨进程 → 使用 HTTP

3.2 架构角色

在 MCP 的架构里，有三个关键角色各司其职：

一个 AI Agent（MCP Host）可以通过配置多个 MCP Client，连接到不同的 MCP Server，实现跨进程工具调用。这就像把一个多功能工具箱拆成了一个个独立的小工具包，需要哪个就调哪个。

3.3 通信原理

基于 stdio（标准输入输出流） 的通信原理其实很直观：

• 键盘输入 → 控制台输出，这是最基础的模式。
• 当一个进程（Agent）调用子进程（比如 node child_process）时，通过 stdio 标准输入输出流就能实现通信。
• 对于远程场景，MCP 同样支持基于 HTTP 的通信方式。

4. 项目实战：构建一个 MCP Server

光说不练假把式，下面我们通过 mcp-demo 项目，从零开始搭建一个完整的 MCP Server。

4.1 项目初始化

先看看项目的 package.json 配置：

 复制代码{
  "name": "mcp-demo",
  "version": "1.0.0",
  "description": "MCP Demo 项目",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@langchain/core": "^1.2.3",
    "@langchain/mcp-adapters": "^1.1.3",
    "@langchain/openai": "^1.5.5",
    "@modelcontextprotocol/sdk": "^1.29.0",
    "chalk": "^5.6.2",
    "zod": "^4.4.3"
  }
}

4.2 核心依赖解析

项目依赖了几个关键包，各司其职：

4.3 MCP Server 代码详解

下面我们逐段解析 src/my-mcp-server.mjs 的实现，一步步拆解这个 Server 是如何跑起来的。

4.3.1 导入依赖

 复制代码import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

关键点：

• McpServer：MCP 服务端的核心类，用于创建服务器实例、注册工具。
• StdioServerTransport：基于标准输入输出流的传输层，实现跨进程通信。
• z（Zod）：用于声明和验证工具参数的数据结构。

4.3.2 定义数据源

 复制代码// 假数据，未来可以走数据库
const database = {
    users: {
        '001': { id: '001', name: '张三', email: 'zs@qq.com', role: 'admin' },
        '002': { id: '002', name: '李四', email: 'ls@qq.com', role: 'user' },
        '003': { id: '003', name: '王五', email: 'wu@qq.com', role: 'user' },
    }
}

这里用内存中的静态数据模拟数据库。在实际项目中，这里可以替换为真实的数据库连接（MySQL、PostgreSQL、MongoDB 等）。这正是 MCP 的精妙之处：工具的实现细节对 LLM 完全透明，LLM 只管调用，不管背后是内存数据还是生产数据库。

4.3.3 创建 MCP Server 实例

 复制代码const server = new McpServer({
    name: 'my-mcp-server',
    version: '1.0.0',
});

每个 MCP Server 都有自己的名称和版本号，这是 MCP 协议规范的一部分，便于 MCP Client 识别和管理多个 Server。想象一下，如果你的 Agent 同时连接了十几个 Server，有名字和版本号就方便多了。

4.3.4 注册工具（Tool）

 复制代码server.registerTool('query-user', {
    description: `查询数据库中的用户信息。输入用户ID，返回该用户的详细信息(姓名、邮箱、角色)`,
    inputSchema: {
        user_id: z.string().describe('用户ID，例如：001，002，003')
    }
}, async (userId) => {
    const user = database.users[userId];
    if (!user) {
        return {
            content: [
                { type: 'text', text: `用户 ID ${userId} 不存在。可用的ID：001, 002, 003` }
            ]
        }
    }
    return {
        content: [
            {
                type: 'text',
                text: `用户 ${user.id}的信息是：
                    姓名：${user.name}，邮箱：${user.email}，角色：${user.role}`
            }
        ]
    }
})

这是 MCP Server 的核心。registerTool 方法接收三个参数，每个参数都不可或缺：

关键设计思想：

• description 是写给 LLM 看的 —— LLM 通过这段描述来判断何时该调用这个工具。描述写得好，LLM 才能用得准。
• inputSchema 使用 Zod 定义，LLM 根据 Schema 生成结构化的参数，就像给 LLM 一张填表模板。
• 返回值遵循 MCP 协议的 content 格式，支持多种内容类型（text、image 等），灵活度很高。

4.3.5 启动传输层

 复制代码// 跨进程通信方式 stdio
const transport = new StdioServerTransport();
await server.connect(transport);

这是整个 Server 的最后一步，也是最关键的一步：

• StdioServerTransport() 创建一个基于标准输入输出流的传输层。
• server.connect(transport) 将 Server 绑定到该传输层，开始监听来自 MCP Client 的请求。

这意味着： 任何能够启动子进程并与其 stdio 通信的程序（Node.js、Python、Ja va、Rust 等），都可以作为 MCP Client 来调用这个 Server 中的工具。这就是 MCP 跨语言、跨进程的核心实现，也是它最厉害的地方。

5. MCP 的通信机制

5.1 Stdio 通信模型

 复制代码┌──────────────┐    stdin    ┌──────────────┐
│              │  ─────────> │              │
│  MCP Client  │             │  MCP Server  │
│  (Agent)     │  <───────── │  (Tool 提供) │
│              │    stdout   │              │
└──────────────┘             └──────────────┘

1. MCP Client（Agent 端）通过 child_process 启动 MCP Server 子进程。
2. Client 通过 stdin 向 Server 发送 JSON-RPC 格式的请求（比如：调用工具 query-user，参数 {user_id: "001"}）。
3. Server 处理请求后，通过 stdout 返回 JSON-RPC 格式的响应。
4. Client 接收响应，将其传递给 LLM 进行下一步推理。

5.2 HTTP 通信模型

对于远程工具调用，MCP 同样支持基于 HTTP 的传输方式，允许 Agent 调用部署在远程服务器上的工具。本地和远程两手抓，MCP 的适用场景一下子就拓宽了。

6. MCP Tool 的本质

在 MCP 的视角下，Tool 的本质可以概括为三个核心组成部分，每个部分各司其职：

这种设计将 语义层（给 LLM 看）和 执行层（给机器跑）清晰地分离开来，实现了 LLM 与 Tool 的彻底解耦。简而言之，LLM 只负责“理解”和“决策”，具体的执行交给 Handler，各取所长。

7. 总结与展望

7.1 本文要点回顾

1. MCP 解决了什么问题？ —— Tool 无法跨项目复用、跨语言调用的痛点，让工具开发从“各自为战”走向“标准化协作”。
2. MCP 是什么？ —— 一种标准化 LLM 与 Tool/Resource 通信的协议，核心是解耦和扩展 Context。
3. MCP 的核心特点 —— 跨进程调用（本地 stdio + 远程 HTTP），灵活覆盖各种场景。
4. 如何构建 MCP Server？ —— 使用 @modelcontextprotocol/sdk，通过 McpServer + registerTool + StdioServerTransport 三步即可完成，门槛并不高。
5. Tool 的本质 —— Description + Input Schema + Handler 三位一体，各司其职。

7.2 未来展望

MCP 作为 AI Agent 生态的关键基础设施，未来有很多值得期待的方向：

• 多语言 SDK 生态 —— 随着 Python、Ja va、Rust 等语言的 SDK 成熟，跨语言工具调用将更加便捷，不再受限于语言。
• 工具市场（Tool Marketplace） —— 标准化的 MCP Server 可以被发布和共享，形成类似 npm/PyPI 的工具生态，开发者可以像安装软件包一样安装工具。
• 企业级 MCP 网关 —— 统一管理、鉴权、监控企业内部的各种 MCP Server，让企业级 AI 应用更可控、更安全。
• 与 Agent 框架深度集成 —— LangChain、AutoGen、CrewAI 等框架将 MCP 作为一等公民支持，未来开发 Agent 会像搭积木一样简单。