Component Library MCP: So nutzen Agents echte Komponenten
Bitte Claude Code um eine Einstellungsseite, und du hast sie in einer Minute. Vielleicht erfindet es dabei aber einen <Button intent="primary">, den deine Bibliothek nie hatte, schreibt #3b82f6 hart in den Code, wo ein Token hingehört, und baut einen Date Picker nach, den du längst hast. Ein Component Library MCP Server behebt das an der Quelle: Er gibt dem Agent Tools, mit denen er nachschlägt, was es gibt, die echten Props liest und die echten Dateien installiert. Dieser Guide zeigt, wie eine React-Komponentenbibliothek sich Claude Code, Cursor und Codex zugänglich macht, welche vier Teile dafür zusammenspielen (ein MCP-Server, eine Regeldatei, llms.txt und eine Registry) und welches Setup unsere CLI für dich schreibt.
Wir bauen Wingo UI, deshalb nutzen die Beispiele unseren Server, unsere CLI und unsere Registry, mit Ausgaben aus Release 1.7.0. Der Ansatz funktioniert aber mit jeder Bibliothek, auch zu einem internen Design System, und wo ein anderes Tool besser passt, sagen wir das. Kürzere Guides zu Agents und UI findest du unter UI mit KI-Agenten bauen: AGENTS.md vs CLAUDE.md vs Cursor-Regeln für die Regeldatei, ein Claude Code shadcn Setup für den shadcn-MCP-Server neben einer zweiten Registry und einen Guide zur React AI Chat UI für den Fall, dass der Screen, den du baust, der Chat selbst ist.
Was ist ein Component Library MCP Server?
Ein Component Library MCP Server ist ein Server für das Model Context Protocol (opens in a new tab), der eine UI-Bibliothek in Tools verwandelt, die ein Agent aufrufen kann: den Katalog durchsuchen, Props und Usage einer Komponente lesen, die Designregeln abrufen und installierte Versionen mit dem neuesten Release vergleichen. Der Agent fragt nach, statt sich zu erinnern.
Der Client (Claude Code, Cursor, Codex, Gemini CLI) listet die Tools eines Servers auf und lässt das Modell entscheiden, wann es sie aufruft. Ein Server läuft als lokaler Prozess über stdio oder als Remote-Endpoint über Streamable HTTP. Remote-Server lassen sich leichter aktuell halten, weil jeder Client ein neues Release sieht, sobald du es deployst.
Die React Component Library MCP Server, die wir geprüft haben, gibt es in drei Formen. So sehen sie im Vergleich aus, Stand Oktober 2026:
Quellen, geprüft im Oktober 2026: die shadcn-MCP-Doku (opens in a new tab), der MCP-Guide von Material UI (opens in a new tab), der MCP-Guide von React Suite (opens in a new tab) und unsere MCP-Server-Doku.
Die erste Form ist ein Doku-Lookup. MUI und React Suite liefern npm-Pakete aus, der Agent braucht also korrekte Props und funktionierende Links, aber nie Quelldateien. Läuft deine App auf Material UI, ist der eigene Server von MUI die richtige Wahl.
Die zweite Form ist ein Registry-Installer. Die shadcn-Doku beschreibt, wie man aus jeder shadcn-kompatiblen Registry in components.json auflistet, sucht und installiert; Designregeln oder Update-Checks erwähnt sie nicht. Beziehst du Komponenten aus mehreren Registries, deckt ein einziger shadcn-Server alle ab, und das ist ein echter Vorteil.
Eine Bibliothek, deren Quellcode du in dein Projekt kopierst, braucht die dritte Form: Doku, Installation und Wartung in einem Server. Wenn Komponenten als bearbeitbarer Code in deinem Repository liegen, muss der Agent wissen, was die Bibliothek bietet, welche Version dein Projekt hat und wie die Bibliothek benutzt werden soll. Genau den letzten Punkt transportiert eine Props-Tabelle allein nicht.
Warum erfinden Coding-Agents Komponenten?
Weil das Modell aus seinen Trainingsdaten schreibt, und die sind älter als deine Bibliotheksversion und neigen zu den häufigsten APIs. Ohne Möglichkeit nachzuprüfen füllt der Agent jede Lücke mit der wahrscheinlichsten Vermutung: die shadcn-API in einer Bibliothek, die nicht shadcn ist, ein Prop, das vor zwei Major-Versionen umbenannt wurde, ein Hex-Wert, wo ein semantisches Token hingehört.
Das Engineering-Team von monday.com hat denselben Fehler in How We Use AI to Turn Figma Designs into Production Code (opens in a new tab) beschrieben (Rivka Ungar, 2. Februar 2026). Ihr erster Versuch, einen Figma-Link mit dem Figma-MCP in Cursor einzufügen, lieferte Code mit hartcodierten Farben, der ihre Design-System-Komponenten überging. Ihre Diagnose sinngemäß: Das Modell wusste schlicht nicht, was ihr Design System eigentlich ist. Danach bauten sie einen MCP-Server für das Design System und stellten fest, dass auch der allein nicht reichte. Der MCP-Server lieferte zwar Wissen, entschied aber nicht, wie und wann dieses Wissen über eine ganze UI hinweg anzuwenden ist.
Ein Server voller richtiger Fakten bringt nichts, wenn der Agent ihn nie aufruft, ihn erst nach dem Code aufruft oder die Props liest und dann alles mit Utility-Klassen neu stylt. Der Server ist deshalb nur eines von vier Teilen.
Was braucht ein Agent außer dem MCP-Server?
Er braucht eine Regeldatei, die sagt, wann er welches Tool aufruft, Doku, die er ohne MCP lesen kann, und eine Registry plus CLI, die die Dateien schreibt. Jedes Teil beantwortet eine andere Frage und ändert sich unterschiedlich schnell:
Entscheidend ist die Aufteilung: Die Regeldatei bleibt kurz und stabil, und alles, was sich ändert, liegt hinter dem Server. Props-Tabellen, die du in eine Regeldatei kopierst, veralten mit dem nächsten Release, und ein Agent vertraut eher der Kopie, die schon in seinem Kontext steht, als einem Tool, das er erst aufrufen müsste. Unsere Regeldatei nennt Tools und Befehle. Die Props einer Komponente listet sie nie auf.
Welche Tools sollte ein Component Library MCP Server anbieten?
Ein paar reine Lese-Tools, zugeschnitten auf das, was ein Agent beim Bauen von UI tut: finden, lesen, die Regeln befolgen, installieren, aktuell bleiben. Unserer hat zehn:
search_components: findet Komponenten, Blöcke, Hooks und Helper per Stichwort.list_categories: zeigt die Kategorien mit der Zahl ihrer Items.get_component: Props, Parts, Usage, Abhängigkeiten, den Installationsbefehl und den Quellcode.get_block: einen ganzen Screen oder Abschnitt und die Komponenten, aus denen er besteht.get_design_rules: Tokens, Größen, Motion, Formulare, Overlays und Mobile-Regeln.get_theme_tokens: die CSS-Variablen für Light und Dark Mode.get_install_instructions: das Projekt-Setup für Next.js oder Vite.check_updates: vergleicht installierte Items mit dem neuesten Release.get_changelog: die letzten Releases und ihre Notes.get_account_status: ob der Key Pro hat, mit den Links zum Upgrade.
Dazu kommt ein Prompt, build_screen, der den Agent durch Suche, Regeln, Installation und Zusammensetzen führt. Jedes Tool ist in seinen Annotations als read-only und idempotent markiert, und keines schreibt auf deine Platte. Dateien schreibt die CLI.
Die Suche sollte Slugs und je eine Zeile liefern
Ein Suchergebnis ist eine kurze Liste, die der Agent auf einen Blick erfasst. Das ist die echte Antwort unseres Servers auf search_components mit der Query „orders table with filters“ und limit: 5, gekürzt auf die ersten drei Treffer:
Jeder Treffer enthält Slug, Art, Zugriffsstufe und Version, und die letzte Zeile nennt das nächste Tool. So muss der Agent nie raten, welcher Aufruf aus einem Slug Props macht. Der dritte Treffer passt kaum. Das ist in Ordnung: Eine Zeile Beschreibung reicht dem Agent, ihn zu überspringen, ohne dafür einen get_component-Aufruf zu verbrauchen.
Props brauchen ihre Defaults
get_component liefert die Props-Tabelle, die auch die Doku-Seite zeigt, mit Typen und Defaults, dazu Parts, ein Usage-Beispiel, die npm- und Registry-Abhängigkeiten und den Installationsbefehl. Defaults halten den generierten Code kurz. Ein Agent, der weiß, dass der Button standardmäßig type="button", tone="neutral" und size="md" hat, schreibt <Button>Cancel</Button>, statt geratene Props auszubuchstabieren. Und einer, der weiß, dass loading die Breite hält und aria-busy setzt, packt keine eigene Spinner-Logik um den Button.
Unten siehst du diesen Button mit dem Brand-Tone und einem Loading-Label, beides über Props gesetzt.
$ npx wingo-ui@latest add buttonOhne JavaScript zeigt die Demo einen gefüllten Button „Pay now“ in der Brand-Farbe; ein Klick zeigt einen Spinner und „Paying“ in derselben Breite.
Halte die Tool-Ausgabe klein
Große Antworten stoßen in den Clients an harte Grenzen. Laut der MCP-Doku von Claude Code (opens in a new tab), Stand Oktober 2026, warnt Claude Code, wenn ein Tool-Ergebnis 10.000 Tokens überschreitet, kappt Ergebnisse standardmäßig bei 25.000 Tokens (MAX_MCP_OUTPUT_TOKENS hebt das an) und speichert Textergebnisse über 50.000 Zeichen in eine Datei, statt sie in den Kontext zu legen.
Unsere Data Table ist eine Datei mit 3.940 Zeilen, etwa 150 KB TypeScript. Ihre Doku ohne Quellcode kommt mit etwa 18.000 Zeichen zurück, rund 4.500 Tokens. Mit Quellcode (bei einem Pro-Key) wächst derselbe Aufruf auf über 160.000 Zeichen und reißt jede dieser Grenzen. Die Regel für Agents, und für alle, die so einen Server entwerfen, lautet deshalb: Doku über MCP, Dateien über die CLI. Ruf get_component bei großen Items mit includeSource: false auf und lass npx wingo-ui@latest add den Code schreiben.
Für Regeln gilt dasselbe. get_design_rules mit dem Topic all liefert etwa 45.000 Zeichen, rund 11.000 Tokens bei den üblichen vier Zeichen pro Token, und liegt damit schon über der Warnschwelle von Claude Code. Das Topic mobile allein hat etwa 1.900 Zeichen, forms etwa 4.200. Frag nach dem Topic, das die Aufgabe braucht.
Fehler sollten sagen, was als Nächstes zu tun ist
Ein Tool-Fehler ist ein Prompt, den der Agent liest, also schreib ihn auch so. Bei einem unbekannten Slug antwortet der Server mit den ähnlichsten Treffern und verweist zurück auf search_components. Fragt der Agent ein Pro-Item ohne Pro-Key an, kommt die Doku zurück und dazu dieser Text, Wort für Wort von unserem Server (Links gekürzt, Zeilen umbrochen):
„Do not re-create it from the docs“ ist der wichtigste Satz auf dem ganzen Server. Ein Agent, der gerade eine vollständige Props-Tabelle und eine lange Beschreibung der Interaktion gelesen hat, hat alles, um einen Nachbau zu versuchen. Das Ergebnis ist eine halbe Kopie, die auf dem Papier zur Doku passt und sonst zu nichts: kein Versionsprotokoll, keine Updates, keiner der Edge Cases, die die Beschreibung in einer Zeile zusammenfasst.
Die Server-Instructions liest der Agent zuerst
Claude Code schaltet Tool Search standardmäßig ein, deshalb werden zu Beginn einer Session nur die Tool-Namen und die Instructions jedes Servers geladen; die vollständigen Tool-Definitionen folgen erst, wenn das Modell danach sucht. Laut derselben Doku schneidet Claude Code jede Tool-Beschreibung und die Instructions jedes Servers standardmäßig bei 2.048 Zeichen ab. Die Instructions sind die Visitenkarte deines Servers beim Modell: welche Aufgaben er übernimmt, wann es nach seinen Tools suchen soll, und die Regeln, die das Abschneiden überstehen müssen. Schreib „erst suchen, dann UI schreiben“ in die ersten Zeilen.
Was dieses Limit kostet, haben wir an unserem eigenen Server gemerkt. Seine Instructions haben in Release 1.7.0 2.235 Zeichen, deshalb schneidet Claude Code den letzten Satz ab, ausgerechnet den, der verbietet, eine Komponente ohne den passenden Key nachzubauen. Die Regel erreicht den Agent trotzdem, weil jede Ablehnung und die Regeldatei sie wiederholen. Zähl deine Zeichen und wiederhole jede wichtige Regel an einer Stelle, die das Modell nicht übersehen kann.
Wie verbinde ich Claude Code, Cursor und Codex?
Ein einziger CLI-Befehl schreibt die MCP-Config und die Regeln für deinen Agent. Ist WINGO_UI_API_KEY gesetzt, schreibt er die HTTP-Configs unten, die den Key aus der Umgebung lesen, sodass er nie in deinem Repository landet; ohne die Variable schreibt er den lokalen stdio-Proxy. Willst du den MCP Server einrichten, ohne die CLI zu nutzen, geht das auch von Hand.
Ein zweiter Aufruf ändert nichts, und die anderen Server in deinen MCP-Configs bleiben erhalten. Hier landen die Dateien für jeden Agent:
Der Zugriff hat drei Stufen. Ohne Key antworten Suche, Doku, Props, Designregeln und Tokens, ohne Quellcode. Ein Key aus einem kostenlosen Account (nur E-Mail, keine Karte) fügt den Quellcode der 75 kostenlosen Items hinzu. Ein Pro-Key fügt den Quellcode aller 326 Items hinzu. Leg den Key in deinem Account an und exportier ihn in deinem Shell-Profil als WINGO_UI_API_KEY.
Claude Code
Claude Code speichert MCP-Server in drei Scopes: local (der Default, privat für dich in ~/.claude.json), project (.mcp.json im Stammordner des Repositorys, für das ganze Team eingecheckt) und user (alle deine Projekte). Für eine Bibliothek, die das Team teilt, nimm den Project-Scope; .mcp.json setzt ${VAR} aus der Umgebung ein, deshalb kannst du die Datei gefahrlos committen:
Für ein schnelles persönliches Setup fügt dieser Einzeiler den Server im Local-Scope hinzu:
Führ /mcp in einer Session aus, um zu sehen, ob der Server verbunden ist. Wenn du schon andere Claude Code MCP Server nutzt, steht dieser einfach daneben in derselben Datei, und agents install lässt die Einträge stehen, die es nicht selbst geschrieben hat. Unser Claude Code shadcn Tutorial geht den shadcn-MCP-Server, seinen Skill und eine zweite Registry im selben Projekt durch.
Cursor
Cursor liest .cursor/mcp.json im Projekt und ~/.cursor/mcp.json für alle Projekte. Es nutzt eine eigene Variablensyntax, ${env:NAME}, beschrieben in der MCP-Doku von Cursor (opens in a new tab):
Codex
Codex liest MCP-Server aus ~/.codex/config.toml (oder aus .codex/config.toml eines vertrauenswürdigen Projekts). Bei einem Remote-Server nennt bearer_token_env_var die Variable, die den Token enthält, so wie es die MCP-Doku von Codex (opens in a new tab) beschreibt. Starte Codex danach neu, damit es den Server lädt. Das Codex MCP Setup Tutorial deckt den Rest eines Codex-Projekts ab: AGENTS.md-Regeln, Prompts, die bei echten Blöcken ansetzen, und die Lösungen, wenn sich ein Server nicht verbinden will.
Alle anderen Clients
Clients, die an einen Remote-Server keinen Header schicken können, nutzen den lokalen Proxy. Er liest den Key, den wingo-ui login gespeichert hat, und spiegelt die Remote-Tools, sodass neue Tools erscheinen, ohne dass du etwas aktualisierst:
Was gehört in die Regeldatei?
Wann welches Tool dran ist, wie installiert wird und was der Agent nie tun darf, in so wenigen Zeilen wie möglich. Das ist der komplette Block, den wir in AGENTS.md, CLAUDE.md oder GEMINI.md schreiben:
Einige Entscheidungen darin sind bewusst getroffen. Jeder Punkt sagt dem Agent, was er tun soll oder wann. Der Block nennt Tools und Befehle, listet aber keine Props einer Komponente, denn Props ändern sich und Tool-Namen nicht. Er hat einen Fallback für Sessions ohne MCP-Server, damit der Agent auf die CLI ausweicht, statt zu raten. Und er trägt eine Versionsmarke: npx wingo-ui@latest agents status sagt dir, ob deine Kopie aktuell ist, und agents update schreibt nur den Text zwischen den Markierungen neu.
Claude Code bekommt außerdem einen Skill mit dem längeren Workflow, und Cursor eine Projektregel, die für .tsx-, .jsx- und .css-Dateien gilt. Das komplette Setup steht auf der Doku-Seite zu Coding-Agents.
Für eine interne Bibliothek übernimmst du die Struktur: eine Zeile, was die Bibliothek ist, eine, welche Tools vor dem UI-Code dran sind, eine zur Installation, eine zum Styling, ein Fallback. Fünf Zeilen, die ein Agent befolgt, schlagen fünfzig, die er überfliegt. Welche dieser Dateien jeder Agent liest und wie eine einzige AGENTS.md Claude Code, Codex und Cursor zugleich bedient, steht in unserem Vergleich AGENTS.md vs CLAUDE.md.
Wo passen llms.txt und Markdown-Doku hinein?
Sie bedienen Assistenten, die eine URL lesen können, aber keine MCP-Verbindung haben, und sie springen ein, wenn der Server nicht eingerichtet ist. Der llms.txt-Vorschlag (opens in a new tab), veröffentlicht von Jeremy Howard im September 2024, legt eine Markdown-Datei in den Stammordner der Website: eine H1 mit dem Namen, eine kurze Zusammenfassung, dann Abschnitte mit Links. Er empfiehlt außerdem eine saubere Markdown-Version jeder Seite unter derselben URL mit angehängtem .md, und seine aktuelle Version (aktualisiert im August 2026) beschreibt einen rel="alternate"-Link vom Typ text/markdown, der darauf zeigt.
Unsere Umsetzung folgt diesem Aufbau:
- /llms.txt ist die Karte: was die Bibliothek ist, die Zahlen, die Preise, die Doku-Seiten, die Installationsbefehle, ein Link pro Kategorie und eine Zeile pro Item mit seinem Markdown-Link.
/llms/<category>.txtenthält die Item-Doku einer Kategorie, zum Beispiel alle Tabellen oder alle Overlays.- Jede Doku-Seite hat einen Markdown-Zwilling, etwa /components/button.md, verlinkt im HTML-Head.
- /llms-full.txt enthält alles in einer Datei, etwa 3,3 MB, Stand Oktober 2026 (die Doku von Release 1.7.0 plus die Blogposts).
Diese letzte Datei ist die Falle. Ein Modell, das 3,3 MB Doku bekommt, kürzt sie entweder oder verbraucht seinen Kontext für Komponenten, die es nie nutzen wird. Behandle llms.txt als Karte und schick den Agent zu der einen Kategorie-Datei oder .md-Seite, die die Aufgabe braucht. Bei einem Chat-Assistenten, der URLs abrufen kann, legt ein Prompt wie „lies https://wingo-ui.com/components/data-table.md (opens in a new tab) und schreib damit eine Bestelltabelle“ die echten Props mit einem einzigen Abruf vor das Modell.
Was llms.txt nicht kann, ist handeln. Es kann dem Agent nicht sagen, welche Version dein Projekt hat, ob dein Key ein Item abdeckt, und es schreibt keine Dateien mit ihren Abhängigkeiten. Deshalb ist es in unseren Regeln der Fallback und der MCP-Server der Standard.
Warum über eine Registry installieren statt Code einzufügen?
Weil Registry und CLI die exakten Dateien mit ihren Abhängigkeiten schreiben und festhalten, was sie installiert haben, und dieses Protokoll der einzige Weg ist, auf dem spätere Releases Code erreichen, den du bearbeitet hast. Ein Agent, der Quellcode aus einem Tool-Ergebnis kopiert, überspringt alle drei Schritte.
Nimm den Block Login Page. Der Befehl npx wingo-ui@latest add login-page schreibt drei Dateien nach components/blocks, zieht dann die 16 Registry-Items nach, von denen der Block abhängt (Alert, Avatar, Button, Checkbox, Input, OTP Input, Password Input, Separator, Toast und sieben Hooks und Helper), plus alles, wovon diese abhängen, und installiert seine npm-Pakete: motion, lucide-react, react-hook-form und zod. Version und Content-Hash jedes Items hält der Befehl in wingo-ui.json fest und legt eine unveränderte Kopie unter .wingo-ui/base/ ab. Wenn ein Release den Block ändert, führt npx wingo-ui@latest update einen Drei-Wege-Merge zwischen dieser unveränderten Kopie, deiner bearbeiteten Datei und der neuen Version aus, so wie git Branches zusammenführt.
Ein Agent, der Code aus get_block einfügt, kann eine Abhängigkeit verpassen, hält nichts fest und hinterlässt dir Dateien, die kein Tool aktualisieren kann. Deshalb trägt jede Antwort den Installationsbefehl, und die Regeln sagen „mit der CLI installieren“, bevor überhaupt etwas zum Styling kommt.
Die Registry spricht auch das shadcn-Format. Kostenlose Items installierst du direkt über ihre URL, zum Beispiel npx shadcn@latest add https://wingo-ui.com/r/button.json, und Pro-Items über ihren Namen, sobald die @wingo-ui-Registry mit deinem Key in components.json steht. Damit kann sie auch der shadcn-MCP-Server installieren. Den Haken beschreibt unsere Installationsseite: Die shadcn-CLI hält keine Versionen fest, deshalb kann wingo-ui update spätere Änderungen nicht in so installierte Dateien mergen.
Wie sieht eine komplette Agent-Session aus?
Nimm eine Next.js-App, die schon eine wingo-ui.json hat, und einen schlichten Prompt: „Bau eine Anmeldeseite mit Zwei-Faktor-Codes und eine Bestellseite mit Filtern, mit Wingo UI.“ Ist der Server verbunden und sind die Regeln eingerichtet, geben Regeln und Server-Instructions diesen Weg vor, ohne dass der Prompt ein einziges Tool nennt:
check_updatesmit den Items auswingo-ui.jsonund ein einzeiliger Bericht, was sich upstream geändert hat.search_componentsmit „sign in page“ und der Artblock. Auf unserem Server ist der erste Trefferlogin-page.get_blockfürlogin-page: die Props, die Komponenten, aus denen der Block besteht, und der Installationsbefehl.search_componentsmit „orders table with filters“, dannget_componentfürdata-tablemitincludeSource: false.get_design_rulesfür die Topicsformsundmobile.- Eine Installation für alles:
npx wingo-ui@latest add login-page data-table(Button, Input und der Rest kommen als Abhängigkeiten mit). - Zwei Seiten, gebaut aus den installierten Komponenten und über ihre Props konfiguriert.
Schritt 2 ist der, den ein Setup ohne Server überspringt. Ohne Suchmöglichkeit schreibt ein Agent ein Anmeldeformular von Grund auf: zwei Felder, ein Button, vielleicht ein Link „Passwort vergessen“, der ins Leere führt. Der Block, den die Suche liefert, deckt die Anmeldung per Passwort, E-Mail-Link oder Code ab, Buttons für Google, Apple und Microsoft, Zwei-Faktor-Codes, die nach drei falschen Versuchen für eine Minute sperren, und den kompletten Ablauf zum Zurücksetzen des Passworts. Der Seitencode ist kurz, weil der Block die Arbeit macht:
Ein abgelehntes Promise aus onSignIn zeigt seine Meldung in einem Alert über dem Formular, und twoFactor schickt ein korrektes Passwort weiter zum Code-Schritt. Drei falsche Codes sperren die Eingabe für eine Minute, egal was dein Handler tut.
Die Falle steckt in den Handlern, die der Code weglässt. Der Block liefert simulierte Handler mit, damit seine Demo funktioniert, und jedes on*-Prop, das du auslässt, behält seine Simulation. Ohne onVerifyCode akzeptiert die Zwei-Faktor-Ansicht 123456. Ohne showProviders={false} oder ein eigenes onProvider zeigen die Buttons für Google, Apple und Microsoft 1,2 Sekunden lang einen Spinner und rufen dann onSuccess auf. Ein Agent, der onSignIn verdrahtet und aufhört, liefert eine Login-Seite aus, auf der ein Klick auf Google direkt zu /orders führt, ohne dass sich jemand anmeldet. Die Props-Tabelle aus get_block dokumentiert jeden dieser Defaults, also ist die Lösung dieselbe wie überall: Props lesen, dann jeden Handler verdrahten oder das Feature abschalten.
Die Demo unten läuft auf diesen simulierten Handlern, mit den Standard-Methoden und -Providern.
$ npx wingo-ui@latest add login-pageOhne JavaScript zeigt die Demo das Anmeldeformular: Felder für E-Mail und Passwort, eine Checkbox „Remember me for 30 days“, den Anmelde-Button, die Option mit dem E-Mail-Link und Buttons für Google, Apple und Microsoft.
Die Bestellseite folgt demselben Muster. Die Data-Table-Props, die der Agent gelesen hat, bestimmen den Großteil des Codes: typisierte Spalten aus createColumns, eine Badge-Spalte mit einem Tone pro Status, eine Währungsspalte mit Summe im Footer, Filter pro Spalte und Schnellfilter-Chips.
Die Seite selbst bleibt eine Server Component, die die Zeilen lädt und weiterreicht:
Die Aufteilung ist gewollt. getRowId, rowActions und onSelect sind Funktionen (genau wie jeder eigene cell-Renderer in den Spalten), und der App Router kann keine Funktionen von einer Server Component an eine Client Component übergeben. Ein Agent, der <DataTable> mit Inline-Callbacks direkt aus einer Server-page.tsx rendert, bekommt beim Rendern genau diesen Fehler. Wenn Spalten und Callbacks in einer Client-Datei liegen und nur einfache Zeilen übergeben werden, passiert das nicht.
Zwei weitere Details stammen direkt aus der Doku, die get_component liefert. Die mobile-Rollen bestimmen Titel und Untertitel jeder Karte unter 768px, wo die Tabelle standardmäßig zu Karten wird (mobileLayout="cards"). Und persistKey merkt sich Sichtbarkeit, Reihenfolge und Breite der Spalten, Dichte und Seitengröße im Local Storage.
$ npx wingo-ui@latest add data-tableOhne JavaScript zeigt die Demo eine Kundentabelle (Kunde, Stadt, Status, Betreuer, Saldo, letzte Rechnung) mit einem Suchfeld, Schnellfilter-Chips wie Active und Overdue sowie Aktionen für Export und neue Kunden.
Noch ein Fall, den du einplanen solltest: Login Page und Data Table sind beide Pro. Ohne Pro-Key liefern die Schritte 3 und 4 die Doku plus die oben zitierte Ablehnung, und ein Agent, der die Regeln befolgt, meldet die Lücke, statt beide aus ihren Props-Tabellen nachzubauen.
Wie bleiben Komponenten, die ein Agent installiert hat, aktuell?
Der Agent prüft, du entscheidest. Zu Beginn jeder UI-Arbeit verlangen die Regeln check_updates mit den Items aus wingo-ui.json. Die Antwort listet jedes Update mit seinem Semver-Sprung und den Notes jedes Bibliotheks-Releases, das das Item berührt hat, danach die Items, die aktuell sind. Hier die echte Ausgabe für ein Projekt mit einer älteren Data Table und einem aktuellen Button:
Die Nummern vor den Notes sind Bibliotheks-Releases; das Item selbst geht von 1.0.0 auf 1.1.0.
Der Claude-Code-Skill sagt dem Agent, dass er Updates erwähnen und nur ausführen soll, wenn du zustimmst. Ein Update ist eine Codeänderung in Dateien, die dir gehören, und verdient dasselbe Review wie jeder andere Diff. Im Terminal reichen dafür drei Befehle:
Die Regeln haben ihre eigene Version: agents status meldet eine alte Kopie, und agents update frischt sie auf. Willst du eigene Änderungen an einer verwalteten Datei behalten, lösch ihre Zeile wingo-ui:managed. Die Doku zu Updates erklärt Konflikte und das Flag --theirs, und unser Guide zum Aktualisieren von shadcn-Komponenten, ohne Änderungen zu verlieren zeigt denselben Drei-Wege-Merge von Hand mit git.
Wie prüfe ich, was der Agent gebaut hat?
Prüf es wie einen Pull Request von einem schnellen Junior-Entwickler, der die Doku gelesen hat. Der Server bringt den ersten Entwurf auf die richtigen Komponenten; den Blick auf das Ergebnis ersetzt er nicht. Unsere Checkliste:
- Fest eingesetzte Farben und Radien. Durchsuch den Diff nach Hex-Werten,
rgb(und Klassen mit Arbitrary Values wierounded-[...]. Die Regeln verlangen semantische Tokens, und eine verirrte Hex-Farbe übersieht man leicht. - Nachgebaute Komponenten. Eine neue Datei unter
components/, die wie ein Bibliotheks-Item aussieht, heißt: Der Agent hat die Suche übersprungen. - Restyling statt Props. Eine lange Klassenliste an einem Button ersetzt oft ein
variant,toneodersize, das der Agent nicht gelesen hat. - Simulierte Handler. Blöcke liefern Demo-Handler für jedes
on*-Prop. Vergleich die Handler, die der Agent verdrahtet hat, mit den Features, die auf dem Screen geblieben sind, wie im Login-Beispiel oben. - Handybreite und beide Themes. Bei 390px sollten Tabellen zu Karten werden und Menüs als Bottom Sheets aufgehen (unser Guide zu Mobile-first React-Komponenten hat die komplette Liste); Light und Dark sollten beide sauber aussehen.
- Bibliotheksdateien.
npx wingo-ui@latest diff <slug>zeigt, ob der Agent eine davon bearbeitet hat. Änderungen sind erlaubt, werden aber beim nächsten Update zu Merge-Arbeit.
Solltest du einen MCP-Server für dein eigenes Design System bauen?
Wenn mehrere Leute oder Agents UI auf einer internen Bibliothek bauen, ja. Ein UI Component Library MCP Server ist ein kleineres Projekt, als es klingt: Unserer ist eine Datei mit etwa 220 Zeilen auf dem TypeScript SDK (@modelcontextprotocol/server) plus vier kleine Tool-Module, und der Großteil der Arbeit steckte in den Daten dahinter. Das Protokoll war der einfache Teil. Was wir einem Design-System-Team mitgeben würden, nachdem wir unseren gebaut haben:
- Fang mit Metadaten an, die du schon pflegst. Unsere Tools lesen dieselben Registry-Metadaten, aus denen die Doku-Seiten entstehen. Wenn deine Props nur in TypeScript-Typen leben, zieh sie einmal in Daten heraus, die Doku und Server teilen, sonst laufen die beiden auseinander.
- Halte jedes Tool read-only. Lass den Agent lesen; schreiben sollen deine CLI oder dein Paketmanager.
- Gib strukturierten Content und Text zurück. Das Modell liest den Text; Skripte und künftige Clients parsen die Struktur.
- Halte Ausgaben klein und nenne den nächsten Schritt. Slugs in der Suche, der Quellcode hinter einem Flag, das nächste Tool am Ende.
- Schreib Fehler als Anweisungen. „Meintest du …“ und „nicht nachbauen“ legen dem Modell die Lösung genau dann vor, wenn es sie braucht.
- Halte die Server-Instructions unter 2.048 Zeichen, mit dem Satz „wann du diesen Server nutzt“ ganz vorn. Unsere liegen in 1.7.0 um 187 Zeichen darüber, und der Satz, der wegfällt, ist uns wichtig.
- Liefere das Release aus, das du deployt hast. Ein frischer Server pro Request, gestützt auf die Registry dieses Deploys, heißt: Agents sehen nie veraltete Props.
- Biete HTTP und stdio an. Remote-HTTP für Clients, die Header schicken, einen lokalen Proxy für den Rest.
Der MCP-Server für UI-Komponenten, den wir betreiben, antwortet ohne Account. Du kannst also jeden Client damit verbinden und diese Entscheidungen aus Sicht des Agents sehen, bevor du deinen eigenen entwirfst.
Welche Guides gehen tiefer?
Jeder dieser Posts aus UI mit KI-Agenten bauen vertieft einen Client, eine Datei oder eine KI-Oberfläche:
- Claude Code shadcn Setup: der shadcn-MCP-Server, der shadcn-Skill und ein CLAUDE.md-Block, der sagt, welche Registry für welchen Ordner zuständig ist.
- Cursor shadcn MCP und Regeln: dasselbe Setup für Cursor, mit
.cursor/mcp.jsonund einer kurzen.mdc-Projektregel. - Codex MCP Setup für React UI: ein Befehl, der den Server in
~/.codex/config.tomlund die Regeln in AGENTS.md schreibt. - AGENTS.md vs CLAUDE.md vs Cursor-Regeln: wo du Regeln einmal schreibst, damit Codex, Cursor und Claude Code sie alle lesen.
- Ein Design System für Claude Code: Tokens, eine DESIGN.md, ein Projekt-Skill und ein Hook, die 50 Screens einheitlich halten.
- llms.txt in Next.js: llms.txt, llms-full.txt und ein
.md-Zwilling für jede Seite, erzeugt aus den Daten, die deine Seiten rendern. - React AI Chat UI: Thread, Nachrichten, Composer, Reasoning-Zeile und Modellauswahl, mit Streaming und Auto-Scroll.
- React Prompt Input: Enter und Shift+Enter, IME-Komposition, Datei-Uploads, Stop während des Streamings und Diktat an der Cursorposition.
- React Markdown Streaming: halb geschriebene Syntax reparieren und nur den letzten Block neu rendern, damit gestreamte Antworten nicht mehr flackern.
- Tool Call UI für KI-Agenten: eine Zeile pro Tool Call mit Status, lesbarer Ein- und Ausgabe, Fehlern, die sich selbst aufklappen, und Freigaben.
- React Speech to Text Input: MediaRecorder mit einer Live-Vorschau per Web Speech, wo der Browser sie hat, und einem Server-Fallback.
- AI-Elements-Alternativen: fünf React-Kits für KI-Chats im Vergleich, jetzt, wo AI Elements von Vercel in shadcn/ui wandert.
Wo fange ich an?
Zum Ausprobieren verbindest du den Server mit npx wingo-ui@latest agents install claude (oder dem Namen deines Agents) und bittest in einfachen Worten um einen Screen. Ein kostenloser Account fügt den MCP-Antworten den Quellcode der 75 kostenlosen Items hinzu, darunter der Button und der OTP Input; die CLI installiert diese auch ohne Account. Login Page und Data Table gehören zu Pro, das alle 326 Items abdeckt: 8 $ im Monat, 80 $ im Jahr oder 150 $ einmalig, auf der Preisseite. Die MCP-Server-Doku enthält das Setup pro Client und Hilfe bei Problemen.
Wenn du deine eigene Bibliothek pflegst, ist ein MCP-Server der günstigste Weg, den wir kennen, damit Agents sie richtig nutzen. Kombinier ihn mit fünf Zeilen Regeln und einem Installer, der Versionen festhält, und der Agent hört auf, deine Komponenten zu erfinden, und fängt an, sie zu installieren.
Häufige Fragen
Was ist ein Component Library MCP Server?
Das ist ein Model-Context-Protocol-Server, der eine UI-Bibliothek als Tools für Coding-Agents bereitstellt: den Katalog durchsuchen, die Props einer Komponente mit Defaults und Usage lesen, die Designregeln abrufen und installierte Items auf Updates prüfen. Der Agent ruft diese Tools auf, statt eine API aus seinen Trainingsdaten zu raten.
Brauche ich noch eine Regeldatei, wenn ich einen MCP-Server verbinde?
Ja. Der Server liefert Fakten, aber ein Agent greift nicht immer von selbst zu einem Tool. Ein paar Zeilen in CLAUDE.md, AGENTS.md oder einer Cursor-Regel sagen ihm, dass er sucht, bevor er UI schreibt, dass er mit der CLI installiert und nie eine Komponente nachbaut, die die Bibliothek schon hat.
Reicht llms.txt ohne MCP-Server?
llms.txt hilft Assistenten, die nur URLs lesen können, kann aber selbst nichts tun. Die Datei installiert nichts, vergleicht deine installierten Versionen nicht mit dem neuesten Release und sagt dem Agent nicht, welche Items dein Plan enthält.
Funktioniert der MCP-Server von Wingo UI ohne Account?
Für die Doku ja: Suche, Props, Usage, Designregeln und Theme-Tokens antworten ohne Key. Ein Key aus einem kostenlosen Account (nur E-Mail) fügt den Quellcode der 75 kostenlosen Items hinzu, ein Pro-Key den Quellcode aller anderen.
Kann ich den shadcn-MCP-Server mit Wingo UI nutzen?
Ja. Trag die @wingo-ui-Registry in components.json ein, für Pro-Items mit deinem API-Key, dann kann der shadcn-MCP-Server daraus suchen und installieren. Er liefert weder unsere Designregeln noch Update-Checks, und die shadcn-CLI hält keine Versionen fest, deshalb kann wingo-ui update spätere Releases nicht in so installierte Dateien mergen.
Welche Coding-Agents können sich mit dem MCP-Server von Wingo UI verbinden?
npx wingo-ui@latest agents install schreibt fertige Configs und Regeln für Claude Code, Codex, Gemini CLI, Grok und Cursor. Jeder andere Client, der lokale Befehle ausführt, kann den stdio-Proxy nutzen, npx -y wingo-ui@latest mcp.
- MCP
- Claude Code
- Cursor
- Codex
- KI-Agenten
- Registry
