MCP Server Retorna Respostas Incorretas/Genéricas no Chat do n8n

Oi pessoal,

Estou testando atualmente uma integração MCP entre n8n e o YouTrack (Issue tracker) MCP server.

O servidor MCP em si parece estar funcionando corretamente, porque quando uso o mesmo servidor a partir do Zed Editor, obtenho resultados precisos do YouTrack.

No entanto, quando uso o MCP através de um chat de IA do n8n (ou também um workflow com um agente de IA), as respostas são incorretas ou genéricas.

Configuração

  • n8n Chat
  • MCP Server: YouTrack MCP
  • Autenticação: Bearer token
  • Endpoint MCP:
    https://youtrack.server.url/mcp

O mesmo endpoint e bearer token são usados tanto no n8n quanto no Zed Editor.


Problema

Ao fazer uma pergunta como:

“Qual é a issue mais nova no projeto IT?”

o chat do n8n retorna algo não relacionado como:

Este parece ser uma resposta de uma busca na Base de Conhecimento que não retornou resultados (o array articlesPage está vazio).

Como posso ajudá-lo com seus artigos?

- Pesquisar artigos
- Ver um artigo
- Criar um novo artigo
- Atualizar um artigo

Isso sugere que a chamada da ferramenta MCP pode não estar sendo interpretada corretamente, ou o agente pode estar selecionando a capacidade/ferramenta MCP errada.


Comportamento Esperado

Ao fazer a exata mesma pergunta no Zed Editor usando o mesmo servidor MCP, obtenho o resultado correto:

Com base nos resultados da busca, a issue mais nova no Projeto YouTrack "IT" é:

IT-5077 — <título>

Criada: 15 de maio de 2026
Relator: <nome>
Tipo: Task
Estado: Submitted

Então o servidor MCP em si parece estar funcionando.


Questões

  1. Alguém viu um comportamento igual/similar e sabe como resolver?

Notas Adicionais

  • Nenhum erro de execução óbvio aparece no n8n

  • O teste de conexão MCP é bem-sucedido

  • O problema parece estar relacionado a como o agente de IA escolhe ou interpreta as ferramentas MCP

  • Estou atualmente comparando o comportamento entre:

    • mesmo endpoint MCP
    • mesmo bearer token
    • mesmo modelo subjacente (qwen 3.6 via ollama)

Qualquer ideia ou dica de debug será bem-vinda.

Ou isto é algo que devo abrir uma issue no github do n8n?

Atualmente executando a versão 2.17.5 do n8n (auto-hospedado).

A seleção incorreta de ferramentas é o problema central. O agente de IA do n8n usa a lista de ferramentas do MCP retornada no momento da conexão para decidir qual ferramenta chamar. Se os nomes ou descrições das ferramentas forem ambíguos ou sobrepostos, o LLM escolhe a errada.

Algumas coisas para verificar:

  1. Abra o nó MCP no n8n e veja a lista de ferramentas que ele descobre. Compare os nomes das ferramentas com o que o Zed está usando. O YouTrack MCP provavelmente expõe ferramentas separadas para artigos e para problemas. O agente está correspondendo seu prompt à ferramenta de busca de artigos em vez da ferramenta de problemas.

  2. O modelo importa aqui. Qwen 3.6 via Ollama tem roteamento de ferramentas mais fraco do que GPT-4o ou Claude. Tente o mesmo prompt com um modelo mais forte. Se funcionar com um modelo diferente e falhar com Qwen, o problema está do lado do modelo, não do n8n.

  3. Adicione um prompt de sistema ao seu nó de agente de IA que nomeie explicitamente quais ferramentas usar para quais tipos de consultas. Algo como: Para buscar problemas no YouTrack, use a ferramenta search_issues. Isso direciona o LLM para a ferramenta correta quando as descrições sozinhas não são suficientemente distintas.

  4. Você está na versão 2.17.5, que está atrasada em relação à atual. O tratamento de chamadas de ferramentas do MCP teve correções em versões recentes. Vale a pena testar na versão mais recente antes de ir para o GitHub.

oi @Njo_D , bom dia!

quais tools/capabilities o MCP está expondo ?
o agente consegue diferenciá-las corretamente?
já testou uma instrução extremamente explícita, algo como “use the issue search tool only”, para ver se o problema é routing do agente e não o MCP ?
eu também tentaria capturar os tool traces/chamadas MCP reais no n8n para confirmar qual capability o agente está selecionando. hoje a resposta sugere que ele está caindo na Knowledge Base tool, mas ainda falta validar se o problema está no agent routing do n8n ou na resposta retornada pelo próprio MCP server.