1. MCP 是什么，为什么它火了？
1. MCP 全称 Model Context Protocol，是 Anthropic 在 2024 年底开源的模型上下文协议，目标是给大模型连接外部工具和数据定一个统一标准。
2. 在它出现之前，每个应用接每个工具都要写一遍胶水代码，m 个应用乘 n 个工具就是 m 乘 n 的对接成本，MCP 把它降成 m 加 n。
3. 打个比方，MCP 之于工具生态就像 USB-C 之于外设，不管什么设备插上就能用，不用每个厂商搞一套私有接口。
4. 它火了还有一个原因：OpenAI、Google 等主要玩家在 2025 年相继宣布兼容 MCP，事实标准就此坐实，生态雪球滚了起来。
5. 面试里答这题的关键是点出"协议"两个字，它不是某个框架或某个产品，而是一套约定，谁都可以实现。
6. 常见误区是把 MCP 说成 Anthropic 私有功能，实际上它开放规范、任何人都能写 Server 和 Client，这正是它扩散快的原因。

2. MCP 的整体架构是怎样的？
1. MCP 采用客户端和服务端架构，宿主应用比如 Claude Desktop、某个 IDE 里跑的是 MCP Client，负责和模型侧打交道。
2. MCP Server 是独立进程，每个 Server 专注暴露一类能力，比如查数据库、读文件系统、调内部 API，进程间相互隔离。
3. Client 和 Server 之间走 JSON-RPC 2.0 通信，消息格式和生命周期都在规范里定义清楚，跨语言实现没有歧义。
4. 一台宿主可以同时连接多个 Server，一个 Server 也可以被多个宿主复用，拓扑上是多对多的松耦合。
5. 能力发现是架构里的亮点：Client 连上 Server 后先拿能力清单，模型据此决定能调什么，不需要硬编码工具列表。
6. 面试加分点：强调 Server 之间互不可见，宿主负责编排和安全策略，这个设计直接影响后面权限和隔离的答法。
7. 常见误区是把 MCP Server 说成"部署在模型厂商那边"，实际上 Server 跑在用户或企业自己的环境里，数据不必出门。

3. MCP 和 Function Calling 是什么关系？
1. 两者不在一个层次：Function Calling 是模型厂商提供的能力，让模型输出结构化的调用意图；MCP 是工具的发现、连接和执行标准。
2. 可以这么理解，Function Calling 解决"模型怎么说要调工具"，MCP 解决"工具从哪来、怎么接、怎么安全地跑"。
3. 实际链路里两者是配合关系，宿主把 MCP Server 提供的工具列表转成 Function Calling 的工具定义喂给模型。
4. 模型发出调用请求后，由 MCP Client 路由到对应 Server 执行，再把结果作为观察塞回上下文。
5. 没有模型原生 Function Calling 也能用 MCP，只是宿主要自己解析模型输出，兼容成本高一些。
6. 面试里要能一句话收尾：MCP 不替代 Function Calling，而是站在它下游，把工具生态标准化。
7. 常见误区是回答成竞争关系，或者把 MCP 说成"新一代 Function Calling"，都说明没理清分层。

4. MCP Server 里都有什么能力？
1. 规范定义了三大原语：Tools 是模型可主动调用的函数，Resources 是可供读取的数据内容，Prompts 是预置的提示词模板。
2. Tools 是最常用的原语，比如发邮件、查订单，模型根据描述决定何时调用，语义上偏"动作"。
3. Resources 偏"数据"，把文件、数据库行、API 响应以 URI 形式暴露，应用可以订阅它防止错过更新。
4. Prompts 原语常被忽略，它让 Server 附带最佳实践的提示词模板，用户在界面里点一下就能用，类似快捷指令。
5. 除此之外还有 Sampling 这种高级能力，Server 可以反过来请求宿主让模型补一次推理，实现 Server 侧的智能体行为。
6. 面试加分点：能区分"谁发起、谁执行"，Tools 由模型发起、Server 执行，Sampling 反向，由 Server 发起、宿主执行。
7. 常见误区是把三大原语混为一谈，或者以为 MCP 只有 Tools 一种东西，暴露出只看过入门文章。

5. 开发一个 MCP Server 难不难？
1. 官方提供了 Python、TypeScript 等语言的 SDK，把协议细节封装掉了，写一个最小可用的 Server 通常几十行代码。
2. 开发者只需要声明工具名、描述、输入参数的 JSON Schema，再写好处理函数，SDK 负责消息解析和能力协商。
3. 真正的工作量不在 hello world，而在工程化：参数校验、错误处理、超时控制、日志埋点一样都不能少。
4. 工具描述是重中之重，写得含糊模型就乱调或不调，写描述本质是在做面向模型的接口文档，值得花一半时间。
5. 调试有官方 Inspector 工具，可以手动调用工具、看消息流，比盲测效率高得多，面试提这个很加分。
6. 常见误区是把内部接口原样包一层就上线，实际要做粒度收敛，把细碎 API 组合成业务级的粗粒度工具。
7. 还要注意幂等性设计，模型可能重复调用同一工具，写操作不加幂等保护会出事故。

6. MCP 的传输方式有哪些？stdio 和 HTTP 怎么选？
1. stdio 传输是 Server 作为本地子进程，通过标准输入输出和宿主通信，适合个人本地工具，天然免鉴权、低延迟。
2. HTTP 加 SSE 或新版 Streamable HTTP 传输适合远程场景，Server 独立部署，多用户多宿主共享访问。
3. 选型第一问是"工具处理的数据在哪"，本地文件、本机数据库用 stdio，云端 SaaS、团队共享服务用 HTTP。
4. stdio 的生命周期跟着宿主走，宿主退出进程就没了，简单但没法集中运维和升级。
5. HTTP 模式要做鉴权、限流、多租户隔离，工程复杂度上一个台阶，但换来了集中管理和审计能力。
6. 面试加分点：提到 2025 年规范把 HTTP 传输升级为 Streamable HTTP 并弃用纯 SSE，说明跟进了协议演进。
7. 常见误区是给纯本地场景硬上远程 Server，白白引入网络延迟和鉴权负担，属于过度设计。

7. MCP 怎么做鉴权和安全控制？
1. 远程传输场景规范采用 OAuth 2.1 做授权框架，Client 代表用户拿到访问令牌再去请求 Server。
2. 本地 stdio 场景没有网络暴露面，主要靠操作系统进程权限控制，风险集中在"这个 Server 能动本机什么"。
3. 核心安全原则是用户确认机制：敏感工具调用前应让用户显式批准，宿主负责实现这一层交互。
4. 工具描述本身也是攻击面，恶意 Server 可以在描述里藏提示注入诱导模型，所以工具清单要经过审查而不是全盘照收。
5. 混合攻击场景要警惕，比如恶意 Server 诱导调用另一个可信 Server 的敏感工具，跨 Server 的调用策略必须由宿主管控。
6. 面试加分点：能说出"能力越强，确认越严"的分级思路，读操作自动放行、写操作人工确认、不可逆操作多重确认。
7. 常见误区是以为接了 MCP 协议就安全了，协议只管通信，安全策略完全是宿主和部署方的责任。

8. MCP 和更早的插件方案有什么本质不同？
1. ChatGPT Plugins 时代每个插件是绑死在某一家平台上的，接口规范也偏向那一家，换平台基本要重写。
2. OpenAPI 这类接口描述标准很成熟，但它是面向开发者的机器接口，缺一层"给模型看"的语义描述和调用协商。
3. MCP 把"工具描述、调用、返回、能力发现"打包成模型友好的完整闭环，模型侧的理解成本大幅降低。
4. MCP Server 独立于任何一家模型厂商，同一份 Server 可以接 Claude、GPT 或开源模型宿主，这是和插件最大的区别。
5. 插件方案普遍把用户数据放在厂商云端处理，MCP 的 Server 跑在本地或自有环境，数据主权感强很多。
6. 面试加分点：从生态角度收尾，协议中立带来了 Server 数量的网络效应，这是插件时代做不到的。
7. 常见误区是只说"MCP 更新"，答不出具体差异维度，建议从厂商绑定、语义层、数据位置三个点展开。

9. MCP 在生产环境有什么常见的坑？
1. 工具列表膨胀是头号坑，接了十几个 Server 后几十个工具描述塞满上下文，token 成本飙升还稀释模型注意力。
2. 解法包括按需启用 Server、动态筛选工具子集，或用工具检索先选再调，别把全量清单一股脑给模型。
3. Server 版本管理容易失控，工具签名一改，依赖它的智能体行为就悄悄变了，要有兼容性约定和回归测试。
4. 远程 Server 的可用性会被放大，一个依赖抖动可能让整条智能体链路超时，超时与降级策略必须提前设计。
5. 权限粒度问题很实际，很多 Server 一开始做得太粗，一个 token 能读全库，出事就是大事故。
6. 观测性不足排障极难，要把每次工具调用的请求、响应、耗时、失败原因全量落日志。
7. 面试收尾可以点一句：生产化 MCP 的本质是把"玩具工具箱"变成"有 SLA 的内部服务"，工程量主要在这。

10. 什么场景值得上 MCP，什么场景是杀鸡用牛刀？
1. 值得上的第一种场景：企业内部有多个 AI 应用要共享一批工具能力，MCP 的标准化收益立刻兑现。
2. 第二种场景：工具会持续增加，团队希望"新增能力不改宿主代码"，靠能力发现自动纳入。
3. 第三种场景：本地隐私敏感数据要用起来，本地 Server 让数据不出门，比传给云端插件安心。
4. 不值得的场景之一：只有一个应用、只有两三个固定工具，直接 Function Calling 硬编码更简单。
5. 不值得的场景之二：对延迟极其敏感的链路，多一层协议和进程间通信的开销要先掂量。
6. 不值得的场景之三：工具逻辑极不稳定、天天变，先稳定工具本身再谈标准化，否则协议层跟着乱。
7. 面试收尾强调判断框架：MCP 买的是"生态复用和数据主权"，没有这个需求就没必要付复杂度成本。

11. MCP 生态的现状和趋势怎么看？
1. 官方注册表和各社区仓库里 Server 数量已经数以千计，数据库、浏览器、办公套件、云服务都有现成实现。
2. 大厂入场是分水岭，OpenAI、Google、微软相继支持后，MCP 从 Anthropic 系扩展成跨厂商公共设施。
3. Agent 框架几乎全线兼容 MCP，LangChain、AutoGen 等都能把 MCP Server 当工具源，接入选型成本很低。
4. 趋势之一是企业私有 Server 兴起，把内部系统包成 MCP 工具，成为智能体落地的基础设施投资。
5. 趋势之二是治理层补齐，注册表审核、安全扫描、权限网关这些配套正在出现，解决野蛮生长的信任问题。
6. 也有竞争变量，各家自研协议或扩展并未完全统一，面试表态可以保守些：MCP 是当前最大公约数，但不是终局。
7. 给面试官的收尾话术：关注 MCP 不如关注它背后的趋势，智能体与工具生态正在走向标准化互联，这才是确定性方向。

包含的内容比较多，这里只做了简单的截图介绍，需要拿来学习的小伙伴查看下方图片！

📚 大模型面试题系列 · 持续更新

INTRO_REMOVED

长按识别二维码，添加微信好友