MCP

FrankenSonos MCP: KI-Agenten steuern deine Sonos-Lautsprecher im eigenen LAN

Wenn Terminal, HTTP-API oder ein MCP-fähiger KI-Agent die Sonos-Lautsprecher steuern soll, die du bereits besitzt, bietet FrankenSonos alle drei Zugänge in einem einzigen speichersicheren Rust-Binary. Das Projekt ist aber Pre-Release: Der Einstieg verlangt einen Build aus dem Quellcode, der Daemon muss auf einem Rechner im selben LAN wie die Lautsprecher laufen, und Zugriff von überall benötigt zusätzlich ein Tailscale-Tailnet.

Official source · FrankenSonos

Install

git clone https://github.com/Dicklesworthstone/frankensonos
cd frankensonos
cargo build --release

Für wen es sich lohnt

Du besitzt bereits Sonos-Lautsprecher und willst die Beschallung des ganzen Hauses an ein Terminal, eine HTTP-API oder einen KI-Agenten übergeben, der MCP spricht: FrankenSonos ist ein vom Hersteller als memory-safe (speichersicher) beschriebener Rust-Controller und Daemon — ein einzelnes Binary, das das ganze Haus steuert. Jeder der drei Zugänge passt zu einer eigenen Leserschar: Befehlszeilen-Fans nehmen das fsonos-CLI, Integrationsbastler die HTTP-API mit OpenAPI-Dokument, und wer die Arbeit der KI überlassen will, nutzt den MCP-Server. Heimautomatisierer mit Vorliebe für Kommandozeile und Skripte fühlen sich hier besonders wohl; bedient werden nur die Lautsprecher, die du schon besitzt — keine neue Hardware nötig.

Die Voraussetzungen zuerst: Das Projekt ist Pre-Release, es gibt noch keine offiziell herunterladbaren Binaries, der erste Start beginnt also mit einem Build aus dem Quellcode (die Rust-Toolchain ist in rust-toolchain.toml fixiert). Der Daemon muss auf einem Rechner im selben LAN wie die Lautsprecher laufen; wer von überall zugreifen will, bringt diesen Rechner zusätzlich ins eigene Tailscale-Tailnet. Wer eine Ein-Befehl-Installation mit Sofortstart erwartet, wartet besser auf das offizielle Release. Diese beiden Voraussetzungen machen das Ganze eher zu selbst gehosteter Infrastruktur als zu einer fertigen App; wenn du beides akzeptierst, lies weiter zum ersten Versuch.

Weniger geeignet oder abwarten: Ohne Sonos-Lautsprecher, ohne Bereitschaft, eine Rust-Toolchain zu installieren, oder ohne einen Rechner, der dauerhaft im Lautsprecher-LAN läuft, lassen sich die Voraussetzungen kaum erfüllen. Ob Lautsprecher anderer Marken funktionieren, sagt die Evidenz nicht — nicht einfach annehmen.

Der erste Versuch in 3 Minuten

Der empfohlene Hauptweg ist der offizielle: aus dem Quellcode bauen, die Ersteinrichtung durchführen und dann einen Agenten auf den Daemon zeigen. Warum kein Download: Die CI erstellt zwar bei jedem Push auf main Artefakte für Apple Silicon und x86_64-Linux, aber sie laufen mit dem Pipeline-Lauf ab; zudem ist offiziell, dass Downloads mit 0.1.0 beginnen werden. Auf den Lautsprechern wird während des ganzen Vorgangs nichts installiert.

Voraussetzungen: ein Rechner im selben LAN wie die Lautsprecher, mit installierter Rust-Toolchain.

Schritt eins, klonen und bauen:

git clone https://github.com/Dicklesworthstone/frankensonos
cd frankensonos
cargo build --release

Schritt zwei: auf diesem Rechner fsonos setup ausführen; laut offizieller Beschreibung übernimmt es die Ersteinrichtung.

Schritt drei: von einem beliebigen Tailnet-Rechner den Agenten auf den Daemon zeigen:

claude mcp add --transport http fsonos https://<mac>.<tailnet>.ts.net:8443/mcp

Für den ersten Aufruf nimm den leichtesten Schritt: die MCP-Ressource sonos://zones lesen und die Lautsprecherzonen ansehen, um zuerst die Verbindung zu prüfen, bevor irgendein Gerät angefasst wird. Zu Erfolgssignalen beschreibt die Evidenz keinen konkreten Ausgabetext; gesichert ist, dass Endpunkt und Ressourcennamen wörtlich aus dem offiziellen Text stammen. Soll der Agent steuernde Aktionen ausführen, wirken diese auf echte Geräte; die Evidenz nennt keinen Weg zum Rückgängigmachen, also nicht als umkehrbar behandeln. Der Prüfpunkt liegt vor der Aktion: nachvollziehen, was der Agent aufruft und welche Zone betroffen ist, erst dann freigeben. Den ersten Versuch auf Lesen zu beschränken und echte Steuerung getrennt zu üben, ist der entspannteste Rhythmus.

Anwendungsfälle

Fall eins: der Agent nimmt das ganze Haus auf. Szenario: der Agent ist über den obigen Endpunkt mit dem Daemon verbunden, und du willst vor dem Rausgehen kurz prüfen, in welchen Räumen Musik läuft. Versuch: die MCP-Ressource sonos://zones lesen. Erwartbares Ergebnis: Informationen zu den Lautsprecherzonen; die genauen Felder und Formate nennt die Evidenz nicht, maßgeblich ist die tatsächliche Antwort. Bist du nicht im selben Netz, kann der Agent dieselbe Abfrage von jedem Tailnet-Rechner aus erledigen — für Vielfahrer besonders praktisch; für den Dauereinsatz lässt sich die Abfrage auch als täglicher Routinecheck einbauen.

Fall zwei: ganz ohne Agenten, direkt im Terminal die Beschallung steuern. Szenario: du arbeitest direkt an dem Rechner, der den Daemon betreibt. Versuch: das fsonos-CLI nutzen, das überall --json unterstützt. Erwartbares Ergebnis: Ausgabe als JSON, gut für Skripte zu parsen und leicht in bestehende Automatisierung einzuhängen; die Liste der konkreten Unterbefehle steht nicht in der Evidenz, deshalb werden hier keine Beispiele erfunden. Skripte rufen das CLI, der Agent geht über MCP — beide Wege lassen sich je nach Situation kombinieren.

Nutzungsgrenzen

  • Lese-/Schreibcharakter: steuernde Aufrufe wirken real auf die Lautsprecher. Die Evidenz liefert keine Lese-/Schreib-Markierungen, Namen oder Parameter der einzelnen MCP-Tools; gesichert ist nur, dass der Server Tools sowie die beiden Ressourcen sonos://zones und sonos://dj mitbringt.
  • An den Lautsprechern selbst: offiziell wörtlich „Nothing is installed on the speakers and nothing about them is changed“ — es wird nichts auf den Lautsprechern installiert und an ihnen nichts geändert; das heißt aber nicht, dass Aktionen nebenwirkungsfrei sind, die Steuerung der Wiedergabe bleibt eine reale Änderung am Gerät. Ob lokale Dateien und Daten jenseits der Lautsprecher gelesen oder geschrieben werden, sagt die Evidenz ebenfalls nicht.
  • Clients und Zugänge: offiziell ist nur der eine Agenten-Befehl für claude genannt; als MCP-Transport sind streamable HTTP oder stdio möglich; wie andere Clients andocken, steht nicht in der Evidenz.
  • Netz und Deployment: gleiches LAN ist harte Voraussetzung; netzübergreifender Zugriff hängt am Tailnet, der Endpunkt hat die Form https://<mac>.<tailnet>.ts.net:8443/mcp, und die Platzhalter sind durch die eigene Tailnet-Domain zu ersetzen. Authentifizierung und Credentials sind in der Evidenz nicht beschrieben.
  • Versionsstand: Pre-Release, kein offizieller Release-Download, CI-Artefakte laufen mit dem Pipeline-Lauf ab, die offizielle Version beginnt bei 0.1.0, ein Upgrade-Pfad steht nicht in der Evidenz.
  • Noch unbestätigt: Namen und Parameter der MCP-Tools, der Authentifizierungsmechanismus, ob das Lesen von Ressourcen Geräteaktionen auslöst, eine Undo-Mechanik. Unbekanntes heißt nicht risikofrei; bevor der Agent erstmals selbstständig handelt, Aktionen auf Lesendes beschränken und dann schrittweise erweitern.