MCP 面试高频考点如何用 Client 与 JSON Schema 沉淀可复用的 Prompts 工作流面试场景面试官我们团队现在面临一个典型问题不同业务线都在写类似的提示模板比如“需求评审”“故障复盘”“接口文档生成”散落在各个项目里版本混乱参数也不统一。如果让你基于 MCP 设计一套可复用的 Prompts 工作流让 Host 里的 AI 应用能稳定发现、调用和演进这些模板你会怎么落地候选人先给结论我会把“可复用提示模板”作为 MCP Server 的 Prompts 能力暴露而不是做成 Tool 或 Resource由 MCP Client 负责发现、拉取和按参数渲染用 JSON Schema 约束入参结构并在 Server 侧做二次校验避免模型或上游传入非法值。这样分工的原因是MCP 中 Prompts 的语义就是“用户可显式选择的模板化消息或工作流”适合做可复用流程入口Tool 更适合有副作用或模型可自动调用的操作Resource 更适合只读上下文资料 [资料1]。如果把提示模板硬塞成 Tool会让模型误以为可以自动触发某些固定流程也混淆了“模板选择”和“动作执行”的边界。基础问题先把能力边界说清楚面试官那你先解释一下Prompts、Tools、Resources 在这个场景里分别负责什么为什么不能全部做成 Tool候选人结论很明确Prompts 负责“工作流入口模板”Tools 负责“流程中的外部动作”Resources 负责“流程需要引用的上下文材料”。以“故障复盘”工作流为例。用户在 Host 中选择“故障复盘 Prompt”后Client 先发现这个 Prompt 模板模板会声明需要哪些参数比如故障时间、影响范围、监控链接、处理人。然后在执行过程中如果需要查询知识库就调用检索 Tool如果需要挂载事故单、变更记录或运行手册就通过 URI 读取 Resource。最后把参数、检索结果和资源内容组装成结构化消息交给模型。为什么不全做成 Tool因为 MCP 规范里Tools 是模型可自动调用的操作强调“做事情”Prompts 是面向用户选择、可参数化的模板强调“怎么开始一个任务” [资料1][资料3][资料4]。如果把“生成复盘文档”做成 Tool模型可能在用户没有明确选择的情况下自动触发而且输入参数、确认流程、版本管理都会变得模糊。Prompt 模板本身没有副作用它只是把用户意图和上下文组织好真正有副作用的动作比如写回文档系统、创建工单才应该交给 Tool。面试官点评这一轮的考察点是 MCP 三类能力的语义边界。合格回答需要明确 Prompts 适合模板化工作流入口Tool 适合模型可控的动作Resource 适合只读上下文不能只背定义要结合业务说明为什么这么选。加分项是能指出“不要把只读资料强行设计成有副作用的 Tool”这一反模式 [资料1]。追问一JSON Schema 放在哪谁来校验面试官你提到用 JSON Schema 约束参数。那 Schema 应该定义在哪里Client 拿到 Schema 后能不能直接信任候选人结论是JSON Schema 应由 MCP Server 在暴露 Prompt 时一并声明Client 负责做前置表单渲染、参数补全和基础校验但 Server 必须做最终校验和授权判断不能因为请求来自 AI 应用就默认可信 [资料1]。具体分工是这样的第一Server 在 Prompt 元数据里声明参数结构包括字段名、类型、是否必填、枚举范围、描述信息。例如“故障复盘”Prompt 可以要求incident_id为字符串、severity必须是 P0/P1/P2/P3 枚举、timeline为对象数组。这样 Client 不需要硬编码每个模板而是可以动态发现 Prompt 列表和参数要求。第二Client 根据 Schema 生成交互界面或参数收集逻辑。如果用户通过 Host 手动选择 PromptClient 可以先校验必填项、类型和枚举值如果是模型参与参数填充Client 也应把 Schema 作为约束减少无效调用。Python SDK 里类似 Tool 的类型标注最终会转化为结构约束开发者不需要手写大量请求解析和校验样板代码但这并不意味着业务校验可以省略 [资料2]。第三Server 端必须把传入参数视为不可信输入。比如runbook_uri、ticket_url、service_name这类字段不能直接拼接到提示词或下游请求里要校验 URI 白名单、资源范围、字段长度和格式。如果 Prompt 工作流中包含高风险 Tool 调用比如发布变更、发送通知还要在执行前让用户看到具体影响并确认 [资料1]。容易踩坑的一个细节是很多人会把 Schema 当成安全边界本身认为“类型对了就安全”。实际上 Schema 只能约束结构不能代替授权。比如用户传了一个合法格式的incident_id但他根本没有查看该事故单的权限Server 仍然要拒绝。面试官如果参数里允许引用 Resource比如传入一个文档 URI异常怎么处理候选人结论是要区分“模板参数错误”“资源不可读”“下游 Tool 失败”三类异常不能把所有错误都包成一句“生成失败”。如果是参数不符合 SchemaClient 在提交前就应提示避免无意义请求如果是资源不存在、无权限或 URI 不在允许范围内Server 应返回结构化错误告诉 Client 哪个字段有问题、可选值是什么如果是工作流中的 Tool 调用失败比如检索服务超时Prompt 不应静默继续而是要标记失败步骤决定是降级为“仅基于已提供信息生成草稿”还是中断流程。具体超时、重试和降级策略不能拍脑袋定要根据业务 SLA、风险和压测结果确定。面试官点评这一轮考察 JSON Schema 在 MCP 中的真实作用以及“结构校验不等于安全”。合格回答需要说明 Schema 由 Server 声明、Client 做前置体验优化、Server 做最终校验和授权。加分项是能把异常分层处理并点出凭据脱敏、审计日志、高风险操作确认这些安全要求 [资料1]。追问二MCP Client 如何把 Prompt 工作流跑起来面试官那从工程落地看MCP Client 的职责是什么如果既有本地 stdio Server又有远程 HTTP ServerClient 要不要写两套逻辑候选人结论是Client 应承担连接、发现、参数装配、调用编排和结果展示但不要把业务模板硬编码在 Client 里传输层差异应被 SDK 屏蔽业务层只面向统一的 MCP 接口编程。一个可落地的流程如下Host 启动后MCP Client 根据配置连接一个或多个 Server。本地开发或桌面集成场景可以用 stdio 启动子进程远程团队共享服务可以用 Streamable HTTP。Python SDK 的 Client 既可以连本地内存对象、stdio 子进程也可以连远程 URL这说明核心调用逻辑不需要因为传输方式改变而重写 [资料1][资料2]。Client 调用 Prompt 发现接口获取可用工作流列表例如“需求评审”“故障复盘”“接口文档生成”并读取每个 Prompt 的参数 Schema。用户选择某个 Prompt 后Client 根据 Schema 收集参数。这里可以结合 Host 自身能力做自动填充比如从当前页面读取需求标题、从剪贴板读取日志片段、从 Resource URI 加载文档。Client 把参数提交给 Server获取渲染后的 Prompt 内容。这里返回的不应只是一段纯文本还可以包含建议调用的 Tool、需要加载的 Resource、给用户的确认项。Client 按工作流执行后续步骤先拉取必要 Resource再按需调用 Tool例如检索内部知识库、读取变更记录最后把组装好的上下文交给模型生成结果。整个过程要记录审计日志谁在什么时候选择了哪个 Prompt、使用了哪些参数、访问了哪些资源、调用了哪些 Tool、结果状态如何敏感字段必须脱敏凭据不能出现在日志或返回内容里 [资料1]。伪代码层面版本无关的接口设计可以这样表达client MCPClient(transport_config) prompts client.list_prompts() selected prompts.find(incident_review) validation client.validate_prompt_args(selected.name, user_args) if not validation.ok: show_errors(validation.errors) return prompt_result client.get_prompt(selected.name, validated_args) for resource in prompt_result.required_resources: context.append(client.read_resource(resource.uri)) for tool_call in prompt_result.suggested_tools: if requires_confirmation(tool_call): user_confirm(tool_call) context.append(client.call_tool(tool_call.name, tool_call.args)) final_messages compose_messages(prompt_result.messages, context) show_to_user(final_messages)这里要特别说明上面是接口设计伪代码不绑定某个 SDK 版本的具体方法名实际实现时应遵循所用 MCP SDK 的官方 API。方案设计团队复用要考虑什么取舍面试官你这套方案的适用边界是什么有什么取舍候选人结论是这套方案适合“模板可标准化、参数可结构化、流程需要团队共享治理”的场景不适合高度即兴、完全依赖自由对话、且无法沉淀参数模型的零散任务。关键取舍有三个。第一Prompt 放在 Server 还是 Client 配置里。放在 Server 的好处是集中治理、版本统一、Host 不需要升级就能拿到新模板缺点是团队需要维护 Server 的发布、权限和可用性。如果只是个人本地脚本直接写在 Client 也可以但团队复用更适合 Server 化。第二工作流编排放在 Prompt 返回结果里还是 Client 固定逻辑里。如果把 Tool 和 Resource 依赖完全写死在 Client模板升级会很僵硬如果完全由 Server 动态返回Client 又需要处理更多不确定性。我的建议是Prompt 声明必需参数和推荐资源高风险 Tool 仍由 Client 按明确规则执行并要求用户确认避免 Server 一个模板变更就触发危险动作。第三检索能力放在 Prompt 流程里自动调用还是由 Host 在调用模型前主动检索。MCP 中可以把知识检索封装成 Tool由模型根据任务决定何时检索也可以由 Host 预先检索前者灵活后者流程更可预测 [资料1]。对于团队级 Prompt 工作流我倾向于把“必须引用”的资料通过 Resource 或前置检索固定下来把“补充探索”交给模型调用检索 Tool这样既保证结果稳定又保留灵活性。还有一个容易踩坑的点stdio 模式下Server 的调试日志不能写到标准输出否则会破坏 JSON-RPC 通信日志必须走标准错误。远程 HTTP 模式下还要额外处理认证、授权、会话管理、限流和超时不能把本地可用的代码直接暴露到公网 [资料1]。面试官总结面试官今天这组问题从“Prompts 为什么不是 Tool”开始到 JSON Schema 的职责边界再到 MCP Client 的连接、发现、编排和异常处理实际考察的是你能不能把 MCP 的协议语义用在真实工程里而不是只会背三个能力名词。合格的落地方案应该满足四点第一能力选择符合语义Prompts 做模板入口Tools 做动作Resources 做上下文第二Schema 用于动态发现和前置校验但安全上坚持 Server 端不可信输入校验与授权第三Client 通过统一协议连接不同传输不把模板硬编码死第四对异常、审计、确认机制和适用边界有清晰交代。如果候选人还能进一步说明 RAG 检索结果也是不可信数据、不能让检索内容覆盖系统规则并且知道如何在 Prompt 工作流中保留来源元数据用于引用和排错 [资料1]那会是明显加分项。参考资料MCP 基础知识MCP Python SDKhttps://github.com/modelcontextprotocol/python-sdkPromptshttps://modelcontextprotocol.io/specification/2026-07-28/server/promptsToolshttps://modelcontextprotocol.io/specification/2026-07-28/server/tools