MCP 面试高频考点企业内网统一管理多个 MCP ServerResources、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 ServerMCP 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 可以这样设计Resourcemcp://docs/policy/{docId}作用读取指定制度文档正文与元数据返回字段 JSON Schema 约束docId、title、version、updatedAt、sections[]、sourceUri、classificationToolsearch_policy_resources作用按条件检索可访问的政策文档 Resource URI输入 Schemakeyword: stringdepartment: string可选includeArchived: boolean默认 false输出 Schemaresources[]每项包含uri、title、snippet、updatedAtPromptsummarize_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 暴露只读上下文避免把所有能力都塞进有副作用的 ToolJSON Schema 负责把入参、返回和错误变成可校验、可发现、可审计的契约。真正容易出错的地方往往不是协议字段怎么写而是有没有守住每个服务端的授权边界、有没有把模型输入当作不可信数据、有没有把统一接入做成统一风险入口。参考资料Authorizationhttps://modelcontextprotocol.io/specification/2026-07-28/basic/authorizationAuthorization Security Considerationshttps://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerationsMCP 基础知识MCP Java SDKhttps://github.com/modelcontextprotocol/java-sdk