「Agent Tool」什么是 MCP？它由哪几部分组成？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 4. 什么是 MCP（模型上下文协议）？讲讲它的核心内容？和 5. MCP 由哪几部分组成？，用于记录与总结 AI Agent 工具调用相关的核心面试知识点。

「什么是 MCP？它由哪几部分组成？」，可以这样作答：

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年底推出的开放协议，解决的核心问题是「模型接工具太碎片化」——在它出现之前，每接一个新工具都要单独写集成代码、处理认证、适配格式，而且这套代码和具体模型强绑定，换个模型就得重写。MCP 的思路是给「AI 接工具」定一套行业标准：工具方按协议实现一个 Server，任何支持 MCP 的 AI 客户端直接接入，一次实现、到处复用。

MCP 由三层组成：角色层——Host 是 AI 应用本身，Client 是 Host 内负责与 Server 通信的模块，Server 是工具提供方实现的独立进程，一个 Host 可以同时连多个 Server；能力层——Server 能暴露三类东西：Tools（有副作用的操作）、Resources（只读数据）、Prompts（提示词模板）；协议层——消息格式统一用 JSON-RPC 2.0，传输方式支持 stdio（本地子进程）和 Streamable HTTP（远程）两种。

要注意它和我们第 1 篇讲的 Function Calling 不是一个层面的东西：Function Calling 解决「模型怎么输出结构化的调用请求」，MCP 解决「工具怎么标准化接入」——一个管模型的「嘴」，一个管工具的「插座」，两者互补。

如今 Claude Desktop、Cursor、Windsurf 等主流 AI 客户端都内置了 MCP 支持，GitHub、Slack、PostgreSQL、Google Maps 等头部工具均提供官方或社区的 MCP Server——在配置文件里加几行 JSON、重启，客户端就能自动发现并使用这些工具，基本零代码接入。这也是 MCP 生态能在短时间内快速铺开的原因。

1 为什么需要 MCP：接工具有多麻烦

先看没有 MCP 的日子里，给模型接一个工具是什么体验。想让它操作 GitHub，你得手写 GitHub API 的调用、处理认证、转换数据格式；想接 PostgreSQL，再来一套；模型升级、接口变了，对接代码跟着改；从 Claude Desktop 换到 Cursor，之前的对接代码全部重写。

MCP 出现前工具接入碎片化：每个工具与模型像孤岛、逐个手写对接

接十个工具就是十套互不相通的对接代码，每个工具、每个模型都像一座孤岛。这套方案的毛病可以用三个词概括：碎片化（一套接一套不通用）、难复用（换个客户端就作废）、强绑定（和具体模型/客户端绑死）。

2 MCP 的核心思路：给「AI 接工具」定行业标准

MCP 的思路一句话就能说清：把「接工具」这件事标准化。

最贴切的类比是 USB。USB 出现前，每台外设都有自己的接口和驱动，插什么设备都要专门适配；USB 定义了统一接口后，任何设备「插上就能用」。MCP 对 AI 生态做的正是同一件事——工具提供方（比如 GitHub）按 MCP 规范实现一个 Server，把它能做的事声明出来；任何支持 MCP 的 AI 客户端（Claude Desktop、Cursor、各种 Agent 框架）都能直接连上这个 Server，自动发现它提供的能力。

USB 类比：MCP 为 AI 接工具定统一标准、一次实现到处复用

工具方实现一次，处处复用；客户端接入一次，处处可用。这就是 MCP 的核心价值。

3 先建立整体感：从三层看 MCP

MCP 的完整组成，站在三个层次看就清楚了：角色层回答「谁和谁通信」，能力层回答「Server 能暴露什么」，协议层回答「消息怎么传」。

MCP 三层整体架构：角色层 / 能力层 / 协议层

下面逐层拆开。

4 第一层：角色架构 Host / Client / Server

角色层有三个角色，注意其中两个容易被忽略的那个：

Host（宿主）：AI 应用本身——Claude Desktop、Cursor 这类产品就是 Host；
Client（客户端模块）：Host 内部负责和 Server 通信的模块——它不是一个独立应用，而是 Host 里的一个组件；
Server（服务端）：工具提供方实现的独立进程——比如 GitHub 官方 Server，把「列出 PR」「创建 Issue」这些操作封装成可调用的能力。

Host / Client / Server 角色关系：一个 Host 连多个 Server

三者是「宿主、司机、服务商」的关系，关键在一对多：一个 Host 可以同时连多个 Server。模型装上文件系统、GitHub、PostgreSQL 三个 Server，就同时拥有了三大类能力，工具之间还能互相配合。这也是 MCP 面试里最常见的雷区——很多人把它记成「Client + Server」二元结构，漏掉了 Host 这个「宿主应用」的角色。

5 第二层：能力类型 Tools / Resources / Prompts

Server 能暴露三类能力，这是 MCP 的核心抽象：

Tools（工具）：有副作用的操作——创建文件、提交代码、发 Slack 消息、调第三方 API。它会改变外部状态，所以通常需要用户授权才能调用；
Resources（资源）：只读数据——读日志、查数据库、取文档内容。没有副作用，像「工具的资料室」，可以相对宽松地暴露；
Prompts（提示词模板）：带参数占位符的预定义模板——比如一份「代码审查标准 prompt」接收「编程语言」「代码内容」两个参数，团队成员可以直接复用。

Server 可暴露的三类能力：Tools / Resources / Prompts

三类能力本质区别对比

区分三者的核心判据是有没有副作用，一句话记住：Tools 改变世界，Resources 观察世界，Prompts 结构化表达。

6 第三层：协议层 JSON-RPC 2.0 + 传输方式

角色和能力都有了，Server 和 Client 之间消息怎么传？协议层分两个独立部件：消息格式和传输方式。

消息格式用 JSON-RPC 2.0——一个轻量的远程调用协议，用 JSON 表达「调用」，易读易调、语言无关。Client 想了解 Server 有什么工具，发一条 tools/list；想调用某个工具，发一条 tools/call：

// Client 向 Server 查询工具列表
{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}
// Server 返回工具列表
{"jsonrpc": "2.0", "id": 1, "result": {"tools": [{"name": "read_file", ...}]}}
// Client 请求调用某个工具
{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {"name": "read_file", "arguments": {"path": "/tmp/log.txt"}}}

传输方式两种：

stdio：本地子进程通信，通过 stdin/stdout 传消息，低延迟——Claude Desktop 在本地接入 Server 就用它；
Streamable HTTP：远程 HTTP 连接，Server 部署在服务器上，多个客户端可以共享。

值得一提的演进：早期规范的 HTTP+SSE 双端点方案，在 2025 年 3 月的规范更新里被标记为 deprecated，合并成单端点 /mcp 的 Streamable HTTP——短请求返回普通 JSON，长请求升级为 SSE 流。

stdio 与 Streamable HTTP 两种传输方式

把这两部分分开看才是协议层的精髓——消息格式和传输方式是解耦的：JSON-RPC 2.0 定义了消息长什么样，stdio / Streamable HTTP 定义了消息怎么传，两者互不依赖。想加一种新的传输方式，消息格式完全不用动，这也是 MCP 灵活性的来源。

消息格式与传输方式解耦设计

7 面试总结

回答 MCP 相关面试题，先避开三个经典误区：

误区	正解
MCP 和 Function Calling 是一回事	FC 管「模型怎么输出结构化调用请求」，MCP 管「工具怎么标准化接入」，不同层面、互补关系
MCP 是 Anthropic 专属的	它是开放协议，任何支持 MCP 的客户端都能接入
MCP = Client + Server 二元结构、Server 的能力全是 Tools	三层结构要讲全，Host 角色不能漏；能力分 Tools / Resources / Prompts，判据是有无副作用

再按这张框架组织答案：

层次	要点
定义	Anthropic 2024 年底推出的开放协议，解决工具接入碎片化，一次实现到处复用（USB 类比）
角色层	Host（应用本身）/ Client（通信模块）/ Server（工具实现），一个 Host 连多个 Server
能力层	Tools 有副作用需授权 / Resources 只读 / Prompts 模板，「改变世界、观察世界、结构化表达」
协议层	JSON-RPC 2.0 统一消息格式 + stdio / Streamable HTTP 两种传输，格式与传输解耦
加分项	生态快的原因：实现门槛极低 + 头部工具第一时间跟进，形成正向循环

追问预案：

「MCP 和 Function Calling 是什么关系？」——不同层面：Function Calling 是模型侧的输出契约（输出结构化的 tool_calls JSON），MCP 是工具侧的接入标准；两者互补——MCP Server 暴露的能力，最终也是以「工具」的形式被模型调用（详见第 1 篇）。
「Host 和 Client 怎么区分？」——Host 是应用本身，Client 是 Host 里负责和 Server 通信的模块；一个 Host 内可以跑多个 Client、连多个 Server，这是一对多的核心设计。
「Tools 和 Resources 的本质差异？」——有没有副作用：Tools 改变外部状态、需要授权；Resources 只读、可以宽松暴露。
「为什么 Streamable HTTP 取代了双端点方案？」——一个端点更简单，短请求返回普通 JSON、长请求升级 SSE 流，两种模式一个端点点搞定。
「MCP 生态为什么发展这么快？」——实现门槛极低（开源规范 + Python/TypeScript SDK，最简 Server 不到 30 行代码）+ GitHub、Slack 等头部工具第一时间跟进，配置几行 JSON 就能用，形成正向循环。