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 应用,负责界面、模型与权限确认客户端厂商
ClientHost 内部与某个 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 / 可流式 HTTPServer 作为一个网络服务,通过 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;它换来的是复用与自动化,代价是必须认真做权限收敛。

笔记加载中…