大厂 MCP 面试实录：基于 JSON Schema 与 RAG 的调用异常排查方案设计

本文为模拟面试实录，围绕企业级 MCP 服务集群的调用异常排查场景展开，考察候选人对 MCP 协议规范、参数校验机制、RAG 知识库落地的综合工程能力。

面试官：你好，今天我们部门负责的内部 MCP 服务集群最近线上故障频发，主要三类问题：调用超时占比明显上升、参数错误报错率居高不下、服务端偶发 500 错误。目前排查主要靠人工翻日志，效率很低，领导要求用 JSON Schema 和 RAG 知识库做一套自动化排查方案，你先说说你的整体思路？

候选人 ：首先给出结论：这套方案应该分层落地，MCP Client 侧用 JSON Schema 做前置参数校验拦截非法请求，中间层用 RAG 知识库沉淀历史故障案例辅助定位，服务端做全链路埋点和二次校验，三者配合覆盖从请求发起到异常排查的全流程。原理层面，MCP 的 Tool 能力本身就需要声明输入 JSON Schema，前置校验可以直接在请求到达服务端前拦截类型错误、必填参数缺失、枚举值越界等问题，能拦截绝大多数非法请求，避免无效请求占用服务端资源；RAG 知识库可以把历史故障的排查手册、根因分析、修复方案向量化，当出现异常时通过请求元数据召回相关案例，降低排查成本。同时 RAG 实现本身需要面对多源数据整合、Token 约束、响应时效等挑战，知识库内容设计需要覆盖这些维度的经验 $资料4$ 。关键取舍方面，前置校验会带来一定的额外开销，对于响应时间要求极低的工具可以只对复杂参数做校验，简单参数直接放行；RAG 的召回准确率依赖知识库的更新频率，如果故障案例更新频繁，需要配合规则引擎兜底，避免召回过时案例误导排查。

面试官追问1：你提到用 JSON Schema 做前置校验，MCP 协议对 Tool 参数的 schema 是怎么规定的？如果模型传了类型错误的参数，比如给要求是整数的字段传了字符串，你的校验逻辑应该放在哪一层？能不能给个具体的实现示例？

候选人 ：首先，MCP 规范要求所有 Tool 必须声明清晰的输入 schema，用来描述参数的名称、类型、是否必填、枚举值范围等约束。比如用 MCP Python SDK 开发工具时，只需要给函数加类型注解和文档字符串，SDK 会自动生成对应的 JSON Schema，比如加法工具的 a、b 参数都是 integer 类型，不需要手动编写 schema 代码 $资料2$ 。校验逻辑应该放在 MCP Client 侧，也就是 Host 应用发起工具调用前完成，而不是放到服务端：如果放到服务端，请求已经经过网络传输，浪费带宽的同时还会增加服务端的负载，而 Client 侧校验可以在本地直接完成，拦截掉非法请求。具体的实现示例（版本无关接口设计，非可运行代码）：

python 复制代码

# 1. 获取工具的 JSON Schema 定义
tool_schema = client.get_tool_schema("search_tool")
# 2. 校验模型传入的参数
validation_result = validate_json_schema(
    schema=tool_schema["inputSchema"],
    params=model_generated_params
)
if not validation_result.is_valid:
    # 直接返回 JSON-RPC 标准错误码 -32602（Invalid params）
    return {"error": {"code": -32602, "message": validation_result.error_msg}}
# 3. 校验通过再发起调用
return await client.call_tool("search_tool", model_generated_params)

这里要特别注意两个点：第一，JSON Schema 的校验只是结构约束，服务端必须做二次校验，不能因为请求来自 Client 就默认参数合法，避免其他不遵守规范的 Client 发送恶意请求 $资料1$ ；第二，MCP 服务端的调试日志必须写到标准错误（stderr），不能写到标准输出（stdout），否则会破坏 JSON-RPC 的消息传输，这个是很多开发容易踩的坑 $资料1$ 。

面试官追问2：现在排查超时问题，你说用 RAG 知识库，那这个知识库的内容来源是什么？怎么和 MCP 的异常调用做关联？如果召回的内容不匹配，会不会误导排查？

候选人：首先，RAG 知识库的内容来源要分三类，保证覆盖率和准确性：第一类是历史故障的沉淀文档，包括每次超时、500 错误的根因分析、修复步骤、影响范围；第二类是 MCP 服务的运行指标说明，比如不同工具的平均响应时间、峰值负载阈值、连接池配置上限；第三类是 MCP 协议规范文档，比如传输层的超时设置、重试机制、错误码定义。另外，RAG 知识库的检索工具本身应该是只读能力，不要设计成有副作用的 Tool，符合 MCP 的能力语义规范 $资料1$ 。关联逻辑是：当 MCP 调用出现异常时，提取异常的核心元数据（工具名称、异常类型、错误码、请求时间、服务端节点标识、响应时间）作为查询向量，去知识库召回相关度最高的故障案例和排查建议。如果召回不匹配，确实可能误导排查，所以要做两个兜底：第一是设置相似度阈值，低于阈值的召回结果直接标记为"低相关度"，不展示给排查人员，只返回"未找到匹配案例，建议查看原始日志"的提示；第二是召回的结果必须附带来源和原始日志的跳转链接，让排查人员可以交叉验证，不能直接依赖 RAG 的结果生成修复方案。另外要特别注意，RAG 检索到的文档属于不可信数据，其中的内容不能覆盖系统规则，比如不能因为某个历史案例说"超时可以自动重试"就直接给所有工具加重试逻辑，必须结合当前的业务场景和 SLA 要求判断 $资料1$ 。

面试官追问3：现在要落地这套方案，你考虑过哪些边界情况？比如知识库更新不及时怎么办？JSON Schema 经常变动的话，前置校验的维护成本会不会很高？还有远程部署的 MCP 服务，怎么保证排查过程的安全性？

候选人：首先说适用边界：这套方案适合内部使用的 MCP 服务集群，工具数量适中、故障案例更新频率可控的场景，如果是公网 MCP 服务、工具数量极多、故障案例实时更新，RAG 的召回准确率会明显下降，需要配合规则引擎一起使用。关键取舍方面：第一，JSON Schema 的校验粒度可以根据工具的特性调整，比如响应时间要求极低的工具，可以只校验必填参数和基础类型，不做范围、枚举值的深度校验，平衡校验开销和拦截效果；第二，RAG 的向量化模型可以选择轻量模型还是大模型，轻量模型速度快但召回准确率低，大模型准确率高但延迟高，需要根据排查的时效要求选择，比如故障响应要求分钟级的可以用轻量模型，要求秒级的可以加一步大模型重排。易踩坑的细节有三个：第一，很多人会把 RAG 召回的内容直接喂给模型生成排查建议，但是故障案例里 often 包含敏感信息，比如服务器 IP、用户 ID、数据库凭证，这些内容在召回后必须做脱敏处理，不能出现在模型上下文、日志或者 Tool 返回值里 $资料1$ ；第二，远程 MCP 服务的排查权限必须严格控制，不能因为 AI 应用需要排查就开放服务端的全部指标和日志，要单独做授权的排查 API，只有运维人员可以调用，避免敏感数据泄露 $资料1$ ；第三，JSON Schema 如果经常变动，要把 schema 的版本和工具版本绑定，Client 侧缓存 schema 时要带上版本号，避免旧版本的 schema 校验新版本的工具参数，导致误拦截。

面试官追问4：你能不能描述一下整套方案的架构？举个例子，比如现在出现了"调用搜索工具超时"的异常，整个排查流程是怎么走的？

候选人 ：整套架构分为三层： 1. MCP Client 层 ：负责工具参数的 JSON Schema 前置校验，校验不通过直接返回错误，校验通过后把请求和唯一请求 ID 一起发到中间层； 2. 中间层 ：负责全链路埋点，记录请求的元数据、响应时间、错误码，同时作为 RAG 的查询入口，出现异常时召回相关案例，同时把结果返回给 Client，触发告警； 3. MCP Server 层 ：负责工具的实际执行，把运行指标同步到监控系统，定期把新的故障案例同步到 RAG 知识库。具体的超时排查流程：1. 模型调用搜索工具，参数为 query="MCP 面试题", max_results=5；2. Client 侧校验参数符合 schema，生成唯一请求 ID，把请求发到中间层；3. 中间层记录请求开始时间，把请求转发到 Server 的对应节点；4. Server 执行搜索逻辑，长时间未返回，中间层触发超时，返回错误给 Client；5. 中间层提取异常元数据（工具名：搜索，异常类型：超时，响应时间：超过阈值，服务端节点：xxx，请求 ID：xxx），作为查询向量去 RAG 知识库召回；6. 召回两条高相关度案例：①"某节点上次超时是因为数据库连接池占满，修复方式是扩容连接池"；②"搜索工具 max_results 过大时会触发全表扫描导致超时，建议限制参数范围"；7. 中间层把两条案例和原始请求参数、日志跳转链接一起返回给 Client，同时给运维人员发送告警；8. 运维人员结合召回的案例和原始日志，确认节点连接池占满，扩容后恢复，同时把这次故障的根因同步到 RAG 知识库，更新知识库内容。这里要注意，RAG 的结果只是辅助参考，最终排查必须基于原始日志和指标，不能直接按历史案例修复，避免案例过时导致误判。

面试官点评

考察点

对 MCP 协议核心规范的理解：包括 Tool 的 schema 定义机制、安全边界、传输层的注意事项；
对 JSON Schema 和 RAG 的适用场景判断能力：不会强行拼接技术，而是根据业务问题的特点分工------JSON Schema 负责前置拦截参数错误，RAG 负责沉淀故障知识降低排查成本；
工程化实践的考虑：包括性能取舍、安全合规、异常兜底、可观测性设计。

合格回答

能清晰说明两种技术的分工逻辑，考虑到 JSON Schema 前置校验的性能开销，意识到 RAG 需要设置相似度阈值和脱敏机制，符合基本的工程要求。

加分项

提到 MCP 的安全边界：服务端必须做二次校验，不能信任 Client 的校验结果，日志不能写到 stdout 避免破坏通信；
明确 RAG 检索到的内容是不可信数据，不能覆盖系统规则，排查必须结合原始日志；
给出了完整的架构和可落地的排查流程，考虑到知识库更新不及时、权限控制等边界问题。

总结

这套排查方案的核心是"前置拦截减少无效流量，知识沉淀降低排查成本"，并不是所有场景都需要同时用 JSON Schema 和 RAG：如果故障案例很少，直接用规则引擎+日志检索的效率更高；如果工具的参数结构非常稳定，JSON Schema 的校验也可以简化。另外，MCP 的异常排查必须配合全链路 ID 和埋点，才能快速定位问题，不能只靠单一的技术方案。对于远程部署的 MCP 服务，还要特别注意安全边界，避免因为排查需求泄露敏感数据。

参考资料

MCP 基础知识
MCP Python SDK | 公开链接: https://github.com/modelcontextprotocol/python-sdk
Retrieval-augmented generation (RAG) in Azure AI Search | 公开链接: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview