stdio MCP servers connect eagerly at session start and stay pinned all session — no lazy/on-demand connect, which exhausts connection-limited backends (e.g. Unity)

Resolved 💬 2 comments Opened Jun 17, 2026 by johnkslg Closed Jun 22, 2026

Summary

A configured stdio MCP server is spawned at session startup and held alive for the entire session, regardless of whether any of its tools are ever used. There is no lazy / on-demand connection (connect on first tool call) and no way to release the connection mid-session.

This is a real problem when the MCP server is a bridge to a backend that allows only a limited number of concurrent connections. The motivating case: a Unity Editor MCP relay (relay_win.exe --mcp) where the Unity editor accepts only 3 concurrent relay connections.

Impact / motivating scenario

I routinely run many Claude Code instances at once against the same repo. The Unity MCP server is configured at user scope in ~/.claude.json, so every session — across every project — eagerly spawns the relay and grabs one of Unity's 3 connection slots at startup. After 3 idle sessions, every additional session fails to connect, even though most of those sessions never touch Unity at all.

Because connection is tied to session lifetime (not tool usage), there's no way to "be a good citizen" from the model side. Instructing the agent to only call MCP tools when needed does nothing — the slot is already taken at startup.

Expected behavior

One or more of:

  1. Lazy connect for stdio servers — defer spawning/connecting until the first tool from that server is actually invoked (mirrors how HTTP/SSE servers can connect in the background and be awaited only when needed). Idle sessions would then hold zero backend connections.
  2. Idle disconnect — release a stdio server connection after N minutes of no tool calls, reconnecting on next use.
  3. Live enable/disable via /mcp — let /mcp connect/disconnect an individual stdio server mid-session without a full restart (today this only works for plugin MCP servers).

Any of these would let connection-limited backends be shared across many sessions.

Current behavior / workarounds

  • stdio servers spawn at session start and live for the whole session.
  • The only opt-out is to make the server not auto-load (remove it from config / use --strict-mcp-config --mcp-config <file> to launch only the sessions that need it). This is a coarse, per-launch decision, not on-demand.
  • /mcp does not support live connect/disconnect of manually-configured stdio servers; changes to enabledMcpjsonServers/disabledMcpjsonServers require a session restart.

Environment

  • Claude Code on Windows 11
  • Model: Opus 4.8
  • MCP server: stdio (relay_win.exe --mcp) defined in ~/.claude.json user scope

Proposed primary fix

Lazy-connect stdio MCP servers on first tool use, with the schema-deferral that already exists for tool search making this natural — the server's tools are already deferred, so the connection could be too.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗