My MCP servers were using 560MB each in every session. Now they only start when called
I normally keep 8 or more sessions of Claude Code open simultaneously. At some point, I discovered each new session was launching a complete copy of the MCP servers I've set up so far (Gmail, Calendar, Drive, Zoom, LINE and one more). Each one required approximately 560 megabytes, so my computer was carrying multiple copies of these processes at all times, all through the day, even when nothing was calling them.
Thus, I decided to get rid of them from the always-on list and start them only when necessary. Now I only need to execute a small command (mcp-call) to get a particular tool running. For instance, running a search on my emails is simply mcp-call gmail-local with the search tool and a query, and the process finishes right after that. The agent can still find the tools since a short skill lists them, and the hooks that used to check the old MCP calls (the HTML format of emails, asking before anything gets sent or deleted) now run on the new command too. I actually thought it was likely that at least one of these would break.
Is there any MCP server you'd never take off the always-on list? Curious to learn which one and why.
Replies
A full day went into chasing down idle agent memory because an internal report cited a very specific footprint. Nobody had actually measured anything. It was just a placeholder someone typed in months earlier. Double-check how that number is collected before changing your architecture.
@konstantin_tikhaev Fair point. Mine wasn't a guess though. With 34 sessions open, the MCP processes were using about 19GB between them, and that's where the roughly 560MB a session came from.
@hisashispace With 19GB tied up across 34 active sessions, lazy-loading is a necessary operational fix, not premature optimization.
@konstantin_tikhaev Yeah, once I saw the number it was an easy call. The part I was actually worried about was breaking things, but the hooks kept working on the new command and nothing else broke either.
@hisashispace Clean process boundaries make hooks safer anyway. The only real tradeoff is that cold start latency on the first tool call will be noticeable.
The one I would keep always on is the browser one, because what it carries is not a process but context: it drives my real Chrome with the sessions I am already signed into, store consoles and the like, and I use it often enough that a cold start on every call would add up. Everything stateless I would happily make lazy like you did. I run several sessions in one repo in parallel too, and the thing your post made me realise is that the hooks are the real asset, not the servers. If the guard rails, ask before sending, ask before deleting, live on the command rather than on the server, you can swap the plumbing underneath as often as you like. Nice that nothing broke.