Hubitat's Community MCP Server Now Gives Every AI Client Its Own Key

Most smart home MCP setups have one key. Give it to Claude, a script and a second assistant, and all three get the same access. If one leaks, you reset the key and reconfigure everything. Hubitat Local MCP Server 4.8.0, released October 17, is the first community server I've found that fixes this properly: each AI client can get its own token, with its own limits.

What this server is

Hubitat Local MCP Server is a community project, not Hubitat's own. It installs through Hubitat Package Manager and runs on the hub itself, so there's no extra box to keep alive. The author, kingpanther13, announced it in the Hubitat community release thread on July 14. It goes well past device control: it creates and edits native Rule Machine rules and Visual Rules, dashboards, virtual devices, HSM and hub settings. The README counts more than 100 tools, most of them tucked behind gateway tools by default so the AI isn't handed the whole catalog at once.

That's a different animal from Hubitat's built-in AI (MCP) Connector Integration. Hubitat's docs say the built-in connector is for local AI agents ("cloud agents are not supported at this time") and uses a bearer token that "should be protected like a password." If it's compromised, you reset it, which means updating the configuration in your agent.

What 4.8.0 adds

Per the changelog and PR #551, there's a new per-client access tokens section under Advanced settings. It needs hub firmware 2.5.2 or later. For each client you set:

Tools. An allow list. A new token starts with every grantable tool on (104 in the maintainer's live test) and you untick what it shouldn't have. A tool added by a later update stays off for existing clients until you turn it on. That's the right default.
Read / Write. These can only narrow the main page's switches, never widen them.
Local / cloud. Which endpoint the token may use.
Tool-name number. Its own prefix, handy if one client talks to more than one hub.

A client sees only its own tools, and a refused call tells it which setting blocked it. A client token can never read or change the MCP Rule Server app itself, which matters because that app's pages and state hold every token. Self-administration, the Developer Mode deploy and code management stay with the main token. Access tokens are always masked in a client's results, and MCP log entries carry the client's name, so you can tell which assistant did what.

Rotation and revocation are what I'd check first, and the PR is candid about them. In the maintainer's testing, "a revoked or rotated token kept authenticating at the hub for up to about a minute," so the app now refuses a revoked or rotated token by its hash for 10 minutes. Rotating one client leaves every other client working.

Two things to know before you turn it on

Scoping is per tool, not per device. The maintainer confirmed it in the PR review: which devices any client can reach still comes from the server-wide device list, and "a client that must not reach devices is simply not granted the device tools." So you can't give one assistant the lights and another the locks. Set the device list for your most trusted client and narrow everyone else by tools.

Once any client token exists, every client has to send its token as ?access_token= or an Authorization: Bearer header, the main token included. The URLs the app shows already work that way. But a hand-built config that passes the token some other way will stop connecting, so check your existing clients right after you create the first client token.

The guardrails it already had

4.8 lands on top of a month of safety work, all in the changelog:

4.5.0 (Oct 4): separate on/off switches for the local and cloud endpoints.
4.5.3 (Oct 5): an optional setting that hides OAuth access tokens in responses, including the URLs of apps like Maker API.
4.5.5 (Oct 6): every write tool tells the AI to read the tool guide first, with acknowledgment keys that rotate hourly.
4.7.3 (Oct 17): backups kept under a storage budget (default 10 MB) instead of a 20-item cap.
4.8.1 (Oct 18): on the cloud connection, results over 99,000 bytes come back as response_too_large with guidance, instead of a gateway timeout.

The README also describes a gate on destructive writes like deleting devices, rebooting, or editing apps and rules. The Write switch has to be on, the AI has to pass confirm=true, and a full hub backup has to exist from the last 24 hours.

What users report

The release thread is mostly people having Claude build and fix rules. One user generated "a polished, searchable, interlinked 500+ page PDF documentation of EVERYTHING on my hub." Things broke, too. A user with 638 devices and 213 Rule Machine rules hit 502 errors from two diagnostics tools over the cloud relay; 4.1.1 fixed that on September 5. Claude Desktop users were steered from mcp-proxy to mcp-remote, and the 4.7.0 notes say slow writes still need mcp-remote with --protocol auto.

Know the project, too. It's small (18 stars on GitHub as I write this) and it moves fast: the changelog lists 17 releases between October 3 and October 18. The maintainer says in the thread he had no prior coding experience and leans on AI to fix the bugs he spots. He's also a core maintainer of ha-mcp, the community Home Assistant server I compared with the built-in one in my previous piece. An automated code review on PR #551 raised concerns about token-rotation timing and the lack of per-client device limits. The maintainer answered both and the bot withdrew them. I haven't seen an independent security review.

How I'd split clients

If you run this server, here's the layout I'd start with:

A health-check client. Read on, Write off, local only, and only the info and diagnostics tools.
A rule-building client for Claude. Write on, with the destructive operations, radio and firmware tools unticked.
Cloud access only for the client that needs it. Everything else stays local.
The main token stays out of every AI client. Use it to administer the server, nothing else.

Then rotate one client's token and confirm the others keep working before you trust the setup.

This is the shape I wish every platform had. openHAB's MCP add-on ties an agent's access to the openHAB user behind its token, so separating two agents means two openHAB users. Home Assistant gives you a narrow server and a wide one. Hubitat's community server turns "this assistant can read, that one can write, and neither can touch the server's own settings" into a few checkboxes. The missing piece is per-device limits, and I'd want that before giving any client lock or garage-door tools.