MCP — Model Context Protocol — ermöglicht es KI-Agenten, zur Laufzeit Tool-Calls an externe Services zu machen. Figma liefert einen offiziellen MCP-Server, und die Community hat mehrere weitere gebaut. Das Versprechen: Der Agent kann auf Anfrage, mitten in einem Gespräch, Designdaten direkt von Figma abrufen. Kein Export-Schritt. Immer live.

figmascope setzt auf die entgegengesetzte architektonische Wette: einmal exportieren, ein Bundle ausliefern, nie wieder verbinden. Das sind genuiner verschiedene Entscheidungen mit verschiedenen Auswirkungen. Hier ist, was jede wirklich kostet und gewinnt.

Was Figmas MCP-Server ist

Model Context Protocol ist Anthropics offener Standard für die Verbindung von KI-Agenten mit externen Tools über eine Server-Schnittstelle. Ein MCP-Server exponiert typisierte Tools, die der Agent aufrufen kann: "get_file," "get_node," "get_styles" und so weiter. Wenn der Agent Design-Kontext braucht, ruft er das Tool auf, der MCP-Server ruft die Figma-API auf, und das Ergebnis kommt als Kontext für den aktuellen Prompt zurück.

Figmas offizieller MCP-Server deckt Datei-Lesen, Node-Inspektion, Komponenten-Abruf und Kommentar-Zugriff ab. Community-MCP-Server (es gibt mehrere auf GitHub) erweitern dies mit benutzerdefinierten Schemas, zusätzlichen Transformationen oder engeren Geltungsbereichen, die für spezifische Agenten-Workflows optimiert sind.

Um einen Figma-MCP-Server zu verwenden, konfiguriert man ihn im Agenten-Client (Claude Desktop, Cursor, Continue usw.), gibt ein Figma-PAT an, und der Server läuft als lokaler Prozess. Wenn der Agent Figma-Kontext benötigt, ruft er das Tool auf. Man exportiert explizit nichts — der Agent holt, was er braucht, wenn er es braucht.

Das MCP-Modell in der Praxis

Ein typischer MCP-gestützter Figma-Workflow sieht so aus: Man öffnet Cursor, startet ein Gespräch, sagt "implementiere den Checkout-Screen aus dieser Figma-Datei", und der Agent ruft get_file auf, zieht den Node-Baum und hat die Design-Daten im Kontext. Wenn man dann sagt "der Designer hat die Button-Tokens aktualisiert", kann der Agent erneut aufrufen und frische Daten bekommen.

Dieses Live-Verbindungsmodell ist real und überzeugend für einige Workflows. Der Agent arbeitet mit aktuellen Daten. Man verwaltet keine Export-Artefakte. Es gibt keinen manuellen Schritt zwischen "Designer hat eine Änderung gepusht" und "Agent hat sie".

Wo MCP gewinnt

Live-Daten, kein Export-Schritt. Der Agent holt den aktuellen Zustand auf Anfrage. Wenn das Design vor zehn Minuten geändert wurde, kann der Agent es sehen. figmascope erfordert einen manuellen Re-Export, um Änderungen zu erfassen.

Gesprächsmäßige Design-Exploration. "Welche Farbe hat der CTA-Button?" "Wie viele Screens referenzieren diese Komponente?" Mit MCP kann ein Agent diese Fragen durch Aufrufen von Figma beantworten. Mit einem Bundle ist die Antwort nur so frisch wie der letzte Export.

Figma direkt bearbeiten. Einige MCP-Server exponieren Schreiboperationen — Nodes erstellen, Eigenschaften aktualisieren, Kommentare posten. Das ist nur mit einer Live-Verbindung möglich. Ein statisches Bundle hat keinen Schreibpfad.

Kein manueller Workflow. Für Entwickler, die bereits MCP-verbundene Agenten-Setups verwenden, bedeutet kein Export-Schritt eine Sache weniger zu vergessen. Das Kontext-Management wird an den Agenten delegiert.

Wo MCP verliert

Das Live-Verbindungsmodell hat architektonische Kosten, die leicht zu unterschätzen sind.

Session-gebundener Zustand. MCP-Aufrufe finden im Kontext einer Gesprächs-Session statt. Die Daten, die der Agent in Session A abgerufen hat, sind in Session B ohne erneutes Abrufen nicht verfügbar. Wenn man einen neuen Chat startet, beginnt der Agent von vorne. Ein figmascope-Bundle bleibt zwischen Sessions, zwischen Entwicklern und zwischen Tools erhalten — es sind einfach Dateien.

Für git opak. Es gibt kein Artefakt. Nichts zu committen. Der Design-Kontext, der den Code informiert hat, lebt nicht im Repository. In sechs Monaten, wenn man verstehen möchte, wie das Design aussah, als eine Komponente gebaut wurde, gibt es keine Aufzeichnung. Mit einem Bundle im Repo hat man eine Commit-Geschichte der Design-Intention.

Erfordert Verbindung. MCP braucht einen laufenden Server, eine Live-Figma-API-Verbindung und ein PAT mit Zugang. Netzwerk ausgefallen, Figma-API ausgefallen, PAT abgelaufen — der Agent hat keinen Kontext. Ein Bundle funktioniert im Flugzeug.

Modell-abhängiger Abruf. Was der Agent über MCP abruft, hängt davon ab, was er zu fragen entscheidet. Er holt möglicherweise nicht die Token-Werte. Er zieht möglicherweise nicht das Komponenteninventar. Er fordert möglicherweise nur den Node-Teilbaum an, den er für nötig hält, und verpasst räumlichen Kontext benachbarter Nodes. Der Abruf ist probabilistisch, nicht deterministisch. figmascope holt alles, jedes Mal, mit einem festen Schema.

Schwerer zu testen und zu reproduzieren. "Mein Agent hat diese Komponente aus diesen Figma-Daten zu diesem Zeitpunkt gebaut" ist mit MCP nicht verifizierbar. Der Abruf ist flüchtig. Mit einem Bundle kann man exakt wiederholen: gleiches Bundle, gleicher Agent, gleicher Prompt — deterministischer Output. Das ist wichtig für Debugging, Code-Review und Release-Verantwortlichkeit.

Kontextfenster-Druck. Ein naiver get_file-Aufruf auf eine komplexe Figma-Datei gibt einen enormen JSON-Baum zurück. Agenten müssen selektive Tool-Calls machen, um innerhalb der Kontext-Budgets zu bleiben. Das führt zu Heuristiken und Urteilsaufrufen, die schiefgehen können. figmascope verarbeitet den Baum vorab in ein strukturiertes IR mit nur dem Notwendigen, in einer bekannten, begrenzten Größe.

figmascopes Bundle-Modell: einmal erfassen, für immer ausliefern

figmascope exportiert ein .zip aus einfachen Dateien von der Figma REST API — kein Plugin, kein Server, läuft im Browser. Das Bundle enthält:

Einmal exportiert, ist das Bundle in sich abgeschlossen und unveränderlich. Es geht ins Repo neben den Code, den es beschreibt. Jeder Agent, jede Session, jeder Entwickler, jeder CI-Job kann es lesen. Keine Verbindung zu irgendetwas erforderlich.

Versionierbare Diffs: Bundles wie Code vergleichen

Das ist das stärkste Argument des Bundle-Modells. Weil der Output strukturiertes JSON und Markdown ist, kann man differn.

Vor einem Design-Sprint ein Bundle exportieren. Nach dem Sprint ein weiteres exportieren. diff auf tokens.json ausführen:

- "spacing.4": "16px"
+ "spacing.4": "14px"

Das ist eine Breaking Change in der Spacing-Skala. Sie ist sichtbar, überprüfbar und auf einen Commit zurückverfolgbar. Mit MCP passiert dieselbe Änderung still — das nächste Mal, wenn der Agent abruft, erhält er den neuen Wert, und es gibt keine Aufzeichnung, dass sich etwas geändert hat.

Man kann das als PR-Gate verwenden: das Bundle als Teil des Design-Handoffs exportieren, committen, Designer- und Dev-Sign-Off auf dem Diff verlangen, bevor die Implementierung beginnt. Das ist Design-Spec-as-Code. MCP hat kein Äquivalent.

Determinismus-Argument

Gleiche Figma-Dateiversion + gleicher figmascope-Export = gleiches Bundle. Jedes Mal. Das IR-Schema ist fest. Die Token-Sourcing-Logik ist deterministisch. Die String-Key-Extraktion ist regelbasiert.

MCP-Abruf ist nicht deterministisch. Der Agent entscheidet, was er abruft. Verschiedene Agenten, verschiedene Prompt-Formulierungen, verschiedene Kontext-Budgets — verschiedenes Abrufverhalten. Der Output ist modell-abhängig.

Für Produktions-UI-Codegen ist Determinismus wichtig. Man möchte, dass die Spezifikation, die eine Komponente generiert hat, reproduzierbar ist. Man möchte die Komponente aus denselben Inputs regenerieren können und konsistente Ergebnisse erhalten. Bundles unterstützen das. MCP-Sessions nicht.

Vergleich

Dimension Figma MCP figmascope Bundle
Datenfrische Immer live — holt aktuellen Figma-Zustand Snapshot — so frisch wie der letzte Export
Export-Schritt erforderlich Nein Ja — einmalig pro Design-Version
Versionskontrollierbar Nein — kein Artefakt Ja — Bundle ist diffbares JSON + Markdown
Session-übergreifend persistent Nein — muss pro Session erneut abgerufen werden Ja — Dateien bleiben unbegrenzt erhalten
Offline funktionsfähig Nein Ja
Deterministischer Output Nein — modell-abhängiger Abruf Ja — gleicher Input → gleiches Bundle immer
Kontextfenster-Druck Hoch — rohe Figma-JSON ist groß und unstrukturiert Niedrig — IR ist vorverarbeitet, begrenzte Größe
Schreiboperationen auf Figma Ja (einige MCP-Server) Nein — nur lesender Export
Design-Spec in git-Geschichte Nein Ja — Bundle committen, Design-Geschichte verfolgen
Agenten-Setup erforderlich Ja — MCP-Server pro Agenten-Client konfigurieren Nein — jeder Agent, der Dateien liest, funktioniert
i18n-String-Keys Nicht im Basis-Figma-MCP-Schema Ja — stringRef.key in IR + strings.json
Räumliches / Layout-IR Roher Figma-Node-Baum (keine semantischen Layout-Typen) Typisiertes IR: stack / overlay / absolute / leaf
Token-Sourcing Variablen wenn gesetzt; sonst Rohwerte Variablen → aus Häufigkeit abgeleitet → keines

MCP glänzt für "Figma live bearbeiten" — Bundles glänzen für "Produktions-UI bauen"

Das ist die ehrliche Zusammenfassung. Wenn der Workflow gesprächsmäßige Design-Exploration ist — "diese Komponente ändern," "diesen Screen annotieren," "welche Farbe haben die Tokens auf diesem Frame" — ist MCPs Live-Verbindung das richtige Modell. Der Agent ist ein Mitarbeiter im Design-Prozess und braucht aktuelle Daten dafür.

Wenn der Workflow das Bauen von Produktions-UI aus einem finalisierten (oder fast finalisierten) Design ist — Komponenten implementieren, State verdrahten, Tests schreiben — ist das Bundle-Modell besser. Man möchte die Spec im Repo verankert haben, diffbar über Design-Iterationen, von jedem Agenten ohne Konfiguration lesbar und deterministisch genug, um darauf aufzubauen.

Die beiden Modelle ergänzen sich. MCP verwenden, wenn das Design in Flux ist und man kollaborativ iteriert. Ein figmascope-Bundle exportieren, wenn das Design stabil ist und man es Ingenieuren zur Implementierung übergibt. Das Bundle wird zur Quelle der Wahrheit, gegen die die Implementierung gebaut wird — nachverfolgbar, überprüfbar, reproduzierbar.