Linha de comando e MCP em app builder: o que muda quando o projeto sai do navegador
A maioria das ferramentas de construção com IA vive inteira dentro de uma aba. Isso resolve muito bem o começo, e começa a apertar quando o projeto cresce: você quer rodar o app na sua máquina, quer abrir os arquivos no editor que já usa, quer pedir uma alteração ao assistente que já está aberto no seu terminal.
É aí que entram duas peças que mudam bastante o dia a dia, e que hoje separam as plataformas: uma linha de comando de verdade e um servidor MCP.
O que uma linha de comando resolve que o navegador não resolve
Três coisas concretas.
Ver o projeto inteiro de uma vez. Na tela, a definição do app aparece dividida em abas: entidades aqui,
automações ali, configuração de cada página em outro lugar. Em arquivo, é uma pasta. Você abre fab.schema.json e
lê todas as entidades e campos numa tela só, e a busca do seu editor funciona em cima disso.
Rodar antes de publicar. Um comando que sobe o app na sua máquina, no mesmo template que a plataforma usa para publicar, dá o ciclo curto que falta quando toda verificação depende de um deploy.
Automatizar. Assim que a definição é arquivo, ela entra em controle de versão, em revisão por pull request e em esteira de CI. Isso não interessa a todo mundo, e para quem entrega app para cliente interessa muito.
O que um servidor MCP resolve
MCP é o protocolo que deixa um assistente conversar com uma ferramenta sem intermediário humano. Na prática, é o que faz a diferença entre estes dois diálogos:
"Cole aqui o schema do seu projeto para eu poder sugerir a automação."
"Vou ler o schema e escrever a automação."
O segundo é o que acontece quando existe um servidor MCP rodando com a sua credencial. O assistente chama a operação de leitura, recebe as entidades reais, os campos reais e os ids reais, e escreve em cima disso.
E essa é a parte que costuma ser subestimada: sem o schema em mãos, um modelo inventa. Um id de modelo errado responde 404, um campo que não existe responde 422, e o assistente passa três tentativas corrigindo argumentos quando o problema era não ter lido nada antes de escrever.
O detalhe que decide a segurança: como a chave nasce
Quase toda plataforma que oferece acesso por terminal resolve a autenticação de um jeito só: uma tela com um botão "gerar chave", um valor que aparece uma vez, e um aviso para você guardar em lugar seguro.
O problema não é a chave, é o trajeto dela. Entre a tela e o seu terminal, ela passa pela área de transferência, quase sempre pelo histórico do shell, às vezes por um canal de chat quando alguém precisa configurar a máquina de outra pessoa, e com frequência por um arquivo de configuração que acaba num repositório.
A alternativa é o fluxo de dispositivo, o mesmo padrão que você já usou para autorizar um aplicativo numa televisão. O terminal pede uma autorização, mostra um código curto, e abre uma página onde você confere que o código é o mesmo e aprova. A chave nasce já dentro da máquina que vai usá-la e nunca é exibida em lugar nenhum.
Três consequências valem a pena:
- Nada para copiar significa nada para vazar. A chave não existe em formato exibível em momento algum.
- A permissão é pedida na hora. Uma máquina que só precisa consultar pede leitura, e a credencial dela nem enxerga as operações de escrita. Um assistente que não vê uma ferramenta não tenta usá-la e não gasta rodadas interpretando um 403 como erro de argumento.
- A revogação é do lado certo. Deslogar numa máquina esquece a credencial ali. Revogar no painel derruba aquela máquina no servidor, que é o que você precisa quando o notebook sumiu.
Onde a credencial fica depois
No chaveiro do sistema operacional, quando existe um. Quando não existe, num arquivo com permissão restrita, e vale exigir que a ferramenta diga que caiu nesse caso. Uma ferramenta que escolhe o lugar pior em silêncio ensina o usuário a supor que está sempre no melhor.
O que continua fora do terminal, de propósito
Duas coisas, e a divisão é deliberada:
Credencial de integração. Os arquivos que descrevem o que o projeto tem conectado devem ser de leitura: eles dizem que existe uma integração e quais operações chamar, para um assistente conseguir trabalhar, e nunca o segredo em si. Conectar e girar chave acontece na plataforma.
Apagar. Um arquivo que sumiu da sua pasta não deveria sumir do app. A sua cópia local pode estar velha, a IA pode ter editado o projeto na plataforma enquanto isso, e apagar lá por causa de uma ausência aqui destrói trabalho. O comportamento certo é reportar a diferença e deixar a decisão com você.
Como avaliar isso numa plataforma
Se você está comparando ferramentas e esse tipo de acesso importa, são cinco perguntas que separam rápido:
- A chave é copiada ou nasce por fluxo de dispositivo?
- Dá para pedir só leitura?
- A revogação vale para o servidor ou só esquece a chave na máquina?
- O servidor MCP expõe leitura de schema, ou só operações de escrita?
- O que o comando de publicação faz com um arquivo que sumiu?
As respostas dizem mais sobre a maturidade da ferramenta do que a lista de comandos.
Na Fabapp
A linha de comando faz login por fluxo de dispositivo, guarda a credencial no chaveiro, aceita --scopes "read"
para uma máquina que só consulta, e traz a definição do projeto com pull. O dev roda o app localmente no
mesmo template da publicação, e o deploy publica. O servidor MCP usa a credencial que o login já guardou e
respeita a permissão dela: um token de leitura não lista as ferramentas de escrita.
As máquinas conectadas ficam em Perfil, em Chaves e CLI, com a permissão de cada uma e o último uso. A revogação é imediata e vale para o servidor.