n8n + human approval + MCP
Integre consulta MCP e uma reserva fictícia protegida por revisão humana no n8n. Use o canal de chat de desenvolvimento disponível na instalação, sem enviar mensagens a pessoas externas. A entrega deve mostrar a proposta antes da execução, a recusa sem efeito e a aprovação com um único resultado, além de eventos que permitam reconstruir o caminho.
Comece pelo simulador de aprovação e correlação. A etapa integrada precisa de cliente e servidor MCP compatíveis, AI Agent e o mecanismo de human review da versão instalada. OpenTelemetry é opcional conforme disponibilidade, mas o histórico de execução e o registro de efeito são obrigatórios. Não forneça um export com versão presumida: construa o fluxo e registre sua configuração real.
n8nMCPAvaliaçãoAutomaçãoAo terminar esta aula
- Prove recusa sem efeito pela ausência de chamada e de recibo.
- Correlacione proposta, decisão, execução e resultado externo.
- Use tracing somente conforme versão e status de disponibilidade conferidos.
Antes de continuar: Leitura: n8n + human approval + MCP
Verifique o contrato MCP e selecione tools
MCPSalve aprovacao.cjs e execute os casos locais. Depois, conecte o MCP Client Tool a um servidor de desenvolvimento que ofereça consulta e reserva fictícia. Registre versão do cliente, servidor, revisão e transporte. Confira no editor a configuração de endpoint suportada e não substitua um endpoint SSE por Streamable HTTP sem evidência de compatibilidade. Liste as ferramentas e selecione somente as necessárias. Uma operação administrativa presente no servidor não precisa chegar ao agente deste workflow.
Faça uma consulta de estoque e capture argumentos e retorno. Teste servidor indisponível e verifique que a resposta comunica a lacuna antes de propor reserva. O agente não deve fabricar quantidade disponível. Se o contrato da tool mudar, confirme que o consumidor rejeita saída incompatível ou atualiza seu contrato de forma controlada. Preserve um identificador de correlação para ligar consulta, proposta e execução, mantendo credenciais nos mecanismos apropriados e fora dos itens comuns compartilhados.
Configure a revisão no caminho da tool
FundamentosNo AI Agent, abra a conexão de tools e configure o passo de human review conforme a interface documentada na instalação. Use chat de desenvolvimento ou outro canal autorizado para o laboratório. Conecte a reserva ao passo que exige revisão e deixe a consulta de leitura fora dele quando a política permitir. Prepare a mensagem com nome e parâmetros documentados da tool, sem esconder item e quantidade em um resumo genérico. Inspecione o que o humano realmente vê antes de aceitar.
Execute uma proposta e negue. Confira que a tool de reserva não foi chamada e que o workflow comunica a recusa. Execute outra proposta e aprove. Capture o resultado e a decisão associada. Altere quantidade após a decisão no teste local e confirme que a proposta anterior não libera a mudança. Na integração, o executor deve receber ou consultar a proposta autorizada e impedir argumentos diferentes segundo a política. Um prompt pedindo para não alterar não é equivalente à validação de backend.
Teste espera, retomada e repetição
AvaliaçãoDefina tempo de validade da aprovação e comportamento para ausência de resposta. No simulador, execute após expiração e confira bloqueio. No workflow, observe o estado de espera e retome com a decisão suportada. Teste reinício durante a pausa quando seu armazenamento permite. Registre o que foi recuperado e o que depende da configuração. Não use uma nova mensagem como substituto da retomada sem verificar se ela recria a operação e perde a identidade original.
Repita a mesma operação aprovada e conte recibos no serviço fictício. A ferramenta deve usar uma chave estável ou consultar o resultado anterior. Simule timeout depois do efeito e reconcilie pela mesma chave. Se o servidor MCP não oferece esse contrato, acrescente um executor idempotente ou declare o limite e não teste efeitos reais. O histórico do n8n pode mostrar apenas uma retomada enquanto um serviço externo recebeu duas operações; por isso a contagem do lado do efeito é indispensável.
Construa evidência de observabilidade
AvaliaçãoInspecione a execução e relacione nodes de consulta, proposta, revisão e reserva. Guarde correlação, status e duração, retirando segredos dos detalhes compartilhados. Se sua versão suportar OpenTelemetry em ambiente de desenvolvimento, configure o collector conforme a documentação e envie um trace de teste antes do workflow. Confira spans de workflow e node, a relação de retomada e propagação que realmente ocorrer. Considere o status Preview e não assuma que toda instalação possui a interface de configuração.
Monte uma tabela de resultados com nominal, recusa, expiração, repetição e falha MCP. Acrescente a evidência de efeito único e a localização da execução. A conclusão deve distinguir o que foi comprovado localmente, no workflow e no serviço externo. Se tracing não estiver disponível, apresente o histórico e explique a limitação específica; ele continua suficiente para revisar os caminhos desde que seja ligado à decisão e ao ledger. Nenhuma captura verde substitui essa ligação.
↗ Trace executions with OpenTelemetry↗ Human-in-the-loop for tools
Exercício aplicado
Um agente consulta estoque por MCP e propõe reservar I2. A tool de reserva exige revisão humana. A mesma operação poderá ser retomada duas vezes, e uma decisão expirada deve bloquear antes do efeito.
- Execute recusa, aprovação, expiração e repetição locais.
- Conecte MCP compatível e selecione somente consulta/reserva fictícias.
- Configure human review com nome e parâmetros visíveis.
- Capture histórico, contagem de efeitos e traces de desenvolvimento quando disponíveis.
Abrir resolução comentada
A decisão guarda um snapshot normalizado de id, item, quantidade, organização, ator e revisão. O executor calcula o mesmo snapshot e exige igualdade antes de consultar ou criar o efeito. Os casos que alteram cada campo começam com ledger vazio e devem conservar zero entradas; isso impede reutilizar aprovação de OP7 para OP9 ou outra quantidade. O snapshot deve ser registrado por backend confiável, não aceito como decisão produzida pelo modelo.
A resolução local registra proposta e decisão, valida revisão e validade antes do efeito e usa OP7:1 para repetição. A recusa OP8 não gera entrada, enquanto as duas chamadas aprovadas de OP7 retornam o mesmo resultado. A decisão expirada falha antes do ledger.
Na integração, a reserva passa pelo human review com argumentos visíveis e pelo executor autorizado. A consulta MCP permanece somente leitura. O registro do serviço confirma unicidade e o histórico permite localizar os caminhos. Tracing de desenvolvimento acrescenta tempos e relações quando suportado, sem ser tratado como garantia de segurança ou feature estável de produção.
const efeitos=new Map(),eventos=[];
function snapshot(p){
if(!p||typeof p.id!=='string'||typeof p.sku!=='string'||typeof p.tenant!=='string'||typeof p.ator!=='string'||!Number.isInteger(p.quantidade)||p.quantidade<1||!Number.isInteger(p.revisao))throw new Error('proposta invalida');
return JSON.stringify([p.id,p.sku,p.quantidade,p.tenant,p.ator,p.revisao]);
}
function executar(p,d,agora){
const chave=snapshot(p);
if(!d||d.snapshot!==chave||d.exp<=agora)throw new Error('decisao invalida ou expirada');
eventos.push({correlacao:p.id,evento:'decisao',aprovado:d.aprovado});
if(!d.aprovado)return {status:'recusado'};
if(!efeitos.has(chave))efeitos.set(chave,{recibo:p.id+':'+p.revisao,status:'reserva_simulada'});
eventos.push({correlacao:p.id,evento:'resultado'});return efeitos.get(chave);
}
const p={id:'OP7',revisao:1,sku:'I2',quantidade:1,tenant:'lojaA',ator:'ana'};
const d={snapshot:snapshot(p),exp:200,aprovado:true};
// Todas as mutacoes devem falhar antes de qualquer efeito.
for(const mutacao of [{quantidade:999},{sku:'I99'},{id:'OP9'},{tenant:'lojaB'},{ator:'bia'}]){
try{executar({...p,...mutacao},d,100);}catch(e){console.log('bloqueio',e.message);}
if(efeitos.size!==0)throw new Error('efeito indevido');
}
console.log(executar(p,d,100),executar(p,d,100));
console.log(executar(p,{...d,aprovado:false},100));
try{executar(p,d,300);}catch(e){console.log(e.message);}
console.log({quantidadeEfeitos:efeitos.size,eventos});Como conferir seu resultado
- Recusa e expiração geram zero efeitos.
- Repetição conserva um único recibo.
- Cada efeito possui decisão e proposta correlacionadas.
- Alterar id, sku, quantidade, tenant ou ator com a mesma decisão gera zero efeitos.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Vincular snapshot ao humano/contexto.
- Distinguir revisão, validade e ledger.
Executor vazio: mutações id/sku/quantidade/tenant/ator e decisão expirada; depois nominal repetido.
Conferir raciocínio e critérios de domínio
Mutação de id, sku, quantidade, tenant ou ator diverge do snapshot; todas são recusadas antes do ledger e deixam zero efeitos.
Decisão expirada ou negativa também não emite. Duas execuções da proposta nominal aprovada dentro da validade devolvem o mesmo recibo.
A contagem esperada é um efeito nominal, confirmada no serviço de reserva. Uma única retomada no histórico não demonstraria essa unicidade por si.
Evidências para autoavaliação ou revisão por pares
- Vínculo da proposta: Mutação de id, sku, quantidade, tenant ou ator diverge do snapshot; todas são recusadas antes do ledger e deixam zero efeitos.
- Validade e replay: Decisão expirada ou negativa também não emite. Duas execuções da proposta nominal aprovada dentro da validade devolvem o mesmo recibo.
- Contagem externa: A contagem esperada é um efeito nominal, confirmada no serviço de reserva. Uma única retomada no histórico não demonstraria essa unicidade por si.
Um erro frequente
Uma retomada no workflow implica um efeito externo.
Unicidade precisa ser verificada também no serviço que executa o efeito.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Aprovar a resposta do agente é aprovar qualquer tool?
Não. A revisão deve estar ligada à chamada concreta.
Nome e argumentos precisam ser apresentados antes do efeito.
2. MCP Client Tool garante suporte à revisão atual?
Não por si só. É necessário verificar cliente, servidor e transporte.
O campo e o binding suportados dependem da instalação.
3. Trace prova efeito único?
Não. Consulte o registro do executor ou serviço externo.
A observabilidade mostra execução; idempotência precisa de um contrato de efeito.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- MCP Client Tool
n8n • consulta: 2026-10-06
n8nMCPConsumir tools externas, autenticação e seleção das ferramentas expostas ao agente.
Limites: Página ainda usa SSE Endpoint; verificar versão do node e transportes realmente suportados, sem generalizar para MCP atual.
- Transports overview — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPJSON-RPC, stdio e Streamable HTTP; regras para transportes customizados.
Limites: HTTP+SSE legado não deve ser ensinado como o transporte remoto atual; streaming é opção do binding.
- Human-in-the-loop for tools
n8n • consulta: 2026-10-06
n8nPausar tool call, exibir nome/argumentos, aprovar/negar e continuar.
Limites: Canal de aprovação requer credenciais; testar negação e vínculo entre parâmetros aprovados e executados.
- View all executions
n8n • consulta: 2026-10-06
n8nInspecionar runs, estado, histórico e retentativas.
Limites: Disponibilidade de dados depende de configurações de salvamento e edição/licença.
- Trace executions with OpenTelemetry
n8n • consulta: 2026-10-06
n8nSpans de workflow/nodes, coletor OTEL e atributos de trace.
Limites: Alguns recursos exigem self-hosted Enterprise; não prometer acesso gratuito a todos os modos de observabilidade.