MCP access to all WebSocket commands for debugging

[altendky]

Hey — I've been thinking about the debugging and maintenance side of MCP tooling for Home Assistant.

Looking at ha-mcp's tool set and HA's registered WebSocket commands, there's a coverage gap. ha_call_service covers all services generically, but there's no equivalent for the ~200 registered WebSocket commands. Commands not wrapped by dedicated tools are unreachable — things like trace/get for automation trace debugging, matter/commission for Matter devices, assist_pipeline/run for voice pipelines, repairs/list_issues, diagnostics/get, etc.

I built hamster-mcp, a custom component that takes a different approach: 6 meta-tools that dynamically discover all registered WebSocket commands, services, and Supervisor API endpoints at runtime (via hass.data["websocket_api"] and the service registry). New integrations' commands are available immediately without updating the MCP server. The idea is full access for debugging and maintenance rather than curated tools for day-to-day workflows.

A few questions I'd like to discuss:

• Is full WebSocket command access actually useful to others, or is this a niche I'm over-indexing on?
• Would something like a generic ha_send_websocket_command tool alongside ha-mcp's curated tools make sense? Or does that conflict with the curation philosophy?
• Should I keep maintaining hamster separately for the debug/maintenance niche, or try to contribute this approach here?

I'm a single maintainer and want to put effort where it helps the ecosystem most.

[sergeykad]

Hi @altendky, I think ha-mcp and hamster-mcp serve genuinely different niches, and there's room for both. ha-mcp is an external MCP server focused on a curated, safe-by-default tool set. Tools are annotated with safety hints (readOnlyHint, destructiveHint, idempotentHint) following MCP best practices, and designed so that even smaller locally-run models can use them effectively. Fewer tools with clear, narrow descriptions means less confusion for the LLM when picking the right action. hamster-mcp running inside HA has access to internals that an external server can't reach. Full admin/debug access via runtime discovery is a different and complementary approach.

On a generic ha_send_websocket_command: worth considering. We already have ha_call_service as a generic escape hatch for services, so there's a natural parallel. That said, many WS commands can modify system state in ways that are hard to undo, and a fully open passthrough could conflict with the safety-first philosophy. It also makes it harder to provide meaningful safety annotations per-command. Something to explore further.

Contributions are welcome! If you're interested in contributing specific features, happy to collaborate. Maintainer access can be discussed with @julienld as the project owner.

[altendky]

hey sergey, thanks for the response and explanation. i agree that hamster has ... well, every safety risk possible. :] it shouldn't be your everyday turn-on-the-lights access point. having a safety focused option in ha-mcp is great and as i use ha more i'll have to feel out both of them.

i don't know if i asked for maintainer access, but i didn't intend to. i'm quite used to and comfortable being an external contributor. i'm sure i'll be back around with issues and prs as i get more time into using ha personally.

thanks, and have a great day!

[kingpanther13]

Some of the stuff that you listed we already have... Like automation traces and repairs list issues. However I like that you brought this up, it gives me ideas for potential future things. My pending tool #854 is supposed to be a catchall for things like this, but it's nice to have unique tools as well.

The biggest problem with your approach is that it's essentially the same as ssh into the HA server, which is fine if you're willing to deal with the risk, but it is very risky. I occasionally will ssh into my HA with Claude for some various things but I'm always monitoring it closely because it almost always will jump to editing configuration.yaml or will do some crazy nonsense like directly editing the code of an existing integration (this just happened a few hours ago). Our approach has individual tools with specific rules that allow much tighter control over what you can and can't do.

Not saying one approach is right or wrong, they're just different tools. I like what you made, and I'm looking forward to seeing issues and PRs from you in the future!

[altendky]

hi king, thanks for your thoughts here. i agree with your safety concerns. hamster is not a tool to take lightly. my analysis of the actual gaps certainly may have been off in various ways, as you pointed out. i should get a better feel for this so i confidently know the actual differences.

i would tend more towards discoverable tool presentation allowing for the more specific presentation of read vs. write etc, but clients don't do a consistent job of actually implementing the non-basic features of the mcp protocol like server->client notifications for newly added tools. also, i'm presenting resources via tools for the same reason. :[ but even with that, the safety concerns would still be valid, even if better.