MCP 是什么:让 AI 接入你的工具与数据
到现在为止,AI 的能力受限于一件事:它只能看见你粘贴给它的东西。想让 AI 查一下数据库里上周的订单、读一下本地项目目录、拉一下 GitHub 的 issue,你只能自己导出、复制、粘贴。MCP(Model Context Protocol,模型上下文协议)要解决的就是这个断层——它是由 Anthropic 提出的开放协议,让模型通过标准接口去访问外部工具与数据,而不用为每个 AI 客户端、每个数据源各写一套对接代码。
为什么需要 MCP
在 MCP 之前,给 AI 接外部系统有三条路,都不轻松:
| 方式 | 做法 | 问题 |
|---|---|---|
| 手工粘贴 | 自己导出数据贴进对话 | 慢、易过期、大数据量贴不下 |
| 定制集成 | 为某个 AI 产品写专属插件 | 换个客户端就得重写一遍 |
| 自己写脚本 | 让 AI 生成脚本,你本地跑,再把结果贴回去 | 能用,但每步都要人接力,无法循环 |
| MCP | 数据源提供方按协议实现一次 Server,所有支持 MCP 的客户端都能用 | 需要理解和配置,且有权限风险 |
MCP 的价值是把「N 个客户端 × M 个数据源」的适配工作,压缩成「每个数据源实现一次」。对使用者来说,就是一次配置,之后 AI 自己会去取数据、调工具。
三个角色:Host、Client、Server
你在用的 AI 应用(Host,宿主)
│ 例如桌面客户端、IDE 插件、命令行助手
├── MCP Client(内置在 Host 里,一个 Server 对应一个连接)
│ │
│ ├── MCP Server:文件系统 → 读写你指定的目录
│ ├── MCP Server:Git 仓库 → 查提交、读 diff、看 issue
│ └── MCP Server:数据库 → 执行只读查询
└── 模型:根据 Host 提供的工具清单,决定调用哪个工具、传什么参数
| 角色 | 是什么 | 谁负责 |
|---|---|---|
| Host | 你实际使用的 AI 应用,负责界面、模型与权限确认 | 客户端厂商 |
| Client | Host 内部与某个 Server 的独立连接,负责协议握手与消息转发 | 客户端厂商 |
| Server | 真正干活的程序,暴露工具与数据给 Client | 工具/数据提供方,或你自己写 |
理解这三个角色的实际意义:能力来自 Server,权限来自 Host。你在 Host 里决定允许哪些 Server、允许它碰哪些目录,这是安全的第一道闸门。
一次调用的完整流程
用户:统计上周各区域的订单量,做成表格
1. Host 把「可用工具清单」和这个问题一起交给模型
2. 模型决定调用「数据库查询」工具,参数是它自己写的只读查询语句
3. Host 弹出确认:允许执行这次查询吗?→ 你点确认
4. Server 执行查询,把结构化结果返回给 Client
5. 模型拿到结果,按你要求的格式整理成表格回答
看懂这张流程就能理解 MCP 的两个要点:调用是模型自己决定的(第 2 步),但放行权在你手里(第 3 步)。
三类能力:tools、resources、prompts
MCP Server 主要暴露三类东西,名字很好记:
| 能力 | 含义 | 例子 | 谁来发起 |
|---|---|---|---|
| tools(工具) | 可执行的动作,可能改变状态 | 写文件、跑查询、创建分支、发消息 | 模型决定调用,通常需要你确认 |
| resources(资源) | 可读取的数据,一般只读 | 文件内容、表结构、日志片段、配置 | 客户端按需加载或你手动指定 |
| prompts(提示模板) | 预置的提示词/流程模板 | 「按规范生成发布说明」「审查这份 diff」 | 你在界面上主动选用 |
安全上要记住分界线:resources 与 prompts 风险低,tools 风险高。因为 tools 能产生副作用——写文件、改数据、发消息都可能不可逆。配置时优先只读,需要写权限时限定到具体目录或具体表。
两种传输方式
Server 与 Client 之间怎么通信,常见两类:
| 传输 | 工作方式 | 适合场景 | 注意 |
|---|---|---|---|
| stdio(标准输入输出) | Host 把 Server 作为一个本地子进程启动,用标准输入输出通信 | 本地文件、本地数据库、个人工具 | 需要本机装好运行时;日志不能随便往标准输出打印 |
| HTTP + SSE / 可流式 HTTP | Server 作为一个网络服务,通过 HTTP 连接并推送事件流 | 团队共享服务、远程内网系统 | 需要鉴权与网络可达性,注意别把内部服务暴露到公网 |
选择原则很简单:能本地就本地(stdio),要共享才上网络(HTTP)。具体支持哪种传输、用什么字段配置,随客户端版本变化,以你所用的 Host 与 Server 官方文档为准。
与「自己写脚本喂给 AI」的对比
| 对比项 | 自己写脚本 | MCP |
|---|---|---|
| 谁执行 | 你在终端里跑 | AI 在对话中自主调用 |
| 能否多步循环 | 每步都要人接力 | 可连续调用多个工具直到完成 |
| 复用性 | 只服务这一次 | 所有支持 MCP 的客户端通用 |
| 审计与权限 | 靠你自己把关 | 由 Host 统一确认与记录 |
| 灵活度 | 想怎么改就怎么改 | 受 Server 已暴露的能力限制 |
| 上手成本 | 会写脚本就行 | 需要理解协议与配置格式 |
两者不是替代关系:一次性、探索性的活儿,写脚本更快;反复要用的能力,做成 MCP Server 才划算。
典型使用场景
| 场景 | 用到的能力 | 典型问法 | 风险提示 |
|---|---|---|---|
| 本地文件整理 | 文件系统 tools | 「把 downloads 里的发票按月份归档」 | 先只读跑一遍确认规则,再给写权限 |
| 数据库查询 | 数据库 tools(只读账号) | 「统计上月各省份订单量与环比」 | 严格用只读账号,禁止带上删改权限 |
| 网页抓取与搜索 | 抓取/搜索 tools | 「把这个竞品页面整理成对比表」 | 注意目标站点条款与隐私数据 |
| 代码仓库协作 | Git/GitHub tools | 「总结这个 PR 的改动与影响面」 | 写操作(推送、合并)谨慎开启 |
| 日志与监控分析 | 日志/可观测 tools | 「找出过去一小时错误率最高的接口」 | 日志常含用户信息,注意脱敏 |
| 团队协作工具 | 消息/文档 tools | 「把这个结论同步到项目文档」 | 发消息类操作应逐次确认 |
常见坑
| 坑 | 后果 | 改法 |
|---|---|---|
| 给 Server 开工作目录的根路径 | 一次误操作可能影响大量文件 | 只挂载必要子目录,先只读 |
| 数据库用管理员账号 | 模型可能执行危险语句 | 建专用只读账号,限制到具体库表 |
| 一次装十几个 Server | 工具过多导致模型选择混乱,风险面变大 | 按需启用,用完关掉 |
| 把密钥写在共享配置里 | 配置同步即泄露 | 用环境变量,且不提交到仓库 |
| 认为「AI 会自己判断安全性」 | 它可能把提示注入当指令执行 | 关键操作必须人工确认,遵循最小权限 |
小结:MCP 是让模型通过标准接口访问外部工具与数据的开放协议,角色上是 Host 里的 Client 连接一个个 Server,能力上分 tools、resources、prompts 三类,传输上本地用 stdio、共享用 HTTP;它换来的是复用与自动化,代价是必须认真做权限收敛。