How I Use AI to Help Me Manage My Home Lab (with MCP)

MCP (Model Context Protocol) lets an AI assistant like Claude read from your home lab — containers, GPU usage, services — so you can just ask "what's eating my VRAM?" instead of SSHing around three boxes to find out. The catch: most home-lab MCP servers are community projects, and the access you hand them matters a lot. Here's how I think about wiring AI into a lab as a read-only helper, and the safety rails I wouldn't skip.

It's 11pm. I'm half-asleep, and a fan somewhere in the lab has decided to sound like a jet taking off.

So begins the ritual: SSH into one box, run docker ps. SSH into another, run nvidia-smi. Check a third for the thing I forgot I moved there last month. Ten minutes later I've answered one tiny question — which container is pegging the GPU? — and I'm wide awake and annoyed.

For a while now I've had the same lazy daydream: what if I could just ask the lab what's wrong? Not click through five dashboards. Just type a question and get an answer.

That's the thing MCP actually makes possible. But I want to be upfront about where I land, because it shapes the whole post: I want AI helping me manage the lab — answering questions, spotting the obvious — not running it. A read-only co-pilot, not a sysadmin with root. Let me explain why, and how I'd set it up.

What MCP actually is (in plain English)

MCP stands for Model Context Protocol. It's an open standard from Anthropic, released in late 2024 and later handed to a Linux Foundation project, that solves a boring-but-important problem: how does an AI model talk to your stuff?

Before MCP, every tool needed its own custom glue to connect to an AI. MCP is the common plug. You run a small program called an MCP server that exposes some capability — "list Docker containers," "read GPU stats" — as named tools. Your AI app (the client) connects to that server and can now use those tools. One standard, lots of servers. By early 2026 there were already over 10,000 public ones.

If you want the deeper "what is this and why does it matter" version, I wrote a whole guide to the Model Context Protocol earlier. For today, that one sentence is enough: an MCP server is a little adapter that lets an AI see or do a specific thing.

The home-lab version is exactly what it sounds like — an MCP server that exposes your lab's information (containers, services, GPU, network) as tools the AI can call.

Start read-only: the safest first win

If you only do one thing here, make it a read-only server. Read-only means exactly that: the AI can look, but it has no tools to change anything. No restarts, no config edits, no "oops."

A good example is homelab-monitor, a single-container dashboard for GPU, VRAM, Docker, systemd services, and host health. The part that's relevant here: it ships with a built-in MCP server that's read-only by design — there are no write tools at all, so an agent can look but never touch.

The dashboard runs on one port and the MCP server rides along on another, exposing around a dozen tools covering hosts, containers, services, GPU, per-process memory, and local AI model servers. Point Claude at it and you can finally ask the questions I used to SSH around for:

• "Which container is using the most RAM right now?"
• "Is the GPU pegged, and what's using it?"
• "Did any systemd service fail since this morning?"

Because there's nothing to write, the worst case is a wrong answer — not a wrecked box. That's the whole point of starting here. (To be clear, I'm describing this as the pattern I'd reach for, not a tour of my own running setup.)

Wiring it into Claude

Connecting a local MCP server to Claude Desktop is mostly editing one JSON file. On a Mac it lives at ~/Library/Application Support/Claude/claude_desktop_config.json, and the easy way to find it is Settings → Developer → Edit Config.

Inside, there's an mcpServers section. Each server gets an entry with a command to run and its arguments. Here's the shape of it (an illustrative example, not a copy-paste config for any specific server):

{
  "mcpServers": {
    "homelab": {
      "command": "npx",
      "args": ["-y", "some-mcp-server", "--host", "http://10.0.0.5:9810"]
    }
  }
}

Save the file, fully quit and reopen Claude Desktop, and it'll launch the server and pick up its tools. Then you just ask your question in chat. The official Claude docs walk through this with real examples, and each server's README tells you the exact command and arguments it expects.

One tip from doing fiddly config work before: use absolute paths, not relative ones. Claude launches these servers itself, so "the folder I happened to be in" doesn't mean anything to it.

The part nobody likes to talk about: trust and access

Here's where I get a little preachy, because this is the bit that actually matters.

Almost every home-lab MCP server you'll find is a community project — unofficial, maintained by one or two people, often very good, but not blessed by Docker or Ubiquiti or Home Assistant. That's not a reason to avoid them. It is a reason to look before you leap.

The security research on MCP keeps circling the same theme: the danger isn't usually some exotic exploit, it's implicit trust. You install a server, it shows up with a bunch of tools, and the AI just… uses them. If one of those tools is sketchy — or the server quietly asks for more access than it needs — you've handed a program a key to your systems on vibes alone. The folks who maintain the standard publish a solid MCP security best practices doc if you want the formal version.

My checklist before running any MCP server against my lab:

• Read who made it. Real repo, real history, recent commits, issues that get answered? A server with three stars and one anonymous commit gets a hard no.
• Skim the actual code. You don't need to be a security researcher. Just see what it does and what it reaches for.
• Check what tools it exposes. Read-only monitoring is a very different risk than "can restart any container" or "can change firewall rules."
• Watch what it mounts. A host monitor needs deep access — a read-only Docker socket (the control channel for your containers), parts of the filesystem, maybe the systemd bus. That's normal for monitoring, but know that you're granting it, and prefer read-only every time.

And then the golden rule: least privilege. Give a server the smallest access that lets it do its job, and nothing more. If you only want to ask questions, you never need a server that can make changes.

If you do want write access, demand "preview then confirm"

Some servers go beyond reading. unifi-mcp, for the UniFi networking stack, can actually change things — but it does it the right way: changes are opt-in and gated behind a preview-then-confirm flow. The agent shows you what it's about to do and waits for your yes before anything touches the controller. That's the model I'd accept for write access. Anything that silently makes changes is a hard pass.

Same caution, bigger stakes, for something like ha-mcp, an unofficial Home Assistant server with 90-plus tools. It can genuinely control your smart home — lights, locks, switches. Useful, but that's real-world write access. I'd keep it read-only or very tightly scoped, and I would not let it act unattended.

Last thing: keep it local. None of this should be hanging off the open internet. My one honest first-person flex here is that I reach everything in my lab over the same private setup I use for my local AI stack — I get to it through Tailscale, so there's nothing exposed publicly. If you've read my take on the hidden risks of a self-hosted AI stack, this is the same access hygiene applied to AI tooling: don't bind things to 0.0.0.0 and hope for the best.

Where I draw the line

So, do I let an AI run my home lab? No. And I don't want to.

What I'm genuinely sold on is the read-only co-pilot: ask a plain-English question, get a straight answer, skip the 11pm SSH scavenger hunt. That alone is worth setting up, and it carries basically no risk because there's nothing to break.

Write access is where I get conservative. I run local models through my own stack, and local models — especially the smaller ones — get things wrong. A wrong answer costs me nothing. A wrong action on my network or my containers could cost me an evening. The math isn't close. If I ever allow a change, it's behind preview-then-confirm, and I'm watching.

The cool demo is "I gave the AI the keys." The version I'd actually live with is quieter: AI as the assistant that already knows where everything is, hands the wrench to me, and lets me decide whether to turn it.