Connecteur MCP

Met un connecteur MCP à disposition d'un Agent IA ou d'un Superviseur : l'agent peut alors appeler les outils exposés par ce serveur pendant son analyse.

Ce nœud est déclaratif : il ne reçoit rien, ne transforme rien et ne fait pas partie du flux du document. Il déclare simplement quels outils l'agent connecté a le droit d'appeler.

Ports

• Sortie « MCP » (haut, type MCP) — à relier à la patte « MCP » d'un Agent IA ou d'un Superviseur. Un nœud porte un seul connecteur : posez-en plusieurs pour donner plusieurs serveurs d'outils au même agent. Un même nœud peut alimenter plusieurs agents.

Configuration

• Connecteur — celui à rendre disponible, parmi ceux activés dans Admin → Connecteurs MCP. Les connecteurs natifs (math, wikipedia, hunspell, calendar) y figurent comme les connecteurs personnalisés.
• Tables accessibles (connecteur natif correspondence uniquement) — cochez les tables de correspondance publiées auxquelles l'agent a droit. Sans sélection, toutes les tables publiées de l'organisation lui sont accessibles. La restriction est appliquée côté serveur : l'agent ne voit que ces tables dans list_tables et ne peut pas interroger les autres, même en en devinant le nom. Si une table cochée est dépubliée ou supprimée, elle est signalée « introuvable ou non publiée » et l'agent n'y a plus accès (la restriction ne retombe jamais sur « toutes les tables »). Changer de connecteur efface la sélection.
• Outils exposés — le bouton Lister les fonctions interroge le serveur et affiche les fonctions qu'il publie, avec leur description. Le serveur est réellement contacté (ou démarré) : la réponse peut prendre quelques secondes. Chaque fonction a une case à cocher : décochez-la pour l'interdire à l'agent (voir ci-dessous). Le nœud affiche le nombre de fonctions interdites.

Un connecteur désactivé ou supprimé côté administration reste sélectionné dans le graphe mais n'est jamais transmis à l'agent — l'exécution ne casse pas, l'agent travaille simplement sans cet outil.

Interdire des fonctions

Un serveur MCP publie souvent plus de fonctions que l'agent n'en a besoin : une fonction coûteuse, trop bavarde (un résultat qui sature la fenêtre de contexte du modèle) ou simplement hors sujet. Décochez-la dans Outils exposés, puis enregistrez.

Une fonction interdite est retirée de la liste remise au modèle à l'ouverture de la session : il ne la voit pas et ne peut pas l'appeler, même en devinant son nom. Les logs du test le confirment par une ligne « 🚫 Outils interdits de « connecteur » (masqués à l'agent) », et le détail des nœuds du panneau de test liste les fonctions interdites de chaque agent.

• C'est une liste d'interdictions : une fonction ajoutée plus tard au serveur est autorisée par défaut, jusqu'à ce que vous la décochiez.
• Une fonction interdite qui n'existe plus sur le serveur reste listée (« interdite, absente du serveur ») : vous pouvez la réautoriser sans relister.
• Interdire check_spelling sur le connecteur hunspell désactive aussi sa vérification systématique.
• Changer de connecteur efface les interdictions.

Ce que l'agent en fait

Les outils sont proposés, pas imposés : c'est le modèle qui décide s'il appelle une fonction et avec quels arguments. Les appels effectués apparaissent dans les logs et dans la trace d'exécution du job.

Une exception : hunspell, dont la vérification orthographique est lancée systématiquement avant l'appel au LLM, ses résultats étant réinjectés même si l'IA ne les reprend pas d'elle-même.

note

Attacher un connecteur active la boucle d'outils de l'agent, comme le fait une Compétence. L'agent effectue donc des appels supplémentaires au modèle : c'est visible dans la trace d'exécution et dans les coûts IA.

Connecteur relié à un Superviseur

Un connecteur connecté à la patte « MCP » d'un Superviseur est partagé par tous ses sous-agents. C'est le moyen d'attacher un outil commun une seule fois plutôt qu'une fois par sous-agent — chaque sous-agent pouvant par ailleurs avoir ses propres connecteurs.

Pour le connecteur correspondence, la restriction de tables du Superviseur est héritée par ses sous-agents ; un sous-agent qui pose son propre nœud restreint remplace celle du Superviseur. Si plusieurs nœuds visent le même connecteur sur un même agent, leurs tables s'additionnent, et un nœud sans sélection (toutes les tables) l'emporte sur un nœud restreint.

Les fonctions interdites suivent la même logique : celles du Superviseur s'appliquent à ses sous-agents, sauf pour un sous-agent qui pose ses propres interdictions sur ce connecteur. Si plusieurs nœuds visent le même connecteur sur un même agent, chacun vaut autorisation : une fonction n'est interdite que si tous l'interdisent.

Pourquoi un nœud plutôt qu'une case à cocher

Les connecteurs se cochaient auparavant dans la configuration de l'agent. Le rattachement portait alors sur l'agent partagé : cocher un outil pour un besoin ponctuel l'armait dans tous les pipelines utilisant cet agent, y compris ceux où il n'avait aucun sens (et où il coûtait des appels au modèle).

Attaché par un nœud, l'outil appartient à cet agent, dans ce pipeline — le même agent peut être outillé ici et nu ailleurs. Les pipelines existants ont été convertis automatiquement : chaque agent dont les cases étaient cochées s'est vu poser les nœuds correspondants, déjà reliés.