MCP server for the Logitech Harmony Hub (local websocket API), activity-first and allow-listed by the hub's own config
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"mcp-server-harmony","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# mcp-server-harmony [](https://github.com/SDNick484/mcp-server-harmony/actions/workflows/ci.yml) An [MCP](https://modelcontextprotocol.io) server for **Logitech Harmony Hubs**, one or many (say, one per TV). It talks to each hub directly over its local websocket API, with no Home Assistant and no Logitech cloud. It lets an MCP client such as Claude start and stop activities, press buttons, and read what's on. It works with any remote paired to a hub (Elite, Companion, 950), since the server talks to the hub, not the remote. > **Status: first contact with real hubs done (2026-10-14).** Two hubs connected, reported their > state and names, and powered off on request. Starting activities, button presses, reconnects > and config pushes are still verified against the simulator only: the tests run the real > aioharmony library against a wire-level fake hub. Every protocol detail that hasn't been > confirmed on hardware is a named assumption (see > [Verification status](#verification-status)), and > [HARDWARE_VALIDATION.md](HARDWARE_VALIDATION.md) is the checklist for confirming them. Not affiliated with Logitech. Built on [aioharmony](https://github.com/Harmony-Libs/aioharmony), the library behind Home Assistant's Harmony integration. ## Design: activity-first A Harmony is built around *activities* ("Watch Shield", "Listen to Music"): starting one powers the right devices and sets their inputs. That's also the right level for a model: - `start_activity("Watch Shield")` is one call; the hub handles the device choreography. - `send_command("VolumeUp")` with no device goes **through the running activity**, so volume reaches the receiver and Pause reaches the Shield without the model knowing your wiring. - `send_command(device="Onkyo AV Receiver", ...)` is there for the cases activities don't cover. ## Several hubs One server drives all your hubs, each by its own name (the on…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.