探索 MCP 中的文件上传与下载
内容提要
MCP 推出实验性文件传输扩展，使文件可在模型上下文之外直接上传或下载。服务器用 x-mcp-file 标记文件参数，客户端先发送元数据，服务器校验权限后返回上传地址和 requestState，客户端上传后重试工具调用；下载则通过结果中的 _meta 返回地址。该扩展支持凭据控制与完整性校验，目前仍为草案，预计年底稳定。
延伸解读
文件传输为何独立于模型上下文
文章强调，文件字节和上传/下载地址都不进入模型上下文，模型只发起工具调用并拿到结果。这样设计是为了让大文件直接到达目标存储，避免模型读取或处理每个字节。对开发者而言，这意味着文件传输的协调工作由客户端完成，模型无需感知传输细节，有助于降低上下文负担并提升大文件场景的可行性。
上传流程中的两阶段校验
上传并非一次性完成：客户端先发送文件元数据，服务器检查权限和存储配额，通过后返回上传地址和 requestState；客户端上传成功后再携带 requestState 重试工具调用。服务器会验证 requestState、确认重试与原始调用匹配，并向存储服务核实文件大小和类型后才执行工具。这种设计可在传输大文件前发现只读目录等问题，避免无效上传。
凭据控制与重定向限制
由于文件可能传到第三方存储，扩展要求每个上传/下载目标标明 credentials 字段。omit 表示不附带 MCP 凭据，依赖目标自身的预签名授权；include 则仅允许在 MCP 地址路径下或同源 URL 使用 MCP 凭据。客户端还必须拒绝重定向和带 Authorization 头的目标，防止凭据被转发到其他源。这些规则控制凭据去向，但不完全控制文件去向，草案建议主机用允许列表限制 omit 目标。
完整性校验不等于安全
下载完成后，客户端会核对文件字节数与 size，若服务器提供摘要还会计算哈希比对，不匹配则丢弃文件。但文章明确指出，摘要匹配只证明字节与给定哈希一致，并不证明文件安全；服务器仍可能提供有害文件及匹配摘要。因此客户端必须将下载文件视为不可信。这一区分对实现者很重要，避免把完整性校验误当作安全审查。
Q&A
MCP 文件上传扩展目前是什么状态？什么时候会稳定？
该扩展目前仍是实验性草案，没有参考实现，预计在今年年底前最终确定并成为稳定版本。
MCP 文件上传扩展如何标识文件参数？
服务器在工具的输入 schema 中用 x-mcp-file 标记文件参数，客户端据此填充文件信息，模型无需直接处理文件内容。
MCP 文件上传的完整流程是怎样的？
客户端先发送文件元数据调用工具；服务器校验权限和配额后返回 upload_required 结果，包含上传地址和 requestState；客户端上传文件后，用相同参数和 requestState 重试工具调用；服务器验证上传并执行工具。
MCP 文件下载与上传在响应格式上有什么不同？为什么？
下载目标通过工具结果的 _meta 字段返回，因为下载发生在工具完成后，客户端无需重试；上传目标则通过 upload_required 结果返回，因为需要客户端先上传再重试工具调用。
MCP 文件传输中的 credentials 字段有什么作用？
credentials 字段控制客户端是否附带 MCP 凭据：omit 表示不附带，目标需自行授权（如预签名 URL）；include 表示附带，但仅限 MCP 地址下的路径或服务器同源 URL。
MCP 文件下载后如何保证文件完整性？完整性校验能确保文件安全吗？
客户端会检查文件字节数是否与 size 匹配，若服务器提供摘要则计算哈希比对，不匹配则丢弃文件。但摘要匹配只证明字节与哈希一致，不代表文件安全，客户端仍须将下载文件视为不可信。
