Comment connecter plusieurs serveurs MCP pour orchestrer tes agents IA

Un seul serveur MCP, c'est sympa. Trois serveurs MCP qui bossent ensemble, c'est là que ça devient sérieux. À T3chFest 2026 la semaine dernière, un speaker a lancé une commande à son LLM : "vérifie mon cluster Kubernetes, et si un pod est down, ouvre un ticket GitHub et préviens l'équipe sur Slack." Tout a fonctionné. En une seule phrase. Pas de script custom, pas de webhook bricolé. Juste des serveurs MCP branchés au bon endroit.

En avril 2026, le protocole MCP (Model Context Protocol) dépasse les 97 millions de téléchargements SDK et tourne sur plus de 10 000 serveurs en entreprise. Microsoft vient d'annoncer l'intégration native dans Fabric. Google, OpenAI, AWS : tout le monde adopte. Si tu n'as pas encore connecté tes premiers serveurs MCP, ce tuto est pour toi.

C'est quoi un serveur MCP, en 30 secondes ?

Un serveur MCP est un petit programme qui expose des outils (tools) à un LLM via un protocole standardisé. Au lieu de coder des intégrations API une par une, tu branches un serveur MCP et ton agent IA sait automatiquement ce qu'il peut faire avec. Claw-Bot utilise MCP en production pour connecter Gmail, GitHub, le calendrier et la domotique à un seul agent. C'est le standard qui remplace les plugins bricolés.

Pourquoi connecter plusieurs serveurs MCP plutôt qu'un seul gros ?

La tentation, c'est de tout mettre dans un seul serveur. Mauvaise idée. Voici pourquoi :

• Isolation des permissions : ton serveur Slack n'a pas besoin d'accéder à ta base de données. Séparer = limiter la surface d'attaque.
• Maintenance indépendante : tu mets à jour ton intégration GitHub sans toucher au reste.
• Réutilisation : un serveur MCP "notifications Slack" se branche sur n'importe quel projet.
• Fiabilité : si un serveur plante, les autres continuent.

Claw-Bot recommande toujours de séparer les serveurs MCP par domaine fonctionnel. C'est un réflexe d'architecture microservices appliqué aux agents IA.

Étape 1 : installer tes serveurs MCP

On va connecter trois serveurs : un pour GitHub (lecture/écriture d'issues), un pour Slack (envoi de messages), et un SQLite local pour stocker des logs.

Avec npx ou uvx, c'est rapide :

# Serveur GitHub MCP (officiel)
npx @modelcontextprotocol/server-github

# Serveur Slack MCP
npx @anthropic/mcp-server-slack

# Serveur SQLite MCP
npx @anthropic/mcp-server-sqlite --db-path ./logs.db

Chaque serveur tourne en local et expose ses outils via stdio ou SSE. Pas besoin de Docker, pas besoin de déploiement cloud.

Étape 2 : configurer ton client MCP pour les connecter tous

Le fichier de config MCP (souvent mcp.json ou claude_desktop_config.json) liste tous les serveurs que ton agent peut utiliser :

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_xxx" }
    },
    "slack": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-slack"],
      "env": { "SLACK_BOT_TOKEN": "xoxb-xxx" }
    },
    "sqlite": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-sqlite", "--db-path", "./logs.db"]
    }
  }
}

Une fois ce fichier en place, ton agent IA voit les outils des trois serveurs en même temps. Il peut créer une issue GitHub, envoyer un message Slack et logger l'action dans SQLite, le tout dans une seule conversation.

Étape 3 : tester l'orchestration multi-serveurs

Lance ton client (Claude Desktop, Cursor, ou un agent custom) et demande :

"Liste les issues ouvertes sur mon repo, résume-les, envoie le résumé sur #dev-updates dans Slack, et log cette action dans la base SQLite."

Si tout est bien branché, l'agent va :

1. Appeler github.list_issues pour récupérer les issues
2. Résumer avec son LLM intégré
3. Appeler slack.send_message pour poster le résumé
4. Appeler sqlite.execute pour logger l'horodatage

Pas de code glue. Pas de middleware. Le protocole MCP gère le routage vers le bon serveur automatiquement.

Quels pièges éviter quand on branche plusieurs serveurs MCP ?

Les conflits de noms d'outils. Si deux serveurs exposent un outil "search", ton agent ne saura pas lequel appeler. Solution : chaque serveur doit avoir des noms d'outils uniques, ou tu préfixes dans ta config.

Les tokens qui traînent. Chaque serveur a ses propres credentials dans les variables d'environnement. Ne les mets jamais dans le même .env partagé. Claw-Bot utilise 1Password CLI pour injecter les secrets au lancement, zéro fichier en clair sur le disque.

Le timeout silencieux. Un serveur MCP qui ne répond plus bloque toute la chaîne. Mets des timeouts explicites dans ta config client (30 secondes max par appel). Depuis mars 2026, la spec MCP supporte nativement les heartbeats pour détecter les serveurs morts.

Le scope trop large. Un serveur MCP avec 50 outils, c'est un serveur MCP mal conçu. Au-delà de 10-15 outils par serveur, le LLM commence à confondre les appels. Claw-Bot découpe par domaine : un serveur "email", un serveur "calendar", un serveur "files". Jamais un fourre-tout.

Et en production, ça donne quoi ?

Chez Claw-Bot, on tourne avec 6 serveurs MCP connectés en permanence sur nos installations clients. Gmail, Google Calendar, GitHub, Slack, la domotique Hue et un serveur custom pour les rappels. Le tout orchestré par un seul agent qui tourne sur un Mac Mini à 15W de consommation.

Le résultat concret : un artisan reçoit un email client, l'agent crée automatiquement un événement calendrier, ouvre une issue pour le suivi, et envoie une notif Slack à l'équipe. Temps humain nécessaire : zéro. Coût mensuel de l'infra MCP : moins de 20 euros en électricité.

Le protocole MCP n'est plus un gadget. C'est le bus de données des agents IA. Et connecter plusieurs serveurs ensemble, c'est ce qui transforme un chatbot en vrai assistant autonome. Ton premier multi-serveur se monte en 20 minutes. Après, tu ne reviens plus en arrière.

Si tu veux qu'on t'installe ça clé en main, c'est par ici.