Qu'est-ce qu'un serveur MCP, brièvement
Le Model Context Protocol est un standard ouvert permettant de connecter des agents et des applications IA à des outils et des 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é pendant 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 aspiratoire :
| Ce qu'il retourne | |
|---|---|
docs_search | Conseils sur les composants, utilisation, 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 standards de design, un code généré de plus haute fidélité respectant les meilleures pratiques, et des réponses cohérentes provenant 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) qu'une simple signature de type ne transmet 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 lors d'une version majeure précédente, 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 rappel, 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 le rappel car le rappel é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. Il s'agit d'un arbitrage différent, et cet arbitrage devient clair une fois mis par écrit.
| Appel d'outil MCP | Fichier dans le dépôt | |
|---|---|---|
| Lorsqu'il est disponible | Lorsque l'agent décide de l'appeler | À chaque tour, sans condition |
| Fraîcheur | Toujours à jour | Aussi actuel 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 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 du choix de l'agent de l'appeler | Il est simplement présent |
| Configuration | Un serveur en cours d'exécution, une configuration, parfois une authentification | Écrire un fichier, le commiter |
La ligne sur la fiabilité est celle qui surprend les utilisateurs. Un serveur MCP n'est utile que si l'agent l'appelle, et un agent convaincu de déjà connaître votre composant Button n'appellera rien. C'est précisément le cas où vous en aviez le plus besoin.
Si vous installez un serveur MCP de design system et ne voyez aucun changement dans la qualité du résultat, vérifiez s'il est réellement appelé avant de conclure qu'il ne fonctionne pas. Une erreur par excès de confiance ne déclenche pas de recherche. Une instruction dans votre fichier de documentation du dépôt disant « interrogez toujours le serveur du design system avant d'écrire un composant » est souvent l'élément manquant.
La ligne sur l'échelle est celle où MCP est véritablement irremplaçable. Une bibliothèque de composants massive comprenant des centaines de composants, chacun avec ses variantes et ses notes d'accessibilité, ne peut pas être collée dans le contexte. C'est un problème de récupération (retrieval) et cela le restera toujours.
Pourquoi l'agent conçoit toujours mal
Voici la partie qui est souvent négligée. Donnez à un agent un serveur MCP parfait pour votre bibliothèque de composants et il produira un code qui compile, utilise les vraies props et respecte les conventions de la bibliothèque. Il produira tout de même une interface sans véritable identité visuelle : des grilles de cartes uniformes, une hiérarchie portée uniquement par la graisse de la police, une couleur d'accentuation appliquée partout où elle semble plausible, et un espacement qui est techniquement issu de l'échelle mais rythmiquement arbitraire.
Il ne s'agit pas d'un défaut de connaissance. L'agent connaissait chaque composant. C'est un défaut de jugement, et cela arrive parce que rien ne lui a indiqué l'aspect visuel de votre produit.
| Serveur MCP | Directives de design dans le dépôt | |
|---|---|---|
| Réponses | « Quelle est l'API de ce composant? » | « À quoi devrait ressembler cet écran? » |
| Géré par | Les mainteneurs de la bibliothèque | Vous |
| Contenu | Props, variantes, imports, notes d'accessibilité, exemples | Rôles des couleurs, échelle typographique, rythme d'espacement, motifs, interdictions |
| L'échec en son absence | Du code qui ne s'exécute pas | Du 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 d'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 sémantiques des couleurs pour les modes clair et sombre, échelles typographiques et d'espacement, motifs, ainsi que des règles explicites de ce qu'il faut faire ou ne pas faire, le tout sérialisé dans un fichier DESIGN.md placé dans le dépôt aux côtés de vos serveurs MCP. Parcourez les kits ou découvrez ce qu'est un fichier DESIGN.md.
Quoi mettre 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 des couleurs et usage de chacune | Fichier | Léger, s'applique à chaque décision prise par l'agent |
| Échelle 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 la partie 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 fichier 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 de bibliothèque de composants, un serveur d'outil de design et un serveur de 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.