MCP 面试高频考点：本地文件访问 Server 怎么设计才安全可用？

MCP 面试高频考点本地文件访问 Server 怎么设计才安全可用面试场景面试官我们在做一个本地 AI 助手希望通过 MCP 让模型安全读取本机文件同时避免路径穿越、误读敏感文件、大文件拖垮进程以及超时重试带来的重复读取问题。如果让你负责这个 MCP Server你会怎么设计候选人我的结论是这个场景优先用Resources 承载只读文件访问把有副作用的操作如写入、删除放到 Tools 并加确认传输用 stdio 适配本地子进程启动在 Server 侧做严格的路径校验、大小限制、超时控制、幂等读取和审计日志而不是把安全寄托在客户端或模型身上。MCP 本身是客户端—服务端架构Host 里的 MCP Client 和 Server 建立会话消息基于 JSON-RPC本地启动子进程时 stdio 是最自然的选择调试日志必须写到 stderr不能污染 stdout 的协议通道 [资料1]。基础问题为什么选 Resources不把读文件全做成 Tool面试官先不展开安全。你为什么说只读文件优先用 Resources候选人因为语义不同。MCP Server 常见能力分三类Tools 是模型可发起调用的操作Resources 是由 URI 标识、可被应用读取的上下文Prompts 是用户可显式选择的模板化消息或工作流 [资料1]。读文件本质上是“获取上下文”如果把纯读取都做成 Tool会让模型把“查资料”当成“执行动作”不利于 Host 做上下文管理也违背“不要把只读资料强行设计成有副作用的 Tool”的原则 [资料1]。具体到文件访问我会这样分 -Resources暴露可读取的文件或目录摘要URI 形如file://allowed/path或应用自定义 scheme由 Host 决定何时把哪些资源纳入上下文。Resources 是 application-drivenHost 可以根据用户当前打开目录、工作区或显式授权范围决定如何组合上下文 [资料3]。 -Tools只保留必要操作例如“列出允许目录下的文件”“读取文件片段”“搜索文件内容”。这些虽然也可能只读但它们更像“发起一次检索动作”适合 Tool写入、删除、移动等高风险操作必须是 Tool而且要在执行前让用户确认影响范围 [资料1]。面试官那 Resources 不就是直接把文件内容喂给模型吗候选人不是。Resources 提供的是“可读取的上下文能力”不等于无条件把整个文件塞进上下文。Server 可以返回元数据、摘要、分块信息或者只提供片段读取接口对应的资源表示真正进入模型的内容量由 Host 和策略控制。MCP 的设计原则强调 Server 聚焦单一职责、易于构建和组合Host 负责复杂编排 [资料4]所以文件 Server 应该专注“安全暴露文件能力”不要在 Server 里硬编码整套 RAG 流程。第一轮追问安全边界怎么画路径校验放哪一层面试官好能力划分清楚了。那你说的“安全访问”具体怎么做很多人会说做个 schema 校验就够了。候选人结论先说参数 schema 只能做结构约束不能替代服务端校验和授权。MCP 明确要求 Server 必须把模型传入的文本视为不可信输入对文件路径、URL、资源标识符等做约束不能因为请求来自 AI 应用就默认可信 [资料1]。我的文件 Server 会做几层控制 1.根目录白名单启动时配置允许访问的根目录例如用户明确授权的工作区。所有资源 URI 和 Tool 参数最终都要解析到这些根目录下。 2.路径规范化对用户或模型传入的路径做规范化解析.、..、符号链接再判断最终真实路径是否仍在白名单内防止路径穿越。 3.敏感路径拒绝对系统目录、凭据目录、隐藏配置目录做默认拒绝除非用户显式授权这里的规则要可配置但默认保守。 4.文件类型与大小限制二进制文件、超大文件不直接返回全文可返回元数据文本文件读取也要限制单次返回字节数或行数。 5.用户确认高风险操作写入、覆盖、删除等操作必须展示具体影响范围并要求用户确认不能让模型直接执行不可逆动作 [资料1]。 6.审计日志记录谁在什么时间访问了哪个资源、调用了哪个 Tool、范围和结果状态敏感字段脱敏凭据绝不能出现在日志、Tool 返回值或模型上下文中 [资料1]。面试官如果 Host 已经登录了本地用户Server 能不能直接信任候选人不能。即使是本地进程Server 也要按“每次请求校验授权”的思路设计。远程 MCP Server 必须对每次请求做授权检查不能只判断是否登录本地场景虽然没有网络认证但同样不能假设调用方天然善意因为模型可能生成误操作客户端也可能有 bug [资料1]。本地文件访问的授权核心是“用户授权范围”而不是“进程是否本地启动”。第二轮追问超时、重试、幂等怎么和 Resources/Tools 配合面试官接下来问工程问题。文件读取可能遇到大文件、磁盘慢、文件被占用、权限不足。你怎么处理超时重试会不会导致重复读甚至重复写候选人我的结论是超时要分层设置重试只用于安全的幂等读取写操作默认不自动重试并且所有操作都要明确幂等语义。先说超时。MCP 通信基于 JSON-RPC本地 stdio 传输适合 Host 启动子进程但这不意味着没有超时问题大文件读取、磁盘 I/O 阻塞、符号链接循环、网络盘挂载断开都可能卡住。超时值不能拍脑袋固定成某个数字应该结合业务 SLA、文件大小上限和压测结果确定例如读取小文本、列目录、读元数据可以较短读取大文件片段可以稍长但都要有上限避免 Server 长时间占住 Host 的会话。然后是重试与幂等 -Resources 读取天然适合幂等读取同一个 URI、同一个范围结果不应改变 Server 状态因此网络抖动、超时断开后可以重试。但要注意“读取过程中文件被修改”的一致性问题重试时应带上版本标识或修改时间避免把新旧片段拼错。 -只读 Tool例如列目录、搜索文本、按块读取应设计成幂等输入里可以包含limit、offset、chunk_id、if_modified_since等参数让重试结果可预测。 -写操作 Tool例如创建文件、追加内容、删除文件不能简单按“调用失败就重试”处理。我会要求写操作具备幂等键或明确的条件语义比如“仅当文件不存在时创建”“写入到指定版本号之后才覆盖”没有幂等保障的写操作默认不自动重试而是把错误返回给 Host由用户决定是否继续。 -异常分类权限不足、路径越界、文件不存在这类确定性错误不要重试I/O 超时、临时锁冲突、子进程响应中断这类可恢复错误才考虑有限重试重试次数和退避策略同样要根据风险和压测确定不能盲目无限重试。面试官如果读取大文件超时了你是让 Host 重新拉整个文件还是支持分块候选人我会设计成分块 Resources 或分块 Tool而不是鼓励一次读完整文件。RAG 实践里也强调切块要保留语义完整性同时避免不相关内容占上下文检索结果要保留来源元数据 [资料1]。文件 Server 虽然不一定要内置完整 RAG 索引但可以提供 - 文件元数据 Resource路径、大小、修改时间、MIME 类型、摘要。 - 分块内容 Resource/Tool按行区间、字节区间或语义块读取并返回块 ID、来源路径、偏移量。 - 搜索 Tool在允许目录内做关键词或简单索引搜索返回匹配片段和来源。这样 Host 在编排时可以先拿元数据判断是否值得读再按需取块既降低超时概率也减少上下文浪费。方案设计一个可落地的本地文件 MCP Server 轮廓面试官你能画一下接口轮廓吗不要写猜出来的 API就讲设计。候选人可以。基于 Python SDK 的基本形态Server 可以用MCPServer初始化并用装饰器注册 Tool 和 Resource公开示例里展示了mcp.tool()和mcp.resource(uri://{param})的用法Resource 通过带参数的 URI 模板暴露内容 [资料2]。我的设计会保持这种简单风格但把安全和稳定性逻辑放在函数内部的校验层。接口上大致分三类 1.目录与元数据 Resource- 例如workspace://meta/{path}返回规范化后的真实路径、大小、修改时间、是否目录、是否可读。 - 所有path参数在内部先做白名单根目录校验越界直接返回明确错误不泄露其他目录存在性细节。 2.文件内容 Resource- 例如workspace://file/{path}?chunkid或workspace://file/{path}#linesstart-end只返回授权范围内的文本片段和来源元数据。 - 单次返回大小受限超大文件默认不提供全文 URI只提供分块入口。 3.必要 Tools-list_directory(path)列目录返回子项元数据。 -search_text(path, query, limit)在授权目录下搜索返回片段和位置。 -write_file(path, content, expected_versionNone)高风险写操作要求用户确认带版本条件实现幂等更新。实现上要注意一个容易踩坑的细节stdio 模式下 Server 的 stdout 只能输出协议消息调试日志必须写到 stderr否则日志会破坏 JSON-RPC 通信 [资料1]。很多本地调试时“连上了但解析失败”的问题都是因为把 print 打到了 stdout。另外本地 Server 虽然用 stdio但如果未来要支持远程访问就需要切到 Streamable HTTP并补上认证、授权、会话管理、限流和超时 [资料1]。所以我会把“传输层”和“文件访问核心逻辑”解耦核心逻辑只接收已解析的请求对象和授权上下文不直接依赖 stdio 或 HTTP。面试官异常处理和可观测性呢候选人我会把错误分成几类参数错误、越权错误、文件不存在、I/O 错误、超时、内部错误。返回给 Client 的错误信息要足够让 Host 提示用户但不能泄露敏感路径全貌或系统细节。审计日志记录访问的资源范围、Tool 名称、结果状态、耗时、是否命中重试敏感内容本身不记录。超时发生时要主动取消读取任务避免文件句柄泄漏重试时保留同一个请求 ID 或幂等键便于排障时追踪一次用户意图对应的多次尝试。面试官点评考察点这道题表面上是在问“怎么写一个文件 MCP Server”实际考察四个层面 1. 是否理解 MCP 的客户端—服务端架构、JSON-RPC 消息基础以及本地 stdio 与远程 HTTP 的适用边界 [资料1]。 2. 是否能根据语义正确区分 Tools、Resources、Prompts而不是把所有能力都塞进 Tool [资料1]。 3. 是否具备安全意识知道 schema 校验不等于授权路径、资源标识符都要做服务端校验 [资料1]。 4. 是否有工程化思维能把超时、重试、幂等、分块读取、日志与可观测性落到具体接口设计上。合格回答应包含 - 明确选择 Resources 承载只读文件上下文Tool 承载动作型能力。 - 给出路径白名单、规范化、敏感路径拒绝、大小限制、高风险操作确认等安全措施。 - 说明 stdio 下日志必须走 stderr不能污染协议输出。 - 解释只读操作可重试、写操作需要幂等保障超时和重试策略需结合 SLA 与压测确定。加分项包括 - 能把文件访问和 RAG 的切块、来源元数据思想结合但不把 Server 做成臃肿的全流程系统。 - 能提出分块读取、版本号/修改时间校验、错误分类和审计日志体现生产可用性。 - 能说清适用边界本地单用户工作区访问适合 stdio跨机器、多用户场景必须补认证授权、限流和会话管理不能直接照搬本地方案 [资料1]。总结做本地文件访问 MCP Server核心不是“把读文件函数暴露出去”而是在 MCP 的能力模型里做对分工Resources 负责安全、可组合的只读上下文Tools 负责有明确输入输出的动作stdio 负责本地高效通信。安全上永远把模型和客户端输入视为不可信在 Server 侧做路径、授权和风险控制工程上要通过分块、超时、幂等和可观测性避免大文件、异常 I/O 和重试把本地助手拖垮。一个容易踩坑的细节是 stdio 下误用 stdout 打日志这会直接破坏协议通信另一个常见取舍是不要为了“方便”把所有能力都做成 Tool否则会模糊上下文与动作的边界增加 Host 编排和安全治理的成本。参考资料MCP 基础知识MCP Python SDKhttps://github.com/modelcontextprotocol/python-sdkResourceshttps://modelcontextprotocol.io/specification/2026-07-28/server/resourcesArchitecturehttps://modelcontextprotocol.io/specification/2026-07-28/architecture