Qu'est-ce qu'un serveur MCP, brièvement
Le Model Context Protocol est un standard ouvert permettant de connecter des agents et applications IA à des outils et données externes via une seule couche d'intégration. Au lieu que le modèle réponde à partir de ce qu'il a absorbé durant son entraînement, il appelle un outil, obtient une réponse actuelle et travaille à partir de celle-ci.
Pour un design system, cela signifie un serveur placé devant votre documentation et votre code, exposant quelques outils de recherche ou de consultation. L'agent décide quand les appeler durant une session.
Un exemple concret, outil par outil
Le Carbon Design System d'IBM publie un serveur MCP, actuellement en préversion publique. Sa liste d'outils documentée constitue un excellent modèle car elle est spécifique et non aspirationnelle :
| Ce qu'il retourne | |
|---|---|
docs_search | Guides des composants, usage, accessibilité et documentation de référence |
code_search | Exemples de code React et Web Components, icônes et pictogrammes — sous forme de fichiers d'exemples complets, avec props et imports |
get_charts | Exemples de graphiques pour React, Angular, Vue, Svelte, JS vanilla et HTML |
labs_search | Composants expérimentaux — AnimatedHeader, Processing, Resizer, WhatsNew, Labs UIShell |
Les raisons invoquées par IBM sont l'accès instantané aux normes de design, un code généré de plus haute fidélité respectant les meilleures pratiques, et des réponses cohérentes issues d'une source de vérité unique, réduisant ainsi les écarts et les retouches.
Notez que code_search retourne des *fichiers d'application d'exemple complets*, et non des signatures. C'est la décision de conception qui rend ces serveurs efficaces. Un modèle à qui l'on fournit un exemple complet et fonctionnel reproduit les conventions environnantes — style d'import, composition, ordre des props — ce qu'une simple signature de type ne permet pas.
Le problème qu'il résout réellement
Demandez à un agent de code de construire un formulaire avec votre bibliothèque de composants et observez ce qui échoue. Ce ne sera généralement pas la mise en page. Ce sera une prop renommée il y a deux versions majeures, un chemin d'import déplacé lors d'une restructuration du package, un nom de variante qui n'a jamais existé, ou un composant déprécié et remplacé.
C'est un problème de mémorisation, et il possède une propriété spécifique et redoutable : un résultat erroné ressemble exactement à un résultat correct. Un nom de prop halluciné est syntaxiquement valide, sémantiquement plausible et semble correct lors de la revue. Vous ne vous en rendez compte qu'à l'exécution, ou via une erreur de type si vous avez la chance d'en utiliser.
Un nom de prop halluciné est syntaxiquement valide, sémantiquement plausible et semble correct lors de la revue. La récupération l'emporte sur la mémorisation car la mémorisation échoue silencieusement.
La situation s'aggrave avec le temps. La connaissance qu'a un modèle de votre bibliothèque est figée à sa date de coupure d'entraînement et s'éloigne de la réalité à chaque version. Pour un design system privé ou interne, c'est encore pire : le modèle ne l'a jamais vu, donc chaque appel qu'il écrit est une invention. MCP est la solution appropriée dans les deux cas, car il remplace la mémoire par une consultation.
Le modèle de coût dont personne ne parle
On présente souvent MCP comme étant strictement supérieur au contexte statique. Ce n'est pas le cas : c'est un compromis différent, et ce compromis devient évident dès qu'on le formalise.
| Appel d'outil MCP | Fichier dans le dépôt | |
|---|---|---|
| Quand il est disponible | Quand l'agent décide de l'appeler | À chaque tour, sans condition |
| Actualité | Toujours à jour | Aussi à jour que le fichier |
| Coût | Un aller-retour et des tokens d'appel d'outil par requête, de manière répétée | Tokens de contexte une seule fois par session |
| Échelle | Illimitée — une bibliothèque de 4 000 composants ne pose aucun problème | Limitée par la fenêtre de contexte |
| Fiabilité | Dépend de la décision de l'agent de l'appeler | Il est simplement présent |
| Configuration | Un serveur actif, de la configuration, parfois l'authentification | Écrire un fichier, le commiter |
C'est la ligne sur la fiabilité qui surprend généralement. Un serveur MCP n'est utile que si l'agent l'appelle ; or, un agent convaincu de connaître déjà votre composant Button n'appellera rien. C'est précisément là que vous en aviez le plus besoin.
Si vous installez un serveur MCP pour votre design system et que vous ne constatez aucune amélioration de la qualité du résultat, vérifiez s'il est réellement appelé avant de conclure qu'il ne fonctionne pas. Une erreur affirmée ne déclenche pas de recherche. Une instruction dans votre dépôt stipulant « interrogez toujours le serveur du design system avant d'écrire un composant » est souvent l'élément manquant.
C'est sur la question de l'échelle que MCP est véritablement irremplaçable. Une vaste bibliothèque comprenant des centaines de composants, chacun avec ses variantes et ses notes d'accessibilité, ne peut pas être copiée dans le contexte. C'est un problème de récupération, et cela le restera toujours.
Pourquoi l'agent conçoit-il toujours mal
C'est ici que le bât blesse. Donnez à un agent un serveur MCP parfait pour votre bibliothèque de composants, et il produira un code qui compile, utilise les bonnes props et respecte les conventions de la bibliothèque. Cependant, il produira toujours une interface sans point de vue : des grilles de cartes uniformes, une hiérarchie portée uniquement par la graisse de la police, la couleur d'accentuation appliquée partout où elle semble plausible, et un espacement techniquement conforme à l'échelle mais rythmiquement arbitraire.
Il ne s'agit pas d'un manque de connaissances. L'agent connaissait chaque composant. C'est un défaut de jugement, car rien ne lui a indiqué à quoi votre produit doit ressembler.
| Serveur MCP | Directives de design dans le dépôt | |
|---|---|---|
| Réponses | « Quelle est l'API de ce composant ? » | « À quoi cet écran doit-il ressembler ? » |
| Géré par | Les mainteneurs de la bibliothèque | Vous |
| Contenu | Props, variantes, imports, notes d'accessibilité, exemples | Rôles de couleurs, échelle typographique, rythme d'espacement, motifs, interdictions |
| Échec en son absence | Code qui ne s'exécute pas | Code qui s'exécute mais ressemble à celui de tout le monde |
Le second échec est le plus coûteux, car il arrive en production. Une erreur de build vous arrête. Une interface générique, non.
Nous avons analysé 299 fichiers DESIGN.md publiés pour être lus par des agents IA, afin de vérifier s'ils répondaient aux critères de la seconde colonne. La plupart ne le font pas : 86 % spécifient les couleurs en hexadécimal brut sans rôle sémantique, 76 % n'énoncent aucune interdiction, 57 % ne définissent aucun motif distinctif, 69 % ne disent rien sur le mode sombre, et 44 % ne contiennent aucune valeur de taille concrète. 54 % s'appuient sur au moins un adjectif vague, le plus souvent « clean » (39 %) et « moderne » (36 %) — des mots auxquels un modèle répond en produisant la moyenne de tout ce qu'il a vu.
Aucun serveur MCP ne peut corriger cela, car aucun serveur MCP n'en connaît la réponse. C'est votre décision de design, et elle doit être consignée là où l'agent lit systématiquement.
Les kits de design Identity Forge constituent cette seconde colonne : rôles de couleurs sémantiques pour les modes clair et sombre, échelles typographiques et d'espacement, motifs, et directives explicites (do's and don'ts), le tout sérialisé dans un fichier DESIGN.md placé dans le dépôt aux côtés des serveurs MCP que vous utilisez. Parcourez les kits ou découvrez ce qu'est un fichier DESIGN.md.
Quelle information va où
Une règle de fonctionnement, appliquée aux éléments contenus dans un design system :
| Où | Pourquoi | |
|---|---|---|
| API des composants, props, variantes | Serveur | Volume important, évolue souvent, nécessaire uniquement à la demande |
| Exemples de code | Serveur | Trop nombreux pour tenir dans le contexte ; récupérés selon le besoin |
| Catalogue d'icônes | Serveur | Des centaines de noms, nécessaires un par un |
| Rôles de couleurs et usage de chacun | Fichier | Léger, s'applique à chaque décision prise par l'agent |
| Échelles typographique et d'espacement | Fichier | Nécessaire en continu, pas à la demande |
| Interdictions | Fichier | Un agent ne pense jamais à demander ce qui est interdit. Il doit déjà le savoir |
| Motifs et personnalité | Fichier | C'est l'élément qui rend le design unique |
La ligne des interdictions est le test le plus probant. La récupération d'informations (retrieval) ne fait remonter que ce que l'agent a pensé interroger, et un agent sur le point d'ajouter une ombre portée n'a aucune raison de chercher si « les ombres portées sont autorisées ». Les contraintes doivent être présentes avant la décision, ce qui implique un contexte statique, et non un outil.
Configuration avec un kit de design
Si vous utilisez Identity Forge, les deux solutions sont disponibles. Le kit de design fournit les décisions de design à l'agent sous forme de fichier ; le serveur MCP lui donne accès à vos kits, tokens et formats d'exportation via des outils.
{
"mcpServers": {
"identityforge": {
"command": "npx",
"args": ["-y", "identityforge@latest", "mcp"]
}
}
}Exécutez-le parallèlement au serveur propre à votre bibliothèque de composants s'il en possède un — celui de Carbon, de Figma ou votre serveur interne. Ils répondent à des questions différentes et ne sont pas conflictuels.
Une courte checklist d'évaluation
Avant d'adopter un serveur MCP de design system, voici cinq questions à se poser :
- Est-ce que `code_search` renvoie des exemples complets ou seulement des signatures ? Les exemples complets transmettent les conventions. Les signatures, non.
- Est-il versionné par rapport à la bibliothèque que vous utilisez réellement ? Un serveur qui suit la version
latestalors que vous êtes bloqué deux versions majeures en arrière est pire que l'absence de serveur, car il se trompe avec assurance d'une manière nouvelle. - Couvre-t-il les directives d'accessibilité ? Des API de composants sans notes d'accessibilité produisent des composants qui s'affichent mais excluent des utilisateurs.
- Comment fonctionne l'authentification ? Plusieurs serveurs publiés sont réservés au personnel du fournisseur pendant la phase de preview, avec un formulaire de demande pour les autres. Vérifiez ce point avant de baser votre planification dessus.
- Vos agents l'appellent-ils réellement ? Vérifiez les logs. Un serveur non appelé est un fichier de configuration, pas une capacité.
Que fait concrètement un serveur MCP de design system ?
Il expose la documentation de votre design system, les exemples de code des composants, les tokens et les icônes à un agent IA sous forme d'outils appelables. L'agent l'interroge pendant une session au lieu de s'appuyer sur ce qu'il a appris lors de son entraînement, ce qui signifie qu'il écrit pour votre API actuelle plutôt que pour une API mémorisée.
Un serveur MCP rendra-t-il l'UI générée par IA plus esthétique ?
Il la rendra plus fonctionnelle — props correctes, imports réels, variantes actuelles. Il ne lui donnera pas l'apparence de votre produit, car le serveur contient l'API des composants et non vos décisions de design. La qualité visuelle provient des directives sur les rôles, l'échelle, le rythme et les interdictions, lesquelles doivent figurer dans un fichier que l'agent lit à chaque session.
Ai-je besoin d'un serveur MCP si j'ai déjà un DESIGN.md ?
Si votre bibliothèque de composants est volumineuse ou privée, oui — un fichier ne peut pas contenir des centaines d'API de composants, et l'agent inventera celles qu'il ne connaît pas. Si vous utilisez une bibliothèque petite ou très connue, le fichier peut suffire. Ils résolvent des problèmes différents et l'un ne remplace pas l'autre.
Pourquoi mon serveur MCP n'améliore-t-il rien ?
Vérifiez s'il est bien appelé. Les agents n'invoquent un outil que lorsqu'ils jugent en avoir besoin, et un agent convaincu de connaître votre Button n'interrogera rien. L'ajout d'une instruction explicite dans les règles de votre dépôt pour consulter le serveur du design system avant d'écrire des composants règle généralement le problème.
Puis-je exécuter plus d'un serveur MCP de design system ?
Oui, et c'est courant. Un serveur pour la bibliothèque de composants, un serveur pour l'outil de design et un serveur pour le kit de design répondent à des questions différentes et ne sont pas conflictuels. Surveillez le nombre total d'outils plutôt que le nombre de serveurs — une liste d'outils combinée trop longue rend le choix du bon outil plus difficile pour l'agent.