Serveurs MCP : étendre l'IA avec de vrais outils

Les grands modèles de langage sont intelligents. Ils peuvent raisonner, écrire, analyser et créer. Mais ils sont aussi isolés. Par défaut, un LLM ne peut pas consulter la météo d'aujourd'hui, vérifier ta base de données, chercher sur le web ou lire un fichier de ton ordi. Il ne sait que ce qui était dans ses données d'entraînement et ce que tu colles dans le prompt.

MCP — le Model Context Protocol — change ça. C'est un standard pour connecter les modèles d'IA à des outils externes. Pense à ça comme USB pour l'IA : une prise universelle qui permet à n'importe quel modèle d'utiliser n'importe quel outil, tant que les deux parlent le protocole.

Comment fonctionne MCP

Le flux est simple :

L'idée clé : le LLM décide quand utiliser un outil. Tu n'écris pas de code qui dit “si l'utilisateur demande à propos de GitHub, appelle l'API GitHub.” Le modèle comprend l'intention de l'utilisateur, reconnaît qu'il a besoin de données externes, appelle le serveur MCP approprié, obtient le résultat, et l'incorpore dans sa réponse.

C'est ce qui rend MCP puissant — et ce qui le rend différent des intégrations d'API traditionnelles où un développeur doit anticiper chaque workflow possible.

Quels serveurs MCP existent

Il y a 117 serveurs MCP disponibles sur Zubnet. Voici les catégories et quelques points forts :

Outils de développement

• GitHub — chercher des repos, créer/lire/fermer des issues, lister les PR, lire le contenu des fichiers, créer des branches
• GitLab — similaire à GitHub, pour les projets hébergés sur GitLab
• Linear — créer et gérer des issues, lire le statut des projets
• Sentry — chercher des erreurs, lire des traces, résoudre des issues

Bases de données

• PostgreSQL — exécuter des requêtes de lecture contre ta base Postgres
• MySQL — pareil pour MySQL/MariaDB
• SQLite — interroger des fichiers SQLite locaux
• Redis — lire des clés, scanner des motifs

Recherche et recherche documentaire

• Brave Search — recherche web sans tracking
• Exa — recherche sémantique à travers le web
• ArXiv — chercher des articles académiques
• Wikipedia — consulter des connaissances encyclopédiques

Systèmes de fichiers et stockage

• Filesystem — lire, écrire, lister et chercher des fichiers dans un répertoire spécifié
• Google Drive — chercher et lire des documents depuis Drive
• S3 — lister et lire des objets depuis des buckets AWS S3

Communication

• Slack — lire des canaux, envoyer des messages, chercher l'historique
• Discord — lire et envoyer des messages dans des serveurs
• Email — lire et rédiger des courriels via IMAP/SMTP

Données et API

• Fetch — faire des requêtes HTTP vers n'importe quelle URL
• Puppeteer — naviguer sur des pages web, prendre des captures d'écran, extraire du contenu
• Google Maps — géocodage, itinéraires, recherche de lieux

Parcours la liste complète sur notre MCP Store.

Configuration pour Claude Desktop

Claude Desktop supporte MCP nativement. Pour connecter un serveur, tu ajoutes sa configuration au fichier de config de Claude. Sur le MCP Store de Zubnet, chaque serveur a un bouton de copie en un clic pour cette config exacte.

Le fichier de config vit à :

• macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows : %APPDATA%\Claude\claude_desktop_config.json

Voici à quoi ressemble une config avec deux serveurs MCP :

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    },
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {
        "BRAVE_API_KEY": "your_brave_key_here"
      }
    }
  }
}

Sauvegarde le fichier, redémarre Claude Desktop, et les outils apparaissent automatiquement. Claude les utilisera quand pertinents pour ta conversation.

Configuration pour Cursor

Cursor (l'éditeur de code IA) supporte aussi MCP. La config va dans le fichier .cursor/mcp.json de ton projet :

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "/path/to/your/project"
      ]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost/mydb"
      }
    }
  }
}

Ça donne à l'IA de Cursor la capacité de lire tes fichiers de projet et interroger ta base de données — la rendant dramatiquement meilleure pour comprendre ton codebase et répondre aux questions sur tes données.

Configuration sur Zubnet

Pour les agents tournant sur la plateforme Zubnet, la configuration des serveurs MCP est encore plus simple :

1. Va au MCP Store

2. Trouve le serveur que tu veux (ex., GitHub)

3. Clique “Activer”

4. Entre la configuration requise (clés API, URL, etc.)

5. Connecte-le à ton agent

Le serveur tourne sur notre infrastructure. Pas d'installation locale, pas de npx, pas de Node.js requis. Ça marche, point.

Schémas de config : ce dont chaque serveur a besoin

Chaque serveur MCP a besoin d'une certaine configuration. Les motifs les plus courants :

Comment l'IA décide d'utiliser des outils

C'est la partie qui ressemble à de la magie. Tu n'écris pas de règles. Le LLM comprend tout seul.

Quand tu demandes “quelles issues ouvertes avons-nous sur GitHub ?”, le modèle reconnaît que :

1. Ça nécessite des données qu'il n'a pas (tes issues GitHub spécifiques)
2. Un outil GitHub est disponible
3. La fonction list_issues avec state=open est le bon appel

Il construit l'appel d'outil, l'envoie au serveur MCP, obtient la réponse JSON, puis la résume en langage naturel.

Pour les tâches multi-étapes, le modèle enchaîne les appels d'outils. “Trouve l'issue ouverte la plus commentée et poste un résumé sur #dev-chat dans Slack” pourrait impliquer :

1. github.list_issues(state=open, sort=comments)
2. github.get_issue(number=142) (pour les détails complets)
3. slack.post_message(channel=#dev-chat, text=...)

Trois appels d'outils, orchestrés automatiquement. Pas de code écrit.

Considérations de sécurité

Construire ton propre serveur MCP

La spécification MCP est ouverte. Si l'outil dont tu as besoin n'existe pas encore, tu peux le construire. Un serveur MCP est un programme qui :

1. Déclare ses outils disponibles (nom, description, schéma de paramètres)
2. Gère les requêtes d'appel d'outils
3. Retourne des résultats structurés

Le SDK officiel est disponible en TypeScript et Python. Un serveur minimal en TypeScript fait environ 50 lignes de code. La spécification et les SDK sont à modelcontextprotocol.io.

Si tu construis un serveur que d'autres pourraient trouver utile, considère le publier dans l'écosystème MCP. La communauté grandit chaque semaine.

Quand utiliser MCP vs les appels d'API classiques

MCP n'est pas toujours la bonne réponse. Utilise-le quand :

• Tu veux que l'IA décide quand appeler des services externes (workflows dynamiques, guidés par l'utilisateur)
• Tu construis des agents qui ont besoin d'accès aux outils
• Tu veux une interface standard à travers plusieurs outils (un protocole, 117 serveurs)

Utilise les appels d'API classiques quand :

• Le workflow est déterministe (toujours appeler cette API, puis celle-ci)
• Tu as besoin d'un contrôle précis sur chaque requête
• La performance est critique et tu ne peux pas te permettre la boucle de décision du LLM

---

Parcours les 117 serveurs MCP sur notre MCP Store. Configurations en un clic pour Claude Desktop et Cursor. Ou active-les directement pour tes agents Zubnet.