简单来说，MCP 就是 AI 领域的 Type-C 接口

很多人一看到「协议」这个词就容易犯怵，先别管专业术语，我们用一个生活化的例子来理解。

回想一下以前手机充电线的混乱局面：苹果用 Lightning，老安卓用 Micro USB，新安卓用 Type-C，出门必须带三根线，充电宝上也插着三个不同接口。过去大模型对接外部工具时，也是类似的麻烦：你想让 Claude 读取本地文件，得专门写一套适配代码；想让 GPT 接入同样的功能，又得改成 OpenAI 函数调用的格式；换到 Cursor 编辑器，插件的规则又不相同。

MCP 所做的事情，就是将所有这些参差不齐的接口统一成 Type-C 那样的标准。只要你开发的工具遵循 MCP 协议——无论是文件系统、飞书、数据库还是邮件服务——所有支持 MCP 的 AI 客户端都能直接调用，再也不用为每个客户端单独编写适配代码。

它不是某个具体工具，也不是某个 SDK，更不是某家公司的专属产品。它是一套中立的通信规范，规定了大模型与外部工具之间如何建立连接、传递参数、返回结果。这有点像 HTTP 协议，不管后端使用什么服务器、前端使用什么浏览器，大家都遵循同一套规则进行交互。

三层架构：谁来执行，谁来传递

不少人一开始会误以为 MCP 就是一个插件市场，点一下安装就能直接使用。后来搞清楚了它的三层关系，才知道完全不是这么回事。

最贴近普通用户的是MCP 客户端，也就是我们日常使用的 AI 工具：Trae、Cursor、Claude Desktop 等。在设置里添加 Server、管理工具列表，都属于这一层的操作。它的角色相当于一个「转接头」，将 MCP 服务的能力翻译成大模型能够理解的格式。

中间那一层是大模型本身，也就是所谓的「宿主」。模型不会直接去访问你的文件或 API，它只负责自己最擅长的任务——推理。判断当前任务是否需要调用工具、调用哪个工具、传递什么参数，这些都由模型决定，但具体的执行环节它不参与。

最底层是MCP 服务端，这才是真正干活的角色。比如本次使用的 filesystem Server，它负责真实地去读取文件、写入文件、列出目录，然后将结果返回给上层。所有实际操作都在这一层完成，安全边界也在这里控制。

三层之间完全依赖 MCP 协议进行通信，彼此无需关心对方的具体实现细节，只要按照协议格式交互即可。你更换了客户端或模型，但只要它们都支持 MCP，服务端的代码一行都不需要修改。

从零配置一个 filesystem MCP Server

回到实际操作，就拿官方的文件系统 Server 来举例，这也是最常用且最适合新手入门的一个。

官方已经将包发布到 npm 上了，下载安装后直接用 npx 就能启动运行。

全局安装：

复制代码    @modelcontextprotocol/server-filesystem

直接使用 npx -y 即可运行：

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

stdio 模式通过标准输入输出进行通信，无需开放端口、无需配置网络，本地运行时最为轻量。args 中的最后一个路径，就是允许 AI 访问的目录。

第一个测试：Claude cli

首先在对应 JSON 配置目录下通过 npx -y 本地启动，会出现以下提示：

启动 claude，输入 /mcp，claude 成功连接本地启动的 mcp 服务：

这时就可以正常使用文件系统的各项功能了。

第二个测试：Trae

不少人为了图省事，直接将路径写成了 D 盘根目录，写完就意识到不对劲——这等于给 AI 开启了整个 D 盘的读写权限？

后来查阅官方文档才放心，filesystem Server 做了严格的目录限制：它只能访问配置中指定的目录及其子目录，上层目录根本无法触及。相当于你只给了 AI 一把抽屉的钥匙，而不是整个家的钥匙。

即便如此，仍然建议只授予项目所需的最小目录权限，权限控制越严格越安全。

跑通第一个 MCP 调用

在 Trae 的设置中打开 MCP 配置：

点击添加，选择手动配置，再选择原始配置，然后粘贴刚刚的 JSON 配置：

返回之后就能看到连接成功的提示：

以前 AI 修改文件时，流程是编辑器把文件内容读出后传给模型，模型改完再由编辑器写回去；现在则变为模型通过标准协议调用工具，工具自行完成操作。前者是「你把东西给我，我帮你改」，后者是「我指挥工具去执行操作」。

后者才是 Agent 应该具备的工作方式。

以前就有函数调用，MCP 究竟新在哪里？

相信不少人都会有这个疑问：大模型的函数调用功能早已存在，MCP 到底新在哪里，为什么值得这么多人关注？

过去的函数调用，是「各家自扫门前雪」。OpenAI 有自己的函数调用格式，Anthropic 有自己的工具调用规范，每个厂商的具体实现各不相同。你写了一个文件操作工具，想同时支持 Claude 和 GPT，就必须编写两套适配逻辑。更不用说各种第三方 AI 客户端了，每家的插件系统都各有差异。

MCP 是把这件事标准化了。它不绑定任何模型厂商，也不绑定任何客户端，就是一套中立的通信协议。开发一个 MCP Server，所有支持 MCP 的环境都能使用，无需重复造轮子。

而且 MCP 不仅能接「工具」，还能接「资源」。比如你可以创建一个数据库的 MCP Server，让模型直接查询数据；做一个飞书的 Server，让模型直接读取文档、发送消息；做一个 GitHub 的 Server，让模型直接提出 PR。这些能力以前并非无法实现，但每次都要重新编写对接代码，成本太高。

往大处说，这东西将 AI 从「聊天机器人」向「智能体」推进了一大步。过去模型只能在对话框里输出文字，现在它可以通过标准协议，真实地操作你电脑上的文件、云端的服务、公司内部的系统，而且是安全可控的。

几个容易搞错的认知误区

聊几个刚开始接触时容易踩的认知误区，估计不少人都会遇到。

第一个，MCP 不是框架也不是 SDK。很多新手一听到新名词就想去 npm install，其实它本质是一套通信协议规范。你用 JS、Python、Go 都能编写 MCP Server，只要符合协议格式即可。我们使用的 filesystem，只是官方实现的一个现成服务端示例而已。

第二个，开启 MCP 不等于 AI 能随意翻遍你的硬盘。这是最令人担心的一点。实际上所有操作都被 Server 限制在授权范围内，你给它哪个目录它就只能访问哪个目录，你还可以在 Server 层增加权限控制、操作审计等。安全边界是可控的，并非一开启就全盘暴露。

第三个，MCP 不仅限于本地运行。最初看到的例子都是 stdio 本地进程模式，很多人以为只能在本机使用。其实它还支持 SSE 远程连接，你可以将 Server 部署在服务器上，本地 AI 客户端通过网络来调用。比如公司内部的数据库、文档系统，都可以做成内网 MCP 服务，无需暴露到公网。

最后说点实在的

折腾完这一圈，有三个感受最深。

一是协议的力量真的被很多人低估了。技术圈每次生态爆发，背后基本都有统一协议的影子。HTTP 带火了整个互联网，USB 统一了所有外设。如果 MCP 能真正成为行业共识，未来 AI 工具的生态将比现在繁荣得多，大家不必再重复造轮子。

二是 AI 的主战场早已不在模型本身。现在各家模型的能力差距越来越小，真正拉开体验差距的是上下文、是工具接入、是能否切实解决问题。MCP 所做的就是这件事：为所有模型搭建一个统一的工具接入底座，让大家不再在对接这件事上内耗。

三是不用追概念而焦虑。很多人一看到 MCP、Agent 这些词就心慌，担心自己跟不上进度。其实剥开概念外壳，核心都是老问题的新解法。MCP 解决的就是「大模型如何标准化地接入外部能力」这件事，想通了这一点，上手会特别快。

当然它也不是万能的。如果你只是写个一次性脚本，自己调个 API，完全没必要套一层 MCP。它真正的价值，是在需要复用、跨端、多工具协同的场景中，帮你省掉大量重复的适配工作。

接下来你可以自己编写一个简单的 MCP Server，接入本地的笔记库，让 AI 能直接搜索曾经写过的内容。如果你也在折腾 MCP，或者有什么有意思的服务端推荐，欢迎在评论区留言，我也去试试看。