Designsystem MCP-Server: Was sie lösen und was sie nicht lösen

Das Model Context Protocol ist ein offener Standard, um KI-Agenten und Anwendungen über eine Integrationsschicht mit externen Tools und Daten zu verbinden. Anstatt dass das Modell aus dem antwortet, was es während des Trainings absorbiert hat, ruft es ein Tool auf, erhält eine aktuelle Antwort und arbeitet darauf basierend weiter.

Für ein Designsystem bedeutet das einen Server, der vor Ihrer Dokumentation und Ihrem Code sitzt und eine Handvoll Such- oder Lookup-Tools bereitstellt. Der Agent entscheidet während einer Session, wann er sie aufruft.

Das Carbon Design System von IBM veröffentlicht einen MCP-Server, der sich derzeit in der Public Preview befindet. Die dokumentierte Tool-Liste ist ein gutes Template, da sie spezifisch ist und nicht nur vage Ziele formuliert:

Die genannten Gründe von IBM sind der sofortige Zugriff auf Designstandards, hochpräziser generierter Code, der Best Practices folgt, und konsistente Antworten aus einer gemeinsamen Single Source of Truth, die Drift und Nachbesserungen reduziert.

Bitten Sie einen Coding-Agenten, ein Formular mit Ihrer Komponentenbibliothek zu erstellen, und beobachten Sie, was fehlschlägt. Meistens ist es nicht das Layout. Es ist ein Prop, das vor zwei Major-Releases umbenannt wurde, ein Import-Pfad, der sich durch eine Paket-Umstrukturierung verschoben hat, ein Varianten-Name, der nie existierte, oder eine Komponente, die als veraltet markiert und ersetzt wurde.

Dies ist ein Recall-Problem mit einer spezifischen und tückischen Eigenschaft: Falscher Output sieht exakt wie richtiger Output aus. Ein halluzinierter Prop-Name ist syntaktisch korrekt, semantisch plausibel und liest sich im Review fehlerfrei. Man bemerkt es erst zur Laufzeit oder bei einem Type-Error, falls man das Glück hat, Typen zu verwenden.

Mit der Zeit wird es schlimmer. Das Wissen eines Modells über Ihre Bibliothek ist am Zeitpunkt des Trainings eingefroren und driftet mit jedem Release weiter von der Realität weg. Ein privates oder internes Designsystem ist sogar noch schwieriger: Das Modell hat es nie gesehen, daher ist jeder Aufruf, den es schreibt, eine Erfindung. MCP ist die richtige Lösung für beide Fälle, da es das Gedächtnis durch einen Lookup ersetzt.

MCP wird oft als strikt überlegen gegenüber statischem Kontext diskutiert. Das ist es nicht. Es ist ein anderer Trade-off, der deutlich wird, sobald man ihn schriftlich fixiert.

Die Zeile zur Zuverlässigkeit ist diejenige, die Menschen überrascht. Ein MCP-Server hilft nur, wenn der Agent ihn aufruft. Ein Agent, der davon überzeugt ist, Ihre Button-Komponente bereits zu kennen, wird nichts aufrufen. Und genau das ist der Fall, in dem man es am dringendsten benötigt hätte.

In der Zeile zur Skalierbarkeit ist MCP tatsächlich unersetzlich. Eine große Komponenten-Library mit Hunderten von Komponenten, jeweils mit Varianten und Accessibility-Hinweisen, kann nicht einfach in den Kontext kopiert werden. Das ist ein Retrieval-Problem und wird es immer bleiben.

Hier ist der Teil, der oft übersprungen wird: Gibt man einem Agenten einen perfekten MCP-Server für die Komponenten-Library, wird dieser Code produzieren, der kompiliert, echte Props verwendet und den Konventionen der Library folgt. Er wird dennoch ein Interface ohne klare Design-Vision produzieren: uniforme Card-Grids, Hierarchien, die nur über die Schriftstärke gesteuert werden, Akzentfarben, die überall dort eingesetzt werden, wo sie plausibel erscheinen, und Abstände, die zwar technisch aus der Scale stammen, rhythmisch aber beliebig sind.

Das ist kein Wissensdefizit. Der Agent kannte jede Komponente. Es ist ein Defizit im Urteilsvermögen, und es passiert, weil ihm niemand gesagt hat, wie das Produkt aussehen soll.

Das zweite Scheitern ist das kostspieligere, da es in die Produktion geht. Ein Build-Fehler stoppt den Prozess. Ein generisches Interface hingegen nicht.

Wir haben 299 DESIGN.md-Dateien analysiert, die für AI-Agenten veröffentlicht wurden, um zu prüfen, ob sie die Fragen der zweiten Spalte beantworten. Die meisten tun dies nicht: 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an, 76 % nennen keinerlei Verbote, 57 % definieren keine markanten Motive, 69 % sagen nichts zum Dark Mode und 44 % enthalten an keiner Stelle konkrete Größenwerte. 54 % stützen sich auf mindestens ein vages Adjektiv, am häufigsten „clean“ (39 %) und „modern“ (36 %) – Begriffe, die ein Modell erfüllt, indem es den Durchschnitt von allem produziert, was es jemals gesehen hat.

Kein MCP-Server behebt das, da kein MCP-Server die Antwort kennt. Es ist eine Design-Entscheidung, und sie muss an einer Stelle schriftlich fixiert sein, die der Agent bei jedem Durchgang liest.

Eine Faustregel, angewandt auf die Inhalte eines Designsystems:

Die Zeile mit den Verboten ist der strengste Test. Retrieval liefert nur das, wonach der Agent aktiv fragt, und ein Agent, der gerade einen Schlagschatten hinzufügen möchte, hat keinen Grund zu suchen nach „Sind Schlagschatten erlaubt“. Einschränkungen müssen vor der Entscheidung vorliegen, was statischen Kontext erfordert, kein Tool.

Bei der Nutzung von Identity Forge sind beide Komponenten verfügbar. Das Design-Kit liefert dem Agenten die Design-Entscheidungen als Datei; der MCP-Server gibt ihm Zugriff auf Kits, Tokens und Exportformate als Tools.

{
  "mcpServers": {
    "identityforge": {
      "command": "npx",
      "args": ["-y", "identityforge@latest", "mcp"]
    }
  }
}

Betreiben Sie dies parallel zum eigenen Server Ihrer Komponentenbibliothek, falls vorhanden: Carbon, Figma oder Ihre interne Lösung. Sie beantworten unterschiedliche Fragen und stehen nicht im Konflikt.

Bevor Sie einen MCP-Server für ein Designsystem einführen, sollten diese fünf Fragen geklärt werden:

1. Liefert `code_search` vollständige Beispiele oder nur Signaturen? Vollständige Beispiele vermitteln Konventionen. Signaturen tun das nicht.
2. Ist es auf die Version der tatsächlich verwendeten Library abgestimmt? Ein Server, der latest verfolgt, während Sie zwei Major-Versionen zurückgehängt sind, ist schlimmer als gar kein Server, da er auf neue Weise fälschlicherweise überzeugt ist.
3. Berücksichtigt es Leitfäden zur Barrierefreiheit? Component-APIs ohne Hinweise zur Barrierefreiheit führen zu Komponenten, die zwar gerendert werden, aber Menschen ausschließen.
4. Wie sieht das Auth-Konzept aus? Mehrere veröffentlichte Server sind während der Preview nur für das Personal des Anbieters zugänglich, mit einem Anfrageformular für alle anderen. Prüfen Sie dies vor der Planung.
5. Rufen Ihre Agents es tatsächlich auf? Prüfen Sie die Logs. Ein nicht aufgerufener Server ist eine Konfigurationsdatei, keine Capability.