Les trois serveurs MCP qui valent la peine sur un build web

L'essentiel du frottement d'un build web n'est pas d'écrire du code. C'est de déplacer des faits entre systèmes: les espacements du fichier de design, les noms de champs du CMS, l'erreur du dernier déploiement. Vous les lisez dans une fenêtre et les retapez dans une autre, et l'agent avec qui vous travaillez n'en sait rien. Le Model Context Protocol est le standard ouvert qui comble cet écart, et Claude Code le parle nativement.

La question n'est pas s'il faut connecter des serveurs. C'est lesquels trois, car le coût d'un serveur connecté se paie à chaque requête de la session, et la plupart de ce qui existe ne le vaut pas.

La portée décide qui obtient le serveur

Il y a trois portées, et le choix pèse plus qu'il n'y paraît. La portée locale est celle par défaut et garde le serveur pour vous sur cette machine. La portée utilisateur vous le donne dans tous vos projets. La portée projet écrit le serveur dans un fichier à la racine du dépôt et le partage avec tous ceux qui y travaillent, celle qui compte pour un build client. Comme l'explique la référence MCP, un serveur en portée projet attend une approbation avant de se connecter: committer le fichier ne donne donc pas silencieusement à votre équipe une connexion qu'elle n'a pas choisie.

Notre règle: tout ce dont un collègue a besoin pour reproduire le build va en portée projet, et tout ce qui dépend d'un compte détenu par une seule personne reste local. L'outillage de design relève souvent du second cas, ce qu'il vaut mieux savoir avant de committer un fichier que la moitié de l'équipe ne peut pas utiliser.

C'est le gain le plus net, parce que la passation est un pur transfert de faits et que les humains y sont mauvais. Relire à la main les valeurs de tokens, les échelles d'espacement et les variantes de composants produit une approximation, et l'approximation est là où part le temps de revue design. Un serveur qui laisse l'agent lire le fichier directement supprime toute une catégorie d'allers-retours.

Deux avertissements issus d'un usage réel. D'abord, l'agent traduira volontiers un design en valeurs codées en dur si vous ne lui dites pas d'utiliser vos tokens existants, et il ne sait pas lequel privilégier. Ensuite, les paliers gratuits et d'entrée des plateformes de design plafonnent les appels d'outils assez durement pour arrêter un build en cours de route: vérifiez le plafond avant d'organiser une journée autour.

Où ça paie: le CMS où vous ne voulez pas cliquer

Si le site a un modèle de contenu de quelques centaines d'éléments, l'interface d'administration est le goulot. Créer quarante éléments de collection à la main, c'est un après-midi; les décrire une fois et laisser l'agent les écrire via une API, vingt minutes. Webflow publie son propre jeu d'outils pour agents précisément pour cela, et la même forme existe désormais pour la plupart des CMS hébergés.

Ce qu'il faut anticiper: écrire via une API n'est pas construire dans l'éditeur. Certaines propriétés ne sont tout simplement pas exposées, et on l'apprend en s'y cognant. Nous gardons une note courte par plateforme de ce que l'API ne peut pas régler, car le découvrir deux fois est du pur gâchis. La comparaison des plateformes détaille lesquelles en laissent le plus de côté.

Où ça paie: lire vos propres déploiements

Le troisième est le moins discuté et peut-être le plus utile. Un serveur d'hébergeur laisse l'agent lire le journal de build, les erreurs d'exécution et l'état du déploiement directement, ce qui transforme la boucle de débogage la plus courante sur un site déployé: de coller-et-demander à une seule question. Vercel documente le sien, et le motif se généralise.

Associez-le à l'habitude décrite dans la liste de mise en production et la boucle raccourcit: pousser vers une préversion, demander à l'agent ce que le déploiement a dit, corriger, repousser. Sans copier des lignes de journal dans un chat.

Où ça ne paie pas

Le motif de ce tableau: un serveur mérite sa place quand il remplace une récupération mécanique, et ne mérite rien quand il remplace un jugement. L'analytique en est l'exemple net: sortir les chiffres n'a jamais été la partie difficile.

Le problème de confiance que personne ne met sur la slide

Un serveur connecté peut injecter du texte dans le contexte de votre agent, et du texte en contexte est quelque chose sur quoi l'agent peut agir. C'est toute la forme de l'injection de prompt, et la documentation le dit sans détour: vérifiez que vous faites confiance à un serveur avant de le connecter, car ceux qui récupèrent du contenu externe élargissent votre exposition. Sur un build web, le risque est concret et non théorique: un champ de CMS, une page que vous avez aspirée et un commentaire sur un fichier de design sont tous du contenu qu'un tiers peut écrire.

La défense pratique n'a rien d'astucieux. Connectez peu de serveurs, préférez ceux dont vous pouvez nommer l'éditeur, et traitez tout ce qu'un serveur renvoie comme des données, non comme des instructions. Le même raisonnement vaut pour ce que votre site donne aux crawlers, sujet de ce que reçoivent réellement les crawlers d'IA.

Trois est le bon nombre

Chaque serveur connecté ajoute des définitions d'outils au contexte, et le contexte dépensé en outils n'est pas dépensé sur le code. Nous en faisons tourner trois sur un build typique: l'hébergeur, le CMS quand il y en a un, et le fichier de design tant que le design bouge. Tout le reste se connecte pour un après-midi et se déconnecte. Si vous décidez quoi configurer d'abord, le fichier d'instructions de l'agent compte plus que n'importe quel serveur, et l'article sur CLAUDE.md est le point de départ. Les skills sont le levier suivant, et nous mettons tout cela en place dans le cadre d'un build Webflow ou d'un build sur mesure.