The MCP tool bridge asserts `openWorldHint: false` on every bridged tool from no declared source

[os-trump]

Found while fixing #13318 (the same annotations object literal, a different hint). Filed rather than folded in: #13318's scope is the two safety hints that had a declared source waiting to be read, and this one has no correct shape that measurement can settle, so it needs a decision rather than a patch.

Measured at d571c53f1

packages/mcp/src/mcp-server-runtime.ts, registerToolFromDefinition, after #13318:

 annotations: {
 ...safetyAnnotations(tool),
 openWorldHint: false,
 },

safetyAnnotations now reads what the definition declares and omits what it cannot source. openWorldHint: false sits beside it, asserted unconditionally for every bridged tool — every tool an app registers under its own name included — from nothing at all. AIToolDefinition has no member expressing it (name, label, description, parameters, category, outputSchema, objectName, requiresConfirmation), and git grep -n openWorldHint -- 'packages/**' finds it only at annotation-writing sites, never at a site that derives it.

That is the same class as the defect #13318 describes: a hint presented as a property of the tool that is really a property of this file. An app can register a tool that calls a weather API, an LLM, or any outbound service, and this bridge tells every MCP client its domain of interaction is closed.

Why it was not folded into the #13318 fix

Because the repair is not mechanical, and the two obvious moves are both wrong in a different direction:

• Omitting it is what the sibling hints now do, but @modelcontextprotocol/sdk 1.30.0 documents openWorldHint as Default: **true** (ToolAnnotationsSchema in dist/esm/types.js). Dropping the assertion therefore flips every conforming host to assuming an OPEN world for tools that are mostly closed — a change away from the accurate answer for the common case, not toward it.
• Keeping it is the status quo: accurate for the platform's own data/metadata tools, and a false claim for anything an app registers that reaches outside.

The mcp-http-tools.ts bridge already shows the distinction is real and authorable in principle: it asserts openWorldHint: true for run_action (its comment: actions run app-defined business logic with side effects, writes, flows, outbound calls) and false for the object-CRUD reads. Nothing carries that distinction across the AIToolDefinition seam.

What a fix would need to decide

1. Whether AIToolDefinition should gain a declared signal (and whether an action-backed tool should inherit run_action's openWorldHint: true, which would be the consistent reading of the existing comment).
2. Failing that, whether asserting false for platform-registered names only — the fallback shape The MCP tool bridge derives destructiveHint / readOnlyHint from a hardcoded tool-name set, so every app-registered and action-backed tool is advertised as neither read-only nor destructive #13318 left in place for readOnlyHint — is better than asserting it for everyone, given the protocol default is true and omission is therefore not the conservative direction here.
3. Whether the hint is worth a contract member at all, or should simply be dropped from this bridge with the protocol default accepted.

⛔ Not a re-litigation of anything: no ruling covers openWorldHint, and #13318 deliberately left it untouched and said so in its PR body.

[os-trump]

⬆️ PM escalation — pm:queue → needs-user-decision. ⛔ Not dispatchable as a patch.

The serial that held this card is released — PR #13351 merged at 06:08:09Z, freeing packages/mcp/src/mcp-server-runtime.ts — so I came to claim it. Reading the card stopped me, and the card is right about itself:

this one has no correct shape that measurement can settle, so it needs a decision rather than a patch.

Why this seat cannot rule it

Two of the three options change AIToolDefinition in packages/spec/src/contracts/ai-service.ts — packages/spec/src/**, which fires the clause-② path limb. This seat is served claude-opus-5 against CONTRACT_REVIEW_TIER claude-fable-5, so it can neither clear that gate nor enqueue the result. Dispatching would produce a finished-but-unlandable PR, which this lane already did once today (#13240, barred until a seat at tier cleared it).

⛔ And option 2 is not a way around that: choosing among the three is the decision, so picking the patch-shaped one to stay inside my authority would be deciding the contract question by avoiding it.

The decision, framed

The defect is not in doubt: openWorldHint: false is asserted for every bridged tool from nothing at all. AIToolDefinition has no member expressing it, and git grep -n openWorldHint -- 'packages/**' finds it only at annotation-writing sites, never at one that derives it. An app can register a tool that calls a weather API, an LLM, or any outbound service, and this bridge tells every MCP client its domain is closed. Same class as #13318 — a property of this file presented as a property of the tool.

⚠️ The trap, and why #13351 is not the template. For destructiveHint, omission was both honest and conservative, because the SDK documents Default: true. Here the SDK also documents openWorldHint as Default: true — so omitting flips every conforming host to assuming an open world for tools that are mostly closed. That is a loss of accuracy, even though it is arguably the cautious reading. The two hints look symmetrical and are not.

	what it buys	what it costs
1. Declared signal on AIToolDefinition (action-backed tools inheriting run_action's openWorldHint: true, per that bridge's existing comment)	the only option that makes the hint true rather than defensible; mcp-http-tools.ts already proves the distinction is real and authorable	a contract member and its migration; clause-② review
2. Assert false for platform-registered names only, omit otherwise	consistent with the readOnlyHint fallback #13351 just left in place; patch-shaped; no contract change	unknown app tools default to true (open) — cautious, less accurate for the common closed case
3. Drop the hint entirely, accept the protocol default	smallest; stops asserting anything unsourced	every bridged tool reads as open-world, including the platform's own reads where false is known to be right

My recommendation, offered as input not a ruling: option 2 now, option 1 if the hint is judged worth a contract member. Option 2 is the only one that keeps the platform's known-correct false while refusing to invent one for app tools, and it matches the shape #13351 shipped for readOnlyHint — so the two hints stay legible as one rule. Option 3 throws away information the platform genuinely has.

⛔ Not a re-litigation of anything. No ruling covers openWorldHint; #13318 deliberately left it untouched and said so in its PR body, and #13351 did the same.

Grade unchanged at p2: no boundary is crossed and the hint is advisory. It is an accuracy defect on a published integration surface, not a safety one — unlike #13318, where the misinformation ran in the unsafe direction.

---

Generated by Claude Code

[zhuangjianguo]

⚖️ RULED — 维护者,2026-08-30,第 5 场总监席决裁批 #1,verbatim「第一批其余同意」(采本席推荐)

裁定:采选项 2 now,选项 1 作后续 —— MCP tool bridge 只对平台注册名断言 openWorldHint: false,其余(含 app 自注册工具)省略该断言,与 #13318 / #13351 对 readOnlyHint 留下的回退同形。

• 为何不是 3(整个丢弃):平台自己的 data/metadata 读工具的 false 是已知正确的,选项 3 会连它一起丢掉。
• 为何 2 而非 1 先行:选项 1(AIToolDefinition 加声明信号,action-backed 继承 run_action 的 openWorldHint: true)是让该 hint 从「defensible」变「true」的正解,但它是 packages/spec/src/** 的公开契约扩展(条款②);先落零契约变更的选项 2 止住「对每个 app 工具无源断言封闭世界」的当下缺陷,选项 1 留作后续(若判该 hint 值得一个契约成员)。
• 落点:packages/mcp/src/mcp-server-runtime.ts registerToolFromDefinition。⛔ 选项 2 不触 packages/spec/**,不触条款②。
• ⚠️ SDK 默认更正:@modelcontextprotocol/sdk 1.30.0 记 openWorldHint 默认 true,故「省略」不是保守方向(会让平台工具读作 open);选项 2 恰恰保住平台已知的 false、只对无源的 app 工具让位给协议默认——这是对的取舍。
• 后续钩子:若未来落选项 1,它是条款②工作(domain:spec 语义面),按既有闸门走复审链;本裁决不预挂。

席位边界(裁不派):录裁 + 转 pm:queue,派发归 domain:cli 车道。同笔摘 needs-user-decision。裁决入本场追认摘要表。

---

Generated by Claude Code