MCP 是什么：让 AI 连上你正在用的软件和数据

打开任何一篇 AI 工具教程，MCP 三个字母出现的频率都高得离谱：「装个 MCP 就能读飞书文档」「配好这个 MCP，AI 直接改 Figma 设计稿」。

但很少有人从头讲一遍：它到底是什么，为什么需要它。

先给你一个结论，方便对齐：

MCP 是给 AI 工具接外部系统用的一套标准接口。 装一个 MCP，就是给你的 AI 多接上一个它原本碰不到的东西。

这一篇讲清楚：它解决什么问题、里面有几个角色、配置长什么样、以及一个必须知道的安全提醒。

MCP 的全称是 Model Context Protocol，中文一般译作模型上下文协议。官方文档的定义是：

MCP 是一个开源标准，用于把 AI 应用连接到外部系统。使用 MCP，像 Claude 或 ChatGPT 这样的 AI 应用可以连接到数据源（例如本地文件、数据库）、工具（例如搜索引擎、计算器）和工作流（例如专门的提示模板），从而获取关键信息并执行任务。

官方还给了一个很直观的说法：

可以把 MCP 理解成 AI 应用的 USB-C 接口。就像 USB-C 提供了一种标准化的方式来连接各种电子设备，MCP 提供了一种标准化的方式，把 AI 应用连接到外部系统。

这个类比抓住了重点：它本身不产生能力，它是一个统一的插口。 插上什么，AI 就多出什么能力。

它由 Anthropic 在 2024 年 11 月提出并开源，现在是一个由社区共同推进的开放标准，最新的规范版本是 2026-07-28。

为什么需要一个标准？看没有它的时候是什么局面。

假设有 5 个 AI 工具，你想让它们都能连上 10 个系统（数据库、云盘、日历、设计工具……）。在没有统一标准的年代，需要写 5 × 10 = 50 套对接。每出一个新工具，前面 10 个系统全要再对接一遍。

有了 MCP 之后：

• 每个系统只需要提供一个 MCP 服务端（写一次）
• 每个 AI 工具只需要支持 MCP 这一个协议（做一次）
• 之后任意组合都能连上，变成 5 + 10 = 15 件事

官方原文的说法是：MCP 用单一的客户端-服务端协议取代了点对点的定制集成，任何兼容 MCP 的 AI 应用都可以发现并调用这些轻量服务端暴露出来的工具、读取数据资源、使用提示模板。

对你的直接好处：你在网上看到的 MCP 服务端，基本上换个工具也能用。 生态是共享的，不绑在某一家产品上。

一次 MCP 连接里有三个角色，看懂这三个，配置文件里的字段你就都认识了：

流程是这样的：你说一句「看一下这个 Figma 设计稿」→ 你的 AI 工具（客户端）通过 MCP 找到 Figma 服务端 → 服务端去调 Figma 的接口拿到数据 → 结果回到 AI 的上下文里 → 它基于这份数据回答你。

服务端能提供三类东西（这是协议规定的）：

• 工具（tools）：可以被调用去执行的动作，比如「创建一个议题」「查询这张表」
• 资源（resources）：可以被读取的数据，比如某个文件、某条记录
• 提示模板（prompts）：预置好的提示词模板

日常用得最多的是第一类。你听到「这个 MCP 提供了 12 个工具」，说的就是它。

官方文档里列的几个例子，很能说明 MCP 的用途边界：

• Agent 可以访问你的 Google 日历和 Notion，变成一个更懂你个人情况的助理
• Claude Code 可以根据一份 Figma 设计稿，生成整个网页应用
• 企业内的聊天机器人可以连接组织里的多个数据库，让员工用对话的方式做数据分析
• AI 模型可以在 Blender 里创建 3D 模型，然后用 3D 打印机打出来

看出共同点了吗？每一条都是「AI 要用到一个它本来碰不到的系统」。

落到国内的日常场景，常见的 MCP 服务端包括：本地文件系统、浏览器自动化、数据库查询、GitHub、飞书/企业微信文档、各类云服务的 API。

判断你需不需要装某个 MCP，就问一句：这件事的数据在哪？ 如果数据在一个 AI 够不着的系统里，那你需要的就是那个系统的 MCP 服务端。

「安装一个 MCP」听起来像装软件，实际上多数时候就是往配置文件里加一段。以最常见的写法为例：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "~/work"]
    }
  }
}

这段的意思是：给我的 AI 工具挂一个叫 filesystem 的服务端，启动方式是用 npx 跑官方的文件系统服务端，允许它访问的目录是 ~/work。

几个你会反复看到的字段：

注意最后一行：很多 MCP 服务端需要你提供该系统的凭证（比如 GitHub token）。这类东西不要直接写进会提交到仓库的文件里——本站 3.4「API Key 和 .env 是什么」讲的就是这件事。

不同工具的配置文件位置不同，但字段结构基本一致。看懂这一段，你就看得懂网上大多数 MCP 安装说明。

这是本篇最重要的一步，请不要跳过。

装一个 MCP 服务端，等于把一部分权限交出去。 文件系统服务端能读你指定目录里的所有文件；GitHub 服务端拿着你的 token，理论上能做你 token 权限内的任何事。而这个服务端的代码，通常是某个第三方写的。

三条基本纪律：

1. 看来源。 优先用官方或知名项目维护的服务端，别人随手发的仓库先去看看有多少人在用
2. 给最小权限。 文件系统服务端只把需要的那个目录给它，不要直接给整个用户目录；token 只勾选必要的权限范围
3. 凭证单独管。 API Key 放环境变量或 .env，不要写进会同步到云端的配置里

另外提醒一点：MCP 服务端返回的内容会进入 AI 的上下文，返回内容里的文字也可能包含指令。这就是为什么好的工具会在执行有风险动作前找你确认——保留这些确认弹窗。

MCP 是插口，不是能力本身。 它的价值在于统一：服务端写一次，所有支持 MCP 的 AI 工具都能用。 接着看：2.3 Skill 讲的是「拿到数据之后怎么做」，两者常常配合使用；装工具从 第 3 段 开始。