MCP 协议全解：AI 界的 USB-C 怎样让大模型看懂你的文件

回想一下：你让 Claude Code 读你项目里的文件，它怎么做到的？你让 Cursor 理解你的代码库，它怎么知道的？你让 TRAE 操作你的本地目录，它怎么实现的？

答案很可能都是同一个：MCP。

MCP（Model Context Protocol）是 Anthropic 推出的大模型上下文协议。它不是一个工具、不是一个应用、不是一个 API Key，而是一个通信协议。它的目标是：让任何一个 AI 模型，都能以统一的方式访问外部资源和工具。就像 USB-C 一根线搞定充电、数据传输、视频输出，MCP 一套协议终结了 RAG、函数调用各自为战的乱象。

---

一、MCP 之前：每个模型都是一座孤岛

在 MCP 出现之前，大模型想跟外部世界交互，基本靠"打补丁"。

想让模型读本地文件？写一段 Python 脚本，用 fs.readFile 把内容读出来，拼到 Prompt 里。想让模型查数据库？写一段 SQL 查询，把结果格式化成文本，塞进上下文。想让模型发邮件？调 Gmail API，拿到返回，再喂给模型。

每个模型、每个数据源、每个工具，都是单独适配的。同一个文件读取功能，给 Claude 写一套，给 GPT 写一套，给 Gemini 再写一套。代码量不大，但适配成本是 O(n×m)——n 个模型 × m 个数据源，指数级爆炸。

更致命的是，这些适配代码散落在各个项目的角落，没有统一标准、没有版本管理、没有安全校验。同样的功能，不同人写出来的实现方式完全不同，维护起来是噩梦。

Context Engineering 的理念已经讲清楚了——AI 需要上下文。但上下文从哪来？怎么接入？怎么管理？没有统一协议之前，全靠手写胶水代码。MCP 解决的，就是这个"最后一公里"的问题。

---

二、MCP 的三层架构：Server、Client、Host

MCP 的架构分三层，每一层职责清晰：

层	角色	干什么	例子
MCP Server	服务端	提供上下文资源或工具，暴露给 LLM 使用	文件系统服务、数据库服务、Gmail 服务
MCP Client	客户端	与 Server 通信，获取上下文，拼装成 Prompt	Cursor 配置的 MCP 连接、TRAE 的内置 MCP
MCP Host	宿主	AI 应用本身，通过 Client 调用 Server	Claude Code、Cursor、TRAE、Codex

三者的协作关系用一句话说清楚：Host 是 AI 应用，Host 内部配置了一堆 Client（像插件一样），每个 Client 连接一个 Server。当用户提问时，Host 通过推理判断需要哪些上下文，然后通过对应的 Client 从 Server 获取数据，拼装成 Prompt 发给 LLM。

一个具体的例子：你在 Claude Code 里问"帮我看看项目中 index.js 的内容"。Claude Code（Host）判断需要访问文件系统，找到配置的 filesystem MCP Client，通过 Client 向 filesystem MCP Server 发起请求，Server 读取文件内容返回，Claude Code 把内容拼到上下文里，发给 LLM 生成回答。

整个流程，用户只看到一行自然语言指令，底下 MCP 三层协作完成了文件读取、上下文组装、推理生成。

---

三、两种能力：Resources 和 Tools

MCP 为 LLM 提供两种核心能力：Resources（资源）和 Tools（工具）。

Resources 是模型"想知道"的东西——数据、文件、API 返回、数据库内容。飞书的文档、高德地图的 POI 数据、本地的 JSON 文件、数据库里的用户表，都是 Resources。模型通过 MCP Server 读取这些资源，作为上下文注入 Prompt。

Tools 是模型"想调用"的能力——发邮件、创建日历事件、执行终端命令、远程控制设备。模型不是只能读，还能动手操作。Tools 让 LLM 从"只能聊天"进化到"能干实事"。

两者的区别很直观：

维度	Resources	Tools
方向	读取（外部 → LLM）	写入/执行（LLM → 外部）
本质	上下文提供者	能力扩展者
典型例子	文件内容、数据库记录、API 数据	发邮件、创建文件、执行命令
触发方式	模型需要时自动检索	模型推理后决定调用

Resources 和 Tools 合在一起，构成了 LLM 与外部世界交互的完整闭环：先读资源获取上下文，再调工具执行操作。 MCP 把这两件事统一到了一套协议里，不再需要为"读文件"写一套代码、为"发邮件"写另一套完全不兼容的代码。

![Resources vs Tools 对比图：读 vs 写，上下文 vs 能力]

---

四、实战：5 分钟搭一个文件系统 MCP Server

理论讲清楚，动手搭一个。MCP 官方提供了开箱即用的 filesystem server，一行命令安装：

 复制代码npm i -g @modelcontextprotocol/server-filesystem

然后配置 MCP Client。以 Claude Code 或 TRAE 为例，在 .mcp.json 中添加：

 复制代码{
    "mcpServers": {
        "filesystem": {
            "type": "stdio",
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-filesystem",
                "F:/workspace/zzd_ai/ai/mcp/mcp-text"
            ]
        }
    }
}

type: "stdio" 表示通过标准输入输出通信（本地进程间通信），command 指定启动命令，args 中的最后一个参数是允许访问的目录路径。配置完成后，Host 重启即可生效。

现在你可以在聊天框里直接说"读一下 F:/workspace/zzd_ai/ai/mcp/mcp-text 目录下的文件"，Host 通过 MCP 协议调用 filesystem server，读取文件内容，返回给 LLM 处理。

这个配置的巧妙之处在于：它把文件系统的访问权限精确控制到了指定目录。 MCP Server 只能访问 args 中指定的路径，不能越界。这是 MCP 协议安全性的重要考量——不是给 LLM 敞开了文件系统的大门，而是只开了一扇有锁的窗。

![MCP 文件系统配置流程图：npx 启动 → stdio 通信 → 指定目录 → LLM 访问]

---

五、手写一个 MCP Server：从零搭起

用官方封装好的 server 是第一步，理解它的内部机制是第二步。手写一个最简单的 MCP Server，核心就三件事：定义 Schema、实现处理逻辑、注册到 Server。

 复制代码// 实例化 MCP Server
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
// 本地 stdio 通信
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import fs from 'fs/promises';const server = new Server(
    {
        name: 'simple-read-mcp',
        version: '1.0.0',
    },
    {
        capabilities: {
            tools: {}  // 声明这个 Server 提供 tools 能力
        }
    }
);async function main() {
    // 创建本地通信通道
    const transport = new StdioServerTransport();
    // 启动 Server，监听 Client 请求
    await server.listen(transport);
}main();

这段骨架代码做了什么：

1. new Server() 创建了一个 MCP Server 实例，声明了名字、版本和能力（tools: {} 表示这个 Server 提供工具调用）
2. StdioServerTransport 建立了本地进程间通信通道——Client 通过标准输入输出和 Server 通信
3. server.listen(transport) 启动 Server，开始监听来自 Client 的请求

骨架搭好之后，还需要注册具体的工具处理函数。核心依赖只有两个：

• @modelcontextprotocol/sdk：MCP 协议的 SDK，负责通信层的协议实现
• zod：数据验证库，用于定义工具的 Schema（参数名、类型、是否必填）

Schema 的作用是告诉 LLM："我这个工具叫什么名字、接受什么参数、返回什么结果"。LLM 看到 Schema 后，就能在推理时判断"要不要调用这个工具、怎么传参"。本质上，Schema 是 LLM 和外部工具之间的"API 文档"。

---

六、MCP 真正的革命性：从 Chatbot 到 Agentic AI

MCP 不只是一个便利的工具，它从根本上重构了 AI 的应用架构。

在 MCP 之前，LLM 应用的本质是"聊天机器人（Chatbot）"——模型在预训练数据的基础上回答问题，偶尔通过手写函数调用补充一些外部信息。能力的边界受限于模型本身的训练数据和开发者为它专门写的适配代码。

MCP 之后，LLM 应用变成了"智能体（Agentic AI）"——模型不再是孤立的对话引擎，而是连接了无数外部资源和工具的中央调度器。它可以通过 MCP 读写文件、查询数据库、调用 API、发送邮件、执行命令，在统一的协议框架下调度所有外部能力。

Context Engineering 为 AI 提供了"需要什么信息"的认知框架，而 MCP 为 Context Engineering 提供了标准化的通信底座。这两者结合，彻底终结了过往 RAG、函数调用零散适配的乱象。

MCP 的核心价值可以用一个类比说清楚：HTTP 统一了浏览器和服务器之间的通信，MCP 统一了 AI 模型和外部世界之间的通信。 HTTP 出现之前，每个浏览器和每个服务器之间的通信方式都不一样。HTTP 出现之后，任何浏览器都能访问任何服务器。MCP 在做同样的事——让任何 AI 模型都能以统一的方式，访问任何外部资源和工具。

维度	MCP 之前	MCP 之后
文件读取	每个项目写 Python 脚本	统一配置 filesystem server
数据库查询	SQL 格式化成文本拼 Prompt	统一 database server
API 调用	手写 fetch + 拼接结果	统一 API server
模型切换	全部适配代码重写	换 Host 配置，Server 不动
安全控制	靠开发者自觉	Server 级别权限控制

---

七、一张图收束

 复制代码用户自然语言指令
        ↓
MCP Host（Claude Code / Cursor / TRAE）
        ↓
推理：需要哪些上下文？
        ↓
MCP Client 层（插件式配置）
 ├── filesystem Client → MCP Server（本地文件读写）
 ├── database Client  → MCP Server（数据库查询）
 ├── gmail Client     → MCP Server（邮件收发）
 └── amap Client      → MCP Server（地图服务）
        ↓
获取 Resources（上下文数据）+ 调用 Tools（执行操作）
        ↓
拼装成 Prompt → LLM 推理 → 生成回答
        ↓
Agentic AI：不只是聊天，而是能读能写的智能体

MCP 不是魔法，它只是把"AI 需要访问外部世界"这件事，从手写胶水代码变成了标准化协议。但正是这个标准化，让 AI 从 Chatbot 走到了 Agentic AI。

---

八、总结

MCP 是 2024 年底 AI 工程化方向最重要的基础设施之一。它不复杂，但影响深远。

三个核心认知：

1. MCP 是一个协议，不是工具。 它定义的是通信标准，不是具体实现。任何人、任何公司都可以基于这个协议实现自己的 Server 和 Client，就像 HTTP 协议下有 Apache、Nginx、IIS 无数种实现。

2. Resources 和 Tools 是 MCP 的两条腿。 Resources 让模型知道世界，Tools 让模型改变世界。读和写，缺一不可。

3. MCP 是 Context Engineering 的通信底座。 Context Engineering 回答了"AI 需要什么上下文"，MCP 回答了"上下文怎么来"。两者结合，AI 从 Chatbot 走向 Agentic AI。

要点	一句话
MCP 是什么	AI 界 USB-C，统一 LLM 与外部世界的通信协议
三层架构	Host（AI 应用）→ Client（插件）→ Server（服务）
Resources	模型想知道的东西：文件、数据库、API
Tools	模型想调用的能力：发邮件、执行命令、创建文件
核心价值	终结 RAG/函数调用各自适配的乱象，统一上下文接入
安全性	Server 级别权限控制，精确到目录/操作类型