提案 SEP-1306: Binary Mode Elicitation for File Uploads
https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1306
真实用例：用于医疗保健计划分析的文档上传
我是正在构建医疗保健计划分析平台 (PlanVantage) 的 MCP 服务器作者。我们的 MCP 服务器允许 AI 助手上传福利计划 PDF，以便自动提取计划设计、费率和缴款信息。后端 API 是一个简单的多部分表单 POST。
当前的问题
- Stdio 传输（本地 MCP 服务器）： 完美运行。我们的工具接受一个
file_path，服务器从磁盘读取文件，并通过多部分表单上传。用户说"上传此目录中的所有 PDF"，它就能正常工作------每个文件只需一次工具调用，快速且可靠。 - 远程 HTTP+SSE 传输（OAuth 连接器）： 对于文件上传来说基本无法使用。MCP 服务器无法访问客户端的文件系统，因此模型退而求其次，读取每个 PDF，进行 base64 编码，并将其作为字符串工具参数传递。对于典型的 2-5MB 的福利 PDF，这会导致：
- 二进制数据大量消耗上下文窗口
- 对于本应是简单批量上传的操作，需要 50-100 多次工具调用
- 频繁失败、输出损坏和超时
- 糟糕的用户体验
这迫使 MCP 服务器作者面临的权衡
| 特性 | Stdio (本地) | 远程 HTTP+OAuth |
|---|---|---|
| 文件上传 | 运行良好 | 无法使用 |
| 安装体验 | 需要 Node.js，配置编辑 | 无缝的一键 OAuth |
| 最适合 | 技术用户 | 非技术最终用户 |
我们无法同时拥有可靠的文件处理和无缝的安装体验。我们的客户是福利顾问和人力资源专业人士------要求他们安装 Node.js 并编辑 JSON 配置文件是行不通的。但远程连接器无法处理他们的核心工作流程（上传计划文档）。
为什么 SEP-1306 能解决这个问题
提议的客户端中介上传流程完全正确。客户端（Claude Desktop）已经拥有文件系统访问权限，并且已经提示用户批准工具调用------将其扩展为代理文件传输到服务器提供的上传端点，将完全弥合这一差距。我们的服务器将提供上传 URL，客户端将处理文件读取和传输，而模型的上下文窗口则保持干净。
这是我们构建生产级 MCP 集成时遇到的最大限制。非常希望看到这个提案取得进展。