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 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.
Examples or references
Contribution
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