Browser pane: tabId rejected as missing despite documented "default: the fronted tab" (read_page, javascript_tool)

Summary

The tabId parameter of the Browser pane tools (mcp__Claude_Browser__read_page, mcp__Claude_Browser__javascript_tool, mcp__Claude_Browser__computer) is documented as optional with a fallback: "Tab to act on within the preview context (default: the fronted tab)". In practice, calls without tabId are rejected by input validation before any fallback applies.

Environment

• Windows 11 Pro (10.0.26100), Claude Code 2.1.195
• Browser pane opened via preview_start({ url }) (in-app preview), single tab ("seed"), which is the fronted tab

Repro steps

1. Open the Browser pane: preview_start({ url: "https://youtube.com/..." }) — returns tabId: "seed", navOk: true.
2. Call read_page({ filter: "interactive" }) without tabId.
3. The call fails with:

``
MCP error -32602: Input validation error: Invalid arguments for tool read_page: [
{ "expected": "string", "code": "invalid_type", "path": ["tabId"], "message": "Invalid input: expected string, received undefined" }
]
``

1. Repeat the same call with tabId: "seed" — works correctly.

Reproduced identically on javascript_tool (javascript_exec without tabId fails with the same -32602, succeeds with tabId). The schema description for computer carries the same "default: the fronted tab" wording, so it presumably shares the behavior.

Expected: an omitted tabId falls back to the fronted tab, as the parameter description states.
Actual: validation treats tabId as required (expected string, received undefined) and the call never reaches the fallback.

Impact

Minor but constant friction: every Browser pane call must thread an explicit tabId even in the common single-tab case, and the first call of a session typically burns one round-trip on the validation error before retrying with the id. Either the validator should allow omission (implementing the documented default) or the descriptions should drop the "default: the fronted tab" claim.