Claude in Chrome MCP: add focus_tab / activate_tab tool

Summary

The claude-in-chrome MCP server exposes tools to list, create, navigate, JS-evaluate, and read tabs, but provides no tool to bring a specific tab to the foreground (i.e., make it the active tab in its window, and focus the window). This is the missing inverse of every existing "don't steal focus" request (#25564, #31119, #39600, #39707): there are workflows where the tab MUST be focused for the page to function correctly, and the agent has no way to do that.

Repro: background-tab throttling leaves canvas/iframe pages blank

1. Use mcp__claude-in-chrome__navigate (or tabs_create_mcp) to load an editor / preview page whose canvas iframe runs its boot sequence on requestAnimationFrame or setTimeout.
2. The MCP tab opens in the connected Chrome window but is not the active tab (another tab is in front, or the window is not focused).
3. Chrome's background-tab throttling pauses rAF and severely throttles timers in the background tab, including its iframes. The canvas iframe's init never completes; the canvas stays blank.
4. read_page / browser_snapshot show the iframe as present but empty. javascript_tool confirms the iframe's document.visibilityState is "hidden".
5. As soon as a human clicks the tab in Chrome, the iframe finishes booting in under a second and the canvas renders.

This is reproducible on any page whose first paint depends on rAF/timers in an iframe. Editor and preview surfaces (Figma-style, Canva-style, in-app design canvases, video preview surfaces) are the common cases.

Why current workarounds do not work

• javascript_tool running window.focus() is no-op for background tabs and is blocked cross-context for iframes that are not same-origin with the top frame.
• chrome.tabs.update(tabId, {active: true}) is the correct Chrome API for this, but is only callable from extension code and is not exposed by the MCP server.
• Control_Chrome.list_tabs (separate MCP) returns empty for tabs created by claude-in-chrome, so its switch_to_tab cannot reach them.
• tabs_context_mcp returns metadata but no action verb that activates a tab.
• The only working workaround today is asking the human to click the tab in Chrome, which defeats the automation premise.

Note: this is the inverse of #25564 / #31119 (which ask for backgrounded tab creation). Those requests are valid for headless validation work; the request here is for the opposite, an explicit foreground action that the agent can take when a page actually needs focus to boot. Both should coexist: opt-in foreground, opt-in background, agent decides.

Proposed API

mcp__claude-in-chrome__focus_tab({ tabId })

Internally:

await chrome.tabs.update(tabId, { active: true });
const tab = await chrome.tabs.get(tabId);
await chrome.windows.update(tab.windowId, { focused: true });

Optional focusWindow: boolean (default true) for cases where the agent wants to make the tab active in its window without raising the window itself.

Scoping: limit to tabs in the MCP tab group, matching the existing tabs_close_mcp scope convention from #25564.

Filed by

Automated agent on behalf of a Claude Code user, as a documented workflow blocker after exhausting MCP-only workarounds.