🧑💻 面试官：假设你在做一个客服 Agent，已经能通过 Tool Calling 查询订单。现在团队说要接 MCP Server。MCP 和 Tool Calling 是什么关系？
🙋♂️ 我：我一开始会把 MCP 理解成一种更标准的工具接入方式。Tool Calling 是模型提出调用工具，MCP 让外部工具更方便地接进应用。
🧑💻 面试官：那 MCP Server 只能提供工具吗？如果整个项目就这一个客服应用、两个固定工具，也一定要接 MCP？
🙋♂️ 我：不一定。MCP 还可以提供资源和提示词；如果工具很少、只给一个应用用，直接封装函数可能更简单。多个 AI 应用要复用同一批能力时，统一协议才更有价值。
🧑💻 面试官：现在我把订单查询和退款工具都接上了。Agent 还是会选错工具，甚至未经确认就准备退款。接入 MCP 的哪一步会自动解决这些问题？
这道题要分清两层：能力怎样接进应用，和 Agent 怎样决定、执行并完成任务。MCP 解决前一层的标准化接入，并不会替后一层做工程判断。
面试速答（60 秒版）
MCP 和 Tool Calling 并不是二选一。
Tool Calling 是模型提出工具调用的方式：应用告诉模型有哪些工具，模型返回想调用的工具和参数，真正执行仍然由应用处理。
MCP 则是 AI 应用连接外部能力的一套协议。比如把“查询订单”做成 MCP Server 提供的工具，应用可以通过 MCP Client 发现并调用它。MCP 提供的也不只有工具，还包括可读取的资源和可复用的提示词。
如果只有一个应用、少量固定工具，直接封装函数可能更省事；当多个应用都要复用同一批能力时，MCP 的统一接入方式就更值得考虑。但工具接进来了，不代表 Agent 会选对、会处理失败，或者知道什么时候结束。退款这类有副作用的动作，还要由应用和服务端做好权限、确认与执行校验。
知识点详解：MCP 接进来之后，一次工具调用发生了什么？
同样是“查订单”，差别发生在哪一层？
先假设客服 Agent 要回答“我的订单发货了吗”。订单系统提供一个 get_order_status 能力。
不使用 MCP 时，开发者可以在客服应用里写一个函数，自己定义工具描述和参数，再把它交给模型。模型提出调用后，应用执行这个函数，把结果交回模型。这个过程就是常见的 Tool Calling 链路。
改成 MCP 后，订单系统可以把查询能力放在 MCP Server 里。客服应用作为 Host，通过其中的 MCP Client 发现 Server 提供了什么，再决定把哪些工具交给模型。模型提出查询请求后，Host 将调用路由给对应的 Server，拿到结果，再继续当前对话。
你会发现：**模型提出调用这件事并没有消失，变化的是外部能力怎样被发现、接入和复用。**MCP 为应用与 Server 之间约定了能力列表和调用方式，例如发现工具的 tools/list、请求执行的 tools/call。但“把哪些工具给模型看”“收到结果后还要做什么”，仍然由应用决定。
MCP 不只有工具，但也不负责替 Agent 做决定
在 MCP 里，Server 可以提供三类常见能力：Tools 是可执行的操作，Resources 是可供应用读取的数据，Prompts 是可复用的交互模板。它们都可以通过统一的协议被客户端发现和使用。
这解释了为什么 MCP 不应该被简单叫作“另一种 Tool Calling”。Tool Calling 说的是模型与工具请求如何交互；MCP 还规定了 AI 应用与外部能力提供方怎样通信。一个 MCP Server 可以只提供资源，不提供工具；一个 Agent 也可以完全不用 MCP，照样通过应用自己的函数完成 Tool Calling。
但协议只把“能用的能力”送到门口，并不会自动回答“此刻该用哪个”“结果是否可信”“任务是否已经完成”。这些是 Agent 的任务逻辑。团队即使接上十个 MCP Server，如果 Host 把一大堆含糊的工具描述都交给模型，不做筛选，也不检查返回结果，Agent 仍可能乱选、反复调用，或者拿着错误结果给用户下结论。
接入完成以后，执行边界反而更要讲清楚
查订单和退款看起来都只是“调用一个工具”，风险却完全不同。
查询时，应用至少要确认用户能看这笔订单。退款时，还要确认用户身份、订单归属、退款条件和金额；有些场景还需要人工确认。这些判断不能因为工具挂在 MCP Server 上就省掉。模型返回一个退款工具请求，只代表它提出了请求，不代表业务系统已经授权。
实际项目里，我们可以让 Host 只把当前任务允许使用的工具暴露给模型；真正执行时，再由服务端依据可信身份和业务规则校验。工具返回的文本也要当作外部数据处理，不能让其中一句“忽略之前的限制”变成新的系统指令。超时、重试和重复退款，则要继续按原来的工程要求处理。
所以，接入 MCP 的验收不应该只看“Server 连上了”。还可以准备几条固定任务：正常查询订单、无权查询别人的订单、未经确认请求退款、工具超时和返回内容带有诱导指令。逐条检查 Host 给模型暴露了什么、调用是否被拦下、Server 返回了什么，以及 Agent 最后怎样回答。这样才知道问题出在接入、工具选择，还是执行边界。
面试官继续追问
MCP Server 已经连接成功，为什么模型还是说没有工具？
“连上”只说明连接这一段成立。先看 Server 是否真的列出了该工具，再看 Host 是否把它纳入当前任务的可用范围、是否将描述交给模型。最后看模型请求和 Host 路由记录，确认它到底是没看见工具，还是看见后没有选。
如果工具很多，也不必把全部描述一次性塞进模型输入。可以按任务筛选或分批发现，但筛选规则和失败回退要由应用设计，MCP 不会替你决定哪一个工具最适合当前问题。
MCP Server 暴露了退款工具，模型就可以直接用吗？
不能把“Server 提供了这个能力”和“当前用户有权执行”混成一件事。Host 可以控制工具是否对当前任务可见，并在高风险动作前要求确认；真正执行退款的服务端，还得核验身份、订单归属、业务条件和审批状态。
而且要考虑重复请求：模型重试、网络超时、用户连点，都可能让一次退款变成多次请求。实际执行层需要有幂等与审计设计，不能因为调用是从 MCP 过来的就默认安全。
只有一个应用、两个固定工具，什么时候才值得引入 MCP？
如果这两个工具只服务于当前应用，变化也不频繁，直接封装通常更简单。接 MCP 还要处理 Client、Server、鉴权、部署和排障，不能只看“接口标准化”这一项收益。
当相同能力要被多个 AI 应用复用，或者团队希望用统一方式发现、管理不断增加的能力时，再考虑把它们做成 MCP Server。选型时看真实接入维护成本和故障排查体验，而不是把“用了 MCP”当成 Agent 工程成熟度的证明。
面试速记卡
- Tool Calling：模型提出调用工具；应用负责执行和回填结果。
- MCP：规范 AI 应用与外部能力之间的发现、读取和调用；不只有 Tools。
- 两者关系：可以配合，不是二选一；接入协议不等于 Agent 会完成任务。
- 选型：单应用、少量稳定工具可直接封装；跨应用复用再评估 MCP 的收益。
- 安全边界：模型请求不是授权，高风险操作仍要在执行处校验和确认。
