MCP Marketplace : connecter des outils externes à votre agent IA

Pourquoi un agent a besoin de portes, pas seulement d'une pièce

L'agent ReAct au cœur de Simmetric Chat sait déjà raisonner et agir : il cherche dans votre base de connaissances avec le RAG hybride, écrit dans la mémoire du workspace et traite des documents. Mais un agent enfermé dans ses propres skills est un système fermé. Le Model Context Protocol (MCP) est le standard ouvert qui en fait un système ouvert - un protocole partagé par lequel un assistant IA peut découvrir et appeler des outils externes, et par lequel des outils externes peuvent atteindre les capacités de l'assistant lui-même.

L'histoire MCP de Simmetric Chat est bidirectionnelle. En sortie, votre agent se connecte à des serveurs MCP externes et acquiert leurs outils comme skills. En entrée, la plateforme peut exposer sa propre connaissance RAG à d'autres clients MCP, comme les assistants dans les IDE. Cet article couvre le côté sortant de bout en bout : le marketplace, les connexions et les contrôles qui décident ce que votre agent peut réellement atteindre dans une conversation donnée.

Le marketplace : un catalogue curé de serveurs d'outils

Les administrateurs atteignent le marketplace depuis la barre latérale - l'entrée est réservée aux admins, parce qu'installer un serveur d'outils ouvre un portail dans les conversations du workspace. Le catalogue présente les serveurs MCP disponibles sous forme de cartes avec les détails qui comptent avant une installation :

• Badges de catégorie - les serveurs sont regroupés par domaine (outils pour développeurs, bases de données, communication, etc.), avec des pastilles de catégorie qui filtrent la grille. Les catégories sont générées à partir des données du catalogue, donc les filtres reflètent ce qui existe réellement.
• Niveaux de vérification - les serveurs official viennent de mainteneurs reconnus, les verified_community ont été revus, et les entrées unverified sont listées mais non vérifiées. Le niveau est sur la carte, pour que le degré de confiance soit visible avant le clic.
• État de santé - l'endpoint de chaque serveur est sondé dans un cycle de 30 minutes, et sa carte montre s'il est actuellement healthy, stale ou down, plus la date du dernier commit pour juger si le projet est activement maintenu.
• Liste des outils - chaque outil exposé par le serveur, avec nom et description, apparaît sur la page de détail avant que vous n'installiez quoi que ce soit.

Une barre de recherche filtre le catalogue par nom ou description en temps réel. Rien de tout cela ne passe par un intermédiaire cloud que vous ne pouvez pas inspecter : le catalogue est un ensemble d'endpoints, et les badges de santé vous disent lesquels sont vivants maintenant.

Installation en un clic, avec portée sur le workspace

Installer un serveur est un seul clic depuis la carte ou sa page de détail, avec un prérequis : un workspace doit être sélectionné, parce que chaque connexion MCP a une portée sur un workspace. Derrière le clic, le système crée un enregistrement de connexion avec le nom par défaut du serveur, tente immédiatement la connexion et enregistre les outils découverts dans le registre des skills de l'agent.

Ce que vous obtenez est l'union des connexions du workspace : chaque serveur MCP activé et connecté contribue ses outils à l'agent. La connexion est créée même si le serveur est injoignable au moment de l'installation - elle arrive marquée disconnected, et vous pouvez corriger son URL ou son transport depuis les paramètres de connexion et la retester.

La désinstallation est l'inverse délibéré : elle supprime l'enregistrement de connexion, ferme la connexion runtime et désenregistre tous ses outils. L'action est destructive - la configuration est retirée, pas soft-deleted - ce qui est le comportement honnête pour une surface de permissions aussi puissante.

Gérer les connexions dans les paramètres

Chaque connexion, installée depuis le marketplace ou créée à la main, vit dans Paramètres → Connexions MCP. Le tableau montre le nom affiché, l'URL du serveur avec son transport, un point d'état live et un interrupteur activer/désactiver :

• Transport. Deux types de connexion sont pris en charge : Server-Sent Events (sse) et streamable HTTP (streamable-http). Modifier une connexion peut changer URL, nom ou transport, et modifier une connexion activée déclenche une reconnexion automatique.
• État live. Le tableau interroge les serveurs toutes les 30 secondes : vert pour connecté, gris pour déconnecté, rouge pour erreur. Une action Test déconnecte, reconnecte et rapporte le nombre d'outils découverts - avec un timeout de 10 secondes, pour qu'un endpoint mort vous coûte dix secondes, pas un après-midi.
• Activer contre désactiver. La désactivation ferme la connexion runtime et désenregistre les outils tout en gardant la configuration en base, pour qu'une intégration saisonnière puisse être éteinte sans rien supprimer.

Pour les cas réels de mismatch de transport, le client retombe avec bon sens : une connexion configurée pour streamable HTTP qui répond par un 4xx retente en SSE, tandis qu'une connexion déclarée explicitement sse reste en SSE.

Pinning par chat : moindre privilège pour les conversations

L'activation au niveau du workspace est un pinceau large. Le contrôle fin, c'est le pinning par chat, disponible depuis le panneau console à côté de chaque conversation : un menu déroulant liste les connexions MCP du workspace avec un point d'état et un interrupteur pour chacune.

Épinglez une connexion pour en faire l'ensemble d'outils délibéré de cette chat - utile pour des conversations ciblées, des discussions sensibles ou pour tester comment l'agent se comporte avec un sous-ensemble d'outils spécifique. Le modèle de pinning est strictement additif : épingler des connexions ne retire jamais les outils des autres connexions actives et connectées du workspace ; retirer tous les pins revient à l'union par défaut de toutes les connexions activées. Les pins survivent aux rechargements et aux redémarrages, stockés par chat, avec un interrupteur optimiste qui revient à l'état précédent et signale une erreur si la persistance échoue.

Le résultat est un modèle de moindre privilège pour les outils de l'agent : le workspace décide ce qui existe, les interrupteurs de connexion décident ce qui est généralement disponible, et chaque chat décide ce que cette conversation précise peut atteindre.

La direction entrante : exposer le RAG via MCP

Le même protocole tourne aussi dans l'autre sens. La plateforme peut faire office de serveur MCP, exposant la recherche RAG hybride sur sa propre base de connaissances pour que des clients MCP externes - les assistants dans les IDE sont l'exemple canonique - puissent ancrer leurs réponses dans votre connaissance curée et protégée par RBAC. Vos documents restent où ils sont ; l'assistant de l'IDE appelle, reçoit des résultats de recherche avec citations et n'a jamais besoin d'une copie du corpus.

Cela transforme la base de connaissances en infrastructure : les mêmes documents indexés servent le workspace de chat interne et tout outil MCP-aware que votre équipe utilise déjà, avec les mêmes règles d'accès appliquées à la frontière.

Où les outils s'insèrent dans la boucle de l'agent

Les outils MCP entrent dans l'agent comme des skills de première classe. Quand l'orchestrateur ReAct tourne, les outils fournis via MCP côtoient les skills intégrées - recherche dans la base de connaissances, mémoire du workspace, traitement des documents - et l'agent décide à chaque tour si un appel d'outil aide à répondre. Les noms d'outils sont encadrés par namespace par connexion pour que les identifiants n'entrent jamais en collision, et chaque événement en streaming qui rapporte un usage d'outil porte le nom de la source lisible, pour que la trace d'activité de la chat montre quelle connexion a servi quel appel.

Les contrôles de santé des connexions installées tournent comme des jobs planifiés via la file basée sur Postgres de la plateforme, pour qu'un marketplace qui devient stale soit remarqué par l'infrastructure et pas par les utilisateurs. Toute la surface - catalogue, connexions, pinning - est protégée par le RBAC de la plateforme : gate admin sur le marketplace et la gestion des connexions, et le pinner par chat reste dans la surface de chat que les utilisateurs ont déjà.

Pour commencer

1. Ouvrez le marketplace depuis la barre latérale (rôle admin) et choisissez un serveur vérifié dont les outils correspondent à un flux de travail réel.
2. Sélectionnez un workspace, installez et confirmez que le point d'état devient vert.
3. Ouvrez une chat, vérifiez que l'outil apparaît dans le panneau console et épinglez-le si cette conversation doit y rester limitée.
4. Posez une question qui nécessite l'outil - la trace d'activité de l'agent montre l'appel, sa source et son résultat.

Les serveurs MCP externes ne sont que des serveurs : exécutez-en un sur votre infrastructure, pointez une connexion dessus, et la surface de capacités de votre agent grandit sans aucune modification de code à la plateforme.

Lire le guide complet dans la doc →