什么是 MCP
文档摘要
什么是 MCP 本节摘要:MCP(Model Context Protocol,模型上下文协议)是 Anthropic 于 2024 年底提出的开放标准,目标是解决 AI 编程的一个根本痛点:模型再聪明,也只能「看到」你喂给它的文本。想让 AI 读本地文件、查数据库、调 API、搜网页?过去每个工具都要单独写集成代码。MCP 把这件事标准化了——一个协议,任意 AI 客户端都能即插即用地连接任意外部工具和数据源。本节从痛点出发,讲清 MCP 的设计动机、核心概念(Tool / Resource / Prompt 三原语),以及它与 OpenAI Function Calling 的本质区别。
什么是 MCP
本节摘要:MCP(Model Context Protocol,模型上下文协议)是 Anthropic 于 2024 年底提出的开放标准,目标是解决 AI 编程的一个根本痛点:模型再聪明,也只能「看到」你喂给它的文本。想让 AI 读本地文件、查数据库、调 API、搜网页?过去每个工具都要单独写集成代码。MCP 把这件事标准化了——一个协议,任意 AI 客户端都能即插即用地连接任意外部工具和数据源。本节从痛点出发,讲清 MCP 的设计动机、核心概念(Tool / Resource / Prompt 三原语),以及它与 OpenAI Function Calling 的本质区别。
一、痛点:AI 的「感官剥夺」
想象一个场景:你在 Cursor 里跟 AI 说「帮我看看 /var/log/app/error.log 里最近的报错」。
没有 MCP 时,AI 会说:「我无法访问你的文件系统。请把日志内容复制粘贴给我。」
于是你:打开终端 → tail -100 /var/log/app/error.log → 复制输出 → 粘贴到对话框 → AI 分析 → 给你修复建议 → 你再手动去改。
这个「人肉中转」的过程,每天可能重复十几次:查文档、读配置、看日志、搜 Stack Overflow。AI 明明有能力理解这些信息,但它「够不着」——它被锁在一个纯文本的对话框里。
MCP 的设计动机就是:给 AI 装上标准化的「手和脚」,让它能安全、可控地触达外部世界。
二、MCP 的核心概念
MCP 定义了三种「原语」(primitive),是 AI 与外部世界交互的基本方式:
Tool(工具)
AI 主动调用的函数。比如:
read_file(path)— 读取文件内容search_web(query)— 搜索互联网run_query(sql)— 执行数据库查询
Tool 是「AI 决定什么时候用、怎么用」的。AI 根据你的问题,判断需要调用哪个 Tool、传什么参数。
Resource(资源)
AI 可以读取的数据源。比如:
- 一个配置文件的内容
- 数据库的 schema 信息
- API 文档
Resource 更像「背景材料」——AI 可以在需要时读取,但不像 Tool 那样有「执行」的含义。
Prompt(提示模板)
预定义的交互模板。比如:
- 「代码审查模板」:自动注入代码 diff + 审查标准
- 「Bug 分析模板」:自动注入错误日志 + 相关代码
Prompt 是 Server 提供给 Client 的「快捷方式」,简化重复性交互。
关键概念:对大多数使用者来说,Tool 是最重要的原语。90% 的 MCP 使用场景都是「AI 调用一个 Tool 来获取信息或执行操作」。Resource 和 Prompt 是锦上添花。
三、MCP vs Function Calling
很多人会问:「OpenAI 的 Function Calling 不也是让 AI 调用外部函数吗?MCP 跟它有什么区别?」
| 维度 | Function Calling | MCP |
|---|---|---|
| 层级 | 厂商 API 级别 | 开放协议级别 |
| 绑定 | 绑定特定模型厂商(OpenAI) | 模型无关(任何 LLM 都能用) |
| 方向 | 单向(AI 调用 → 返回结果) | 双向(Client ↔ Server 持续通信) |
| 生态 | 每个应用自己实现 | 共享生态(一个 Server 所有客户端通用) |
| 发现 | 开发者硬编码函数列表 | Server 启动时自动声明能力 |
| 传输 | HTTP API 调用 | stdio / SSE(支持本地进程) |
类比:Function Calling 像是「每个电器配一个专用充电器」,MCP 像是「USB-C 统一接口」。
实际意义:你写了一个 MCP Server(比如「查询公司内部知识库」),它可以同时被 Cursor、VS Code、Windsurf、Claude Desktop 使用——不需要为每个客户端单独写集成代码。
四、MCP 的生态现状
截至 2025 年中,MCP 生态已经相当活跃:
官方/社区维护的常见 Server:
- Filesystem — 读写本地文件
- Brave Search / Google Search — 网络搜索
- GitHub — 操作仓库(创建 PR、查看 Issue)
- PostgreSQL / SQLite — 数据库查询
- Slack / Notion — 协作工具集成
- Puppeteer / Playwright — 浏览器自动化
支持 MCP 的客户端(Host):
- Cursor、VS Code(Copilot)、Windsurf
- Claude Desktop、Claude Code
- Cline、Continue 等开源工具
💡 技巧:如果你需要的功能已有现成 Server(如文件读取、搜索),直接用现成的,不需要自己开发。只有在需要连接公司内部系统或特定业务逻辑时,才需要自己写 Server(第 05 节讲)。
五、安全模型
MCP 的设计充分考虑了安全性:
- 权限由 Host 控制:AI 调用 Tool 前,IDE 可以弹出确认框让你审批
- Server 运行在本地:大多数 Server 是本地进程(stdio 传输),数据不经过第三方
- 能力声明机制:Server 启动时声明自己能做什么,Client 只暴露已声明的能力给 AI
- 目录白名单:如 Filesystem Server 只能访问你配置的目录,不是整个磁盘
⚠️ 注意:虽然 MCP 有安全机制,但你仍然需要审查 AI 的 Tool 调用。特别是涉及写操作(写文件、执行命令、修改数据库)的 Tool,建议保持「调用前确认」开启。
本节要点回顾
- 设计动机:解决 AI「感官剥夺」——让它安全、标准化地访问外部工具和数据
- 三种原语:Tool(AI 主动调用)、Resource(AI 可读取)、Prompt(预定义模板)
- 与 Function Calling 的区别:MCP 是开放协议级、模型无关、双向通信、共享生态
- 类比:Function Calling 是专用充电器,MCP 是 USB-C 统一接口
- 生态:已有数百个现成 Server,覆盖文件/搜索/数据库/协作工具等
- 安全:权限由 Host 控制,Server 本地运行,能力需声明,写操作需审批
理解了 MCP「是什么」和「为什么」之后,下一节我们拆解它的技术架构:Host / Client / Server 三层是如何通信的。