Appearance
Q5 · 什么是 MCP（Model Context Protocol）？
难度 P0 必背 · 岗位 算法 / 应用 · 预计阅读 8 min 关键词 mcp · protocol · tool-discovery · json-rpc · resources · prompts
假设一个聊天应用要读取本地文件、查数据库，还要调用日历。每接入一种能力都自行设计一套发现、传参和返回方式，维护成本会持续增加。MCP（Model Context Protocol）给应用与外部能力之间提供共同的连接约定。
先认清几个词
| 词 | 含义 | 在这个例子里 |
|---|---|---|
| Host | 面向用户并管理连接的 AI 应用 | 聊天应用 |
| Client | Host 内与一个 Server 通信的协议客户端 | 日历连接实例 |
| Server | 按 MCP 协议提供能力的进程或服务 | 日历服务 |
| Tools | 可被请求执行的操作 | 创建日程 |
| Resources | 可读取的资料 | 日历中的日程内容 |
| Prompts | Server 提供的可复用提示模板 | 整理会议安排的模板 |
| Function Calling | 模型提出工具调用请求的机制 | 模型请求“创建日程” |
MCP 说明应用怎样发现并连接外部能力；模型是否提出一次工具调用，由应用和模型的调用流程决定。 接上 Server 仍需处理权限、参数校验和敏感操作确认。
一个协议怎样连接应用与能力
逐步拆开看
MCP（Model Context Protocol，Anthropic 2024 年提出），我理解它是 AI 应用和外部能力之间的「USB-C 标准」 。
在没有 MCP 的时候，如果有 N 个 AI 应用和 M 个工具，需要 N × M 个适配集成，非常麻烦。MCP 定义了一套标准协议，工具提供方按这个标准暴露能力（MCP Server），AI 应用按这个标准接入（MCP Client），这样只需要 N + M 个接入就够了。
而且 MCP 不只是「调用工具」，它还让模型能动态发现可用资源、读取上下文信息，所以叫「Context Protocol 」。
N×M 问题：为什么需要 MCP
想象一下，你是 GitHub 的工程师，想让各种 AI 都能调用 GitHub API 查代码、提 PR。没有 MCP 的时候 ，你得为每个 AI 应用单独开发集成：
OpenAI GPT-5.x 等用 Function Calling / Responses API 格式，你得按它的 schema 写一套
Anthropic 的 Claude 用类似的但不一样的格式，你再写一套
还有 Meta 的 LLaMA、Google 的 Gemini……每家格式都略有不同
反过来，如果你是开发 AI 应用的，想用各种工具（GitHub、Slack、数据库……），每个工具的接口格式都不一样，你得为每个工具写适配代码。
这就是 N×M 问题 ：N 个 AI 应用 × M 个工具 = N × M 个集成 。
MCP 的解法很简单：定一个统一标准 。工具提供方按 MCP 标准暴露能力，AI 应用按 MCP 标准接入，从此不再需要两两适配。
类比 USB-C 之前的世界：手机有 micro-USB / Lightning / Type-C 各家不同，充电器也各家不同，你出门得带一堆线。USB-C 统一之后，一根线走天下。MCP 之于 AI 工具生态，扮演的就是 USB-C 的角色。
MCP 不只是「工具调用」
很多人把 MCP 理解成「另一种 Function Calling」，这是片面的 。MCP 的全称是 Model Context Protocol，Context（上下文） 是它的关键词。
MCP 定义了三类能力：
1. Tools（工具）
会改变外部世界的操作，比如发邮件、写文件、调 API。这和 Function Calling 里的工具概念一样。
2. Resources（资源）
只读的数据源 ，比如文件内容、数据库记录、网页 HTML。Resources 是「给模型提供上下文」而不是「让模型执行操作」。
举个例子：你让 AI 帮你审查代码，AI 通过 Resources 读取你的源码文件（只读），然后用模型能力分析问题，最后通过 Tools 提交 PR（操作）。Resources 解决的是「模型怎么知道项目里有什么」，Tools 解决的是「模型怎么改东西」 。
3. Prompts（提示词模板）
预定义的 prompt 模板，比如代码审查模板、文档生成模板。这也是上下文的一部分。
举例：MCP Server 可以暴露一个 summarize_pr prompt 模板，宿主应用拉取下来填进 chat，比每个用户自己写 prompt 高效得多。
所以 MCP 解决的不只是「模型怎么调用工具」，而是「模型怎么获取和使用外部上下文」的完整问题。这就是为什么叫 Context Protocol 而不是 Tool Protocol ——能在面试时点出这一层，是 MCP 的高级理解信号。
MCP 架构详解：Host-Client-Server 三层
MCP 的架构分三层，按用户请求传递的方向读：
- Host（宿主应用） 接住用户请求，管理生命周期和权限。
- Client（MCP 客户端） 由宿主使用，管理与 MCP Server 的连接及 JSON-RPC 通信。
- Server（MCP 服务端） 提供 Tools、Resources 和 Prompts，可以是本地进程或远程服务。
Host 是用户直接面对的 AI 应用，比如 Claude Desktop、Cursor IDE。Client 是 MCP 协议层面的客户端，负责和 Server 建立连接、管理会话。Server 是工具提供方，可以是本地程序（比如访问本地文件系统）也可以是远程服务（比如访问 SaaS API）。
通信协议用 JSON-RPC 2.0 ，这是一个成熟的标准，各种语言都有实现。Server 启动时会向 Client 通报「我有哪些 Tools / Resources / Prompts」，Client 收到列表后转给 Host，Host 把这些能力让模型知道。
MCP vs Function Calling：互补不是替代
它们不是替代关系，而是互补 。
| 维度 | Function Calling | MCP |
|---|---|---|
| 层级 | 模型层面的机制 | 应用层面的协议 |
| 管什么 | 模型怎么输出调用请求 | 工具怎么暴露 + 怎么被发现 |
| 覆盖 | 只管 Tools | Tools + Resources + Prompts |
| 格式 | OpenAI/Anthropic 各家定义略不同 | JSON-RPC 2.0 统一 |
| 位置 | LLM 输出层 | AI 应用与工具之间 |
| 关系 | LLM 用 Function Calling 表达调用意图 | MCP Client 把意图转发给对应 Server 执行 |
一个使用 MCP 的 Agent 内部流程是这样：
发现 ：Agent 通过 MCP 询问 Server，得到可用工具列表（schema + 描述）
注入 ：把这些工具的 schema 发给 LLM（此时 LLM 不知道 MCP 存在，只看到一组 Function Calling 工具）
决策 ：LLM 用 Function Calling 输出调用请求
{name, args}执行 ：Agent 通过 MCP
tools/call把请求转发给对应 Server回填 ：Server 返回结果，Agent 塞回 messages，LLM 综合给最终答复
MCP 管「工具怎么暴露」，Function Calling 管「模型怎么表达调用意图」 。两层各管各的，共同构成完整闭环。
MCP 接入时容易误解的地方
踩坑 1：把 MCP 当成另一种 Function Calling
错误描述 ：「MCP 就是 Anthropic 版的 Function Calling」。
正确做法 ：MCP 是应用层协议 （工具如何暴露），Function Calling 是模型层机制 （模型如何输出调用请求）。两者层级不同，互补共存。MCP 还覆盖 Resources 和 Prompts 两类 Function Calling 不涉及的能力。
踩坑 2：忽略 Resources 和 Prompts，以为 MCP 只管 Tools
错误描述 ：「MCP 不就是统一了工具调用吗？」
正确做法 ：MCP 三类能力 — Tools（操作）、Resources（只读数据）、Prompts（模板）。「Context」是关键词 ，不只是「工具」。能在面试时点出这三类能力的区别，非常加分。
踩坑 3：以为 MCP Server 必须是远程服务
错误描述 ：「MCP Server 就是个 HTTP API」。
正确做法 ：MCP Server 可以是本地进程 （stdio 通信，比如本地文件系统、Git 操作），也可以是远程服务（HTTP / SSE）。本地 MCP Server 是当前主流形态，因为很多场景需要访问本地资源（文件、IDE 状态等）。
踩坑 4：忽略安全与权限管理
错误描述 ：「MCP Server 暴露出来就直接用」。
正确做法 ：MCP 协议本身只定义通信，权限和安全由 Host 控制 。Claude Desktop / Cursor 都有「连接前确认」「敏感操作二次确认」机制。生产部署时要考虑：① Server 鉴权（API Key / OAuth）② 操作白名单 ③ 审计日志 ④ 速率限制。
踩坑 5：把 MCP 和 A2A 混为一谈
错误描述 ：「MCP 也能让 Agent 之间互相通信吧？」
正确做法 ：MCP 管的是 Agent 与工具的连接，A2A 管的是 Agent 与 Agent 的通信 。两者作用层不同。
再往下追问时怎么解释
追问 1：MCP 用什么传输协议？ 答题要点：MCP 协议层是 JSON-RPC 2.0 ，传输层支持 ① stdio （标准输入输出，本地进程间通信，最常用）② HTTP + SSE （HTTP 请求 + Server-Sent Events 流式返回，远程 Server 用）③ WebSocket （双向流式，未来扩展）。本地工具用 stdio，远程服务用 HTTP+SSE 是当前主流。
追问 2：MCP Server 能开发哪些场景？ 答题要点：① 开发工具类（GitHub / GitLab / Jira / Linear）② 数据访问类（PostgreSQL / SQLite / S3 / Notion / Google Drive）③ 通信协作类（Slack / 飞书 / 钉钉）④ 浏览器自动化（Puppeteer / Playwright）⑤ 本地系统类（文件系统 / Shell / Git）。已有数千个公开 Server。
追问 3：MCP 现在生态发展怎么样？ 答题要点：① 2025 年 12 月 Anthropic 把 MCP 捐给 Linux 基金会旗下 Agentic AI Foundation（AAIF） ，由 Anthropic、Block、OpenAI 共同创立；② Google、Microsoft、AWS、Cloudflare、Bloomberg 都表示支持；③ Cursor、Claude Desktop、VS Code Copilot 已原生集成 MCP；④ 公开 Server 已数千个。
追问 4：怎么自己写一个 MCP Server？ 答题要点：用官方 SDK（Python / TypeScript / Java），按 MCP 规范实现
initialize、tools/list、tools/call、resources/list、resources/read等方法，启动 stdio 监听即可。Anthropic 提供了@modelcontextprotocol/sdk等工具包，几十行代码就能跑通。追问 5：MCP 和 LangChain 的 Tool 是什么关系？ 答题要点：LangChain Tool 是框架内部抽象 （一个 Python class），MCP 是跨框架协议 （语言无关的 JSON-RPC）。LangChain 已经支持把 MCP Server 转成 Tool（
MCPToolkit），所以两者可以叠用：LangChain 框架 + MCP 工具生态 = 跨厂商兼容。
面试中如何回答
面试回答 MCP 要抓住三个点：
解决的问题 ：N×M 集成爆炸，通过标准化协议减少到 N+M
核心设计 ：不只是工具调用，还包括 Resources（只读数据） 和 Prompts（模板） ，整体是「上下文协议」
架构层次 ：Host-Client-Server 三层，Client 和 Server 通过 JSON-RPC 2.0 通信
能类比 USB-C 解释 MCP 的价值会很加分 ：就像 USB-C 统一了各种设备的充电和数据接口，MCP 统一了 AI 应用和外部能力的连接方式。
最后再点一句「MCP 与 Function Calling 互补 — MCP 在应用层管工具暴露，Function Calling 在模型层管调用意图表达」，这道题就稳了。