大厂 MCP 面试实录内部 REST API 封装为可审计 MCP Tool 的实践设计本文为模拟面试复盘形式围绕「将内部 REST API 封装为可审计 MCP Tools」的业务场景展开由浅入深考察候选人对 MCP 协议选型、安全边界、工程化落地的掌握程度。面试官你好今天我们有个实际业务需求需要把内部订单管理的 REST API 封装成 MCP Tools提供给内部 AI 助手使用同时必须满足操作可审计、高风险操作防误触的要求。你先说说整体的设计思路候选人首先我会基于 MCP 的服务端能力做封装选择 Tools 作为核心能力载体因为我们的 REST API 是模型需要根据用户需求主动调用的操作符合 Tools「模型可控发起、有明确输入输出」的语义[资料3]。具体流程上第一用 JSON Schema 定义每个 Tool 的输入参数做结构层面的约束第二MCP Server 内部对接 REST API 的客户端把 Tool 调用映射为对应的 REST 请求第三针对高风险操作比如订单取消、退款增加人机协同确认环节第四全量记录审计日志满足可审计要求。传输方式上因为是多团队内部共享我会选择 Streamable HTTP 部署 MCP Server方便多个 AI 应用接入。如果用 MCP Python SDK 开发只需要编写带类型标注的业务函数和功能描述SDK 会自动生成对应的 JSON Schema 并处理 JSON-RPC 的通信、校验逻辑无需手动编写协议相关代码[资料2]。面试官你提到选择 Tools 能力MCP Server 还有 Resources 和 Prompts 两类能力这三类能力有什么区别为什么这里不用另外两类候选人三类能力的语义差异很大选型的核心是匹配操作的属性Tools 是模型可以主动发起、有明确输入参数和返回结果的操作适合封装我们的 REST API 这种需要动态传参、可能产生副作用的调用场景Resources 是只读的上下文数据通常由 URI 标识由 Host 主动读取而不是模型发起调用适合提供静态的订单规则文档、历史订单报表这类只读资料如果我们只是要提供固定的订单知识用 Resources 更合适但动态查询的场景下 Resources 的 URI 参数灵活性不足Prompts 是预定义的模板化工作流适合给用户提供固定的操作模板比如「生成月度订单分析报告」的模板不需要封装底层 API 调用。所以我们的场景是封装可调用的 APITools 是最匹配的选型不会强行用另外两类能力。面试官你提到用 JSON Schema 定义 Tool 的输入参数它在这里具体承担什么作用如果模型传了不符合 schema 的参数会发生什么有没有什么边界情况需要注意候选人JSON Schema 在这里是第一道输入校验关卡MCP 协议本身要求 Tool 的输入必须符合定义的 JSON SchemaMCP Server 会自动做结构层面的校验比如参数类型是否正确、必填项是否缺失、枚举值是否合法、字符串格式是否符合要求比如订单号的ORD8位数字格式。如果参数不符合 schema请求会在协议层直接返回错误不会落到我们的 REST API 调用逻辑避免无效请求打垮后端服务。但这里要注意一个边界JSON Schema 只是结构约束不能代替业务层校验和授权[资料1]。比如就算参数结构完全符合要求但用户没有权限查询该订单或者订单号对应的订单已经注销这些业务逻辑的校验还是要在我们对接 REST API 的层做不能依赖 JSON Schema 的约束。另外schema 的定义要尽量 granular比如给订单号加正则约束避免模型传非法参数到后端。面试官如果模型传的参数结构合法但对接的内部 REST API 返回了 500 错误或者出现了网络超时你会怎么处理可审计的要求具体要落地到哪些细节候选人首先异常处理要分层第一针对后端 API 的异常要区分错误类型是业务错误比如订单不存在、权限不足还是系统错误比如 500、超时把结构化的错误信息返回给模型让模型可以判断是调整参数重试还是告知用户问题第二超时时间要根据后端 REST API 的 SLA 设置比如后端 P99 响应是 500ms我们可以把 MCP Tool 的超时设为 2s避免阻塞模型的响应超时后要返回明确的超时错误码方便排查问题。可审计的落地需要记录完整的调用链路包括调用时间、调用方标识哪个用户、哪个 AI 应用、调用的 Tool 名称、传入的关键参数敏感字段比如用户手机号要脱敏只记录前4位后4位或者哈希值、调用结果状态成功/失败、失败原因如果是高风险操作还要记录用户确认的时间、确认的内容。所有审计日志要存在独立的日志服务里设置合理的 retention 周期满足合规要求[资料1]。面试官如果后续我们要封装订单取消这类有副作用的写操作安全控制要怎么加强你提到的人机协同确认具体怎么实现候选人写操作属于高风险不可逆操作安全控制要加两道关卡第一Tool 的元数据描述里要明确写出操作的影响比如「取消订单后将无法恢复会自动触发退款流程」让模型在调用前就能知道风险第二在 MCP Server 端实现确认拦截机制当模型发起写操作 Tool 的调用时Server 不直接执行业务逻辑而是返回一个需要用户确认的提示给 HostHost 弹出确认框给用户用户明确确认后Host 再发起实际的 Tool 调用请求Server 校验确认信息有效后再执行 REST API 调用。同时写操作的权限要和读操作隔离做更严格的授权校验比如只有用户本人或者有运营权限的用户才能调用取消订单的 Tool不能因为请求来自 AI 应用就默认可信[资料1]。另外所有写操作的审计日志要额外记录操作前后的数据快照方便回滚和排查问题。面试官现在内部有 3 个不同的 AI 应用都要用这个封装你怎么做权限隔离和部署有没有什么容易踩坑的细节候选人首先部署方式肯定选 Streamable HTTP因为 stdio 只能给本机 Host 用无法支持多应用远程接入远程部署时还要考虑认证、授权、限流和超时控制[资料1]。权限隔离分三层第一接入层认证每个 AI 应用调用 MCP Server 的时候要带自己的凭据比如 JWT 或者 API KeyServer 先校验凭据的有效性拒绝非法调用第二授权层校验每个凭据绑定对应的权限范围比如客服 AI 只能查询自己负责的用户的订单运营 AI 只能查询统计维度的订单不能访问单个用户的敏感信息第三业务层校验每次调用 REST API 的时候还要校验当前用户有没有权限操作对应的资源做多层防护。容易踩坑的细节有几个第一MCP Server 的调试日志一定要写到标准错误stderr不能写到标准输出stdout否则会破坏 JSON-RPC 的消息格式导致通信失败[资料1]第二不要把模型传入的参数当成可信输入就算经过 JSON Schema 校验也要在业务层做二次校验避免注入攻击第三返回给模型的订单详情要做敏感字段脱敏比如用户手机号、地址中间部分打码避免敏感信息泄露到模型上下文里第四审计日志里不要记录完整的敏感参数避免日志泄露导致数据风险。面试官点评考察点本题核心考察候选人对 MCP 能力选型的理解、协议层约束JSON Schema、JSON-RPC的落地能力、安全边界的把控、工程化实践的积累以及复杂场景下的权衡能力。合格回答能清晰区分 Tools/Resources/Prompts 的适用场景知道 JSON Schema 的结构约束作用能想到审计、权限、异常处理等基础工程要求对 MCP 的传输方式有基本认知。加分项能明确区分结构校验和业务校验的边界知道人机协同确认的实现逻辑能说出远程部署的日志、脱敏、权限分层等易踩坑的细节对方案的适用边界和取舍有清晰认知。总结将内部 REST API 封装为可审计 MCP Tool 的核心设计原则是「能力匹配、安全左移、审计兜底」首先要根据操作的语义选择正确的 MCP 能力避免强行拼接其次要把安全控制嵌入到调用的全链路从参数校验、授权到高风险确认层层把关最后要完善审计日志满足可追溯的合规要求。该方案适合内部可控的 REST API 封装场景如果是公网 API 还需要补充接口签名、传输加密、熔断限流等额外控制具体参数需要根据业务 SLA 和压测结果调整。参考资料MCP 基础知识MCP Python SDK | https://github.com/modelcontextprotocol/python-sdkTools | https://modelcontextprotocol.io/specification/2026-07-28/server/toolsOverview | https://modelcontextprotocol.io/specification/2026-07-28/basic