Feature request: Lazy/on-demand MCP server connections

Status Open

Maintainer reply None cached

Activity 4 comments · opened May 28, 2026

Problem

When multiple MCP servers are configured, all of them connect at session startup regardless of whether they'll be used in that session. This causes significant memory/RAM consumption and slower startup times, especially for users who have several MCP servers configured across different services.

Tool search already defers tool definitions (schema loading) until needed, which helps with context window usage — but the underlying server processes still launch and hold open connections at startup, consuming system resources.

Proposed Solution

Add a per-server configuration option (e.g., "autoConnect": false or "lazyConnect": true) that defers the actual server process launch and connection until one of its tools is first invoked.

Example:

{
  "mcpServers": {
    "essential-server": {
      "command": "...",
      "autoConnect": true
    },
    "occasionally-used-server": {
      "command": "...",
      "autoConnect": false
    }
  }
}

Servers with autoConnect: false would:

NOT spawn a process or establish a connection at session start
Only connect when the user explicitly asks to use one of their tools (or when tool search resolves to one of their tools)
Still appear in /mcp status (shown as "not connected" or "on-demand")

Use Case

Users who work across multiple projects and cloud services often configure many MCP servers (monitoring, databases, version control, project management, cloud storage, etc.). In any given session, only a subset of these are actually needed. Spawning all server processes upfront wastes memory and can cause performance issues on resource-constrained machines.

Alternatives Considered

Manually editing settings per session — works but tedious and error-prone
Using project-scoped settings — helps somewhat but doesn't solve it when multiple servers are needed in the same project
Tool search — already implemented but only defers schema definitions, not the actual connections

Additional Context

This would complement the existing tool search feature nicely — tool search optimizes context window usage, while lazy connections would optimize system resource usage.

View original on GitHub ↗

3 Comments

Arxonic1 · 2 months ago

Independent data point, and a +1 for keeping this distinct from ToolSearch/schema deferral:

Machine: 16 GB Apple Silicon Mac
Concurrency: roughly 9 to 13 Claude Code sessions
Configuration: roughly 10 stdio MCP servers
Measured footprint: about 480 MB for the MCP fleet per session
Result: about 4.3 to 6.2 GB of duplicated MCP processes, causing severe memory pressure and V8 heap OOM crashes

ToolSearch solved the context-window side of this problem, but not the RAM side. The underlying stdio server processes still launch and connect at session startup even when none of their tools are used.

Either of these would solve the process problem:

Lazy process spawn: do not launch a configured stdio MCP server until ToolSearch resolves to one of its tools or the tool is first invoked. Optionally stop it after an idle timeout.
Shared local MCP daemon or pool: keep one long-lived process per configured server and multiplex it across concurrent local Claude Code sessions.

A possible setting shape would be "spawn": "lazy" | "eager" plus "idleTimeoutMs", or a global "sharedMcp": true.

Current workarounds remain partial: trimming configuration, using task-specific --mcp-config profiles, external process reapers, or converting servers to HTTP/SSE. None removes the default per-session duplication for stdio servers.

Related shared-process request: #28860. Related schema-only work that is already shipped: #7336.

hampsterx · 1 month ago

Measured on a workstation running 13 concurrent sessions. Every MCP server is one process per session, spawned at startup and held for the session's lifetime. /clear reclaims none of it, so the only lever is exiting the session.

Per session, claude itself is 341-418 MB and its MCP servers are 1.03-1.35 GB.

The MCP number is already the floor. It excludes 4.1 GB of npm exec wrappers across the fleet, which is my own config error: npx <pkg> leaves a resident npm parent sitting alongside the server it spawned, and invoking the entry point under node directly removes it. I mention it so the 1.03-1.35 GB isn't read as more of the same.

Most of that goes unused, which is the argument for lazy spawn. The session that produced these measurements ran two hours of work and called zero MCP tools while holding seven servers at ~1.1 GB. A session editing markdown still spawns the browser-automation, analytics and Drive servers it will never touch. The biggest single process is a language server that a code-intelligence MCP starts eagerly whether or not a symbol tool is ever called: 435 MB, larger than the claude process hosting it.

#17668 already accepted this reasoning for tool definitions, which are deferred because most tools go unused in most sessions. The processes behind those definitions still start eagerly.

Config scope only goes so far: project-scoped .mcp.json and --strict-mcp-config control which servers a session starts, but a server needed in 10% of sessions still costs 100% of them.

Is a per-server opt-in flag ("lazy": true, connect on first tool call) roughly the shape this would take, or does something in the protocol make connect-on-demand harder than it looks?

GregTheGreek · 1 month ago

+1. Related measurement in #82952 (macOS, 2.1.261): two sessions, 12 MCP processes, 679 MB, with the same stateless API server booted twice with identical credentials. Lazy connect would help, but pooling identical stdio configs across sessions (keyed by command + args + env + cwd, refcounted, idle timeout) is what changes the scaling from sessions x servers to servers.

Showing cached comments. Read the full discussion on GitHub ↗