MCP 面试高频考点：企业内网统一管理多个 MCP Server，Resources、OAuth 2.1 和 JSON Schema 怎么配合

面试场景

这是一场偏工程落地的 MCP 面试，候选人有后端和企业平台开发经验，应聘 AI 应用平台 / MCP 基础设施方向岗位。面试官没有从概念定义开始，而是直接给出一个常见企业需求：公司内网已经上线多个 MCP Server，分别接入文档库、工单系统、代码仓库、运维平台和知识库，现在希望统一接入、统一鉴权、统一资源发现，并避免客户端随意直连带来的权限混乱和运维风险。

基础问题：先做架构分层，不要一上来就写代码

面试官：如果让你设计企业内网统一管理多个 MCP Server 的方案，你会先怎么拆职责？Resources、OAuth 2.1、JSON Schema 各自解决什么问题？

候选人：我的结论是先做"三层分工"，而不是把所有能力都堆到一个网关里。

第一层是统一接入与传输层。多个 MCP Server 部署在内网不同节点，Host 里的 MCP Client 不应该逐个维护地址、凭据和兼容逻辑，而是通过统一入口访问。远程场景适合使用 Streamable HTTP；如果是本机受控子进程，才考虑 stdio $资料3$ 。

第二层是授权边界层 ，核心用 OAuth 2.1。这里的重点不是"用户登录过就行"，而是每个请求都要校验 access token 是否有效、是否是发给当前 MCP Server 的、audience 是否匹配；校验失败必须按 OAuth 2.1 错误处理返回 401 $资料1$ 。同时，客户端请求 token 时必须显式带上 resource 参数，明确目标资源，避免一个 token 被拿去访问别的服务 $资料2$ 。

第三层是能力暴露层，这里要区分 Tools、Resources、Prompts。只读上下文，比如文档片段、工单详情、代码文件元数据、系统配置说明，应该设计成 Resources，由 URI 标识；有副作用的动作，比如创建工单、重启服务、提交变更，才设计成 Tools；可复用的人机协作模板放在 Prompts $资料3$ 。JSON Schema 不是只给模型看的说明书，而是 Tools 入参、Resources 返回结构、错误响应和平台侧校验的共同契约。

面试官：也就是说，你不会把"查文档"做成 Tool？

候选人：不会优先这么做。如果目标是提供可读取上下文，Resources 更符合语义；Tool 更适合模型主动执行操作。把只读资料强行做成 Tool，会让调用链、权限审计和缓存策略都变复杂 $资料3$ 。但如果检索过程本身需要复杂筛选、重排、多条件组合，我会保留一个检索型 Tool 来发现 Resource URI，再由客户端按 URI 读取 Resource 内容，而不是让 Tool 直接返回大块不可控文本。

第一轮追问：统一入口怎么做，才能不把 OAuth 做成"伪单点登录"

面试官：你提到统一入口。很多团队会放一个 API 网关，然后把用户 token 原样转发给后端 MCP Server。这样做有什么问题？

候选人 ：这是一个很典型的坑。我的结论是：MCP Server 不能接受和透传不属于自己的 token。

规范里明确要求，MCP Server 作为 OAuth 2.1 Resource Server，必须校验 token 是授权服务器专门发给自己的，并且只接受对自己资源有效的 token；不能接受或中转其他 token $资料1$ 。如果 MCP Server 还要调用上游 API，它可以作为 OAuth Client 去拿上游的另一个 token，但绝不能把从 MCP Client 收到的 token 直接透传给上游 $资料2$ 。

所以在企业内网方案里，统一入口不能只是"拆路径转发 + 原 token 透传"。更稳妥的做法是：

企业统一身份提供方作为 Authorization Server；
MCP Client 在获取 token 时使用 RFC 8707 的 resource 参数，明确目标是哪个 MCP Server $资料2$ ；
每个 MCP Server 只信任 audience 指向自己的 token；
网关负责传输路由、TLS、限流、审计，不替代业务 MCP Server 做细粒度资源授权；
如果网关需要代表系统访问后端受控服务，它拿的是自己到后端的服务身份 token，而不是复用用户 bearer token。

面试官：如果客户端配置错了，拿了文档库的 token 去调用运维平台呢？

候选人：这种请求必须在运维平台侧被拒绝。因为规范要求 token 必须绑定目标资源，服务端必须验证 audience，无效或过期 token 返回 401 $资料1$ 。平台层还可以在发现阶段就把每个 MCP Server 对应的 resource identifier、能力清单、OAuth 元数据下发给客户端，减少配错概率；但最终拒绝权必须在服务端，不能相信客户端自觉。

第二轮追问：Resources 和 JSON Schema 怎么协作，避免"能发现但不能用"

面试官：再往能力层走。企业里经常出现这种情况：客户端能连上 MCP Server，但不知道有哪些资源可读、URI 怎么拼、返回字段是什么。你怎么设计？

候选人：我会把"资源发现"和"资源读取"分开。

首先，Resources 是上下文入口，必须有稳定 URI。比如： - mcp://docs.intranet/policy/{docId} - mcp://ticket/system/{ticketId} - mcp://repo/{repoId}/file/{path} - mcp://runbook/{env}/{service}

这些 URI 不应该让模型或客户端自由拼接后盲猜。平台需要提供可枚举的目录型 Resource，或者提供受控的检索 Tool，返回合法 URI 及其元数据。

其次，JSON Schema 在这里承担三个职责：

约束 Tool 输入：例如检索文档的 Tool 需要校验关键词、部门、文档类型、时间范围，不能放任任意字符串拼 SQL 或路径 $资料3$ ；
描述 Resource 返回结构：让客户端知道读取某个 Resource 后会拿到哪些字段，比如标题、正文片段、更新时间、来源、权限标签；
统一错误模型：例如未授权、资源不存在、版本冲突、敏感字段脱敏后的提示，都应有稳定结构，方便 Host 展示和排错。

这里我会特别强调一点：Tool 参数上的 JSON Schema 只是结构约束，不能代替服务端授权和输入校验。文件路径、URL、资源标识符这些值即使"长得合法"，服务端也必须再次校验范围，不能因为请求来自 AI 应用就默认可信 $资料3$ 。

面试官：能给一个版本无关的接口设计示例吗？不要写不确定的 SDK 细节。

候选人：可以。我用接口契约来表达，不绑定具体 SDK 版本。

一个文档 MCP Server 可以这样设计：

Resource：mcp://docs/policy/{docId}
作用：读取指定制度文档正文与元数据
返回字段 JSON Schema 约束：docId、title、version、updatedAt、sections[]、sourceUri、classification
Tool：search_policy_resources
作用：按条件检索可访问的政策文档 Resource URI
输入 Schema：
- keyword: string
- department: string，可选
- includeArchived: boolean，默认 false
输出 Schema：
- resources[]，每项包含 uri、title、snippet、updatedAt
Prompt：summarize_policy_for_onboarding
作用：生成面向新员工的制度解读模板，但不直接执行高风险操作

客户端流程是：先调用检索 Tool 获得合法 Resource URI，再按 URI 读取 Resource，最后把可信的上下文交给 Host。这样既保留了模型主动发现的灵活性，又避免了让 Tool 直接返回未经约束的大段文本。

第三轮追问：异常、审计和边界，方案什么时候不适用

面试官：如果出现异常呢？比如 token 快过期、Resource 不存在、Tool 入参被注入恶意路径、某个后端 MCP Server 超时。

候选人：要分层处理，不能把所有异常都抛成"调用失败"。

第一类是鉴权异常。token 无效、过期、audience 不匹配，必须返回 401，按 OAuth 2.1 规范处理 $资料1$ 。客户端不要缓存错误 token，也不能把发给 A 服务的 token 发给 B 服务 $资料1$ 。如果支持 refresh token，刷新流程应由客户端和授权服务器按标准完成，业务 Server 不负责"帮用户续票"。

第二类是资源异常。Resource 不存在、版本已归档、用户无权限读取某一段内容，应返回结构化错误，并在审计日志中记录谁在什么时间访问了哪个资源、结果是什么；敏感字段必须脱敏，凭据不能出现在日志、Tool 返回值或模型上下文里 $资料3$ 。

第三类是输入攻击。Tool 参数哪怕通过了 JSON Schema，服务端也要做路径约束、URL 白名单、SQL 参数化、Shell 禁用等校验。因为 schema 只能证明字段类型和基本结构，不能证明业务安全 $资料3$ 。

第四类是可用性异常。多个后端 Server 性能不一致时，统一入口要做超时、限流和熔断，但具体阈值不能拍脑袋，要结合业务 SLA、风险和压测结果确定。对只读 Resource 可以做受控缓存；对 Tools，尤其是有副作用的运维操作，不能盲目重试。

面试官：这个方案的适用边界是什么？有什么容易踩坑的取舍？

候选人 ：它适合企业内网、多个远程 MCP Server、需要统一身份与资源治理的场景。如果只是本地单机插件，由 Host 直接启动 stdio 子进程，没必要上完整 OAuth 2.1 资源隔离 $资料3$ 。

关键取舍有三个：

网关做路由，不做越权代理。网关能提升接入一致性，但不能替代每个 MCP Server 做 audience 校验和细粒度授权，否则会退化成"一个 token 打全网"。
Resources 优先承载只读上下文，Tool 负责动作和发现。这会让 URI 设计和返回 schema 更规范，但前期建模成本更高。
JSON Schema 是契约，不是安全边界。它能提升可用性和开发效率，但服务端必须独立做授权与输入校验。

一个很容易踩坑的细节是：很多团队在统一接入时会做"token exchange"但忘了校验目标 resource，结果文档服务拿到的 token 也能访问运维服务。规范明确要求客户端请求 token 时带 resource 参数，服务端也必须验证 token 是发给自己的 $资料1$ $资料2$ 。这一步漏掉，统一管理就会变成统一风险。

面试官点评

考察点：这组问题主要看候选人是否理解 MCP 的客户端---服务端架构、三类能力的语义边界，以及远程部署时 OAuth 2.1、资源模型和结构校验如何协同，而不是只会背 Tools/Resources/Prompts 定义。

合格回答 应包含以下几点： - 能区分 Tools、Resources、Prompts 的使用场景，不把只读上下文全部做成 Tool $资料3$ ； - 知道远程 MCP Server 需要逐请求授权检查，不能只看登录态 $资料3$ ； - 理解 MCP Server 作为 OAuth 2.1 Resource Server 必须验证 token 有效性和 audience，失败返回 401 $资料1$ ； - 知道客户端必须使用 resource 参数绑定目标资源，服务端不能接受或透传不属于自己的 token $资料1$ $资料2$ ； - 明确 JSON Schema 只是结构约束，不能替代服务端校验和授权 $资料3$ 。

加分项： - 能给出"检索 Tool 返回 Resource URI，再读取 Resource"的可落地协作模式； - 能说明网关与后端 MCP Server 的授权边界，不把网关做成万能代持； - 能主动提到审计、脱敏、异常分类、缓存与重试边界，以及方案适用范围。

总结

企业内网统一管理多个 MCP Server，不是简单搭一个反向代理，而是要同时解决怎么连、怎么认、怎么读、怎么控四个问题。OAuth 2.1 负责把 token 严格绑定到目标服务和资源，防止越权横向移动；Resources 负责以稳定 URI 暴露只读上下文，避免把所有能力都塞进有副作用的 Tool；JSON Schema 负责把入参、返回和错误变成可校验、可发现、可审计的契约。真正容易出错的地方，往往不是协议字段怎么写，而是有没有守住每个服务端的授权边界、有没有把模型输入当作不可信数据、有没有把统一接入做成统一风险入口。

参考资料

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