MCP：让 AI 不只会聊天，还能连接工具
先记一句：模型本身像一个被关在会议室里的聪明顾问；MCP 是一套标准连接方式，让 AI 应用可以把外面的文件、工具和资料带进会议室。
第一课：为什么需要 MCP
你问 AI：“帮我看看 GitHub 仓库里最新的报错。”模型可能很聪明，但它默认并不知道：
- 你的 GitHub 账号是谁；
- 仓库在哪里；
- 它有没有读取权限；
- 应该通过什么程序去读取。
这就像请来一位很厉害的会计，却把他关在没有电脑、没有账本、没有门卡的会议室里。他有分析能力，但拿不到你的真实资料。
MCP 全称 Model Context Protocol。可以先拆成：
- Model：会理解和生成内容的模型。
- Context：这次工作需要看到的资料。
- Protocol：双方都遵守的连接规则。
一句人话：MCP 是 AI 应用连接外部工具和资料时可以共同遵守的一套标准。
USB 类比
以前每种鼠标、键盘、硬盘都用完全不同的插口，电脑厂商就要为每种设备单独开孔。USB 出现后，大家按同一种标准连接。
MCP 的想法很像：GitHub、文件系统、数据库、Notion 不必分别为每个 AI 产品重新发明一种完全不同的接法。
注意：类比只是帮助理解。MCP 不是一根实体线，也不会自动给 AI 所有权限。
第二课：四个角色分别是谁
继续用“公司请助理”来比喻：
| MCP 角色 | 公司类比 | 实际负责什么 |
|---|---|---|
| Host / AI 应用 | 你所在的办公室 | 承载对话、模型和整体权限边界 |
| MCP Client | 专门联系某部门的助理 | 与某个 MCP Server 保持连接、传递消息 |
| MCP Server | 档案室服务窗口 | 公开它允许使用的工具和资料 |
| 外部系统 | 真正的档案柜 | GitHub 仓库、数据库、文件或第三方服务 |
一个 AI 应用可以连接多个 MCP Server。就像一个办公室可以分别联系档案室、财务室和仓库，每个连接负责不同的事情。
Server 能提供三类常见能力
- Tools 工具：可以执行的动作，例如“创建 Issue”“查询数据库”。像档案员替你办一件事。
- Resources 资源：可以读取的资料，例如一个文件或一份文档。像从档案柜取出资料给你看。
- Prompts 提示模板：服务端提供的可复用任务模板。像公司已经写好的标准申请表。
不是每个 MCP Server 都会同时提供三类能力。
第三课：一次 MCP 调用真的怎样发生
假设你对代码代理说：“读取仓库里的 README，告诉我项目怎么启动。”
- 你提出任务
AI 应用先把你的话和当前对话交给模型理解。 - 模型判断需要外部资料
它发现自己必须读取 README，不能只凭记忆回答。 - AI 应用查看可用工具
MCP Server 之前已经说明“我能读取仓库文件”。 - 模型提出工具调用
例如请求读取路径README.md。这一步不等于已经成功。 - 权限检查并执行
Host、MCP Server 或外部平台根据授权决定是否允许。 - 结果返回给模型
README 内容作为新的 Context 被送回模型。 - 模型根据真实内容回答
这一次答案不只依赖模型记忆，还使用了刚读到的文件。
所以“模型调用工具”不是模型自己长出一只手，而是 AI 应用替它执行经过允许的结构化请求。
第四课：MCP、API 和插件是什么关系
API 像一家店自己的服务窗口
每家店都有自己的地址、认证方式和菜单。开发者要按这家店的规则调用。
MCP 像给 AI 准备的统一服务台规范
MCP Server 可以在背后继续调用 GitHub API、Notion API 或数据库。它把这些能力整理成 AI 客户端更容易发现和使用的工具。
text
AI 应用
↓ 按 MCP 规则
MCP Server
↓ 可能再调用普通 API
GitHub / Notion / 数据库因此 MCP 通常不是“替代所有 API”。更像是在 API 或本地能力外面，加上一层适合 AI 工具使用的统一说明和通信方式。
插件是产品里的扩展包
“插件”是更宽泛的产品概念。一个插件可能内部使用 MCP，也可能使用自己的 API。看到插件两个字，不能自动断定它就是 MCP。
第五课：配置文件怎么读
不同 AI 客户端的文件位置和字段可能不同，但本地 Server 常见结构类似：
json
{
"mcpServers": {
"project-files": {
"command": "npx",
"args": ["-y", "某个可信的-mcp-server", "/我的项目路径"],
"env": {
"SERVICE_TOKEN": "从安全环境中提供"
}
}
}
}逐层翻译成人话：
text
mcpServers 我准备连接的 MCP Server 清单
project-files 我给这条连接起的名字
command 用什么命令启动它
args 启动命令后面还要带哪些参数
env 这个 Server 运行时需要哪些环境变量npx -y 某个包 可能会下载并执行代码。不要从陌生网页复制一段配置就直接运行；先确认发布者、源码、权限范围和它会读取哪些目录。
本地 Server 和远程 Server
- 本地 Server：作为你电脑上的进程运行，可以被授权读取本地文件。
- 远程 Server：运行在网络服务上，通常需要登录或 OAuth 授权。
“Server”不一定代表远处的一台大服务器，它也可以只是你电脑上正在运行的一个小程序。
第六课：权限和安全
MCP 解决的是“怎样连接”，不是“连接后天然安全”。像 USB 接口统一了，也不代表任何 U 盘都应该插进电脑。
安装或授权前问五个问题：
- 这个 Server 来自谁？源码和发布者可信吗？
- 它要读哪些文件、哪些仓库或哪些数据库？
- 它只有读取权限，还是能修改和删除？
- 它会把数据发送到哪里？
- 完成任务后，能否撤销授权或缩小范围？
最小权限原则可以类比成酒店房卡：清洁人员只需要指定楼层和房间的权限，不需要拿到整栋楼的万能钥匙。
第七课：连不上时怎么查
不要连续乱改配置。按连接过程从前往后查：
| 现象 | 最可能卡在哪里 | 先做什么 |
|---|---|---|
| Server 根本没有出现 | 配置没被读取 | 查配置文件位置、重启客户端 |
| 出现后马上离线 | 启动命令失败 | 在终端单独运行 command 和 args |
| 提示 JSON 错误 | 配置语法 | 查逗号、引号和大括号 |
| 能连接但没有工具 | Server 能力或初始化失败 | 看客户端日志中的第一条错误 |
| 工具存在但读取失败 | 路径或权限 | 检查授权目录、账号 Scope |
| 提示未登录 | OAuth / Token | 重新授权，不要把密钥贴进聊天 |
最小排查路线
- 确认客户端真的支持 MCP。
- 确认配置放在这个客户端要求的位置。
- 确认启动命令在终端能运行。
- 确认环境变量存在，但不要把真实值打印出来。
- 只测试一个最小读取动作。
- 阅读第一条错误，不要只看后面连锁出现的十条错误。
自己试着判断
下面这句话哪里不准确？
“我安装了 GitHub MCP，所以模型从此自动知道我所有私有仓库的全部内容。”
答案：MCP 只是建立连接方式。AI 仍然需要账号授权、足够权限和一次具体的读取动作；模型不会因为“装过一次”就永久记住全部仓库。
学完测试
MCP Server 是模型本身吗？
答案：不是。模型负责理解和生成；MCP Server 负责向 AI 应用公开工具或资源，并在权限允许时执行具体操作。
一个 GitHub MCP 工具读取失败时，应该直接换模型吗？
答案：通常先检查连接、账号授权、仓库权限和工具参数。换模型不会自动修复缺少权限或配置错误。