Designsystem MCP-Server: Was sie beheben und was nicht

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

Für ein Designsystem bedeutet das, dass ein Server vor Ihrer Dokumentation und Ihrem Code sitzt und eine Handvoll Such- oder Lookup-Tools bereitstellt. Der Agent entscheidet während einer Session, wann diese aufgerufen werden.

Das Carbon Design System von IBM veröffentlicht einen MCP-Server (derzeit in der Public Preview). Die dokumentierte Tool-Liste ist eine gute Vorlage, da sie spezifisch und nicht bloß ambitioniert ist:

Die von IBM genannten Gründe sind der sofortige Zugriff auf Designstandards, generierter Code mit höherer Fidelity, der Best Practices folgt, sowie konsistente Antworten aus einer gemeinsamen Source of Truth, was Drift und Nacharbeit reduziert.

Bitten Sie einen Coding-Agenten, ein Formular mit Ihrer Komponenten-Library zu erstellen, und beobachten Sie, was schiefgeht. Meist ist es nicht das Layout. Es ist ein Prop, das vor zwei Major-Releases umbenannt wurde, ein Import-Pfad, der sich bei einer Paket-Restrukturierung geändert hat, ein Varianten-Name, den es nie gab, oder eine Komponente, die veraltet und ersetzt wurde.

Dies ist ein Recall-Problem mit einer spezifischen und tückischen Eigenschaft: Falsche Ausgaben sehen exakt so aus wie richtige Ausgaben. Ein halluzinierter Prop-Name ist syntaktisch korrekt, semantisch plausibel und liest sich im Review richtig. Man bemerkt den Fehler erst zur Laufzeit oder – wenn man Glück hat und Typen verwendet – durch einen Typfehler.

Mit der Zeit wird es schlimmer. Das Wissen eines Modells über Ihre Library ist auf dem Stand des Trainings-Cutoffs eingefroren und driftet mit jedem Release weiter von der Realität weg. Bei privaten oder internen Designsystemen ist es noch schlimmer: Das Modell hat sie nie gesehen, sodass jeder geschriebene Aufruf eine Erfindung ist. MCP ist für beides die richtige Lösung, da es das Gedächtnis durch einen Lookup ersetzt.

MCP wird oft als strikt besser als statischer Kontext diskutiert. Das stimmt nicht – es ist ein anderer Kompromiss, und dieser Kompromiss wird deutlich, sobald man ihn aufschreibt.

Die Zeile zur Zuverlässigkeit ist diejenige, die viele überrascht. Ein MCP-Server hilft nur, wenn der Agent ihn auch aufruft. Ein Agent, der davon überzeugt ist, Ihre Button-Komponente bereits zu kennen, wird keinen Aufruf tätigen – und genau das ist der Moment, in dem man die Unterstützung am dringendsten benötigt.

Die Zeile zur Skalierbarkeit ist der Punkt, an dem MCP wirklich unersetzlich ist. Eine große Komponentenbibliothek mit hunderten von Komponenten, jede mit Varianten und Barrierefreiheits-Hinweisen, kann nicht einfach in den Kontext kopiert werden. Das ist ein Retrieval-Problem, und das wird es immer bleiben.

Hier kommt der Teil, der oft übersprungen wird. Geben Sie einem Agenten einen perfekten MCP-Server für Ihre Komponentenbibliothek, und er wird Code produzieren, der kompiliert, echte Props verwendet und den Konventionen der Bibliothek folgt. Er wird jedoch immer noch ein Interface ohne erkennbare Handschrift erstellen: uniforme Card-Grids, eine Hierarchie, die rein über die Schriftstärke gesteuert wird, eine Akzentfarbe, die überall dort angewendet wird, wo sie plausibel erscheint, und Abstände, die technisch zwar aus dem Scale stammen, rhythmisch aber willkürlich wirken.

Das ist kein Wissensdefizit. Der Agent kannte jede Komponente. Es ist ein Urteilsdefizit, und es tritt auf, weil ihm niemand gesagt hat, wie Ihr 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 Durchlauf liest.

Eine Faustregel, angewandt auf die Inhalte eines Designsystems:

Die Zeile mit den Verboten ist der präziseste Test. Retrieval liefert nur das, was der Agent abfragt, 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 Komponenten-Bibliothek, falls vorhanden – etwa von Carbon, Figma oder Ihrem internen Server. 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 Bibliothek versioniert, die Sie tatsächlich verwenden? Ein Server, der latest verfolgt, während Sie zwei Major-Versionen zurückgehängt sind, ist schlimmer als gar kein Server, da er auf eine neue Art und Weise felsenfest falsch liegt.
3. Berücksichtigt es Leitlinien zur Barrierefreiheit? Komponente-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.