Le serveur MCP retourne des réponses incorrectes/génériques dans le chat n8n

Questions
1

Bonjour à tous,

Je suis actuellement en train de tester une intégration MCP entre n8n et le serveur YouTrack MCP.

Le serveur MCP lui-même semble fonctionner correctement, car lorsque j’utilise le même serveur à partir de Zed Editor, j’obtiens des résultats précis de YouTrack.

Cependant, lorsque j’utilise le MCP via un chat IA n8n (ou également un workflow avec un agent IA), les réponses sont incorrectes ou génériques.

Configuration

  • n8n Chat
  • Serveur MCP : YouTrack MCP
  • Authentification : Bearer token
  • Point de terminaison MCP :
    https://youtrack.server.url/mcp

Le même point de terminaison et le même bearer token sont utilisés à la fois dans n8n et Zed Editor.

Problème

Quand je pose une question comme :

« Quel est le problème le plus récent du projet IT ? »

le chat n8n retourne quelque chose sans rapport comme :

Ceci semble être une réponse d'une recherche dans la base de connaissances qui n'a retourné aucun résultat (le tableau articlesPage est vide).

Comment puis-je vous aider concernant vos articles ?

- Rechercher des articles
- Afficher un article
- Créer un nouvel article
- Mettre à jour un article

Cela suggère que l’appel de l’outil MCP peut ne pas être interprété correctement, ou que l’agent peut sélectionner la mauvaise capacité/outil MCP.

Comportement attendu

Quand je pose exactement la même question dans Zed Editor en utilisant le même serveur MCP, j’obtiens le résultat correct :

D'après les résultats de la recherche, le problème le plus récent du projet YouTrack « IT » est :

IT-5077 — <titre>

Créé : 15 mai 2026
Signaleur : <nom>
Type : Tâche
État : Soumis

Le serveur MCP lui-même semble donc fonctionnel.

Questions

  1. Quelqu’un a-t-il observé un comportement similaire et sait-il comment le résoudre ?

Notes supplémentaires

  • Aucune erreur d’exécution évidente n’apparaît dans n8n

  • Le test de connexion MCP réussit

  • Le problème semble être lié à la façon dont l’agent IA choisit ou interprète les outils MCP

  • Je compare actuellement le comportement entre :

    • le même point de terminaison MCP
    • le même bearer token
    • le même modèle sous-jacent (qwen 3.6 via ollama)

Toute idée ou conseil de débogage serait apprécié.

Ou est-ce quelque chose que je devrais signaler sur le github de n8n ?

Actuellement en cours d’exécution sur la version n8n 2.17.5 (auto-hébergée).

3

La mauvaise sélection d’outil est le problème fondamental. L’agent IA n8n utilise la liste d’outils MCP retournée au moment de la connexion pour décider quel outil appeler. Si les noms d’outils ou les descriptions sont ambigus ou se chevauchent, le LLM en choisit un mauvais.

Voici quelques points à vérifier :

  1. Ouvrez le nœud MCP dans n8n et regardez la liste d’outils qu’il découvre. Comparez les noms d’outils à ceux utilisés par Zed. YouTrack MCP expose probablement des outils séparés pour les articles et pour les problèmes. L’agent fait correspondre votre invite à l’outil de recherche d’articles au lieu de l’outil de problèmes.

  2. Le modèle compte ici. Qwen 3.6 via Ollama a un routage d’outil plus faible que GPT-4o ou Claude. Essayez la même invite avec un modèle plus puissant. Si cela fonctionne avec un modèle différent et échoue avec Qwen, le problème se situe du côté du modèle et non du côté de n8n.

  3. Ajoutez une invite système à votre nœud d’agent IA qui nomme explicitement les outils à utiliser pour quels types de requêtes. Quelque chose comme : Pour rechercher des problèmes dans YouTrack, utilisez l’outil search_issues. Cela oriente le LLM vers le bon outil quand les descriptions seules ne sont pas suffisamment distinctives.

  4. Vous êtes sur la version 2.17.5 qui est en retard par rapport à la version actuelle. La gestion des appels d’outils MCP a eu des correctifs dans les versions récentes. Cela vaut la peine de tester sur la dernière version avant d’aller sur GitHub.

4

Bonjour @Njo_D !

quels tools/capabilities le MCP expose-t-il ?
l’agent peut-il les différencier correctement ?
avez-vous testé une instruction extrêmement explicite, quelque chose comme « use the issue search tool only », pour voir si le problème vient du routing de l’agent et non du MCP ?
je tentarais aussi de capturer les tool traces/appels MCP réels dans n8n pour confirmer quelle capability l’agent sélectionne. selon la réponse, il semble qu’il tombe sur la Knowledge Base tool, mais il faut encore valider si le problème vient du agent routing dans n8n ou de la réponse retournée par le serveur MCP lui-même.