Estou no Cloud Starter e não consigo autenticar um cliente contra um MCP Server Trigger, apesar de ter descartado todas as variáveis de configuração que posso controlar.
Configuração: nó MCP Server Trigger, URL de Produção, workflow Ativo. Tentei ambos os tipos de credencial Bearer Auth e Header Auth, ambos falham de forma idêntica com “Falha na autenticação.”
O que confirmei e descartei:
A URL está correta (URL de Produção, corresponde exatamente entre o trigger e o cliente)
O token é idêntico (verificado usando a mesma entidade de credencial em ambos os lados, e separadamente por comparação direta lado a lado)
O campo Nome da credencial Header Auth é exatamente “Authorization”, sem erro de digitação ou problema de capitalização
Os “Domínios de Requisição HTTP Permitidos” do Header Auth estão definidos como Todos
O workflow está Ativo, não apenas salvo
Testado via a ferramenta de teste de conexão integrada do nó MCP Client Tool E via uma execução real ao vivo (Chat Trigger → AI Agent → MCP Client Tool), mesma falha de ambas as formas
Reconstruído do zero em um workflow de teste completamente isolado, trigger novo, credencial nova, cliente novo, zero histórico compartilhado com meu build original, mesma falha
Isso acontece consistentemente, não intermitentemente. Agradeço a ajuda para entender se isso é um problema conhecido com o tratamento de autenticação do MCP Server Trigger, ou algo específico da minha instância.
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Compartilhe a saída retornada pelo último nó
Informações sobre sua configuração n8n
Versão do n8n:
Banco de dados (padrão: SQLite):
Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main):
Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop):
Oi @kfbird, bem-vindo!
“Falha na autenticação” do MCP Client Tool significa que o servidor respondeu com 401 ou 403, portanto a requisição está chegando ao trigger e sendo rejeitada na verificação de autenticação, não na URL ou no transporte. O trigger compara o header recebido com a credencial armazenada como uma string exata sem eliminação de espaços, enquanto os valores de header de saída são removidos dos espaços em branco à esquerda e à direita antes de saírem do cliente. Um token colado com um espaço à direita, tabulação ou quebra de linha parece idêntico em ambos os lados e nunca pode corresponder. Recrie ambas as credenciais, digite um token alfanumérico curto e simples manualmente em cada uma em vez de colar, depois republique e teste novamente.
Para confirmar qual lado está com problema, acesse a URL de produção diretamente:
curl -i -X POST "https://<your-instance>.app.n8n.cloud/mcp/<your-path>" -H "Authorization: Bearer <your-token>"
Um 403 lá significa que o trigger realmente está rejeitando o token. Qualquer outra coisa significa que a autenticação passou e o problema está no nó do cliente.
Você mencionou que definiu o campo Name da credencial Header Auth como "Authorization". Este é na verdade o ponto de falha silenciosa mais comum: o nó MCP Client Tool, ao usar Header Auth, envia o valor como está. Se o trigger está esperando Authorization: Bearer <token> mas o cliente envia Authorization: <token> (sem o prefixo Bearer), a correspondência falha — mesmo que o token em si esteja correto. Verifique novamente se o campo Value em sua credencial Header Auth inclui a string completa Bearer <seu-token>, e não apenas o token bruto.
A autenticação Bearer e Header passam por duas comparações separadas no gatilho, portanto um problema em forma de token não falharia de forma idêntica em ambas. Isso descarta a comparação de credenciais.
A Ferramenta MCP Client imprime “Falha na autenticação” para qualquer 401 ou 403 que recebe, e o gatilho responde com um 401 simples e o corpo “Nenhum transporte encontrado para sessionId” quando a sessão MCP está ausente, o que nunca chega à verificação de credenciais.
O status e o corpo subjacentes são anexados à descrição do erro do nó, portanto abra o detalhe do erro na Ferramenta MCP Client em vez de se basear no título. Uma rejeição de token real é um 403 com um corpo vazio.
A opção Server Transport também deve corresponder à URL que o gatilho fornece. O caminho base simples é HTTP Streamable, e uma URL terminada em /sse é a opção SSE obsoleta.
Tenho o transporte do servidor como HTTP Streamable e estou usando a URL de produção exatamente como foi fornecida. Não acho que seja um problema de incompatibilidade de tokens/credenciais, pois tentei várias vezes refazê-los e corrigir o erro.
Os dois tipos de autenticação que você tentou enviam o token no cabeçalho Authorization, então um cabeçalho sendo reescrito em trânsito falha em todos eles de forma idêntica.
Crie uma credencial Header Auth com o Nome X-Mcp-Token e qualquer valor curto, defina o MCP Server Trigger para Header Auth com essa credencial, defina o MCP Client Tool para Header Auth com a mesma credencial e, em seguida, salve e reative.
Se ainda assim falhar, envie um e-mail para help@n8n.io com o nome da sua instância e a ID do workflow para que possam verificar a rota /mcp na sua instância.
Neste ponto, eu pararia de mudar métodos de autenticação e tornaria a requisição com falha visível.
A divisão útil é:
A requisição realmente chega com o header que você acha que tem?
O gatilho MCP está rejeitando o valor após recebê-lo?
Se você conseguir colocar um nó Webhook simples temporário na frente do mesmo cliente e fazer log dos headers recebidos, você saberá se este é um problema de forma/header do cliente ou um problema de autenticação do gatilho MCP. Se o header estiver presente e exato lá, isso provavelmente não será corrigível apenas a partir da tela do workflow.
Parece que a solicitação está chegando ao n8n corretamente, mas a camada de autenticação do disparador MCP está rejeitando após esse ponto.
Nesse ponto, eu enviaria ao suporte o ID do fluxo de trabalho, a versão do n8n, a configuração de transporte, o tipo de autenticação testado e a resposta 403 bruta.
@kfbird quando você enviar um email para o suporte, mencione que isso se reproduz em um workflow de teste isolado e totalmente novo sem nenhum histórico compartilhado, o que descarta qualquer coisa em cache ou corrompida no seu workflow/credenciais originais, e aponta para um bug no nível da instância ou algo em como o Cloud Starter lida com a autenticação da rota /mcp especificamente. Vale a pena perguntar se isso se reproduz em outros níveis de plano também.
Como você provou que o header chega intacto e o trigger ainda retorna 403, existem três coisas que valem a pena descartar antes (ou enquanto) o suporte investiga:
Reativação após edições de credenciais. Um workflow ativo mantém o estado de credencial que tinha no momento da ativação. Se você editou o valor da credencial enquanto o workflow permanecia Ativo, o trigger pode continuar validando contra o snapshot antigo. Após QUALQUER alteração no trigger ou sua credencial: desative, salve, aguarde alguns segundos, ative novamente. Um simples “Salvar” não é suficiente.
Correspondência exata de caminho. Com transporte HTTP Streamable, a URL de produção deve corresponder caractere por caractere, incluindo a barra final. Alguns clientes normalizam /mcp/<path> para /mcp/<path>/ (ou a removem), e a requisição então atinge a camada de autenticação como uma rota desconhecida e retorna 403. Tente ambas as variantes uma vez no seu teste curl.
Remova o nó MCP Client Tool da equação. Execute o inspector oficial de um terminal (npx @modelcontextprotocol/inspector), defina o transporte como Streamable HTTP, cole a URL de produção e adicione o header Authorization lá. Se o inspector se conectar, o bug está na configuração do nó client, não no trigger — isso é um ponto de dados muito útil para seu ticket de suporte.
Se você postar o formato exato da URL (apenas a parte do caminho, token removido) e se a variante com barra final muda o 403, fico feliz em continuar investigando aqui.
