MCP高频面试题全解析：架构原语、传输与安全模型

最近这半年，我几乎在每场AI应用相关的面试里都被追问同一个词：Model Context Protocol（MCP）。有的面试官直接抛概念题“聊聊你对MCP的理解”，有的给一个实际场景让设计工具接入方案，还有的会突然钻到细节里问“JSON-RPC里request和notification的区别到底是什么”。问法五花八门，但本质都在测一件事：你是真的理解这套协议，还是只是刷过几篇科普。

这套题库是我过去两个月一边自己面试、一边帮团队做模拟面整理出来的。我不打算直接甩一份题目清单让你背，而是把高频题目一条条拆开：先看面试官到底在问什么，再看怎么答才是加分答案，最后给出我自己实践之后的修正意见。整理的原则很朴素——每个问题都要能落到协议的真实机制上，凡是只能背诵定义的答案，我都会额外标注一个“这题这么答容易翻车”。

这套内容适合三类人：准备校招或社招面试的候选人、需要给团队做MCP内部培训的工程师，以及想搞清楚MCP到底有没有实际价值的应用开发者。看完之后，你至少能把协议的角色边界、原语体系、传输层设计和安全模型这套骨架讲清楚。

1. MCP到底解决什么问题：面试前必须背熟的三层逻辑

1.1 面试官问“MCP是什么”时，他真正想听到什么

很多候选人一上来就背定义：MCP是一个开放协议，用于标准化大模型应用和数据源、工具之间的通信。这本身没错，但作为面试答案太干瘪了。面试官问这个概念，不是想知道你知道这个缩写，而是想知道你能不能用这个协议解释清楚一个工程问题：为什么AI应用接入外部工具会这么痛苦。

在这个问题上，我强烈建议按三层逻辑回答。

第一层，说痛点。在没有MCP之前，每一个智能体应用要接入一个数据源或工具，都需要单独写一套适配代码。你接一个天气API要写一个工具类，再接一个数据库查询又要写另一个工具类，再接一个内部文档检索系统，又是新的一套。一个模型服务、一个应用、N个工具，互相之间的连接关系是指数级增长的，这就是典型的M×N集成矩阵问题。

第二层，说方案。MCP的重点在于“标准化插槽”。它把工具、数据资源、提示词模板这三类最常见的能力，统一抽象成三种原语，用同一套JSON-RPC 2.0的格式在客户端和服务端之间传输。接入方不需要关心里面是怎么实现的，只需要遵循协议暴露能力、声明能力、调用能力。

第三层，说边界。这是最加分的部分。MCP不负责模型怎么思考，也不负责工具内部怎么做计算，它只负责定义双方通信的格式和会话的边界。它不是一个算法框架，不是模型推理引擎，就是一层耦合得很松的接口协议。能把边界说得清楚，面试官才会认定你是真的理解协议本身，而不是只记住了几句介绍。

1.2 从M×N集成矩阵到“标准插槽”的演变逻辑

为了把这件事说得更具体，我在模拟面试时经常画一张口头版的对比图。

没有标准协议时，A模型要用B搜索、C数据库、D文件系统，就要写三套对接逻辑；换一个模型，又要重写适配层。这还不是最绝望的，更麻烦的是权限和会话也得分散管理：每个工具各自的鉴权方式不一样，有的用API Key，有的用OAuth回调，有的是内部白名单。集成一次，等于把对方的整个技术细节都学一遍。

有了MCP之后，事情变成了这样：数据源或工具方做一次适配，对外暴露一个MCP Server；应用方通过MCP Client连接这个Server，握手、鉴权、能力发现、调用，全部走标准流程。新增一个工具，只需要多连一个Server，原有代码几乎不用改。这就是“接入一次，到处复用”这个口号背后的真正逻辑。

这套逻辑不是纸上谈兵。我帮团队做内部工具底座的时候，早期用自研插件体系接外部能力，每加一个数据源就要开发、测试、发版一整轮，后来改成MCP接入，新数据源的适配工作量大概砍掉了六成以上，因为能力发现、参数校验、错误返回这些都由协议统一兜底了。

1.3 三层逻辑怎么组织成面试答案

我建议的答题顺序是这样的：30秒讲痛点，60秒讲机制，最后30秒讲边界和适用场景。

痛点要说清楚“M×N问题”和“隔离性缺失”这两个关键词。机制部分要提到三种原语和JSON-RPC，不用展开太深，留到面试官追问细节时再深入。边界部分要主动对比“模型能力”和“协议能力”的区别，比如提到函数调用是模型层面的能力，MCP是应用接入层面的协议，两者协同而不是替代。

我见过一个特别好的回答，候选人在最后补了一句“如果只是单纯接一两个工具，写函数调用适配就够了，没必要上MCP；但如果你有大量工具需要被多个Agent复用，那就需要一个标准协议。MCP适合的是成规模的接入场景，而不是单点问题”。这句话一下就把协议的适用边界说得清清楚楚，比背任何定义都值钱。

2. 架构题与角色边界：Host、Client、Server、Agent的职责与坑

2.1 四个角色的准确边界，别把Host和Client混为一谈

MCP面试题里出现频率最高的一类，就是让你解释架构中的角色。很多候选人嘴里能溜出Host、Client、Server、Agent这串专业名词，但一被追问“Host和Client有什么区别”就卡住了。

这里要注意区分。Host是用户所面对的那个应用程序，是整个会话发生的地方，比如一个聊天客户端、一个代码编辑器都算Host。Client是Host进程内部与某个MCP Server建立连接的那个逻辑组件，一个Host内部可以运行多个Client，每个Client对应一个Server。Server暴露能力的一方，负责注册工具、资源或提示词，并执行实际调用。Agent则是真正做决策的那一层，比如通过大模型决定“用户这句话需要调用哪个工具”。

我面试的时候会特别观察候选人能不能说清楚一个点：Client不是App本身，而是App和某个Server之间专有的桥。这组关系在官方文档里画得很明确，我也建议准备面试的人把这个理解透，而不是只记四行定义。

2.2 一次完整调用的关键时序：从握手到能力发现再到执行

MCP的会话流程是我在实际使用中最看重的一层，因为所有调试问题最后都会回到时序上。我建议候选人把这个流程整理成一条线来记，不要碎片化。

第一步是连接建立。客户端启动之后，先给服务端发送initialize请求，带上自己支持的协议版本和客户端能力信息。服务端收到后返回自己的协议版本、服务端信息和能力声明。这一步本质是握手，双方确认“我们能用同一套规则说话”。

第二步是初始化通知。客户端收到服务端的initialize响应之后，会发送一个notifications/initialized通知，告诉服务端“我已经准备好进入正常工作状态了”。注意这里用的是通知而不是请求，因为不需要服务端回应。

第三步是能力列举。客户端根据握手阶段拿到的服务端能力声明，决定可以调用哪些方法。比如服务端声明了支持工具，客户端就调用tools/list获取工具清单；声明了支持资源，就调用resources/list获取资源清单。这就是所谓的动态能力发现，客户端永远不会硬编码假设服务端有哪些能力。

第四步才是实际操作。Agent根据用户意图选择某个工具或资源，通过client发送tools/call或resources/read，把结果送回给Agent。

这个流程如果答得流畅，面试官通常会松一口气，因为他知道你是跑过真实连接的，而不是只看过架构图。

2.3 高频追问：为什么一个Host可以连多个Server

有一次面试，一个候选人答完角色定义后，面试官追问了一句“那为什么一个Host要同时连好几个Server，直接揉到一个进程里不行吗？”

这个问题可以这样理解。首先，从隔离角度看，不同数据源和工具的安全级别不一样，有的只读、有的能写文件、有的要访问外部API，把它们拆成独立Server，可以在连接层做权限隔离，一个Server出问题不会拖垮整个应用。其次，从生命周期角度看，每个Server可以独立启动、停止和升级，你在不停机的情况下替换一个工具实现，不会影响其他Server的会话。第三，从代码维护角度看，不同团队维护不同的Server，发布节奏可以各自独立，这在企业内部分工里非常常见。

这个题的加分表达是：Host里跑多个Client，每个Client维护着独立的状态机；当某个Server崩溃时，其他会话的上下文和连接状态不受影响。协议在设计上刻意让Client和Server保持轻量、独立，就是为了一对多、多对多场景。

2.4 容易答错的Lifecycle题：stdio模式的会话边界

生命周期除了握手之外，还有一个面试官特别喜欢挖的细节：stdio传输模式下Server进程的生命周期。很多人不知道，在stdio模式下，MCP Server是作为Host的子进程启动的，通信走标准输入输出，这意味着Server可以感知到Host的启动和退出。

这里有一个常见的坑：如果Host不是正常退出，而是被强杀，子进程可能收不到优雅关闭信号，会变成残留进程。所以工程实现上，Client通常还需要在退出路径上主动关闭连接，并且在启动路径上定期做孤儿进程清理。

如果你能把这个工程细节讲出来，并且说一句“这个在浏览器或多进程宿主里尤其要注意，进程模型的稳定性直接影响连接可靠性”，面试官会觉得你踩过真实的坑，这道题的区分度就出来了。

3. 三大原语与能力发现：Resources、Tools、Prompts逐个过关

3.1 原语的功能边界与面试标准答案

MCP有一张很经典的三角模型，三个角分别是Resources、Tools、Prompts。我在面试题库里把这三种原语的功能边界和典型面试回答列成了下面的表格，方便你直接对照记忆。

这个表格是面试回答的基础盘，但只背表格还不够。因为面试官大概率会追问一句：Tools和Resources到底有什么区别？你要能答到点子上：区别的核心在于副作用。调用一个工具是执行操作，它可能改数据、发请求、删文件，所以需要做鉴权和确认；读取一个资源只是拿内容，不会对外部世界产生变更。凡是把这两个混为一谈的答案，一听就是没上过手。

Prompts要额外强调一点：它是服务端定义的模板，不是最终的prompt内容。客户端拿到模板之后可以填充参数，也可以直接把模板连同参数一起交给模型去执行。它解决了“每个客户端都内置一套工作流模板”的重复劳动问题。

3.2 能力协商与动态发现的完整链路

动态发现机制是MCP和传统REST API在思想上一个非常大的差别。传统API接口是固定的，文档里写了哪些接口你就调哪些接口；但MCP的Server能力是可以组合的，有的Server只提供工具，有的只提供资源，有的工具和提示词都有。

客户端怎么知道某个Server有什么能力？答案是initialize握手阶段的capabilities字段。服务端在initialize响应里声明自己支持什么原语，比如capabilities里包含tools就表示我支持tools系列方法。客户端拿到这个声明后，才决定后续要不要调用tools/list。如果服务端没有声明Resources，客户端还硬去调resources/list，协议上会返回method not found。

我在面试中会让候选人描述整个链路，顺序必须正确：握手协商版本和能力，之后列举原语，再按需调用。这条链路理解清楚之后，再去看MCP Client SDK的实现，你会发现它的逻辑就是围绕这个顺序铺开的。

3.3 追加题：Sampling、Roots、Completions这些“非三角能力”的价值

除了三大原语，MCP还定义了几个不那么常被提起但面试里偶尔会问的能力。最容易被追问的是Sampling和Roots。

Sampling的意思是服务端在特定场景下可以反过来请求客户端去做一次模型采样，也就是让服务端借助宿主的模型能力生成一段文本或结构化输出。这个设计有意思的地方在于方向颠倒：通常是大模型调工具，但Sampling是工具请求大模型。它在路由、分类、内容增强等场景有实际用途，同时也是面试官钓鱼的好地方——因为候选人容易误以为这是把模型推理外包给了外部服务。

Roots则更好理解，它是客户端告诉服务端的“可操作范围”。举个例子，一个本地文件Server被某个Host连接，Host通过roots告诉Server“只有某个目录你是可以访问的”，Server在后续处理路径时就以这个边界为根。这是一个权限边界机制，直接关系到越权问题，所以我会把这个知识点放到安全章一起讲。

另一个偶尔出现的是Completions，主要是给交互式客户端做参数补全用的。比如用户在输入框里敲参数，客户端需要提示补全，就通过completions方法从Server拿候选值。这个知识点在IDE类应用面试里出现频率更高。

4. 传输、JSON-RPC与安全设计：面试官挖得最深的四个细节

4.1 为什么是JSON-RPC 2.0，而不是REST或WebSocket

MCP面试中被追问最多的协议细节就是“为什么选JSON-RPC 2.0”。这个问题没有标准答案，但有标准的分析框架。

首先说明REST的问题。REST以资源为中心，一组URL对应一组操作，服务端主动向客户端推送事件时不方便，通常要轮询或SSE搭配，而且REST的语义里没有天然的“双向请求”模型。MCP的会话场景里既有客户端请求服务端，也有服务端向客户端推送通知，比如资源变更通知，单纯靠REST需要引入额外机制才能实现。

再说WebSocket。WebSocket虽然天然支持双向实时通信，但它是传输层的东西，没有定义上层消息格式、没有请求标识符、没有错误码规范。MCP如果直接基于WebSocket，就得自己定义一整层应用协议，成本更高。JSON-RPC 2.0自带请求ID映射、错误对象规范、通知机制、批量请求，是一个“自带规范”的应用层协议，放在MCP这种客户端服务端交互复杂的场景里，省掉了一大堆设计工作。

面试时能把这三层比下来，基本就稳了。如果再补一句“JSON-RPC的request必须带id，notification不能带id，服务端对notification不回响应，这是它适合事件流的原因”，那这道题就是高分答案。

4.2 stdio与Streamable HTTP的选型边界

传输层是MCP一个特别容易被考到二级细节的地方，但也是最容易区分候选人是“背过”还是“部署过”的地方。

stdio是早期MCP的默认传输方式，适用于本地进程。Host启动一个子进程，我写的MCP Server作为一个命令行进程跑起来，通过标准输入输出和命令行通信。这个模式的优点是部署极简，不需要起端口、不需要网络鉴权；缺点是只能服务单客户端，且进程生命周期跟着Host走。

后来出现的是基于HTTP的流式传输，也就是Streamable HTTP模式，它基于HTTP POST加SSE配套实现双向通信。比起早期基于HTTP+SSE的实现，它把请求统一到单一化端点上，支持多会话、支持客户端鉴权头，并且能通过OAuth做标准化授权。这个模式适合服务端部署或被多个客户端共享的工具平台。

面试被问到“你在实际项目里用哪种模式”时，我的答案是分场景：本地开发、走CI的构建辅助工具用stdio；要暴露给多个用户共享能力时，用Streamable HTTP模式部署成独立服务。这个问题考的不是你记得多少SDK方法，而是你对“部署边界”是否有感知。

4.3 从OAuth 2.1到根目录隔离：安全设计的一条完整链路

MCP的安全面试题，通常从一个简单问题开始：“如果MCP Server暴露了一个写文件工具，你怎么防止越权？”

初级回答是“加权限校验”。这个回答会让面试官觉得你缺乏系统思考。我建议把安全设计拆成几个串联环节来说。

第一个环节是根目录机制。客户端在初始化后通过roots通知服务端可操作的目录范围。Server在处理文件类请求时，必须把传入路径解析后判断是否踩在根目录边界之外，一旦越界直接拒绝。这属于一层的边界隔离。

第二个环节是资源分级。我在实际部署里会把MCP Server暴露的资源分成三类：公共资源、敏感资源和受保护资源。公共资源不需要鉴权即可访问；敏感资源需要客户端认证通过后才能访问；受保护资源则要求额外的授权流程。这个分级不完全由协议内置，协议提供了能力声明的结构，工程实现时要把鉴权逻辑嵌到每个端点里。

第三个环节是传输层认证。官方推荐的方向是OAuth 2.1使用Authorization Code Plus PKCE流程，让客户端通过授权码换取访问令牌。对老版本向后兼容时，才允许使用API Key或裸请求头。这个环节要额外注意：别在HTTP模式下复用stdio的免鉴权思路，一旦服务监听在公网端口，裸奔等于直接把文件系统暴露出去。

把这三个环节连贯说下来，面试官能明显感觉到你不是只看了概念，是真的设计过安全边界。

4.4 超时、重试与幂等的工程化设计

这是一道我从后端服务面试里挪到MCP面试题库里的题，问的就是：tools/call这个请求超时了，到底能不能安全重试？

很多人没想过，MCP调用铸错时返回的是JSON-RPC错误结构，包含code和message，但协议本身并不保证所有调用都是幂等操作。你重试一个只读工具没问题，如果重试的是一个删文件工具，就可能造成重复执行和不可预期后果。所以工程上要给高风险工具设计幂等机制，比如在参数里带一个操作ID，服务端在处理时先查这个ID是否已经被处理过，如果处理过就直接返回上一次的结果。

传输层也一样。Streamable HTTP模式下的请求需要一个合理的超时上限，视工具类型而定；通知类消息通常不需要重试，而请求类需要指数退避。另一个细节是SSE连接的保持时长，我实际部署时发现很多服务端默认连接空闲超过一定时间会断开，客户端要做心跳或断线重连，否则事件推送会静默失败。

这题能答到这个颗粒度，面试官基本会认为你有过生产环境经验，因为只有真的被线上告警咬过，才会去关心这些细节。

5. 高频争议题与场景题：没有标准答案，但有表达框架

5.1 关系题：MCP与Function Calling到底什么关系

面试中有一道必考题——MCP和函数调用有什么区别、有什么关系。这道题容易答偏，很多候选人把它理解成“二选一”，说MCP要取代函数调用。这个问题一旦答偏，整场面试都会有隐患。

我的理解是：两者处于不同层次。函数调用是模型层面的能力，指的是大模型在生成过程中，能输出一个结构化的调用意图，包含函数名和参数。它解决的是“模型如何表达想调工具”的问题。而MCP是应用层的协议标准，解决的是“工具如何被发现、如何被调用、如何做鉴权和管理”的问题。它们不但不冲突，反而天然协同：模型通过函数调用的格式，说出想调用哪个MCP工具以及参数映射，客户端再去向MCP Server发tools/call请求，取回结果反馈给模型。

如果这个题是给应届生面试，能说到“一个是模型推理的出口，一个是工具调用的管道”这句话，就完全足够了。

5.2 自研插件体系 vs MCP：到底差在哪

面试官有时会追问：“如果我自己写一套插件体系，也可以接工具，为什么非要用MCP？”

这道题的突破口是“标准化带来的生态效应”。自研插件体系的第一个问题是格式私有，插件的清单格式、调用方式、错误处理全由你自己定，需要写大量文档，且每换一个应用就要重新实现一遍。第二个问题是能力管理不统一，你做了一套工具注册表，别人不一定会按你的格式来，每一家公司的插件要各自适配。第三个问题是生态不互通，自己写的插件只有自己能直接用，社区里的现成Server没法直接复用。

MCP的厉害之处不是技术复杂度，而是把工具接入变成了一个公共约定。出来一个公共的能力发布中心，或者一份现成的Server实现，你的应用可以直接连，不需要针对每个来源做适配。这有点像USB接口之于外设：技术上不算高精尖，但标准化之后，整个生态都受益。

5.3 场景题：某个工具调用想删根目录之外的路径，如何处理

我题库里有一道给高级工程师考的题：你的Host上挂了一个MCP Server，它提供一个工具，接收一个filePath参数，可以删除文件。当Agent把filePath传成“/etc/passwd”之类的系统路径时，系统应该怎样防御？

一个合格的回答会按层次拆解：第一层是根目录校验，客户端在roots里声明过可访问边界，Server在接到请求时要先把路径解析成绝对路径再做前缀校验，不在边界内的直接拒绝且不返回路径细节。第二层是权限模型，Server进程本身应该以最小权限用户运行，不能拥有系统级删除权限，这样即使路径校验有漏洞，进程权限也是第二道闸。第三层是用户确认，对删除类工具通常会设计一个审批前置，让用户或管理员确认后再执行。第四层是可追溯性，所有敏感操作留审计日志，找出是谁在什么时候经哪个Agent发起的。

这个框架的价值在于“纵深防御”的思路，它不依赖任何单点机制的完美性，而是层层设防，每一道都挡住一部分攻击面。回答这类场景题的时候，把这个框架亮出来比直接说“加个鉴权”要高级得多。

5.4 争议题：MCP会让上下文更臃肿吗

最后一道争议题，问的是MCP上工具定义、资源内容会一股脑塞进上下文，导致大模型的上下文越用越大，最后爆掉。这个说法到底对不对？

我的观点是：MCP在协议层反而给了精细化控制的手段，问题的根源是应用层使用方式不当。工具定义通常只在初始化时做一次列举，之后模型只需要知道某个工具的大致用途，真正执行时的返回内容可以按需截断、摘要或存到外部。资源这边更灵活，resources/read是按URI读取单个内容块，不是一次性把整个数据源全部灌进上下文，应用层完全可以只让模型先读元数据，再按需取正文。

这个问题的答案框架是“协议提供手段，应用决定策略”。用得好的团队会设计很严格的召回逻辑，把上下文单次载入控制在很小的范围；用得混的团队会直接把整个文件内容塞给模型，那不是MCP的锅。能分清这一层，面试官就知道你既有协议理解，又懂落地权衡。

6. 我整理题库后的心法与实战调试经验

6.1 用一个最小Server验证每一道题的答案

我整理这套题库的时候，最大的体会是：面试题翻来覆去考的都是那几个机制，真正让你把答案记住的不是背诵，而是用手把这个协议跑一遍。

我的做法是这样：用官方SDK在本地搭一个最小化的MCP Server，只实现三件事——正确回应initialize握手、在tools/list里返回一个加法工具、在tools/call里执行加法并返回结果。然后用MCP Client连接这个Server，把握手、初始化通知、列举工具、调用工具这四步挨个打一遍日志，观察每个请求妹子的格式和时序。

跑完之后你会对几个面试高频点有肌肉记忆：比如请求里必须带id和method，通知不能带id，服务端返回的result必须符合特定结构。这些细节光靠看文档很容易忽略，但只要你亲手连过一次，哪怕面试官追问很刁钻的问题，你也能靠回忆日志答出来。

6.2 聊MCP时的三个加分表达与两个送命回答

根据我帮团队模拟面试的经验，同一个知识点，不同的表达方式，带来的面试效果差别很大。

加分表达之一，是先讲关系再讲概念。比如被问Function Calling时，先指出这是模型能力，再强调MCP是应用接入协议，两者配合不矛盾，然后再举自己项目的例子。加分表达之二，是主动提“能力发现依赖于initialize返回的capabilities”，说明你理解动态协商。加分表达之三，是在讲安全时主动提“根目录白名单加最小权限进程”的组合，而不是泛泛而谈加鉴权。

送命回答也有两个。第一个是只会说MCP能解决M×N问题，但完全讲不出一次真实调用流程，面试官会认为你在背题库。第二个是直接否定MCP的工程价值，说“这是XX公司搞的玩具协议，我不用”，这种态度在面试里非常危险，会直接拉低个人评价。真不喜欢MCP，也要用“当前场景下它不适用，因为接入量很小”这类基于条件而不是基于立场的表达。

6.3 一些值得分享的实战踩坑记录

最后分享几个我在实际使用MCP时踩过的坑，这些内容在文档里不一定写得明确，但对回答面试题很有帮助。

第一个坑是stdio模式下子进程的僵尸问题。曾经我启动了一个MCP Server去处理文件操作，宿主进程异常退出时，子进程没有收到退出信号，导致服务器上挂着没人管的孤儿进程，占用端口和内存。后来我把客户端封成了带退出钩子的工具类，确保宿主正常退出时先向子进程发送关闭信号，再退出自己，这个问题才根治。

第二个坑是Streamable HTTP模式下的SSE连接静默断开。服务端和客户端之间没有活跃消息时，连接会被中间链路关闭，客户端却感知不到，后续调用全部超时。我排查了很久，最后是在客户端启用了心跳检测和自动重连机制，才算稳定下来。

第三个坑是能力协商声明和实际实现不一致。某个Server在initialize时声明了支持Resources，但实际代码里忘了实现resources/read，客户端一调就报方法不存在。这让我意识到，面试里提到的“动态能力发现”不是面试官随口一问，而是工程实现里真实的故障来源：凡是声明了能力，就一定有一一对应的实现和自测覆盖。

第四个坑是HTTP模式下把API Key和OAuth令牌混用。某次我为了图省事，在OAuth授权之外额外允许API Key直接访问受保护资源，结果一个测试脚本误用了错误密钥，返回的鉴权错误信息非常难排查，因为服务端同时处理了两种认证路径，错误会变得不一致。后来我统一走标准的授权码换取令牌流程，问题立刻变清晰。

把这些问题跑过一遍之后，我对MCP面试题的答案理解从“背下来”变成了“信得过”。如果你也准备参加面试，我的建议是别只拿着题库刷，花一个周末把最小Server跑起来，观察一次完整的握手和调用日志。那几段日志给你建立的信心，比看几十篇介绍都有用。