You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and did not find a duplicate.
I am describing a concrete problem or use case, not just a vague idea.
Area
apps/server
Problem or use case
In headless deployments (for example npx t3 serve, web-only or mobile-only control with no Electron desktop runtime in the environment), the built-in browser/preview MCP tools are still injected into every provider session. This costs ~4K tokens of tool context per session, and every browser call fails with PreviewAutomationNoAvailableHostError because no automation host can ever be connected. Agents routinely probe the preview tools once or twice before giving up, burning a turn and tokens on a browser that structurally cannot exist.
Host availability is knowable: the desktop runtime registers with the server over WebSocket, and the preview automation broker already tracks connected hosts per environmentId (apps/server/src/mcp/PreviewAutomationBroker.ts).
Proposed solution
At provider session start, check whether any automation host is connected in the environment before issuing the MCP credential / configuring mcpServers for that session. If no host is present, skip the injection entirely — no credential, no tool list, no developer instructions. The check is a few lines: McpSessionRegistry.issue (apps/server/src/mcp/McpSessionRegistry.ts) or prepareMcpSession (apps/server/src/provider/Layers/ProviderService.ts) consults the broker's connected-host map. Adapters already tolerate a session without MCP config.
This complements #4150 (a manual opt-out for users who want a different browser MCP even with a desktop host): this change removes the tools automatically in environments where they can never work, with no user action.
Why this matters
Headless and mobile-first users currently pay token and latency costs for tools that always fail. Removing them makes agent behavior more predictable (no probing of a nonexistent browser) and reduces per-session context. Web/mobile clients of desktop-hosted servers are unaffected — the environment still has a host, so the tools stay.
Smallest useful scope
One guard in the credential-issuance path: no host connected in this environment at session start → skip MCP injection. No UI, no settings, no new CLI flags.
Alternatives considered
Dynamic MCP tool list (notifications/tools/list_changed) that adds/removes the preview toolkit as hosts connect/disconnect. More correct, but tool-list churn mid-session is a surprise for models and much heavier.
Gating by client surface (web/mobile). Wrong: a remote web/mobile client may be viewing a desktop-hosted server, and those sessions legitimately need the tools.
Status quo: rely on the runtime error and the Codex probe-once instructions. Works, but the ~4K token overhead and probing turns remain.
Risks or tradeoffs
A host may connect mid-session (desktop opens after the agent started); that session simply won't get the tools, which equals today's worst case, and new sessions pick them up.
Multi-environment edge cases: the check must be scoped to the environment the session runs in, matching how the broker routes requests.
This discussion was converted from issue #5266 on August 15, 2026 09:47.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Before submitting
Area
apps/server
Problem or use case
In headless deployments (for example
npx t3 serve, web-only or mobile-only control with no Electron desktop runtime in the environment), the built-in browser/preview MCP tools are still injected into every provider session. This costs ~4K tokens of tool context per session, and every browser call fails withPreviewAutomationNoAvailableHostErrorbecause no automation host can ever be connected. Agents routinely probe the preview tools once or twice before giving up, burning a turn and tokens on a browser that structurally cannot exist.Host availability is knowable: the desktop runtime registers with the server over WebSocket, and the preview automation broker already tracks connected hosts per
environmentId(apps/server/src/mcp/PreviewAutomationBroker.ts).Proposed solution
At provider session start, check whether any automation host is connected in the environment before issuing the MCP credential / configuring
mcpServersfor that session. If no host is present, skip the injection entirely — no credential, no tool list, no developer instructions. The check is a few lines:McpSessionRegistry.issue(apps/server/src/mcp/McpSessionRegistry.ts) orprepareMcpSession(apps/server/src/provider/Layers/ProviderService.ts) consults the broker's connected-host map. Adapters already tolerate a session without MCP config.This complements #4150 (a manual opt-out for users who want a different browser MCP even with a desktop host): this change removes the tools automatically in environments where they can never work, with no user action.
Why this matters
Headless and mobile-first users currently pay token and latency costs for tools that always fail. Removing them makes agent behavior more predictable (no probing of a nonexistent browser) and reduces per-session context. Web/mobile clients of desktop-hosted servers are unaffected — the environment still has a host, so the tools stay.
Smallest useful scope
One guard in the credential-issuance path: no host connected in this environment at session start → skip MCP injection. No UI, no settings, no new CLI flags.
Alternatives considered
notifications/tools/list_changed) that adds/removes the preview toolkit as hosts connect/disconnect. More correct, but tool-list churn mid-session is a surprise for models and much heavier.Risks or tradeoffs
Examples or references
Contribution
All reactions