Prévia e confirmação

Quase toda tool de escrita do MCP roda em dois passos, e não grava nada na primeira chamada. Esse é o protocolo mais importante deste grupo inteiro, porque é ele quem garante que uma mudança feita por conversa é tão segura quanto uma feita clicando na tela. As exceções são poucas e estão listadas mais abaixo.

Os dois passos

Passo um: a prévia. Você pede uma mudança, e seu assistente chama a tool com confirm: false. A resposta traz uma prévia exata do que vai acontecer, mais um confirmation_token. Nada foi gravado ainda. Você está só vendo o que aconteceria, se seguisse em frente.

Passo dois: a confirmação. Você revisa a prévia. Se estiver certa, seu assistente chama a mesma tool de novo, agora com confirm: true e o mesmo confirmation_token que veio no passo anterior. Só nesse momento a mudança é gravada.

O que é o token, e por que ele trava

O confirmation_token é assinado sobre o conteúdo exato daquela mudança, o mesmo payload, campo a campo. Se qualquer campo mudar entre o passo um e o passo dois, seja o texto de uma resposta, o valor de um campo ou o identificador de um item, o token deixa de valer. Não tem como reaproveitar. Nesse caso, o único caminho é repetir o passo um, pegar uma prévia nova com um token novo, e confirmar de novo.

O token também tem prazo: vale 15 minutos a partir da prévia. Passou disso, a confirmação é recusada mesmo com o conteúdo idêntico, e o assistente precisa pedir uma prévia nova.

Isso também significa que o token nunca é algo que dá pra adivinhar ou inventar. Ele só existe porque veio de uma prévia real, gerada pela própria tool. Um assistente não tem como montar um token por conta própria: ele precisa ter passado pelo passo um.

Por que existe esse passo duplo

O motivo não é burocracia. É garantir que o que você aprovou é exatamente o que foi gravado.

Pense no que aconteceria sem isso. Você pede uma mudança, uma tool de escrita roda direto, sem prévia, e grava. Entre o momento em que você formulou o pedido e o momento em que a tool executou, não existe nenhum ponto de checagem. Se o seu assistente entender um detalhe errado, trocar um valor por engano ao montar a chamada, ou escrever algo um pouco diferente do que você pediu, a mudança que entra no seu CRM ou na sua base de conhecimento não é a que você tinha em mente. Você só descobre isso depois, olhando o resultado.

Com prévia e confirmação, esse risco desaparece. A prévia mostra o conteúdo exato antes de qualquer gravação. Você lê e decide se está certo. O token amarra essa leitura à gravação: se alguma coisa mudar no meio do caminho, o token não bate mais, e a tool recusa aplicar. Não existe um jeito de aprovar uma coisa e gravar outra.

Como isso aparece numa conversa

Na prática, você não precisa pedir os dois passos explicitamente. Peça a mudança normalmente, em português: "atualiza esse item da base de conhecimento pra incluir o novo horário de atendimento". Seu assistente chama a tool com confirm: false, te mostra a prévia, e espera sua confirmação antes de seguir pro segundo passo. Leia a prévia com atenção nesse momento, porque é a sua única chance de pegar um engano antes que ele valha.

O que fazer quando o token invalida

Se você mudar de ideia no meio do caminho e quiser ajustar um campo depois de já ter visto a prévia, não tem problema. Peça a mudança de novo, com o ajuste incluído. Seu assistente chama o passo um outra vez, com o payload novo, e recebe um token novo. É o comportamento esperado, não um erro: o token só é válido pro conteúdo exato que gerou ele.

O mesmo vale se a prévia ficou parada mais de 15 minutos. Peça pro assistente refazer a prévia, leia de novo e confirme.

Apagar também passa pela prévia

Exclusões pelo MCP seguem os mesmos dois passos. Na prévia, a tool confere que o item existe e mostra o nome dele. Nada é apagado sem o token. Isso vale para contato, oportunidade, pipeline, tag, campo customizado, item da base de conhecimento, tabela, item do catálogo, template de e-mail e rascunho de template de WhatsApp. Arquivar um playbook de estágio segue o mesmo caminho, e dá pra desfazer depois.

Leia com atenção o nome que aparece na prévia de uma exclusão. É a confirmação de que o assistente pegou o item certo.

Vale pra quase toda escrita, com exceções conhecidas

Esse protocolo cobre a grande maioria das tools de escrita do MCP, das mais simples, como atualizar um dado de contato, até gravações na base de conhecimento.

Existem exceções, e as mais sensíveis estão entre as tools de efeito real: endpoint_execute, golive_send_template e golive_clear executam direto, já na primeira chamada. Não há prévia nem confirmation_token nelas. Pedir pra disparar um endpoint externo, enviar uma mensagem de teste ou limpar a conversa de teste é o mesmo que fazer: não existe um passo intermediário pra revisar. Por isso, nessas tools, a revisão precisa acontecer antes do pedido, não depois.

Outras tools avisam na própria descrição que são "escrita direta, sem confirmação". Entram aqui as escritas de Google Marketing no GA4, no Tag Manager e no Search Console, e o envio de imagens para e-mail e para o cabeçalho de templates. No Tag Manager, publicar a versão no site continua passando pela prévia. analisar_conversas também roda direto: ela só dispara a análise das conversas do período e devolve um identificador para acompanhar.

Fora dessas exceções, se uma chamada de escrita não devolver prévia e token, alguma coisa está diferente do esperado, e vale conferir com a Interage antes de seguir.

Antes de chegar nesse ponto, vale garantir que o identificador usado na chamada também está certo. Isso está em ler antes de escrever, a outra metade dessa disciplina.

Como confirmar

Erros comuns

• Pedir pra "confirmar direto", pulando a prévia. O protocolo existe justamente pra esse momento em que parece mais rápido pular um passo.
• Não ler a prévia com atenção. Ler por cima anula a proteção: é exatamente esse momento que existe pra pegar um engano antes de gravar.
• Estranhar um token que não funciona mais. Se qualquer campo mudou entre a prévia e a confirmação, ou se passaram mais de 15 minutos, o token invalida de propósito. É esperado, não um erro do sistema.
• Assumir que uma tool de escrita gravou sem ver prévia e token. Fora das exceções conhecidas, se isso acontecer, algo está diferente do esperado: pare e confira com a Interage antes de seguir.
• Contar com a prévia numa tool que não tem prévia. Em endpoint_execute, golive_send_template, golive_clear e nas tools de escrita direta, pedir já é executar: revise antes de pedir.