MCP 面试题库
从基础到进阶，每道题附答题要点和”一句话版本”。
基础题（必须流利回答）
Q1：MCP 是什么？它解决了什么核心问题？
答题要点：
- 不是技术问题而是生态碎片化问题
- N×M → N+M（注意：是工作量，不是连接数）
- USB / 货币类比
- 三类能力（Tools/Resources/Prompts）
一句话版本：
MCP 是 AI 模型与外部工具之间的标准化协议，解决了”每个 AI 应用都要重复对接同一系统”的碎片化问题——Server 写一次，所有支持 MCP 的 AI 应用免费复用。
Q2：Host、Client、Server 各自的职责是什么？
答题要点：
| 角色 | 职责 | 例子 |
|---|---|---|
| Host | 运行环境，持有并管理 Client | Claude Desktop、你开发的 App |
| Client | Host 内部创建，1:1 对应一个 Server | 每个连接实例 |
| Server | 暴露 Tool/Resource/Prompt 能力 | GitHub MCP Server |
关键细节： Client 和 Server 是 1:1 关系，Host 可以同时持有多个 Client（连接多个 Server）。
Q3：Tools、Resources、Prompts 有什么区别？
| 能力 | 谁发起 | 有副作用 | 本质 |
|---|---|---|---|
| Tools | AI 自主决定 | 有 | 执行动作 |
| Resources | AI 按需读取 | 无 | 数据访问 |
| Prompts | 用户触发 | 无 | 可复用提示词模板 |
常见误区： Prompts 不是 AI 主动调用的，是用户在界面输入斜杠命令触发的。
Q4：MCP 的传输方式有哪些，分别适用什么场景？
| 传输方式 | 适用场景 | 特点 |
|---|---|---|
| stdio（本地进程） | 开发调试、访问本地文件系统 | 简单直接，无需认证，不支持多用户 |
| SSE/HTTP（远程） | 生产环境部署、多用户并发 | 需要处理认证，支持水平扩展 |
进阶题（体现工程深度）
Q5：MCP 和直接写 Function Calling 有什么本质区别？
答题要点：
- 服务发现机制：FC 需要开发者硬编码可用工具，MCP Server 可以在运行时动态告诉 Client 它有哪些能力
- 跨框架复用：一个 MCP Server 同时服务 Claude/GPT/Gemini/开源模型；FC 格式各家不统一
- 传输层抽象：stdio/SSE 可切换，同一 Server 本地和远程都能用
- 三类能力：FC 只有 Tool 的概念，MCP 新增了 Resource 和 Prompt
一句话版本：
FC 解决了”AI 能调工具”，MCP 解决了”工具如何被任何 AI 复用”——后者是标准化，前者是能力本身。
Q6：如何设计一个高质量的 MCP Tool description？
好的 description 回答 6 个问题：
[何时用] 明确的触发场景
[何时不用] 与其他 Tool 的边界
[输入] 参数的语义，不只是类型
[输出] 返回什么，格式是什么
[副作用] 会修改什么，发什么通知
[失败处理] 出错时返回什么，AI 应该怎么处理
关键认知： “什么时候不用” 比 “能做什么” 更重要——区分边界才能防止 AI 选错 Tool。
Q7：生产环境的 MCP Server 需要考虑哪些安全问题？
- 权限最小化：只暴露必要 Tool，危险操作加确认机制
- Credentials 管理：env 变量注入，绝不硬编码在代码里；生产用 Secret Manager
- 输入参数校验：AI 生成的参数不可信，需要在 Server 侧校验
- 幂等性设计：AI 可能重试，写操作要防重复执行
- Prompt Injection 防护：恶意 Server 可以在 Tool description 中注入指令，只安装可信 Server
- 审计日志：记录 AI 调用了什么 Tool、传了什么参数
Q8：上下文窗口装满了怎么办？
多轮 Tool 调用后 context 撑满是真实的生产问题。
三种解法：
- Tool 返回值压缩：不返回原始数据，返回摘要；用 Resource 替代大数据返回
- Resource 按需读取：大文件/数据库用 Resource 暴露，让 AI 按需读取而非一次性塞入
- 长任务分段：做 checkpoint，把任务拆分成多个对话，每段有明确的输入输出
Q9：动态 Tool 注册的价值和弊端各是什么？
价值：
- 降低 AI 选错率（5个里选 vs 80个里选）
- 节省 context token（Tool 描述本身占 token）
- 天然支持按角色权限控制
弊端：
- 意图分类出错会让正确 Tool 无法暴露（比静态注册更糟）
- 跨场景任务难处理
- 引入额外延迟和成本
- 维护成本高（分组逻辑需要随业务更新）
使用建议： Tool 数量超过 20 个、场景边界清晰时才考虑动态注册。
实战题（结合你的项目经验）
Q10：给你的项目设计 MCP 接入，你会怎么做？
（以 Speakeasy 语言学习 App 为例）
设计思路：
| 能力 | 类型 | 说明 |
|---|---|---|
| 词典查询 | Tool | 输入单词 → 返回释义 + 例句 + 词源 |
| 发音文件 | Resource | 按需读取音频 URL，不一次性加载 |
| 用户学习进度 | Resource | FSRS 记忆曲线数据，按需读取 |
| 词汇学习模板 | Prompt | 斜杠命令，用户填单词，展开成完整学习 prompt |
| 生成记忆口诀 | Tool | 输入单词和上下文，AI 生成记忆技巧 |
体现了什么： 理解三类能力的使用边界——Resource 用于大数据按需读取，Prompt 用于标准化用户体验，Tool 用于执行动作。
Q11：在 ToB 预售中，如何向客户解释 MCP 的业务价值？
不要从技术切入，从成本切入：
“您现在做 AI 项目，每接一个内部系统就要写一套对接代码，对接 10 个系统要写 10 次。用 MCP 标准，每个系统只需要包装一次，后续所有 AI 项目免费复用。集成工作量从 N×M 降到 N+M。
更重要的是：当 AI 模型升级或者你们想换一家模型供应商，不需要改对接代码——MCP 层不变，上层换哪家模型都可以。这就是标准化的价值。“
你可能被问到的批判性问题
”MCP 有什么局限性？”
不要只讲优点，能说出批评才显得认知成熟：
- 有状态连接：SSE 是长连接，Serverless 和 K8s 水平扩容场景有兼容性问题（社区正在解决）
- Prompt Injection 风险：恶意 MCP Server 可以在 description 中注入指令，目前无系统级防护
- Tool 描述质量：MCP 标准化了格式，无法标准化 description 质量——这是人工艺问题
- Anthropic 主导：存在供应商锁定风险，Google 推出 A2A 作为竞争方案
- 过度工程化：单一场景直接写 Function Calling 比引入 MCP Server 简单得多
成熟的表达方式：
“MCP 解决了生态层的碎片化问题，但在有状态连接和简单场景的工程成本上有真实的 tradeoff。我会根据是否需要跨平台复用来决定是否引入 MCP。”