---

一、引言：Context Engineering 的新基建

2024 年 11 月 25 日，Anthropic 公司正式推出 MCP（Model Context Protocol，模型上下文协议），被业界称为"AI 界的通用 USB-C 接口"。这不是一个工具、不是一个应用，也不是一个 API SDK——它是一个协议，目标是让任何一个 AI 模型能以统一的方式访问外部资源和工具。

在 MCP 出现之前，大模型对接外部数据源的现状是：每接入一个工具（高德地图、Gmail、飞书文档、本地文件系统），开发者都要单独写一套适配代码。不同模型的 Function Calling 格式各异，RAG（检索增强生成）方案零散割裂，换个模型就要重写一遍——这就是典型的 “M×N 适配问题”。

MCP 的出现，将这个问题降维成了 “M+N 接入问题”：所有工具提供方遵循同一套协议暴露能力，所有模型客户端通过同一套协议发现和调用工具，一次编写，处处可用。

一句话理解：MCP 就是 LLM 与外部世界的标准化通信协议，类比 HTTP 之于 Web、USB-C 之于硬件外设。

---

二、MCP 是什么？

2.1 核心定位

再次强调：MCP 不是工具、不是应用、不是 API、不是 SDK、不是产品——它是一个协议。 它定义了一套标准，让大模型能够以统一、安全、可扩展的方式去访问"资源和工具"。

维度	说明
本质	开放协议（基于 JSON-RPC）
目标	任何模型 ↔ 任何工具/资源，自由互联
类比	USB-C 之于硬件、HTTP 之于 Web 服务
解决的问题	终结 RAG、Function Calling 零散适配的乱象

2.2 模型需要交互什么？

大模型要从"只会聊天"进化到"能办事"，需要两类东西：

🔹 资源（Resources）

模型想知道的数据来源——数据库、API 接口、本地文件、SaaS 服务（飞书文档、高德地图、Google Drive）等。资源以结构化形式暴露给模型，模型按需读取。

// 示例：MCP Server 暴露的资源列表（概念示意）
{
  "resources": [
    { "uri": "file:///project/src", "name": "项目源码目录" },
    { "uri": "postgres://app/users",   "name": "用户数据库" },
    { "uri": "feishu://doc/xxx",       "name": "需求文档" }
  ]
}

🔹 工具（Tools）

模型能调用的能力——创建日历事件、发送邮件、执行 Shell 命令、远程控制设备、读写文件等。模型通过推理决定何时调用哪个工具，MCP 负责传递参数和返回结果。

核心区别：资源是"读"（模型获取上下文），工具是"写/执行"（模型产生行为）。两者结合，模型才能真正从 chatbot 跃迁到 Agent。

---

三、MCP 的三大核心角色

MCP 架构由三个角色组成，各司其职：

角色	身份	职责	具体例子
MCP Host	宿主程序	承载 AI 模型，发起交互请求	Claude Code、Cursor、Trae、Codex
MCP Client	客户端插件	连接具体的 MCP Server，暴露其能力给 Host	配置在 Host 里的 filesystem 客户端、Gmail 客户端
MCP Server	服务端	提供具体的资源和工具，定义交互方式	文件系统服务、数据库服务、飞书 API 服务

工作流程

用户提问："帮我读取 mcp-test 目录下的所有 .js 文件"
        │
        ▼
┌─────────────────┐
│   MCP Host      │  ← Claude Code 收到用户指令
│  (Claude Code)  │
└────────┬────────┘
         │ 内部推理："我需要访问文件系统，看看有没有可用的 MCP Client"
         ▼
┌─────────────────┐
│   MCP Client    │  ← 已配置的 filesystem 客户端
│  (filesystem)   │
└────────┬────────┘
         │ 通过 stdio 协议通信
         ▼
┌─────────────────┐
│   MCP Server    │  ← @modelcontextprotocol/server-filesystem
│  (文件系统服务)   │     执行实际的文件遍历操作
└────────┬────────┘
         │ 返回文件列表
         ▼
   Claude Code 拿到结果，组织回复给用户

---

四、实战：Filesystem MCP Server 从零上手

4.1 配置 .mcp.json

在项目根目录创建 .mcp.json（Claude Code 启动时自动读取）：

{
    "mcpServers": {
        "filesystem": {
            "type": "stdio",
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-filesystem",
                "D:\\workspace\\zmt_ai\\ai\\mcp\\mcp-test"// 这里存放你自己的文件路径
            ]
        }
    }
}

配置解读：

字段	含义
type: "stdio"	通信方式为标准输入/输出（本地进程通信）
command: "npx"	用 npx 运行，无需提前全局安装
-y	自动确认，跳过安装询问
最后的目录路径	安全边界：MCP Server 只能访问此目录及子目录

⚠️ 安全注意：路径参数定义了 Server 的访问范围，超出该目录的操作会被拒绝，这是 MCP 内置的安全隔离机制。

4.2 使用效果

配置完成后重启 Claude Code，输入 /mcp 即可看到已注册的 MCP Server。之后直接在对话中下达指令即可：

用户: 使用 filesystem MCP 工具，帮我读取 test.js，并改成 ES6 风格。

用户: 使用 filesystem MCP 工具，帮我在 test.js 里添加一行代码，声明变量 b = 2。

Claude Code 会自动通过 MCP 协议调用 filesystem Server，完成文件的读取和修改，全程无需手动操作文件。

示例：

1. 在claude code中：
   2.在trae中(前提：配置好MCP协议)：
   

---

五、MCP 的深远影响：从 Chatbot 到 Agentic AI

5.1 不只是"遍历文件"

有人可能觉得 MCP 就是个"高级版文件遍历工具"，这是严重的误解。MCP 的底层价值在于——它从根本上重构了 AI 应用的架构范式。

过去的 AI 应用架构：
┌──────────┐     定制对接      ┌──────────┐
│  模型 A  │ ────→ 代码1 ────→ │ 工具 X   │
│  模型 B  │ ────→ 代码2 ────→ │ 工具 Y   │  ← 每对组合一套代码
│  模型 C  │ ────→ 代码3 ────→ │ 工具 Z   │
└──────────┘                   └──────────┘

MCP 时代的 AI 应用架构：
┌──────────┐                  ┌──────────┐
│  模型 A  │ ↘               ↗ │ 工具 X   │
│  模型 B  │ ──→ MCP 协议 ──→ │ 工具 Y   │  ← 一套协议全部联通
│  模型 C  │ ↗               ↘ │ 工具 Z   │
└──────────┘                  └──────────┘

5.2 从 Chatbot 到 Agentic AI 的关键一跃

阶段	特征	MCP 的角色
Chatbot	只能基于预训练知识聊天，无法获取实时信息、无法执行操作	无 MCP
RAG 增强	能检索外部知识，但每个数据源独立适配，碎片化严重	无 MCP
Agentic AI	模型自主推理 → 发现可用工具 → 调用工具 → 根据结果继续推理	✅ MCP 提供标准化底座

MCP 为 Context Engineering（上下文工程） 提供了标准化的通信底座——模型不再是凭预训练知识"猜测"，而是通过协议去 发现 Host 里有哪些可用的 Client，哪些资源和工具可以为当前任务提供上下文，然后通过推理决定如何调用。

---

六、全文总结

MCP（Model Context Protocol）是 Anthropic 推出的开放协议，解决的核心问题是：让任何 AI 模型以统一的方式访问任何外部资源和工具。它类比于硬件领域的 USB-C——统一接口、即插即用、生态共享。

---

七、核心知识点复盘

知识点	要点
MCP 本质	协议，不是工具/应用/API/SDK
三大角色	MCP Host（宿主）、MCP Client（客户端）、MCP Server（服务端）
资源 vs 工具	资源是"读"（数据来源），工具是"写/执行"（执行能力）
通信方式	本地用 stdio，远程用 HTTP（基于 JSON-RPC）
配置入口	.mcp.json 文件，放在项目根目录，Host 启动时自动加载
安全模型	MCP Server 只能访问配置中指定的路径范围

---

八、常见问题 / 避坑指南

Q1：配置了 .mcp.json，但 /mcp 显示 “No MCP servers configured”？

原因：.mcp.json 没有放在项目根目录。Claude Code 只读取工作区根目录下的 .mcp.json，子目录中的配置文件不会被识别。

解决：将 .mcp.json 移动到项目根目录，重启 Claude Code。

Q2：npx 和 npm install -g 哪种方式更好？

方式	优点	缺点
npx（推荐）	即用即走，自动拉最新版，不占全局空间	首次运行需下载，略慢
npm i -g	全局可用，启动快	需手动升级，可能版本冲突

日常使用推荐 npx，开发调试阶段可用全局安装提升启动速度。

Q3：MCP 和 Function Calling / Tool Use 的区别？

• Tool Use / Function Calling 是模型的能力（模型"会"调用工具）
• MCP 是协议（定义工具从哪来、怎么接、参数规范是什么）
• 两者是配合关系：MCP 为 Tool Use 提供标准化的工具来源，Tool Use 负责在推理中决定调用哪个工具

Q4：MCP Server 能访问哪些目录？

只能访问配置 args 中明确指定的目录及其子目录。这是 MCP 的安全边界设计，超出范围的路径会被 Server 拒绝。务必只授权必要的最小范围目录。

Q5：MCP 只支持 Claude 吗？

不。MCP 是开放协议，任何模型（Claude、GPT、Gemini 等）和任何客户端（Cursor、Trae、Codex、Claude Code 等）都可以实现和接入。Anthropic 是协议的发起者，但目标是生态级的标准化。