← retour Les serveurs MCP que j'exécute en production chez Seahawk : une pile honnête -- illustration en ligne

Les serveurs MCP que j'ai exécutés en production chez Seahawk : une pile honnête

Logiciel sur mesure et architecture

La plupart des articles sur les serveurs MCP en 2026 sont des démos, pas des piles en production. La version honnête : l'écosystème MCP compte environ 200 serveurs, la moitié sont des jouets, et la pile prête pour la production que tu lances vraiment pour le travail d'agence quotidien est plus petite et plus banale que ce que les vidéos de démo suggèrent. Voici la pile qu'on a exécutée chez Seahawk Media sur les engagements clients, les compromis qu'on a appris, et ce qu'on a essayé qui ne méritait pas sa place.

Point clé : sur plus de 200 serveurs MCP, une véritable pile de production en compte environ huit : Filesystem, Puppeteer, Postgres, Brave, GitHub, Sentry et Notion sont utilisés quotidiennement, le reste n'est que de la démo.

Je dirigeais une agence qui expédiait du travail WordPress, Next.js, et Astro personnalisé plus du SEO et du contenu. La couche MCP était portante à travers tout ça. Si tu pèses quels serveurs MCP installer vraiment sur ton Claude Code quotidien, c'est la réponse qui fonctionne.

Les huit serveurs MCP que nous exécutons quotidiennement

Filesystem (intégré)

Le serveur MCP le plus utilisé que nous avons. Lit, écrit, effectue des recherches dans l'arborescence du projet. Chaque session Claude Code l'utilise. Rien d'exotique ; juste de l'essentiel.

Puppeteer

Automatisation de navigateur pour l'assurance qualité, le scraping de contenu, la capture d'écran, la vérification post-déploiement. A remplacé deux outils SaaS payants auxquels nous étions abonnés. Le seul point de friction est l'installation : nous conservons une image node-puppeteer car l'enfer des dépendances Chromium existe toujours.

Postgres

Requêtes SQL directes contre les bases de données clients. Remplace l'onglet éditeur SQL ouvert dans une autre fenêtre. Particulièrement utile pour les audits de contenu (quels articles n'ont pas d'images à la une, lesquels ont des révisions orphelines, lesquels ont des tags qui ne correspondent à rien). Interroger via Claude est plus rapide que d'écrire soi-même le SQL pour les questions ponctuelles.

Récupération des SERP pour les audits SEO. Nous l'utilisons chaque jour pour la recherche concurrentielle, le diagnostic de classement et le suivi des citations dans les Aperçus IA. L'API Brave est plus fiable que le scraping direct de Google ; le coût s'élève à quelques dollars par mois selon notre utilisation.

GitHub

Lit les issues, les pull requests, les fils de commentaires et les métadonnées des dépôts. Utilisé pour le triage du travail entrant, la rédaction de descriptions de PR et la synthèse de l'activité récente des commits dans les rapports de statut client.

Sentry

Lit les événements d'erreur des sites de production que nous surveillons. Claude peut corréler les événements Sentry aux changements de code récents et identifier le coupable probable plus rapidement que je ne pourrais le faire en cliquant manuellement sur la piste d'erreur. A économisé plusieurs heures par réponse à incident.

Notion

Lit notre documentation interne et les briefs clients. Particulièrement utile pour recouper les standards clients pendant la génération de code. Remplace l'étape manuelle « laisse-moi vérifier ce qu'on a convenu dans le doc de discovery ».

Linear

Lit les issues, les statuts et les assignés. Utilisé pour la préparation du standup quotidien, les rapports clients hebdomadaires et la rédaction automatique des mises à jour d'issues à partir de l'activité des commits.

Ce que nous avons essayé et abandonné

Cinq serveurs MCP que nous avons installés, utilisés pendant un mois, puis supprimés :

Slack MCP. Le ratio signal/bruit de l'extraction de l'historique Slack dans Claude était mauvais. Les messages Slack sont trop peu structurés pour servir de bon contexte.

Google Drive MCP. Le flux d'authentification était fragile et l'analyse des documents peu fiable. Nous exportons en markdown manuellement à la place.

MCPs de web-fetch génériques. La plupart sont plus lents ou moins fiables que Puppeteer quand nous avons besoin de vraiment naviguer sur un site. Nous les avons tous supprimés.

Plusieurs MCPs de génération d'images IA. Nous avons déjà un pipeline FAL qui fonctionne en dehors de Claude ; les wrappers MCP ajoutaient de la latence sans vraiment nous faire gagner du temps.

Adaptateurs génériques Database-MCP. L'adaptateur Postgres MCP intégré a surpassé tous les adaptateurs database MCP génériques que nous avons essayés.

Les règles d'hygiène de la pile MCP

Trois règles sur lesquelles nous nous sommes stabilisés après un an d'essais et d'erreurs :

Moins c'est plus

Huit MCPs, c'est le point idéal. Nous avons essayé quinze pendant un mois ; la pression sur la fenêtre de contexte a ralenti Claude et rendu ses réponses moins précises. Chaque MCP installé a un coût contextuel, et ce coût s'accumule. Auditez trimestriellement ; supprimez tout ce qui n'a pas été utilisé au cours des 30 derniers jours.

L'intégré surpasse le tiers lorsqu'ils se chevauchent

Les MCPs expédiés par Anthropic (Filesystem, les intégrations officielles) sont plus fiables que leurs équivalents communautaires selon notre expérience. Nous privilégions l'intégré et ne recourons au tiers que lorsque l'intégré ne couvre pas le cas d'usage.

L'authentification est le coût caché

Chaque serveur MCP a sa propre histoire d'authentification. Certains utilisent OAuth, d'autres nécessitent des clés API, d'autres des fichiers JSON de compte de service. Le surcoût de configuration est réel ; le coût de maintenance lors de la rotation des jetons l'est encore davantage. Choisissez des MCPs dont le modèle d'authentification correspond à votre infrastructure existante plutôt que ceux qui demandent de nouvelles proliférations de credentials.

Ce que nous surveillons pour 2026

Trois catégories de MCP que je m'attends à voir mûrir :

Les MCP d'agence-CRM (HubSpot, Salesforce, Pipedrive). Ceux qui sont actuellement livrés sont de qualité alpha ; les versions sérieuses arrivent probablement H2 2026.

Des MCPs spécifiques aux projets (un MCP interne à Seahawk exposant notre base de données client, notre logique tarifaire, notre inventaire d'hébergement). On construisait ça en interne plutôt que d'attendre une version générique.

Les MCP de contrôle de navigateur à l'échelle. Puppeteer est bon pour les interactions sur une seule page ; exécuter efficacement des navigateurs sans interface utilisateur sur des centaines de pages nécessite toujours une orchestration personnalisée. La couche MCP ici s'améliore mais n'est pas résolue.

L'essentiel

Huit serveurs MCP fonctionnaient quotidiennement chez Seahawk : Filesystem, Puppeteer, Postgres, Brave, GitHub, Sentry, Notion, Linear. C'était la pile qui livrait. Les 200 autres serveurs MCP de l'écosystème sont largement des démos ou des doublons de ceux-là.

Si vous commencez de zéro, installez Filesystem (déjà présent), puis Puppeteer, puis ajoutez Postgres ou Brave selon que votre travail est plus lourd en code ou plus lourd en recherche. Ajoutez les autres selon les besoins spécifiques qui se présentent. La pile MCP devrait croître parce que le travail l'exigeait, jamais parce que la vidéo de démo était bonne.

Questions fréquemment posées

Quels serveurs MCP valent la peine d'être exécutés en production ?

L'honnête pile de production ici en compte huit : Filesystem, Puppeteer, Postgres, Brave, GitHub, Sentry, Notion, et un de plus, choisi pour le travail quotidien en agence. La plupart des 200 serveurs MCP et plus dans l'écosystème sont des démos ou des jouets ; l'ensemble de production est petit et volontairement ennuyeux.

Combien de serveurs MCP devriez-vous vraiment utiliser ?

Moins que vous ne le pensez. L'écosystème compte environ 200 serveurs, mais une pile quotidienne de qualité production en totalise à peu près huit. En ajouter d'autres augmente la maintenance et la surface de défaillance pour peu de bénéfice. Exécutez les quelques-uns qui méritent leur place et abandonnez le reste.

Quels serveurs MCP avez-vous essayés et abandonnés ?

Plusieurs qui avaient l'air utiles en démo mais qui ont ajouté de la maintenance ou de l'instabilité sans valeur quotidienne. La règle est qu'un serveur doit justifier un usage continu, pas simplement bien fonctionner en démo une seule fois. L'hygiène de la pile compte plus que la couverture.

Qu'est-ce qui rend un serveur MCP prêt pour la production ?

La fiabilité, un cas d'usage quotidien clair, et une maintenance réduite. Un serveur de production est celui auquel votre équipe recourt tous les jours et auquel elle fait confiance pour ne pas casser le flux de travail. S'il ne brille que dans une démo ou nécessite du babysitting constant, il n'a pas sa place dans la pile quotidienne.

À lire aussi : Créer un site d'enchères en temps réel avec Next.js et Supabase, le développement web sur mesure et les logiciels personnalisés.

← retour