FrankenSonos MCP: agentes de IA comandam suas caixas Sonos na sua própria LAN

Para quem é

Você já tem caixas de som Sonos e quer entregar o áudio da casa inteira a um terminal, uma API HTTP ou um agente de IA que fale MCP: o FrankenSonos é um controlador e daemon em Rust descrito oficialmente como memory-safe (seguro de memória) — um único binário roda a casa toda. Cada uma das três portas serve um leitor diferente: quem gosta de digitar comandos usa a CLI fsonos; quem faz integração usa a API HTTP com documento OpenAPI; quem quer delegar à IA usa o servidor MCP. Usuários de automação residencial que preferem linha de comando e scripts vão se sentir em casa; a ferramenta atende só as caixas que você já possui, sem compra de hardware novo.

Os requisitos primeiro: o projeto está em pré-lançamento, sem binários oficiais para baixar, então o primeiro uso começa compilando do código-fonte (a toolchain Rust fica fixada no rust-toolchain.toml). O daemon precisa rodar numa máquina na mesma LAN das suas caixas; para acessar de qualquer lugar, essa máquina também entra na sua tailnet do Tailscale. Quem espera instalação num comando e uso imediato deve aguardar o release oficial. Esses dois requisitos fazem dele mais infraestrutura auto-hospedada do que app pronto para usar; se aceitar ambos, siga para a primeira tentativa.

Não serve, ou espere: sem caixas Sonos, sem disposição para instalar uma toolchain Rust ou sem uma máquina que fique sempre na mesma LAN, esses pré-requisitos ficam difíceis. Funcionar com caixas de outras marcas não está na evidência — não presuma.

Primeira tentativa em 3 minutos

A rota principal recomendada é a oficial: compilar do código-fonte, concluir a configuração inicial e apontar um agente para o daemon. Por que não baixar: a CI gera binários para Apple Silicon e x86_64 Linux a cada push em main, mas eles expiram junto com o pipeline; oficialmente, os downloads começariam com 0.1.0. Em nenhum momento se instala algo nas caixas.

Pré-requisitos: uma máquina na mesma LAN das caixas, com a toolchain Rust instalada.

Passo um, clonar e compilar:

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

Passo dois: execute fsonos setup nessa máquina; pela descrição oficial, é ele que assume e conclui a configuração inicial.

Passo três, aponte o agente para o daemon a partir de qualquer máquina da tailnet:

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

Na primeira chamada, escolha o passo mais leve: ler o recurso MCP sonos://zones para ver as zonas de caixas e verificar se o caminho funciona antes de mexer em qualquer aparelho. Sobre sinais de sucesso, a evidência não descreve o texto de saída exato; o confirmado é que o endpoint e os nomes de recursos vêm literalmente do texto oficial. Se quiser que o agente execute ações de controle, note que elas atuam em equipamentos reais; a evidência não dá caminho de reversão, então não trate como reversível. O ponto de conferência fica antes da ação: veja o que o agente vai chamar e em qual zona atua, e só então libere. Treinar separado a primeira leitura e o controle real é o ritmo mais tranquilo.

Casos de uso

Caso um: o agente faz o inventário das caixas da casa. Cenário: o agente já está ligado ao daemon pelo endpoint acima e você quer conferir rápido quais cômodos estão tocando música antes de sair. Experimente: ler o recurso MCP sonos://zones. Resultado esperado: as informações das zonas de caixas; campos e formato exatos não constam na evidência, vale a resposta real. Fora da rede, qualquer máquina da tailnet permite ao agente a mesma leitura — mais útil para quem passa muito tempo fora; no longo prazo, essa leitura pode virar a checagem diária de rotina.

Caso dois: sem passar pelo agente, controlar o áudio da casa direto no terminal. Cenário: você está na máquina que roda o daemon. Experimente: usar a CLI fsonos, que aceita --json em tudo. Resultado esperado: saída em JSON, fácil de interpretar em scripts e de plugar na sua automação existente; a lista concreta de subcomandos não está na evidência, então nenhum exemplo inventado aqui. Scripts chamam a CLI, o agente vai pelo MCP — os dois jeitos se combinam conforme o cenário.

Limites de uso

• Natureza leitura/escrita: chamadas de controle atuam de verdade nas caixas. A evidência não traz marcação de leitura/escrita, nomes ou parâmetros das ferramentas MCP; só confirma que o servidor traz ferramentas mais os dois recursos sonos://zones e sonos://dj.
• Sobre as próprias caixas: oficialmente, «Nothing is installed on the speakers and nothing about them is changed» — nada é instalado nelas e nada nelas é alterado; mas isso não elimina os efeitos das ações, e o controle de reprodução segue sendo uma mudança real no aparelho. Se há leitura ou escrita de arquivos e dados locais além das caixas, a evidência também não diz.
• Clientes e entradas: oficialmente só há o comando de conexão do agente para o claude; o transporte MCP aceita streamable HTTP ou stdio; como outros clientes conectam não consta na evidência.
• Rede e implantação: mesma LAN é pré-requisito rígido; o acesso entre redes depende da tailnet, com endpoint na forma https://<mac>.<tailnet>.ts.net:8443/mcp, em que os marcadores viram o seu próprio domínio de tailnet. Autenticação e credenciais exigidas não constam na evidência.
• Estado da versão: pré-lançamento, sem download oficial, artefatos de CI expirando com o pipeline, versão oficial começando em 0.1.0 e caminho de atualização sem constar na evidência.
• Ainda sem confirmação: nomes e parâmetros das ferramentas MCP, mecanismo de autenticação, se a leitura de recursos dispara ações nos aparelhos, mecanismo de reversão. Desconhecido não significa sem risco; antes de deixar o agente operar sozinho pela primeira vez, restrinja as ações às de leitura e vá abrindo aos poucos.