Instalar a biblioteca não oficial e provar a sessão

Numa conta pessoal, não existe rota oficial de programação para o NotebookLM; a automação por código descrita aqui usa uma biblioteca não oficial (a API Enterprise é outra rota, com os requisitos vistos no capítulo anterior). A instalação e a autenticação trazem problemas conhecidos: versão que muda sozinha, sessão que parece viva e já morreu, comando que espera um vídeo de 30 minutos e desiste no meio. Antes de instalar qualquer coisa, confira se a operação precisa mesmo de automação. Uma peça por semana sai melhor pela interface web, com Generate later quando o limite acaba.

Se a resposta for automatizar, este capítulo leva você do zero a uma geração assíncrona baixada para a pasta do ciclo: biblioteca instalada com versão fixada, login feito por você, sessão provada com um teste que fala com o servidor, perfil amarrado a uma única conta, código de idioma certo e, no fechamento, o servidor MCP para usar tudo isso de dentro do Claude Code. O resultado conferível é um arquivo de áudio na pasta do ciclo e uma linha no manifesto com a versão da biblioteca que gerou a peça.

A notebooklm-py é uma biblioteca Python publicada por teng-lin no GitHub, que oferece API Python, linha de comando (o comando notebooklm), uma skill para agentes e um servidor MCP. O próprio README avisa, em outubro de 2026: biblioteca não oficial, use por sua conta e risco; usa APIs do Google não documentadas, que podem mudar sem aviso; não tem vínculo com o Google; limites de uso se aplicam; serve melhor a protótipos, pesquisa e projetos pessoais. A versão mais recente era a v0.8.5, publicada no GitHub em 12/10/2026, compatível com Python 3.15 e com correções de autenticação. Este curso fica no Python 3.12 porque é a versão do ambiente montado no capítulo de preparação e a da instalação auditada do caso; trocar de Python e de biblioteca ao mesmo tempo dobra as variáveis quando algo quebra.

MCP (Model Context Protocol) é o protocolo que permite a um agente, como o Claude Code, chamar ferramentas externas por um servidor padronizado. A notebooklm-py traz um servidor MCP que roda localmente (transporte stdio) ou como conector remoto hospedado por você. Com ele, o Claude Code lista notebooks, adiciona fontes e dispara gerações sem você digitar cada comando. Se você ainda não usa o Claude Code, o curso Claude Code cobre a instalação.

Instalação solta, sem versão no comando ou com um upgrade pelo pipx (o instalador que isola a ferramenta do Python do sistema, usado no passo a passo abaixo) quando algo quebra, deixa você sem saber qual versão gerou a peça do mês passado. Instalação fixada põe a versão explícita no comando e no manifesto, e voltar atrás vira reinstalar a anterior. O motivo: a biblioteca acompanha APIs internas que mudam, e cada versão pode trocar nome de comando, flag ou formato de saída. O caso real deste curso fixa a v0.7.3 num commit auditado e proíbe atualização cega; a migração passa por backup, instalação num ambiente isolado, teste rápido e plano de volta. Fixar pela versão do PyPI é mais simples; pelo commit é mais rígido, porque um commit não muda depois de publicado. Os comandos de cada caminho estão nas abas abaixo do passo a passo.

Perfil é a identidade de uma conta. A biblioteca guarda cada login num perfil, com a sessão salva em ~/.notebooklm/profiles/<perfil>/. A flag global --profile escolhe o perfil de cada comando, e os subcomandos profile create, list e switch administram a lista. Trate um perfil como uma pessoa: um perfil, uma conta, sempre a sua. Um notebook pode ser compartilhado com outras contas, mas cada perfil enxerga os notebooks e as permissões da própria conta; rodar um comando no perfil errado cria a peça na conta errada.

Perfil não é atalho para somar limites. Criar contas para multiplicar o volume, ou trocar de perfil quando o limite acaba, é exatamente o comportamento que as regras de automação do capítulo seguinte proíbem, e o caso registra a troca de conta como gatilho antifraude do Google. Os Termos de Serviço do Google proíbem usos indevidos dos serviços; leia-os antes de qualquer automação. Na automação, escreva o perfil e o ID completo do notebook em cada comando (-n com o ID inteiro devolvido por notebooklm create): o caso registra que um prefixo de ID que era único pode virar ambíguo e operar no notebook errado.

O servidor MCP para o Claude Code. O guia de MCP da biblioteca diz que o servidor vem no extra mcp, que a lista de ferramentas não segue versionamento semântico (pode mudar entre versões menores) e traz instruções para Claude Desktop, Claude Code, Cursor e Windsurf. O caso mantém a produção na v0.7.3; o plano de adoção dele prevê, para a série 0.8 e só num ambiente descartável separado da produção, a instalação no Claude Code pelo comando notebooklm mcp install claude-code e a variável NOTEBOOKLM_MCP_STRICT_IDS=1, que recusa IDs parciais ou ambíguos. Antes de usar o servidor, instale o extra mcp, confira notebooklm mcp install claude-code --help e abra a configuração que o comando gravou para conferir se ela chama a mesma versão fixada da linha de comando. A v0.7.3 não tem servidor MCP: notebooklm mcp --help responde No such command 'mcp' e pode sair com código zero, por isso a detecção confere o texto da resposta além do código de saída.

Duas regras do caso valem para qualquer versão. Primeira: todo fluxo escrito para MCP documenta o comando equivalente da linha de comando, porque as ferramentas MCP podem sumir do índice quando a conexão reinicia no meio da sessão, e aí o agente segue pela linha de comando. Segunda: rotina agendada usa a linha de comando, e o MCP fica para a sessão interativa, onde você acompanha cada chamada. A biblioteca também instala uma skill para agentes com notebooklm skill install.

Exemplo resolvido, do caso real. Em 11/07/2026 a esteira GEO-Pesquisador fez uma auditoria da instalação e encontrou dois problemas sobrepostos. O primeiro: o lançador global do comando notebooklm tinha zero bytes e apontava para um Python 3.12 que já não existia. A decisão foi não remendar o lançador: um ambiente isolado provou que a v0.7.3 funcionava, e o reparo foi remover só a instalação quebrada e repetir a instalação fixada pelo commit, sob um Python 3.12 existente.

O segundo problema era mais traiçoeiro. Todo comando devolvia erro de certificado, porque o antivírus da máquina interceptava as conexões seguras, e esse erro escondia o problema real: a sessão tinha expirado. Um ciclo anterior chegou a concluir, errado, que o login exigiria sempre interação. A decisão foi tratar as camadas em ordem: primeiro corrigir a cadeia de certificados com um arquivo próprio apontado por variável de ambiente, para que reinstalar não apagasse o ajuste; aí a mensagem mudou para Authentication expired; então login interativo e auth check --test. Corrigir o certificado validou apenas a conexão; a sessão continuava sem prova até o teste contra o servidor.

Variação: se o seu auth check sem --test passa e a geração falha, rode de novo com --test antes de mexer em qualquer outra coisa. Sessão expirada é uma causa frequente. O caso anotou que repositórios de fluxos da comunidade relatam expiração dos cookies do Google em duas a quatro semanas; trate esse número como estimativa e deixe o auth check --test decidir.

Para avaliar o script, procure três coisas antes de rodar. Primeira: alguma linha lê ou imprime o arquivo de sessão? Se sim, recuse e peça de novo. Segunda: auth check aparece com --test em todos os lugares? Terceira: existe algum pipx install ou upgrade escondido? A verificação não pode mudar o ambiente que ela verifica. Depois rode uma vez com o perfil certo e outra com um nome de perfil que não existe; a segunda precisa parar com código diferente de zero.