I Gave Claude Access to My Homelab. Here's What Happened.

Quick context if you haven't run into MCP yet. It stands for Model Context Protocol, and it's basically a standard way to give an LLM access to tools and data. You run a server that exposes a set of functions (read this, fetch that, do this thing), and a client like Claude can call them during a conversation. So instead of the model being limited to what it was trained on, it can actually do stuff in your systems.

I've been running a custom MCP server for my homelab for a while now, and at this point it's become the way I interact with most of my self-hosted stuff. It started as a thing only I could use, and slowly turned into something my friends and family use too.

The pitch is simple. Instead of opening Audiobookshelf, then Plex, then Booklore, then checking on my 3D printer in another tab, I just ask Claude. "How much longer on the print?" "I'm a few chapters into this book and I'm a bit lost, can you catch me up without spoilers?" "What should I play next, check what's already in my Steam library." It all works.

What I built

It's a single FastMCP server. The architecture is dead simple. Every service (Audiobookshelf, Booklore, Plex, Sonarr, Radarr, Steam, Hardcover, my Elegoo 3D printer, etc.) lives in its own file. There's a services.py that imports them and calls services.register(weather) for each one. That's it.

So when I want to add a new service, I create weather.py, write the tool implementations, and add one line to services.py. The friction of adding utility is basically zero, which is the whole reason it keeps growing.

The clients are just the regular Claude apps. Desktop, mobile, even Claude Code when I'm in a terminal. Nothing custom on that side.

The multi-user piece

The interesting part isn't the MCP server itself. FastMCP makes that easy. The interesting part is letting other people use it without giving them access to everything.

I didn't want my friends to be able to control my 3D printer, obviously. But I did want them to be able to use the parts that made sense for them. So I built a dashboard where users sign in through Keycloak, and from there they can pick which tools they want enabled in their own scope. Their token carries the scoped permissions, and the MCP server enforces them.

The flow for a new user is straightforward. Add my server to Claude once, authenticate, then go to the dashboard and toggle on the tools they want. As I add new services, they show up in the dashboard and users can opt in. No re-adding the server, no reconfiguring Claude.

There's about six people on it now, friends and family. Watching how they use it has shaped what I build next more than my own usage has.

Once I had multiple people on the server, it stopped being just a tool-running service and started being a small social graph. A friend asked me once what I'd just finished watching, and I realized the data was right there in Plex.

So now there's a tool that lets users ask things like "what did Aman last watch" and get a real answer. It pulls from Plex. Each user in the dashboard can set their own privacy rules, what's visible and what's not, so it's opt-in on both sides.

It's a small feature but it's the one I didn't expect to build. It came directly from how people were actually using the thing.

How it actually feels to use

The moments that sold me on this:

Asking Claude to explain the ending of a show I just watched, and having it just know which show that was because it could see my recent Plex activity.

Adding a movie to my watchlist mid-conversation without opening anything.

Rating a book right after finishing it, just by saying so.

Asking how much longer on a print while I'm doing something else entirely.

None of these are revolutionary on their own. But the cumulative effect of not having to context-switch into a UI for any of it is the part that's actually changed how I use my homelab.

Why this matters beyond the homelab

The more I use this setup, the more I think enterprises are overcomplicating MCP in their heads.

Most companies already have public or internal APIs. Wrapping them as MCP tools isn't a big lift. It's the same auth, the same endpoints, just exposed in a way an LLM can call them. The hard part isn't the protocol, it's deciding what to expose and to whom.

And the scoped access pattern I'm using for my friends translates directly. Enterprises already do this with API keys or user auth tied to specific roles. The MCP layer just sits on top of that. Someone in finance could ask "which invoices are overdue and by how much" or "compare this quarter's revenue against last quarter and chart it" and the LLM hits the accounting APIs they already have access to, scoped to what they're allowed to see. An engineer could ask "what's broken in prod right now" or "show me which services have failed deploys this week." Same idea, different tools.

The real value isn't replacing dashboards. It's removing the friction of pulling data across five different systems to answer one question. That's what I get out of my homelab setup, and I don't see why it wouldn't apply at work too.

Where it's going

This is an ongoing project. Early on, all my tokens lived in a local .env file because I was the only user. Bringing in Keycloak forced me to think properly about scopes and hardening, and that's been a continuous process.

The next thing on my mind is pulling in services from open source projects where there's real value to having them in Claude. But that's a rabbit hole on its own. Every new service is a decision about what tools to expose, how to scope them, and whether the convenience is worth the surface area.

For now, six people are using it, I'm using it constantly, and the project keeps growing one small service at a time.