大厂 MCP 面试实录：给 MCP Server 落地可观测性与安全认证方案

本文采用大厂技术岗模拟面试复盘形式，围绕「给 MCP Server 增加日志、指标和分布式追踪」的业务场景，结合 OAuth 2.1 认证与 JSON Schema 校验的技术组合，还原由浅入深的面试考察过程。

面试官：今天我们考察 MCP 的工程化落地能力，不是单纯的概念背诵。假设你现在负责给公司内部的代码检索 MCP Server 做升级，需求有三个：第一是补齐日志、指标、分布式追踪能力，方便后续排查问题和监控服务状态；第二是接入 OAuth 2.1 实现用户级授权，不能只要登录就放行所有 Tool 调用；第三是所有 Tool 的入参都要做严格校验，避免恶意输入。你先说说整体的设计思路？

候选人：整体我会分三层来做：最底层是可观测层，用 SLF4J 输出结构化日志，通过 Micrometer 暴露指标，用 OpenTelemetry 实现分布式追踪，同时把关联 ID 和追踪状态跨异步边界透传，保证全链路可关联；中间是安全层，按照 MCP 规范要求实现 OAuth 2.1 授权码模式，每次请求校验 access token 的有效性，同时做细粒度的 Tool 级权限校验；最上层是参数校验层，用 MCP 协议规定的 JSON Schema 对 Tool 入参做服务端校验，所有不可信输入都做额外约束，敏感字段全链路脱敏。

面试官：你提到用 SLF4J 打日志，MCP 的通信是基于 JSON-RPC 的，而且支持异步调用，你怎么避免日志输出破坏通信？如果 Server 用 stdio 传输，有什么特殊注意点？

候选人：首先日志输出要和协议通信通道分离：如果是 stdio 传输的场景，MCP 的标准输出（stdout）专门用来传 JSON-RPC 消息，调试日志必须写到标准错误（stderr），否则会污染协议消息导致通信失败 $资料2$ 。异步场景下，我会用 Reactor 的上下文传播能力，把关联 ID、trace ID 这些元数据放到异步管道里传递，同时通过 SLF4J 的 MDC 把 ID 注入到日志上下文中，这样不管是同步还是异步请求，日志都能关联到对应的调用链路 $资料1$ 。另外所有日志都会做敏感字段脱敏，比如 access token、用户隐私信息、代码中的密钥都不会明文输出。

面试官：那分布式追踪你怎么和 MCP 的调用链路结合？如果 Tool 执行的时候需要调用下游的其他服务，怎么保证 trace 上下文不丢？

候选人：首先会在 MCP Server 启动时初始化 OpenTelemetry SDK，自动给每个 MCP 请求创建根 Span，把 trace 上下文按照 W3C 标准格式（traceparent、tracestate）透传。如果是 Streamable HTTP 传输的远程 Server，会把 trace 上下文放到 HTTP 请求头里传给下游服务；如果是异步执行的 Tool，会用 OpenTelemetry 的上下文传播器把 trace 状态传递到线程池的任务中，保证整个从 Client 发起请求、Server 执行 Tool、再到调用下游服务的全链路都能被追踪到。同时 Micrometer 会埋点统计 Tool 的调用次数、成功率、延迟、错误码分布这些核心指标，方便对接 Prometheus 等监控系统。

面试官：现在说到安全层，MCP 规范对 OAuth 2.1 有什么强制要求？你怎么实现用户级授权，而不是只要 token 有效就放行？

候选人：根据 MCP 的授权规范，授权服务器必须实现 OAuth 2.1，并且支持 appropriate 的安全措施， confidential 客户端要用 client secret 做认证，public 客户端要支持 PKCE $资料4$ 。我的实现是：首先 MCP Server 会暴露 OAuth 2.1 的授权端点，Client 用授权码模式获取 access token，每次请求都要在 Authorization 头里携带 token；Server 收到请求后先校验 token 的合法性，然后从 token 的声明里解析出用户 ID 和权限范围，再和当前请求的 Tool 所需权限做匹配，只有用户有对应 Tool 的调用权限才放行，不是只要 token 有效就允许调用。同时审计日志会记录用户 ID、调用的 Tool、关键参数、结果状态，所有敏感字段都会脱敏，token 不会出现在任何日志或者返回值中 $资料2$ 。

面试官：那 JSON Schema 在这里的作用是什么？Tool 的参数 schema 是模型传过来的，还是你预先定义的？如果参数不符合 schema 你怎么处理？有没有可能绕过校验？

候选人：JSON Schema 是 MCP 协议规定的参数校验标准，Schema 必须由 Server 预先定义，不能由模型或者 Client 传入------因为模型生成的参数可能不符合业务要求，甚至可能是恶意的，MCP 的规范也明确说 Tool 的参数 schema 只是结构约束，不能代替服务端校验和授权 $资料2$ $资料3$ 。我的实现是：每个 Tool 注册的时候就会绑定对应的 JSON Schema，Server 收到 Tool 调用请求后，首先做 JSON Schema 校验，如果参数不符合格式，直接返回 JSON-RPC 的无效参数错误，不会进入业务逻辑层。同时还会对文件路径、URL、SQL 参数这些高风险字段做额外的约束，比如禁止路径遍历、禁止访问内网地址，防止恶意输入。因为校验逻辑是 Server 端强制执行的，所以不存在绕过的问题。

面试官：如果 Tool 执行的时候抛异常，或者 OAuth token 过期，你怎么保证可观测数据的完整性，不会出现链路断裂？

候选人：首先会做全局的异常捕获：同步执行的 Tool 异常会被捕获，把异常信息、堆栈记录到日志中，同时给当前追踪 Span 打上 error 标签，Micrometer 会记录对应的错误指标；异步执行的 Tool 会设置全局异常处理器，把异常信息上报到追踪系统，避免异步异常丢失。如果 OAuth token 过期，Server 会返回 401 错误，Client 会自动刷新 token 后重试，这个重试请求的 trace ID 会和原请求关联，因为我在 OAuth 的刷新流程里也做了 trace 上下文的透传，保证整个用户会话的链路是连续的。另外所有错误场景的日志都会记录对应的错误码、用户 ID（脱敏后）、请求 ID，方便排查问题。

面试官：现在你的 MCP Server 要同时支持本机 stdio 传输和远程 Streamable HTTP 传输，两种传输下的可观测性、OAuth 实现有没有差异？你怎么统一处理？

候选人：核心的可观测性和安全逻辑是统一的，差异只在传输层的元数据提取：可观测性层面，不管是 stdio 还是 HTTP 传输，都用同一套 SLF4J、Micrometer、OpenTelemetry 逻辑，只是关联 ID 和 trace 上下文的来源不一样------stdio 传输从 MCP 消息的自定义头部提取，HTTP 传输从 HTTP 请求头里提取。OAuth 2.1 层面，stdio 传输是本地调用，可以用环境变量注入的 access token，或者本地缓存的有效 token，不需要每次走完整的授权流程；Streamable HTTP 传输是远程调用，必须每次请求携带 Authorization 头的 token，还要做会话管理、限流、超时控制，防止恶意请求 $资料2$ 。我会把传输层无关的逻辑封装成统一的组件，只把传输层的元数据提取做成适配器，避免重复代码。

面试官：你提到用了 SLF4J、Micrometer、OpenTelemetry 这些依赖，会不会让 MCP Server 变的很重？有没有什么容易踩坑的细节？

候选人：这些依赖都是可选的，比如如果不需要分布式追踪，就可以不引入 OpenTelemetry 的相关依赖，日志用 SLF4J 的话可以对接不同的实现（Logback、Log4j2 等），不会绑定具体的后端，不会显著增加包体积。容易踩坑的点主要有几个：第一，stdio 传输的日志绝对不能写 stdout，否则会破坏 JSON-RPC 通信，这个很多开发者一开始会忽略；第二，异步场景如果不透传 correlation ID 和 trace 上下文，会导致日志和追踪链路断裂，完全没法排查问题；第三，OAuth 2.1 的 token 不能明文存储在日志、数据库或者客户端本地，必须用安全的方式存储；第四，绝对不能信任模型传入的参数，JSON Schema 校验必须在服务端执行，不能依赖 Client 传的 schema；第五，审计日志必须对敏感字段脱敏，不能泄露用户隐私和业务敏感信息。

面试官点评

考察点：本题核心考察候选人对 MCP 工程化落地的综合能力，不是单纯的概念记忆。首先考察对 MCP 协议细节的掌握，比如 stdio 传输的日志输出规则、JSON Schema 的校验责任方、OAuth 2.1 的规范要求；其次考察分布式系统可观测性的落地能力，知道如何把日志、指标、追踪和 MCP 的调用链路结合，处理异步、跨进程的上下文透传；最后考察安全工程能力，理解 MCP 的安全边界，知道不能默认 AI 应用可信，要做服务端校验、细粒度授权、审计脱敏。
合格回答：能清晰分层设计可观测、安全、校验三个模块，知道 stdio 传输日志不能写 stdout，知道 OAuth 2.1 需要做细粒度授权，知道 JSON Schema 是服务端强制校验，能说出基本的异常处理逻辑。
加分项：能说出 W3C 标准的 trace 上下文透传方案，知道 Reactor 异步上下文的传播方式，了解 OAuth 2.1 的 PKCE 要求，能区分 stdio 和 HTTP 传输下的实现差异，能说出审计日志脱敏、敏感信息不落盘等合规要求。

总结

MCP 作为连接 AI 应用和外部能力的协议，工程化落地不能只关注协议本身的能力定义，还需要结合可观测性、安全合规、参数校验等通用工程实践。同时要特别注意 MCP 场景的特殊性：比如 stdio 传输的通信通道隔离、AI 应用传入参数的不可信性、用户级授权的细粒度要求，这些是和其他后端服务开发不同的关键注意点。只有把协议规范和工程实践结合，才能搭建出稳定、安全、可排查的 MCP 服务。

参考资料

MCP Java SDK | https://github.com/modelcontextprotocol/java-sdk
MCP 基础知识
Overview | https://modelcontextprotocol.io/specification/2026-07-28/basic
Authorization | https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization