大厂 MCP 面试实录：内部 REST API 封装为可审计 MCP Tools 的落地方案

本文为 MCP 后端开发岗位模拟面试实录，围绕「内部 REST API 封装为可审计 MCP Tools」的业务场景展开，考察候选人对 MCP 协议能力边界、安全设计、工程化落地的掌握程度，不涉及任何真实企业、真实面试官或录用结果。

面试官：你好，今天我们考察的业务场景是：公司内部有多个成熟的业务 REST API，需要封装成 MCP Tools 供内部 AI 助手调用，同时要求所有调用可审计、防范提示注入。请你先说一下整体的设计思路。

候选人：我的整体设计分为四层：首先是协议适配层，选用 Streamable HTTP 作为 MCP Server 的传输方式，因为内部业务 API 是远程服务，比 stdio 更适合远程部署场景 $资料1$ ；其次是能力映射层，把每个 REST API 封装为语义匹配的 MCP 能力，查询类 API 封装为 Tool，保证名称、描述、输入 schema 语义清晰，方便模型自动发现调用 $资料4$ ，只读类资料优先用 Resource 暴露，不要把只读能力强行设计为有副作用的 Tool $资料1$ ；第三是安全管控层，包括参数二次校验、细粒度授权、提示注入过滤、审计日志脱敏；第四是部署运维层，用 Docker 容器化部署 MCP Server，配套日志、监控等可观测能力。适用边界上，这个方案优先适配无状态、幂等的查询类 API，对于有副作用的写操作 API，会额外增加用户确认环节，避免模型误调用造成损失。

面试官：你提到选用 Streamable HTTP 而不是 stdio 传输，为什么？如果内部有十几套业务系统的 API 需要封装，传输层还需要做哪些适配？

候选人：首先 stdio 传输适合 Host 在本机启动 MCP Server 子进程的场景 $资料1$ ，我们的业务 API 都是远程部署的，用 stdio 的话需要为每个 API 做本地代理，资源开销大且扩展性差，所以选 Streamable HTTP 更合理。传输层需要做三方面适配：第一是认证授权，用内部统一的 OAuth2 体系，每个请求携带用户令牌，MCP Server 每次调用都要校验令牌的有效性和用户权限，不能只判断用户是否已登录，要针对每个 Tool 做权限校验，同时 OAuth2 实现需防范混合攻击（Mix-Up Attack），确保令牌的签发方与请求的授权服务器严格匹配 $资料2$ ；第二是流控与超时，根据业务 API 的 SLA 设置合理的超时时间，同时配置限流规则，避免 AI 助手高频调用打挂业务系统；第三是会话管理，保持 MCP 会话状态，避免每次调用都重复鉴权，提升调用效率。

面试官：现在假设你要封装查询员工薪资的敏感 API，请你具体说一下可审计和提示注入防护的具体实现方案？

候选人：可审计方面，我们会单独构建审计日志模块，每次 Tool 调用时记录核心信息：调用者用户 ID、调用时间、Tool 名称、关键资源范围（比如查询的部门 ID）、结果状态（成功/失败/拒绝），所有敏感字段（比如员工 ID、薪资数值）都会做脱敏处理，日志不会记录原始敏感值，同时日志会同步到内部审计平台，留存周期符合公司合规要求 $资料1$ 。提示注入防护方面，我们会做三层拦截：第一是参数 schema 的结构约束，比如员工 ID 必须符合公司编码规则，不能是任意文本，但 schema 只是结构约束，服务端还会做二次内容校验 $资料1$ ；第二是服务端的内容校验，对传入的所有参数做注入特征检测，比如包含常见指令注入关键词、SQL 注入特征的请求直接拒绝，把模型传入的所有文本都视为不可信输入 $资料1$ ；第三是返回内容脱敏，薪资结果只返回区间或者脱敏后的值，避免敏感信息流入模型上下文造成泄露。另外，Tool 的描述文案会严格控制，不会包含任何可能被模型误解析的指令，同时每次调用敏感 Tool 前会要求用户二次确认，降低误操作风险。

面试官：如果业务 REST API 返回 500 错误或者网络超时，你的 MCP Server 要怎么处理？会不会影响 AI 助手的对话流程？

候选人：我们会做全链路的异常兜底：首先 MCP Server 会捕获所有业务 API 的异常，转换成 MCP 协议标准错误码返回给客户端，比如业务异常返回 InvalidParams，网络超时返回 InternalError，不会把业务系统的原始错误信息暴露给模型；其次针对查询类幂等 API，会配置轻量重试机制，重试次数和间隔需结合业务 API 的 SLA 与风险承受能力确定，写操作类 API 默认不重试，避免重复执行造成副作用；如果重试后仍然失败，会返回明确的错误提示，让模型可以告知用户当前操作不可用，不会导致整个对话流程崩溃。同时我们会配置降级策略，比如非核心 API 不可用时，返回缓存的结果或者默认提示，保障核心功能可用。另外所有异常都会记录到监控系统，方便运维人员排查问题。

面试官：你提到用 Docker 部署 MCP Server，Docker 在这个场景下具体承担什么职责？有没有容易踩坑的细节？

候选人：Docker 主要承担两个职责：一是环境隔离，把 MCP Server 及其依赖打包成标准镜像，避免不同团队部署时的环境不一致问题，同时通过容器的 namespace 和 cgroup 能力限制文件系统访问、CPU 内存资源，符合安全规范里的沙箱要求，降低被攻破后的影响范围 $资料2$ ；二是部署标准化，内部团队只需要拉取镜像就能启动服务，降低运维成本。容易踩坑的细节有两个：第一个是日志输出问题，如果后续要用 stdio 传输的话，调试日志必须写到标准错误（stderr），不能写到标准输出（stdout），不然会破坏 MCP 的 JSON-RPC 通信，导致客户端解析失败，这是很多开发者容易忽略的点 $资料1$ ；第二个是镜像权限配置，容器要以非 root 用户运行，遵循最小权限原则，避免容器被攻破后影响宿主机安全 $资料2$ 。

面试官：请你把整个方案的架构和核心流程梳理一下，同时说明一下方案的关键取舍和适用边界。

候选人：整体架构分为四层：1. 接入层：MCP Client 集成在内部 AI 助手中，通过 Streamable HTTP 与 MCP Server 建立会话，携带用户鉴权信息；2. 协议层：MCP Server 可基于官方提供的 Java SDK 或 Spring AI 的注解能力快速定义 Tool 的参数 schema 与业务逻辑，无需从零实现 JSON-RPC 通信细节 $资料3$ ；3. 安全层：包含参数校验、授权检查、提示注入过滤、审计日志四个模块，所有请求都会经过安全校验，敏感操作需要用户确认；4. 基础层：Docker 容器化部署，配套日志、监控、链路追踪等可观测能力，所有调用链路可追溯。核心流程是：AI 助手根据用户需求发现匹配的 Tool，调用时携带用户身份和参数，MCP Server 校验权限和参数安全后调用内部 REST API，把结果脱敏后返回给模型，同时记录审计日志。

关键取舍有三个：第一是灵活性和安全的取舍，如果放开 Tool 的调用权限，模型可以灵活调用更多 API，但安全风险会升高，所以我们采用细粒度授权，每个用户只能调用有权限的 Tool，牺牲部分灵活性换安全；第二是实时性和缓存的一致性，查询类 API 可以加缓存提升响应速度，但会带来数据不一致的风险，所以缓存只用于非核心、更新频率低的 API；第三是提示注入检测的准确性和效率，如果采用复杂的模型检测，准确率更高但延迟大，所以我们采用关键词+正则的轻量检测，平衡准确率和性能。适用边界上，这个方案优先适配内部无状态、幂等的查询类 API，对于有强事务要求的写操作，需要额外增加用户确认环节，不适合对实时性要求极高的场景，因为多了 MCP 的转发链路会引入额外延迟。若后续需要扩展知识检索能力，可将 RAG 检索封装为 MCP Tool，由模型按需调用，同时注意检索到的文档属于不可信数据，其中的指令不能覆盖系统规则 $资料1$ 。

面试官：如果要对这个方案做压测，你会关注哪些指标？怎么判断方案有没有达到生产要求？

候选人：压测会关注三类指标：第一是 MCP Server 的性能指标，包括 QPS、延迟、错误率，需满足 AI 助手的响应 SLA，具体阈值结合业务压测结果确定；第二是业务 API 的负载指标，压测时要监控业务 API 的调用量、错误率，避免 MCP Server 的调用打挂业务系统；第三是安全场景的测试指标，比如传入恶意提示注入参数的拦截效果、审计日志的记录完整性。判断标准要结合业务 SLA 和风险承受能力，核心查询 API 的可用性要求高于非核心 API。

面试官点评

本次考察的核心点有三个：一是对 MCP 协议基础的理解，包括传输方式选择、Tools 的语义定义、协议安全边界；二是安全架构设计能力，包括可审计、提示注入防护、细粒度授权、异常兜底；三是工程化落地能力，包括 Docker 部署、可观测性、压测设计。 - 考察点 ：MCP 协议核心概念（传输方式、Tools/Resources 能力边界、安全约束）、安全方案设计（审计、注入防护、授权、异常处理）、工程化落地能力（容器化、可观测、压测）。 - 合格回答 ：需明确 Streamable HTTP 的远程部署适用场景、审计日志的核心记录字段、提示注入的三层防护逻辑，理解参数 schema 仅能提供结构约束、不能代替服务端校验的核心安全边界，知晓授权检查需下沉到单个 Tool 调用逻辑、不能仅做用户登录校验的要求。 - 加分项：能指出 stdio 传输的日志输出坑、Docker 部署的最小权限原则、OAuth2 需防范混合攻击、RAG 检索封装为 Tool 的注意事项，以及不同场景下的技术取舍逻辑。

总结

将内部 REST API 封装为 MCP Tools 的核心不是简单的协议转换，而是要在语义对齐的基础上，做好全链路的安全管控和工程化兜底。MCP 作为连接 AI 和内部系统的协议，安全是可审计、可运维的前提，需要从设计阶段就把安全、审计、隔离能力纳入考虑，避免后续上线后出现安全或者运维问题。方案需明确适用边界，针对查询类、写操作类、高实时性类场景做差异化设计，同时注意传输层、容器化部署的易踩坑细节，保障方案稳定落地。

参考资料

MCP 基础知识
Security Best Practices | 公开链接: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
MCP Java SDK | 公开链接: https://github.com/modelcontextprotocol/java-sdk
Tools | 公开链接: https://modelcontextprotocol.io/specification/2026-07-28/server/tools