MCP bidirectionnel : le marketplaces et le RAG exposé

L'assistant qui rencontre les outils à mi-chemin MCP a deux directions, et la plupart des intégrations ne racontent que la première

MCP a deux directions, et la plupart des intégrations ne racontent que la première. Dans le sens connect, vous amenez des serveurs MCP EXTERNES dans le workspace et leurs outils deviennent appelables en chat - sans code, sans redéploiement. Dans le sens expose, Simmetric Chat se retourne : un serveur MCP intégré sert la recherche RAG du workspace aux clients EXTERNES - vos IDE, là où vos développeurs travaillent déjà.

Cet article parcourt les deux sens plus les surfaces de contrôle qui les rendent sûres à opérer : le flux d'installation via le marketplace, les connexions manuelles, l'épinglage par chat, la replie de transport, et les contrôles de santé.

Les opérations d'écriture du marketplaces sont réservées à l'admin (naviguer veut juste un connecté). Faits : FACT-CENSUS.md F-MCP-1.

Le sens connect : le marketplace

Le MCP Marketplace est un catalogue cultivé de serveurs MCP externes. Parcourir le catalogue (liste + détail) veut juste l'authentification ; les bras d'écriture - créer des entrées et installer dans un workspace - sont admin seulement. Le flux d'installation est atomique et autosuffisant :

1. Le schéma valide le payload d'installation (un workspace + une surcharge optionnelle nom/en-têtes - les en-têtes passent une liste de blocage côté écriture qui rejette les clés hop-by-hop, exige une regex sur les noms, et plafonne les tailles).
2. L'entrée doit exister (404) et ne pas être déjà installée dans ce workspace (409).
3. La ligne de connexion scopée au workspace naît avec l'URL et le transport du catalogue.
4. L'événement atterrit dans le journal d'audit (mcp.installed), et le connecteur part fire-and-forget : un échec de connexion se journalise, jamais avalé dans un état « sain ».

Désinstaller est l'inverse : les enregistrements des outils tombent, la connexion s'efface durement, et la ligne d'audit atterrit (mcp.uninstalled). L'installation est ainsi réversible sans résidu.

Les outils externes deviennent des skills de l'agent

Une fois connecté, l'outil de chaque serveur externe s'enregistre dans le registre de skills de l'agent sous des noms sans collisions (mcp_<connexion>_<outil>). Le registre se résout par chat :

• Sans épingles - toute connexion activée du workspace prête ses outils.
• Avec épingles - seulement les épinglées ET activées ET dans le périmètre ; l'ensemble d'épingles ne peut jamais RETIRER des outils (il ne fait qu'ajouter - l'union stricte avec les outils scopés au workspace reste).

L'épinglage par chat est le volant de l'opération : une chat de conformité parle aux exacts outils qu'il doit, sans toucher le reste du workspace.

Le sens expose : l'IDE atteint le RAG

Le serveur MCP intégré expose le retrieval de la plateforme aux clients externes :

• `rag_query` - cherche dans les documents du workspace (la recherche fondée et citée qu'utilise le chat interne).
• `list_workspaces` - le bras de découverte côté client.

Le transport est l'endpoint HTTP Streamable sans état (la révision core actuelle de MCP, réponses JSON seulement) ; le transport SSE hérité reste avec une grâce de dépréciation. L'authentification a deux formes : avec MCP_API_KEY posée, une vérification bearer (manquante ou fausse = 401) ; non posée, le serveur retombe en loopback-seul - les appelants distants reçoivent un 401 plutôt qu'un accès non authentifié. L'histoire de l'IDE : l'éditeur du développeur atteint la même recherche documentaire fondée qu'atteint le chat - la base de connaissances est un corpus aux nombreuses portes.

Les rails d'opération

Trois mécanismes gardent les deux sens opérables plutôt que seulement allumés :

• La replie de transport - une connexion déclarée streamable replie vers SSE sur un refus 4xx (jamais sur un 5xx - une erreur du serveur ne doit pas dégrader le transport en silence) ; une connexion déclarée SSE reste SSE.
• Les contrôles de santé - un cron pg-boss tourne sur les connexions installées + activées toutes les 30 minutes, ping avec tentatives exponentielles, et suit une échelle d'état (sain → stale dès les premiers échecs → down au troisième) avec les détails d'échec tenus par connexion.
• Le mutex de connexion + la carte de statuts - connect/disconnect se sérialisent par connexion ; les statuts vivants viennent de l'exécution, pas de la base, si bien qu'un « test » reflète la vérité de l'instant.

La classe d'audit

Toute mutation de marketplaces et de connexion journalise dans le log des événements (mcp.installed / mcp.uninstalled / les bras CRUD) - le registre d'activité immuable de la plateforme porte la surface (par F-AUDIT-1), au diapason de l'histoire opérative du reste de la plateforme.

Pour continuer

Le guide porte la référence complète - les champs du catalogue, install/désinstall, les sémantiques d'épinglage, les transports côté expose - sur /fr/docs/mcp-marketplace :

• MCP Marketplace - le guide
• Le billet plus ancien sur la première mouture du marketplaces : /fr/blog/mcp-marketplace
• Faits de ce billet : lignes FACT-CENSUS.md F-MCP-1 (MCP bidirectionnel + le marketplaces) et F-AUDIT-1 (le journal des événements)

Provenance : Simmetric Chat docs/MCP_MARKETPLACE.md + packages/server/src/agent/mcpServer.ts/mcpClient.ts (les transports + la replie), services/mcpHealthCheckJob.ts, CHANGELOG.md v0.28.1 - à l'état documentaire épinglé par le census (SHA aca5b8ff).