拆解 Claude Code 向 osFoundry 提交 App 的 MCP 工具：schema、幂等 Key 和等待人工审批的成本

作者用 Python 写了个替代客户端，实测 Claude Code 通过 propose_room_snippet_app 向 osFoundry 提交小应用的完整链路：schema 能拦住什么、拦不住什么，一次提案要烧多少 token，以及幂等 Key 如何把重试导致的重复审批卡从 74 个降到 0。还对比了四种轮询策略，结论是交互式会话里最省钱的等待方式是干脆不轮询。

工具契约：schema 管一半，服务器管另一半

• propose_room_snippet_app 要求 room_id、name、files 和 idempotency_key 四个必填字段，顶层 additionalProperties: false，模型编造 visibility 之类的字段会直接报 schema 错误，而不是被静默忽略
• 但 files 的 key 路径没法用 JSON Schema 约束，需要 propertyNames 加 pattern，而拒绝 .. 的正则在路径归一化后容易失效，所以「必须存在 src/App.tsx」「路径必须是安全相对路径」这两条规则只能由服务器执行
• 作者用 jsonschema 对着线上 inputSchema 验证：8 类错误调用里，4 类被公开 schema 拦下，另外 4 类（缺 App.tsx、绝对路径、.. 路径、反斜杠路径）需要服务器规则
• 给自建客户端的建议：调用前先做同样的本地校验，被拒的提案不仅浪费一次往返，还要重新输出全部文件内容

一次提案到底多大

• 示例是一个 standup 计时器：App.tsx 63 行加 styles.css 14 行，源码 3067 字节，JSON-RPC 信封额外增加 11.9% 的转义开销
• 真正的成本不在信封，而在 files 里的每个字节都是模型输出——Claude Code 先写文件，再作为工具参数写一遍。两文件提案约 1100 token，21 个文件的 App 达到 14143 token（用 tiktoken cl100k 估算）
• schema 没有给 files 设字节上限，实际瓶颈是审批人：审批卡会完整展示每个文件，没人愿意在一张卡里读 21 个文件
• 大项目应该改用 propose_room_repo_app，它指向 GitNest 仓库的固定版本，审批卡只放仓库链接而不是贴代码

审批门与幂等 Key 的实测数据

• 提案只有在 owner 审批后才会出现在 Room 的 app launcher，pending 状态的提案任何成员都打不开——两次模拟中审批前进入 launcher 的数量都是 0
• MCP over HTTP 可能在服务器已处理后丢失响应。模拟 1000 次提案、5% 响应丢失率：每次重试用新 UUID 会产生 74 张重复审批卡；改用内容派生 Key（snip- + sha256(room_id, name, files) 前 32 位）后重复为 0
• 内容派生 Key 的好处是有意修改文件会自然生成新 Key 和新卡片，这正是想要的行为；schema 里 Key 最少 8 字符则挡住了 "1" 这种敷衍值

怎么等 owner 审批最划算

• initialize 返回 listChanged: false，没有任何推送机制，客户端只能三选一：让用户审批后口头告知、轮询 read_room_app_status、或监听 poll_resource_events 的 room 事件
• 按人工审批中位数 6 分钟模拟 2000 次：每 5 秒轮询一次延迟最低（p50 2.4 秒）但平均要 112 次调用，每次调用都是一轮消耗输出 token 的模型回合；30 秒固定间隔 19 次调用、最坏延迟 28 秒；5 秒起步 1.5 倍退避封顶 120 秒只要 11 次调用，p95 延迟 111 秒
• 2000 次里有 14 次审批超过一小时，所有策略都一样会放弃
• 交互式会话的最优解是零次调用：结束回合让用户去 Connected → Needs your approval 审批并告知，之后只调一次 list_room_apps 确认。只有 Claude Code 在等待期间还有别的活干时，轮询才划算