Best MCP Servers for a Homelab: 11 Measured (2026)

All four “favorite MCP servers” roundups I could find share one gap. None publishes a single number. No memory footprint, no startup time, no latency. Enumerate and vibe is the format. So I wrote a small benchmark, pointed it at eleven of the most-recommended MCP servers, and measured what they actually cost to keep resident on a homelab box.

The headline: each server holds 178-422MB of RAM, and the popular advice to “just connect everything” costs about 1GB for five servers, because I measured 961.6MB for a real concurrent stack, two independent measurement paths agreed on it to the decimal, and that is a gigabyte gone before a single model or container starts, spent on tooling I touch a few times a day. Nobody mentions this. RAM is the quiet bill.

The measured table

Fresh spawn per iteration, warm package cache, five iterations per server (three for GitHub and Qdrant, benched later the same evening — the iterations column in the CSV says which), medians reported. RSS covers the full process tree, because npx and uvx both spawn children, and measuring only the parent undercounts 18x. Raw data ships as CSV with a versioned dataset page, CC BY 4.0.

¹ The four Python servers self-report the version string 1.29.0 via serverInfo, a framework string rather than each package’s own release number.

Controls matter here. A bare Node process idles at 52MB and bare Python at 15MB on the same box, so the gap between those floors and the table is frameworks plus dependencies. Your tool code is nearly free. Tool count barely predicts weight. The 26-tool GitHub server is the lightest thing I measured, while the 1-tool sequential-thinking server still costs 186MB. The framework is the payload.

Two findings surprised me. Python servers land as heavy as Node ones, since uvx resolves an environment and spawns its own interpreter chain; fetch holds 220MB for a single tool. And the whole startup-cost worry is mostly noise for homelab use. Everything except Desktop Commander and Qdrant is ready in under a second warm, and a persistent client like Claude Code spawns servers once per session anyway.

The tiers, with the criteria stated

I ranked on four things I can defend: measured cost, utility per megabyte, install friction, and whether the server works standalone or needs a service running behind it.

Tier 1, connect these first

Filesystem (188MB, 14 tools), Fetch (220MB, 1 tool), and Git (185MB, 12 tools). These are the hands and eyes of any local AI setup. They read and edit real files, pull real web pages, and work actual repository history. Every workflow I run daily leans on at least two of the three, so their megabytes never idle.

Tier 2, worth it when the use exists

GitHub (178MB, 26 tools) earns a slot if your work lives in issues and PRs. The npm package I measured is the legacy implementation; GitHub’s current first-party server ships as a Go binary and a hosted remote endpoint, so treat 178MB as the worst case. Playwright (227MB, 24 tools) puts an agent behind a real browser, and the 227MB is just the idle server, so budget for the browser on top. Memory (187MB, 9 tools) gives an agent a persistent knowledge graph across sessions, which pays off once you have sessions worth remembering. Desktop Commander (275MB, 26 tools) is the heaviest Node server, and at 1.7s only Qdrant starts slower. It earns that by being a full terminal-and-editor surface. Run it where you would trust an agent with a shell, and nowhere else.

Tier 3, think twice

Sequential-thinking is the worst utility-per-megabyte in the table. It holds 186MB for one tool that restates a reasoning pattern current models handle natively. Context7 (214MB, 2 tools) pulls current library docs into context, which helps coding agents and duplicates a client that already fetches the web. Qdrant is the heaviest measured at 422MB, and bare uvx failed to install it outright on this machine — the resolver picked a pydantic-core it had to source-build, which dies without a Rust toolchain. Pin it with uvx --python 3.12 mcp-server-qdrant and it starts fine, then holds its FastEmbed embedding model (all-MiniLM-L6-v2 by default) inside that 422MB. Run it if you already run Qdrant for something else.

The service-bound layer I did not measure

The service-bound servers the homelab press centers on need their platform running to mean anything. Proxmox MCP is the consensus pick, covered by three of the four roundups I checked, with one author counting 200+ exposed tools. Kubernetes MCP and Docker Desktop’s MCP Toolkit round out that set. This bench box runs neither Docker nor Proxmox, so those numbers would have been theater, and I left them out. The pattern from the measured set almost certainly transfers. Expect the runtime floor plus dependencies, call it 200-400MB per server, and measure on your own box before trusting anyone’s table, including mine.

Configs beyond Cursor

Three of the four roundups I read assume Cursor, and the fourth stays client-agnostic. Two clients they skip matter in a homelab. Claude Code wires a server in one line.

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem C:/lab

LM Studio and Claude Desktop take the same JSON shape in mcp.json.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:/lab"]
    }
  }
}

Swap npx -y <package> for uvx <package> on the Python servers, and remember the Qdrant interpreter pin from the table above.

What to run this on

The RAM math is friendly. A five-server stack costs about 1GB resident, so any N100-class mini PC with 16GB handles the tooling layer without noticing. The real constraint is whatever model or services run beside it. If the same box also hosts a local LLM, size memory for the model first. Our RTX 5080 throughput dataset and the local LLM on an RTX 5060 guide carry the measured VRAM numbers, and with DDR5 prices where they are, over-provisioning system RAM is the cheapest insurance in the build.

Method, including the traps

The bench script (ops/bench/mcp/mcp_bench.py in our repo) spawns each server fresh, speaks MCP JSON-RPC over stdio with an initialize handshake followed by a tools/list call, and samples RSS across the full descendant process tree 0.4s after the listing returns. Five iterations per server, three for the two late additions. One discarded warmup spawn keeps npm and uv package caches warm, because the documented condition is a configured homelab, and never a first install. Run-to-run ready-time spread stayed under 7% for eight of eleven servers; the Python time and fetch servers carried first-iteration outliers up to 17%, visible in the published arrays. RSS spread stayed within 8MB worst case.

The instrument hit traps, so yours does not have to. Measuring only the spawned npx parent reports 10.3MB while the full process tree holds 189.3MB — an 18x undercount, recorded in the evidence set. Sum the tree. My first Git-server runs timed out because I pointed the repository flag at a plain directory, and the server waits silently. The Qdrant failure looked like a hang until stderr showed the build dying: “Failed to build pydantic-core==2.33.2 … Rust not found, installing into a temporary directory”. Bare uvx had resolved a pinned pydantic-core and fallen back to a source build; the 3.12 interpreter pin sidesteps it. For the five-stack figure the components were memory 189.8, filesystem 187.1, fetch 221.7, git 184.5, and GitHub 178.5, totaling 961.6MB by psutil; an independent PowerShell WorkingSet64 walk over the same process trees returned 961.6MB, exact agreement.

Limitations, named. One Windows 11 machine. Warm caches. Stdio transport only. I measured readiness and listing, and never per-tool-call latency under load. The GitHub entry is the legacy npm package rather than the current Go binary. Linux numbers will differ, likely lower on the Node floor, and that comparison is a natural v2 alongside the service-bound servers once this lab runs Docker.