FrankenSonos MCP: agentes de IA manejan tus altavoces Sonos en tu propia LAN

Para quién es

Ya tienes altavoces Sonos y quieres entregar el audio de toda la casa a un terminal, una API HTTP o un agente de IA que hable MCP: FrankenSonos es un controlador y demonio en Rust descrito oficialmente como memory-safe (con seguridad de memoria); un solo binario mueve la casa entera. Cada una de las tres entradas va a un tipo de lector: quien quiere teclear usa la CLI fsonos; quien busca integración, la API HTTP con documento OpenAPI; y quien delega en la IA, el servidor MCP. Los usuarios de domótica que prefieren la línea de comandos y los scripts se sentirán especialmente cómodos; solo atiende a los altavoces que ya posees, sin compras de hardware nuevo.

Las condiciones, primero: el proyecto está en fase pre-release y aún no hay binarios oficiales descargables, así que el primer uso arranca compilando desde el código fuente (la versión de la toolchain de Rust queda fijada en rust-toolchain.toml). El demonio debe correr en una máquina de la misma LAN que tus altavoces; para acceder desde cualquier lugar, esa máquina debe además unirse a tu tailnet de Tailscale. Si esperas una instalación de un solo comando y lista para usar, espera al release oficial. Estas dos condiciones lo acercan más a infraestructura autoalojada que a una aplicación de instalar y usar; si las aceptas, sigue con el primer intento.

No encaja, o mejor esperar: sin altavoces Sonos, sin ganas de instalar una toolchain de Rust o sin una máquina que viva permanentemente en la misma LAN, estos requisitos son difíciles de cumplir. Si funciona con altavoces de otras marcas no aparece en la evidencia; no lo des por hecho.

Primer intento en 3 minutos

La ruta principal recomendada es la oficial: compilar desde el código fuente, completar la configuración inicial y apuntar un agente al demonio. Por qué no descargar: la CI sí produce binarios para Apple Silicon y x86_64 Linux en cada push a main, pero caducan con la ejecución del pipeline, y oficialmente las descargas empezarán con 0.1.0. En todo el proceso no se instala nada en los altavoces.

Requisitos: una máquina en la misma LAN que los altavoces, con la toolchain de Rust lista.

Paso uno, clonar y compilar:

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

Paso dos: ejecuta fsonos setup en esa máquina; según el texto oficial, se hace cargo y completa la configuración inicial.

Paso tres, apunta un agente al demonio desde cualquier máquina de la tailnet:

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

Para la primera llamada elige el paso más ligero: leer el recurso MCP sonos://zones para ver las zonas de altavoces y comprobar que la cadena funciona antes de tocar ningún dispositivo. Sobre las señales de éxito, la evidencia no describe el texto de salida exacto; lo confirmado es que el endpoint y los nombres de recursos salen literalmente del texto oficial. Si quieres que el agente ejecute acciones de control, ten en cuenta que actúan sobre equipos reales; la evidencia no da ruta de deshacer, así que no las trates como reversibles. El punto de confirmación va antes de la acción: mira qué va a invocar el agente y sobre qué zona, y recién ahí autoriza. Practicar por separado el primer intento de solo lectura y el control real es el ritmo más tranquilo.

Casos de uso

Caso uno: el agente repasa los altavoces de toda la casa. Escenario: el agente ya está conectado al demonio por el endpoint de arriba y quieres revisar rápido qué habitaciones suenan antes de salir. Prueba: leer el recurso MCP sonos://zones. Resultado esperable: información de las zonas de altavoces; los campos y formato concretos no constan en la evidencia, manda la respuesta real. Fuera de la red, cualquier máquina de la tailnet permite al agente la misma lectura, más práctico para quienes pasan mucho tiempo fuera; a largo plazo esa lectura puede volverse el chequeo rutinario de cada día.

Caso dos: sin agente por medio, controlar el audio de la casa directamente en la terminal. Escenario: estás justo en la máquina que corre el demonio. Prueba: usa la CLI fsonos, que soporta --json en todo. Resultado esperable: salida en JSON, fácil de interpretar desde scripts y de enganchar a tu automatización existente; la lista concreta de subcomandos no está en la evidencia, así que no se inventan ejemplos uno por uno. Los scripts llaman a la CLI, el agente va por MCP; las dos formas se combinan según el escenario.

Límites de uso

• Naturaleza lectura/escritura: las llamadas de control actúan de verdad sobre los altavoces. La evidencia no aporta la marca lectura/escritura, ni los nombres ni los parámetros de cada herramienta MCP; solo confirma que el servidor trae herramientas más los dos recursos sonos://zones y sonos://dj.
• Sobre los propios altavoces: oficialmente, «Nothing is installed on the speakers and nothing about them is changed»: no se instala nada en ellos ni se les cambia nada; pero eso no anula los efectos de las acciones, y el control de reproducción sigue siendo un cambio real en el equipo. Si lee o escribe archivos y datos locales más allá de los altavoces, la evidencia tampoco lo dice.
• Clientes y entradas: oficialmente solo se da el comando de conexión para claude; el transporte MCP admite streamable HTTP o stdio; cómo se conectan otros clientes no consta en la evidencia.
• Red y despliegue: la misma LAN es requisito duro; el acceso entre redes depende de la tailnet, con un endpoint con la forma https://<mac>.<tailnet>.ts.net:8443/mcp, donde los marcadores se reemplazan por tu propio dominio de tailnet. La autenticación y credenciales requeridas no constan en la evidencia.
• Estado de versión: pre-release, sin descargas oficiales, artefactos de CI que caducan con el pipeline, versión oficial que empezará en 0.1.0 y ruta de actualización sin constar en la evidencia.
• Sin confirmar aún: nombres y parámetros de las herramientas MCP, mecanismo de autenticación, si leer recursos dispara acciones en los equipos, mecanismo de deshacer. Que sean desconocidos no significa que no haya riesgo; antes de dejar al agente operar solo por primera vez, limita sus acciones a las de lectura y ve ampliando poco a poco.