MCP Daemon Diet — Development skill for Claude Code

mcp-daemon-diet

**One shared MCP daemon per machine, instead of a copy in every agent session.**

Works with any MCP server and any MCP client. Nothing here is specific to one integration - it is the recipe, the launcher and autostart templates for all three operating systems, a watchdog that will not make things worse, two measurement scripts, and thirteen gotchas we paid for in production.

Built and run at [Palo Alto AI Research Lab](https://github.com/tonydzi/tonydzi), where a fleet of Claude sessions across five machines talks to its MCP servers through exactly this setup.

The problem

An MCP server registered as `stdio` is spawned **per client session**. Ten parallel agent sessions means ten copies of the same server: ten times the memory, ten connections to whatever it talks to, ten holders of the same lock.

What we measured on one laptop, 2026-08-01 to 08-03:

server	copies	summed RSS
telegram	~9	~2.7 GB
mongodb	~26	~3.0 GB
n8n	~15	~2.9 GB
whatsapp	~15	~1.5 GB
launcher wrappers (npx/cmd)	~60	~5 GB

**Read those numbers honestly.** Summing RSS over-counts: copies share code pages, so the operating system is not holding that many distinct bytes and you will not get that many back. What is exact is the copy count - and that each copy is an independent client of the upstream service, with its own socket, its own lock and its own session.

Measure your own machine before you believe anyone's table, including this one:

python scripts/mcp_diet_measure.py

If it prints `copies 1` everywhere, you have nothing to fix. That is also what a converted machine looks like: on our hub the same script now reports one `telegram` and one `n8n` process serving every open session.

The fix, in one line

Run the server once, bound to `127.0.0.1:PORT`, and point every client at the URL:

"mcpServers": { "telegram": { "type": "sse", "url