figma-bridge-mcp

Ein lokaler MCP-Server, der KI-Assistenten ermöglicht, Designs in Figma Desktop zu inspizieren, zu erstellen und zu aktualisieren. Er verbindet sich über ein kleines Figma-Entwicklungs-Plugin und stellt fokussierte Werkzeuge für Screenshots, Design-Spezifikationen, JSX-Rendering, Tokens, Assets, Komponenten, FigJam und Figma Slides bereit.

Alles läuft auf 127.0.0.1. Kein Figma Personal Access Token erforderlich. Keine Cloud. Kein binäres Patchen der Figma-App.

Ein optionales REST-Add-on fügt Versionsverlauf, Kommentare und Metadaten veröffentlichter Bibliotheken hinzu. Sein Figma-Token verbleibt auf Ihrem Rechner und wird niemals in Ihrer MCP-Client-Konfiguration oder im Chat platziert.

Voraussetzungen: Node.js 18 oder neuer, Figma Desktop und ein MCP-Client, der lokale stdio-Server starten kann.

Codex, Claude Code und Cursor: MCP und Skills in einem Paket

Figma Bridge liefert drei fokussierte gemeinsame Skills plus dünne Plugin-Adapter für alle drei Clients:

• figma-bridge-design-to-code — exakte Figma-Implementierung im Ziel-Stack;

• figma-bridge-code-to-figma — semantische, komponentisierte Bildschirme aus Code;

• figma-bridge-component-library — Tokens, Styles, Komponenten, Varianten und Eigenschaften.

Die Adapter erkennen alle dasselbe skills/-Verzeichnis und starten dasselbe lokale MCP-Paket. Benutzer laden die Skills nicht separat herunter oder warten sie.

Für Codex fügen Sie dieses Repository als Marktplatz hinzu und installieren das Paket:

codex plugin marketplace add KaiUweHella/figma-bridge-mcp
codex plugin add figma-bridge-mcp@figma-bridge

Dies ist ein GitHub-gehosteter Repository-Marktplatz, keine Einreichung im universellen OpenAI-Plugin-Verzeichnis. Der Katalog folgt dem Repository, während jeder veröffentlichte Plugin-Eintrag einen exakten v<version>-Git-Tag festlegt und die passende npm-Laufzeitversion startet. main und @latest können daher ein installiertes Skill-Paket nicht stillschweigend auf einen anderen Serververtrag verschieben.

Für Claude Code fügen Sie dieses Repository als Marktplatz hinzu und installieren das Paket:

claude plugin marketplace add KaiUweHella/figma-bridge-mcp
claude plugin install figma-bridge-mcp@figma-bridge

Der Claude-Marktplatz verwendet denselben festgelegten GitHub-Release und denselben gemeinsamen Skill-Baum. Das passende npm-Paket muss veröffentlicht werden, bevor Benutzer diesen Release installieren, da das Plugin seinen lokalen stdio-Server über npx startet.

Für Cursor Teams oder Enterprise importieren Sie dieses GitHub-Repository in einen Team-Marktplatz und installieren Figma Bridge über Anpassen. Einzelne Benutzer und Mitwirkende können dieselbe GitHub-Quelle ohne eine zentrale Cursor-Listung verwenden: Klonen Sie den getaggten Release, verknüpfen Sie diesen Checkout in Cursor und laden Sie das Fenster neu:

mkdir -p ~/.cursor/plugins/local
ln -s /absolute/path/to/figma-bridge-mcp ~/.cursor/plugins/local/figma-bridge-mcp

Cursor erkennt das Stammverzeichnis des Agent Plugin-Manifests und lädt sowohl den Skill als auch den MCP-Server.

Clients ohne Plugin- oder Agent-Skill-Unterstützung verwenden weiterhin die normale Serverkonfiguration unten. Sie erhalten weiterhin den kompakten obligatorischen Workflow über MCP-Anweisungen, die benutzergesteuerten MCP-Prompts design-to-code, code-to-figma und create-figma-component sowie figma_reference {name:"workflow"}.

Schnellstart

1. MCP-Server hinzufügen (MCP-only-Fallback)

Verwenden Sie dies, wenn die vollständige Plugin-Installation nicht verfügbar ist oder Sie nur die MCP-Tools ohne den gebündelten Skill wünschen. Das npx-Setup benötigt keinen Clone- oder Build-Schritt. Für Claude Code:

claude mcp add figma-bridge -- npx -y figma-bridge-mcp@latest

Für einen anderen MCP-Client fügen Sie die entsprechende Serverkonfiguration hinzu:

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

Starten Sie den MCP-Client neu, wenn er den Server nicht sofort erkennt. Es gibt absichtlich keinen env-Block: Die Bridge erstellt ihre lokalen Anmeldeinformationen während des Pairings.

git clone https://github.com/KaiUweHella/figma-bridge-mcp.git
cd figma-bridge-mcp
npm install

{
  "mcpServers": {
    "figma-bridge": {
      "command": "node",
      "args": ["/absolute/path/to/figma-bridge-mcp/src/server.js"]
    }
  }
}

2. Figma Desktop einmal paaren

1. Bitten Sie Ihren KI-Assistenten, sich mit Figma zu verbinden, oder rufen Sie direkt figma_connect auf. Es startet die lokale Bridge und gibt einen Zugangsschlüssel sowie einen Plugin-Manifest-Pfad zurück.

2. In Figma Desktop: Plugins → Entwicklung → Plugin aus Manifest importieren… und wählen Sie ~/.figma-bridge-mcp/plugin/manifest.json (den von figma_connect zurückgegebenen Pfad).

3. Öffnen Sie Plugins → Entwicklung → Figma Bridge, fügen Sie den Zugangsschlüssel ein und klicken Sie auf Speichern & verbinden.

4. Wenn das Plugin Verbunden (authentifiziert) anzeigt, kann der Assistent mit dieser Figma-Datei arbeiten. Die Paarung wird gespeichert; in späteren Sitzungen öffnen Sie das Plugin einfach erneut in der gewünschten Datei.

Figma Dev Mode benötigt separate Adapter, da Figma nicht unterstützt, das vorhandene FigJam-Editor-Ziel mit dev in einem Manifest zu kombinieren:

• Importieren Sie ~/.figma-bridge-mcp/plugin/manifest.dev.json für den Figma Bridge Dev Mode. Es hält die authentifizierte MCP-Bridge für Auswahl, Inspektion, Spezifikationen und Exporte verbunden. Der Dev Mode ist schreibgeschützt, daher erfordern Rendering und Canvas-Bearbeitungen weiterhin das Umschalten der Datei in den Design-Modus und das Öffnen des normalen Figma Bridge-Plugins dort.

3. Mit Figma verwenden

Wählen Sie einen Frame oder eine Ebene in Figma aus und beschreiben Sie das gewünschte Ergebnis. Zum Beispiel:

• "Inspiziere meine aktuelle Auswahl und erkläre ihr Layout."

• "Erstelle eine Einstellungskarte neben dem ausgewählten Frame."

• "Exportiere die Tokens und Assets des ausgewählten Bildschirms in dieses Projekt."

• "Implementiere den ausgewählten Frame und vergleiche dann das Ergebnis mit Figma."

Der Assistent kann die aktuelle Auswahl lesen, Screenshots und Spezifikationen erfassen, JSX rendern, Assets exportieren oder gezielte Bearbeitungen vornehmen. Lassen Sie das Figma Bridge-Plugin in jedem Dokument geöffnet, auf das der Assistent zugreifen soll. Wenn mehr als ein Dokument verbunden ist, übergeben Sie eine Figma-URL oder einen Dateischlüssel, damit das Ziel eindeutig ist.

Related MCP server: tellfigma

So funktioniert es

MCP client ──stdio──▶ figma-bridge-mcp (src/)
                        │
                    MCP tool adapters ─▶ Capability Catalog ─▶ CommandPlan
                                                                  │
                                          ┌───────────────────────┴──────────┐
                                  Command Application Modules   generic CLI adapter
                                             │            │
                                      Design Capture      │
                                      Asset Policy        │
                                             └──────┬─────┘
                                      Daemon Client Module
                                             │  HTTP: signed requests
                                             ▼
                                  local daemon :3456–3460
                                             │  WS: challenge/response
                                             ▼
                                  Figma Bridge plugin in Figma Desktop

• Die Engine befindet sich unter engine/. Sie begann als Fork von figma-ds-cli v2.1.0 und hat sich weit darüber hinaus entwickelt (siehe Quellenangabe). Der Chrome-DevTools-„Yolo-Modus“ – der die Figma-App-Binärdatei patcht – wurde vollständig entfernt; es gibt keinen Codepfad dorthin.

• Spezialisierte MCP-Reads (figma_spec, figma_inspect, figma_screenshot) werden direkt über wertezurückgebende Command Application Modules ausgeführt. MCP und CLI sind dünne Adapter über denselben Implementierungen; das generische figma_run bleibt der bewusst breite Child-Process-CLI-Adapter. Ein Daemon Client Module verwaltet Signierung, Timeouts und Transportfehler für beide Pfade.

• Das Design Capture Module durchläuft einen expliziten Knoten einmal und projiziert lokal Struktur, Stil und die verlustfreien Ausgabeformate aus denselben Fakten. Ein Capture wird nur wiederverwendet, nachdem eine günstige Revisionsprüfung bestätigt hat, dass die authentifizierte Plugin-Verbindung und die Figma-Dokumentrevision unverändert sind. Fehlende oder instabile Revisionsmetadaten deaktivieren die Wiederverwendung; Auswahl- und benannte Abschnittsaufrufe bleiben in diesem ersten Slice ungecacht. Captures unterscheiden zwischen erstelltem Figma Auto Layout/Grid, Figmas markierter inferredAutoLayout-Heuristik und Geometrie-Fallback. Sie bewahren auch Code-to-Figma-semantische/Fallback-Metadaten getrennt von späteren nativen Figma-Annotationen sowie vollständige Komponenten- und Variablenmodus-Verträge.

• Das Design Link Registry vergibt einer Komponente, einem Bildschirm oder einem Frame eine dauerhafte, repository-eigene Design Entity-ID. figma-bridge.json enthält portable Code/Storybook/Figma-Links; Figma-Plugin-Daten enthalten nur dieselbe ID und Art. Dieser doppelte Anker ermöglicht es zukünftigen Agenten, die exakt vorhandene Komponente von beiden Seiten aufzulösen, ohne Repository-Pfade in ein Figma-Dokument einzufügen.

• Der reine Berichts-Round-trip Planner vergleicht aktuellen Code und den aktuellen normalisierten Figma-Subtree mit einer expliziten Accepted Design Baseline. Der Project Design Context projiziert diesen Status, die Entity-Links und die genauen nächsten Reads durch eine prozessinterne Command Application. Wenn semantische Pfade existieren, werden geänderte Subtrees mit ihren aktuellen Knoten-IDs gemeldet; Plugin-Marker selbst zählen nie als visuelle Änderungen.

• Ein Design Contract wandelt das vollständige Design Capture einer verknüpften Design Entity in ein deterministisches Repository-Gate um. Führen Sie figma_run ["contract", "capture","ui.button"] einmal aus und überprüfen Sie das JSON; später meldet figma_run ["contract","check","ui.button"] kanonische Abweichungen und erzwingt separat Variantenmatrizen, Token-Binding-Untergrenzen, Geometrietoleranzen und Prototyp-Übergänge. Flüchtige Figma-Handles werden ignoriert und tiefenbegrenzte Captures werden abgelehnt.

• Ein Capability Catalog löst jeden über MCP eingehenden Figma-Befehl in einen unveränderlichen Plan auf, bevor einer der Ausführungsadapter ihn ausführt. Dieser Plan ist die einzige Quelle für Exposition, Figma/Workspace/Shared-State-Effekte, Zielbedarf, Bestätigung, normalisierte Pfade, Wiederholung, Timeout, akzeptierte Exit-Codes und Hintergrundjob-Identität. Unbekannte Befehle standardmäßig auf verweigert/schreiben/keine Wiederholung.

• Ein unveränderlicher Figma Target Context löst expliziten fileKey, eingefügte Figma-URL oder implizites Single-Window-Targeting einmal pro Befehl auf und begleitet dann Planung, Audit, Job-Identität und Daemon-Ausführung. Eine gemeinsame Asset Policy klassifiziert Bildfüllungen, Vektorgrafiken und Vektorgruppen sowohl für Design-Capture-Projektionen als auch für den Export.

• Laufzeit-Protokollvalidatoren lehnen fehlerhafte HTTP-Ausführungspayloads und Plugin-Frames an der Transportgrenze ab. TypeScript überprüft die JavaScript-Nähte (einschließlich des Figma-Plugins), während deterministischer Kontext, Payload sowie Median- und Tail-Latenz-Budgets architektonische Regressionen in CI abfangen, ohne kurze Planungspausen des Shared-Runners als anhaltende Regression zu behandeln.

• Der Daemon vermittelt Befehle an das Figma-Plugin über einen localhost-WebSocket. Zwei Tore schützen ihn:

  • HTTP-Routen (/health, /exec) erfordern eine pro Anfrage HMAC-Signatur, die mit dem Sitzungstoken, einer 0600-Datei, signiert ist – das Token selbst überquert niemals die Leitung.

  • Der Plugin-WebSocket (/plugin) erfordert den Zugangsschlüssel: eine Origin/Host-Whitelist plus einen gegenseitigen Challenge-Response-Handshake, bei dem der Schlüssel nur ein HMAC-Geheimnis ist und ebenfalls niemals die Leitung überquert. Dies schließt die upstream-Lücke, bei der jeder lokale Prozess eine Verbindung zum Plugin-Socket herstellen und Code in Ihrem Figma-Dokument ausführen konnte – und die inverse Lücke, bei der alles, was auf einem lokalen Port antwortet, ein ehrliches Plugin steuern könnte.

Knoten-IDs werden in jeder Form akzeptiert, die ein Benutzer zur Hand hat: 12:34, die URL-Form 12-34 oder eine vollständige Figma-URL (deren Dateischlüssel mit den tatsächlich geöffneten Dateien abgeglichen wird – siehe Mehrere Dateien gleichzeitig).

Schreibbefehle können hinter einer expliziten confirm:true-Bestätigung gesperrt werden, indem FIGMA_WRITE_CONFIRM=1 in der Serverumgebung gesetzt wird. Die Sperre wirkt auf Befehlsebene: Lesevorgänge wie node tree oder component list passieren frei, Mutationen wie node delete, combos oder tokens spacing erfordern eine Bestätigung.

Native JSX-Instanzen benötigen eine dauerhafte Registry-Identität (entity plus einen veröffentlichten key oder eine lokale id). Ihre bearbeitbaren Überschreibungen verwenden die tatsächliche Figma-Struktur der Komponente:

<Instance entity="ui.card" key="..."
  prop:Selected="true"
  text:Title="New title"
  fill:StatusDot="var:status/healthy|#22c55e"
  swap:LeadingIcon="ui.icon.leaf" />

prop: löst eine Komponenteneigenschaftsdefinition auf; text: und fill: lösen einen benannten Nachkommen auf. swap:-Werte und INSTANCE_SWAP-Eigenschaftswerte sind Design-Entitäts-IDs, aufgelöst aus figma-bridge.json; Komponenten-Anzeigenamen werden absichtlich nicht als Swap-Identität akzeptiert. Fehlende, mehrdeutige oder nicht verknüpfte Ziele stoppen den Preflight, bevor der erste Canvas-Knoten erstellt wird.

Abmessungen und Typografie akzeptieren die gleiche var:name|fallback-Form. Der native Executor bindet Breite, Höhe und min/max-Einschränkungen sowie Schriftfamilie/-stil, Gewicht, Größe, Zeilenhöhe, Buchstabenabstand, Absatzabstand und Absatzeinzug. Familie/Stil verwenden STRING-Variablen; die anderen Typografie- und Dimensionsfelder verwenden FLOAT-Variablen. Eine fehlende gebundene Schriftart stoppt den Preflight mit einer Installieren-oder-wähle-eine-andere-Schriftart-Nachricht, anstatt sie stillschweigend zu ersetzen. Benannte Textstile werden ebenfalls vor der Canvas-Erstellung abgeglichen: Ein explizites style="Typography/Eyebrow" wird nur wiederverwendet, wenn seine vollständige Typografie übereinstimmt; ein widersprüchlicher gleichnamiger Stil stoppt, andernfalls wird die exakte Typografie unter einem deterministischen Namen Typography/Generated/... wiederverwendet oder erstellt. Der Figma-float32-Metrik-Rücklesewert wird für einen stabilen Vergleich normalisiert, und familienspezifische Schriftschnitte wie DM Sans/Manrope SemiBold und ExtraBold werden vor jeder Fallback-Familie versucht. Erfolgreiche native Renderings geben textStyleReport- und variableReport-Zählungen für Referenzen, eindeutig wiederverwendete Variablen, erstellte Variablen und gebundene Eigenschaften zurück. Mehrdeutige oder nicht unterstützte Preflight-Fehler enthalten die entsprechenden Null-/Nicht-Null-Zählungen und hinterlassen keine neu erstellten Variablen oder Canvas-Knoten.

<Text> bewahrt auch bearbeitbaren Inline-Rich-Text. Verschachtelte <strong>/<b>, <em>/<i>, <u>, <Span ...> und <a href="...">-Markups werden zu nativen Figma-Bereichen; HTML-Entities werden dekodiert, bevor UTF-16-Bereichsoffsets berechnet werden. Span-Läufe unterstützen font, fontStyle, weight, italic, size, color, letterSpacing, underline/decoration und sichere Links:

<Text font="Inter" size="14">
  Hello <strong>bold <em>and italic</em></strong>
  <Span color="#ef4444" size="18">red</Span>
  <a href="https://example.com">link</a>
</Text>

Plugin-Fenster

Das Figma Bridge Plugin-Fenster ist mehr als nur der Verbindungsstatus:

• Aktivität – jeder vom Agenten ausgeführte Befehl live, mit Dauer und ok/Fehler; Schreibvorgänge werden hervorgehoben. Die reduzierte Zeile trägt die Zählung (12 ok · 1 fehlgeschlagen); der verbundene Port und die Roundtrip-Latenz befinden sich in der Titelleiste.

• Agent pausieren – ein Kill-Switch: Im pausierten Zustand lehnt das Plugin jeden eingehenden Agentenbefehl mit einem expliziten Fehler ab.

• Version speichern – schreibt einen beschrifteten Eintrag in den eigenen Versionsverlauf von Figma (Figma Bridge — <Zeitstempel>) als manuellen Wiederherstellungspunkt, bevor der Agent losgelassen wird. Es gibt keine Wiederherstellungs-API für Plugins: Sie stellen über das Versionsverlaufsfenster von Figma zurück.

• Auswahlanzeige – was immer der Benutzer auswählt, wird automatisch (entprellt) an den Agenten übertragen und als „Agent sieht: …“ angezeigt, sodass der Benutzer immer sieht, was figma_selection zurückgeben wird. Wählen Sie einen Frame aus, sagen Sie „baue dies“ – kein Kopieren der Knoten-ID.

• Einrichtung – Zugangsschlüssel und das optionale REST-Token, immer erreichbar, unabhängig davon, ob die Brücke verbunden ist.

Design-to-Code-Workflow

Das Design ist die vollständige Spezifikation – die Werkzeuge machen das Kopieren einfacher als das Interpretieren. Erstellen Sie einen Bildschirm aus Figma in sechs Schritten:

Behalten Sie das Framework und das Styling-System des Zielprojekts bei. Fügen Sie nicht nur für den Bildschirm Tailwind, ein UI-Kit oder eine Icon-Bibliothek hinzu, und ersetzen Sie niemals exportierte Figma-Grafiken durch eine bequeme Annäherung. Verwenden Sie eine Projektkomponente nur dann wieder, wenn ihr gerendertes Design und ihre Zustände tatsächlich übereinstimmen.

1. figma_screenshot auf dem Zielframe, dann das gespeicherte PNG auslesen – die visuelle Ground Truth. Niemals allein aus einem Knotenbaum bauen.

2. figma_spec mit phase: "structure" – das Markup-Gerüst bauen: echte Textzeichen, aufgelöste Icon-/Komponentennamen (Instanzen werden durchstiegen, sodass Overrides und echte Hauptkomponentennamen erscheinen), Hierarchie und Flex-Richtung. Texte und Icons wörtlich übernehmen. Ein layout:inferred (Figma heuristic — verify)-Marker ist kein erstelltes Auto Layout; die Hierarchie prüfen, bevor es als Komponentenvertrag behandelt wird.

3. Tokens exportieren (figma_run mit ["export","css"] oder ["export","dtcg"]) und als CSS-Variablen / Theme verdrahten. Die Ausgabe benennt ihre Quell-Figma-Datei – prüfen, ob es die Datei ist, die du baust.

4. Assets exportieren (figma_run mit ["export","assets","<nodeId>","-o","/abs/path/src/assets"]) – jeder → assets/…-Verweis im Spec zeigt auf eine Datei, die dies schreibt. Einen absoluten Pfad übergeben; große Exporte laufen im Hintergrund weiter („still RUNNING“) – denselben Aufruf erneut ausführen, um abzufragen. assets.json wird über Läufe hinweg zusammengeführt und byte-identische Assets werden dedupliziert. Jeder Eintrag enthält Platzierungsdaten (x/y-Offsets, parent-Namenspfad, parentId, absolutePosition, overhang), sodass das Manifest allein einen Overlay positioniert – kein Spec-Querverweis nötig. Die Exportzusammenfassung listet die absolut positionierten und überhängenden Dateien explizit auf: Das sind diejenigen, die Builds verlieren. Überdimensionierte PNGs werden standardmäßig auf das 2-fache ihrer größten Figma-Nutzung heruntergerechnet (Retina-Dichte), ohne Hochskalierung und nur wenn die codierte Datei kleiner wird. Seitenverhältnis, Manifest-Platzierung und CSS-Crop-Verhalten bleiben unverändert; --raster-scale 0 übergeben, um die ursprünglichen PNG-Bytes zu behalten.

5. figma_spec mit phase: "style" – Größen, Abstände, Padding, Ausrichtung, Fill/Hug-Sizing, Paints inkl. Verläufe (→ var(name) markiert eine Design-Token-Bindung), Radien, Schatten, Typografie, opacity, clip (overflow hidden) und abs-Positionierung anwenden. Dekorative Vektoren erscheinen als vector art → assets/…-Zeilen mit Platzierung – die exportierten SVGs platzieren, niemals in CSS approximieren.

   Strukturiertes YAML/JSON behält zusätzlich exakte Komponenteneigenschaftsdefinitionen und -werte (einschließlich INSTANCE_SWAP und SLOT), Eigenschaftsreferenzen, bevorzugte Werte, direkte Overrides, freigelegte Instanzen und Slot-Verstöße. Variablenbindungen enthalten Sammlungsidentität, erstellte Scopes, explizite/aufgelöste Modi, codeSyntax.WEB und den aufgelösten Wert; inferredVariables wird separat als reiner Vorschlagsnachweis ausgegeben.

   Bei einem großen Abschnitt zuerst depth:0 anfordern. Dies ist ein vollständiger Vertrag für den Abschnittscontainer selbst (einschließlich Hintergrund, Rahmen, Radius und Layout) ohne Nachkommen. Dann untergeordnete Knoten-IDs in begrenzten Aufrufen anfordern. dedup:true für wiederholte Karten/Listen verwenden; gemeinsame S<n>-Referenzen bleiben verlustfrei und verhindern, dass identische Instanzstile das Ergebniskontingent erschöpfen.

6. Verifizieren – Screenshot deines Builds erstellen und mit dem PNG aus Schritt 1 vergleichen, dann die mechanische Prüfung ausführen:

   figma_run ["verify-build", "/abs/path/to/project"]

   Es durchsucht das Projekt mit assets.json und listet jede exportierte Datei auf, die nicht im Build referenziert wird – mit Größe, Offsets und Parent, sodass das Platzieren ein Schritt ist – plus einen border-image-Lint (CSS border-image ignoriert border-radius; Gradientenstriche auf abgerundeten Boxen benötigen das Wrapper- oder Maskenmuster). Exit-Code 1, wenn Dateien fehlen, sodass es auch als CI-Gate funktioniert.

   Mit einem Build-Screenshot führt es auch den visuellen Durchlauf aus:

   figma_run ["verify-build", "/abs/path/to/project", "--compare", "/abs/build.png"]

   Das Referenz-Rendering wird live aus Figma geholt (--node <id>, Standard: der Export-Root des Manifests) oder offline über --design <png> bereitgestellt. Beide Bilder werden auf eine gemeinsame Breite normalisiert und pixelweise differenziert (antialiasing-tolerant); die Ausgabe meldet den Gesamtdiff-Prozentsatz, einen Höhenunterschieds-Befund (Build zu hoch/zu niedrig = eingefügter oder entfernter Block), die am stärksten abweichenden Regionen in Knoten-Pixel-Koordinaten – demselben Raum, den der Spec und assets.json verwenden – und schreibt ein Diff-PNG (rot = abweichend, auf dem abgedunkelten Design). Standardmäßig informativ; --max-diff <pct> steuert den Exit-Code.

Bei großen Bildschirmen sind abschnittsbezogene Agenten eine optionale Optimierung der verstrichenen Zeit, nachdem Screenshot, Strukturplan, Tokens und Assets feststehen. Sie nur für wesentliche Abschnitte mit disjunkten Komponenten-/Stildateien verwenden; der Koordinator behält die Verantwortung für die gemeinsame Shell, Tokens, assets.json, Integration und den finalen Pixel-Diff. Parallele Agenten verbrauchen normalerweise mehr Gesamt-Tokens, da jeder Projektkontext benötigt, daher sequenzielle Arbeit verwenden, wenn Tokens-Kosten wichtiger sind als die Wanduhrzeit.

Für den Build-Screenshot ein vorhandenes Browser-Tool oder Projekt-Harness verwenden. Playwright (oder eine andere Browser-Abhängigkeit) nicht nur für die Aufnahme ohne Zustimmung des Benutzers installieren; falls bereits vorhanden, ist es ein gültiger Aufnahmemechanismus und keine Figma-Bridge-Abhängigkeit.

Derselbe Spec ist auch als figma_run ["export", "code-spec", "<nodeId>"] verfügbar. Standard ist der lesbare Baum; -f yaml oder -f json für das kanonische Modell übergeben.

Verlustfreie strukturierte Spec-Formate

figma_spec und export code-spec verwenden standardmäßig format:"tree", die präzise, zeilenorientierte Agentenansicht, deren Fußzeilen die erforderlichen Asset- und Fidelity-Aktionen enthalten. yaml oder formatiertes json explizit verwenden, wenn ein Consumer das versionierte kanonische Modell benötigt. Beide strukturierten Formate serialisieren dasselbe Modell; nur die Syntax unterscheidet sich. Roundtrip-Tests erfordern, dass jedes Feld – Text, IDs, Layout-Herkunft, Paint, Typografie, modusbewusste Variablen, Assets, Komponentenverträge, Bridge-Intention, native Annotationen, Erfassungsvollständigkeit und Fidelity-Prüfungen – exakt überlebt. Minifiziertes JSON wird nicht angeboten: Reale Agententests zeigten, dass eine einzige riesige Zeile trotz gleicher Rohfelder materiell schwieriger zu verarbeiten war.

Das capture-Feld des Modells meldet explizit angeforderte/tatsächliche Tiefe, Payload-Vollständigkeit, Richtlinie für versteckte Knoten und ob die angeforderte Tiefe Nachkommen abgeschnitten hat. Es gibt keine stille Tool-Ergebnisabschneidung: Wenn ein Spec das konfigurierte Ausgabebudget überschreitet, gibt der Aufruf complete:false mit einem abschnittsweisen Wiederholungsrezept zurück und gibt kein irreführendes partielles Design aus. depth:0 bedeutet absichtlich „nur der angeforderte Knoten“ und ist vollständig, kein tiefenabgeschnittener Baum.

IMAGE-Fill-Dateinamen werden nach Figmas stabilem Image-Hash benannt, nicht nach dem lokalen Ebenennamen/-pfad. Dadurch bleiben figma_spec, isolierte Kind-Aufrufe, Asset-Export und assets.json selbst dann auf demselben Dateinamen, wenn generische Ebenen wie „Frame 64“ über verschiedene Wurzeln erreicht werden.

Für MCP-Design-to-Code-Aufrufe ist dedup:false die Voreinstellung: Jede sichtbare Ebene behält ihre eigene ID, native Figma Inspect css{…}, Layout-/Paint-/Token-Fakten und vollständigen Text. Gemischte Rich-Text-Ebenen tragen ihre einzelnen formatierten Bereiche. Die Fußzeile gleicht die Anzahl der live sichtbaren Ebenen mit expliziten Zeilen, SVG-Interna, Komponenten-Interna und nicht-rendering-Hilfselementen ab. Eine Stilprojektion wird abgelehnt, wenn Tiefenlimits oder eine nicht berücksichtigte Ebene zum Raten zwingen würden; sie anhand der Knoten-IDs aus dem Strukturplan aufteilen. dedup:true nur für eine kompakte Übersicht mit gemeinsamen S<n>-Stil- und Wiederholungsreferenzen setzen.

Bei wiederholten expliziten Knotenaufrufen lösen phase, format und Deduplizierung keinen weiteren vollständigen Figma-Durchlauf aus. Der In-Memory-Design-Capture-Cache ist standardmäßig auf 8 Einträge / 8 MiB begrenzt (DESIGN_CAPTURE_CACHE_ENTRIES und DESIGN_CAPTURE_CACHE_BYTES). Jeder Treffer prüft dennoch die Live-Dokumentrevision; es gibt kein TTL und keinen Stale-While-Revalidate-Pfad.

Code ↔ Figma Design Memory

Jeder wichtigen Komponente, jedem Bildschirm oder Frame eine dauerhafte Design-Entity-ID geben. Die ID beschreibt das Konzept, nicht den aktuellen Ort: Namen wie ui.button, ui.account-card oder screen.settings verwenden.

Nach Auswahl oder Identifikation eines Figma-Knotens kann ein Agent den Link erstellen mit:

figma_run {args:["link","set","9:9","screen.settings","--kind","screen","--source","src/routes/settings.tsx","--export","SettingsScreen","--story","screens-settings--default"], confirm:true}

Dies führt zwei kleine Adapter zusammen:

• figma-bridge.json ist das festgeschriebene, überprüfbare Registry mit repo-relativen Codepfaden plus optionalen Storybook- und Figma-Handles.

• Figma speichert nur {version,id,kind} als Plugin-Daten auf dem Knoten. Es enthält keinen lokalen Pfad, keine Anmeldeinformationen oder maschinenspezifischen Zustand.

figma_run ["link","inspect","9:9"] verwenden, um einen Knoten aufzulösen, und figma_run ["link","list"], um den Repository-Speicher zu inspizieren, ohne Figma zu lesen. Sobald ein Link besteht, legen figma_selection und figma_spec automatisch dieselbe ID und die Code-/Storybook-Ziele des Registry offen. Agenten sollten diese Code-Komponente wiederverwenden oder bearbeiten, anstatt ein Nachbaustück zu erstellen. Das Wiederholen desselben set-Befehls ist sicher und repariert beide Seiten nach einem unterbrochenen Schreibvorgang.

Nach visueller Überprüfung, dass Code und Figma übereinstimmen, ihre aktuellen Fingerabdrücke explizit aufzeichnen. Bildschirm-Entities erfordern einen echten Browser-Screenshot und einen bestandenen Pixel-Schwellenwert:

figma_run ["link","accept","screen.settings","--compare","/abs/build.png","--max-diff","5"]

Quellcode wird niemals im Registry gespeichert. Der anfängliche Code-Adapter hasht die vollständige verlinkte Datei plus ihre Export-Identität; daher kann eine nicht zusammenhängende Bearbeitung in einer gemeinsamen Datei konservativ eine Code-Änderung melden, aber eine echte Änderung wird niemals verborgen. Der Figma-Adapter hasht den normalisierten verlinkten Teilbaum. Für Code-zu-Figma-Knoten speichert er auch jeden eindeutigen figmaBridge.semanticPath mit dem Teilbaum-Hash dieses Knotens. Ein späteres link status kann daher die genauen hinzugefügten, entfernten oder geänderten semantischen Pfade auflisten und knotenspezifische Specs empfehlen. Das Ändern eines semantischen Markers allein ändert den visuellen Fingerabdruck nicht; doppelte Pfade werden als mehrdeutig gemeldet, nicht erraten.

figma_run ["link","status","screen.settings"]
figma_run ["link","context","screen.settings"]

link context ist der bevorzugte Agenteneinstiegspunkt, sobald ein Link existiert. Es gibt die kleinste relevante Projektion zurück: Entity, Code/Export, Figma-Root, Storybook-Story, aktueller Round-trip-Plan, entdeckte DESIGN.md/Token-Dateien und genaue nächste Lesevorgänge. Es wird bei Bedarf generiert, nicht als weitere Speicherdatei persistiert. link accept schreibt nur figma-bridge.json; es ändert niemals Figma oder Code. Für Bildschirme speichert es auch den gemessenen Diff und SHA-256-Hashes beider Vergleichsbilder, sodass ein struktureller Fingerabdruck keine sichtbar falsche Basislinie zertifizieren kann.

Konventionelle DESIGN.md, design/DESIGN.md, tokens.json und design/tokens.json-Speicherorte werden automatisch erkannt. Benutzerdefinierte repo-relative Speicherorte bei Bedarf einmal konfigurieren:

figma_run ["link","configure","--design-doc","docs/product-design.md","--tokens","src/theme/tokens.json"]

figma-bridge.json committen. Keine Geheimnisse, absoluten Pfade oder generierten Anmeldeinformationen darin ablegen. Das Schema und die Konfliktregeln sind in docs/adr/0007-dual-anchor-design-entities.md dokumentiert, mit Basislinien- und Kontextentscheidungen in ADR-0008 und ADR-0009.

Überprüfte CSS ↔ Figma-Grenzstrategien

Semantisches Code-zu-Figma verwendet stabile Policy-IDs anstelle von stillen visuellen Substitutionen: minmax.native-grid, space-around.equal-slots, border.single-paint-native, sticky.metadata-only, filters.layer-stack, masks.vector-mask, font.named-faces und figma-effects.native. Die vollständige Matrix und ihre verbleibenden harten Stopps befinden sich in docs/css-figma-semantic-matrix.md.

Überprüfte verlustbehaftete Richtlinien können sich für eine automatische native Figma-Anmerkung auf dem exakt betroffenen semantischen Knoten entscheiden. Die Anmerkung erklärt die nicht unterstützte CSS-Tatsache, verlinkt die relevanten Figma-Eigenschaften und wird als versionierte figmaBridge.fallbackAnnotations-Plugin-Daten für zukünftige Agenten gespiegelt. Äquivalente native Konvertierungen bleiben unkommentiert, um Überprüfungsrauschen zu vermeiden. Die erste aktive Richtlinie ist border.single-paint-native: Figma erhält die erste explizit gemalte CSS-Seite als den gemeinsamen nativen Strich, behält alle vier Seitenstärken bei und markiert strokes plus strokeWeight. Native Renderings berichten, wie viele Fallback-Anmerkungen hinzugefügt, dedupliziert oder nicht unterstützt wurden.

Intrinsischer einzeiliger DOM-Text wird auf Figma HUG-Größenanpassung abgebildet. Positionierter und mehrzeiliger Text behält die gemessene Box-Geometrie bei; die Brücke fügt keine willkürliche prozentuale Breitenreserve hinzu, um einen Zeilenumbruch zu verhindern.

Variable-Font-Achsen werden erfasst, aber das strukturelle Gate fragt, ob die erforderliche Schriftart installiert oder ein verfügbarer benannter Schnitt vor dem Rendern verwendet werden soll. Nativer Figma Glass bleibt ein bearbeitbarer nativer Effekt, bei dem alle Effektparameter erhalten bleiben; er wird nicht stillschweigend als CSS backdrop-filter behandelt, da Figmas CSS-Export diese Glass-Parameter nicht offenlegt.

Storybook-Spiegelung

Figma-Komponenten tragen einen stabilen Publikationsschlüssel (überlebt die Bibliotheksveröffentlichung; Knoten-IDs sind dateilokal). Der Schlüssel fließt nun durch figma_spec (kanonisches strukturiertes Modell + der "Verwendete Komponentensets"-Baumanhang), figma_selection, component list, figma_inspect und DESIGN.md.

Um sie mit ihrem Code-Spiegel zu verknüpfen:

figma_run ["map", "storybook", "http://localhost:6006"]

Dies gleicht die Komponenten der Datei mit dem Storybook-Index nach normalisiertem Namen ab und schreibt figma-map.json in Ihr Projekt: Figma-Schlüssel ↔ Story-ID / Importpfad, mit einer confidence pro Treffer sowie beiden ungematchten Listen. Bearbeiten Sie Einträge von Hand und setzen Sie "matchedBy": "manual", um sie zu fixieren – fixierte Einträge überleben erneute Ausführungen. Wenn die Datei existiert, kommentieren figma_selection und figma_spec Komponenten automatisch mit ↔ story <id> (<importPath>).

figma-map.json bleibt ein Legacy-Leseadapter, sodass bestehende Zuordnungen weiterhin funktionieren. Neue dauerhafte Verknüpfungen gehören in figma-bridge.json; link set kopiert niemals Legacy-Zeilen hinein. Migrieren Sie eine Komponente, wenn Sie sie das nächste Mal bearbeiten, indem Sie ihre echte Design-Entity-ID zuweisen und ihre Story über --story übergeben. Entfernen Sie die Legacy-Datei erst, nachdem link list jede noch benötigte Zuordnung anzeigt.

Bringen Sie Ihr eigenes Designsystem mit

Dieses Projekt liefert kein Designsystem aus – kein shadcn, keine Tailwind-Voreinstellung, kein Icon-Paket. Das ist beabsichtigt: Ein gebündeltes System ist die Meinung eines anderen, die in Ihre Datei gerendert wird. Stattdessen liefert es eine Möglichkeit, Ihr System in einem Befehl für einen Agenten lesbar zu machen:

figma_run ["kit", "init", "./my-app", "--storybook", "http://localhost:6006"]

Vier Lesevorgänge, ein Bericht:

Es endet damit, zu benennen, was noch fehlt – ein nicht zugeordnetes Storybook, Komponenten ohne Story, der Befehl tokens sync, der beide synchron hält – denn ein Setup, dem stillschweigend die Zuordnung fehlt, sieht fertig aus, bis ein Agent sie benötigt.

DESIGN.md sollte ein Agent zuerst lesen; tokens.json ist das, woran er sich bindet.

Mehrere Dateien gleichzeitig

Die Brücke hält eine Verbindung pro Figma-Fenster, in dem Sie das Plugin gestartet haben. Das ist das Zustimmungsmodell: Eine Datei ist erreichbar, weil Sie sie geöffnet und das Plugin dort gestartet haben – nicht, weil ein Flag den Umfang erweitert hat.

• Ein Fenster – nichts ändert sich. Befehle gehen dorthin.

• Mehrere Fenster – ein Befehl muss sein Ziel benennen, sonst schlägt er fehl und listet die verbundenen Dateien auf:

  figma_status                                        # lists every connected window
  figma_run {args: ["canvas","info"], fileKey: "GY5SasBJ…"}
  figma_spec {nodeId: "12:34", fileKey: "GY5SasBJ…"}

  figma_render, figma_selection, figma_inspect, figma_screenshot und figma_spec akzeptieren denselben Parameter fileKey. Eine vollständige Figma-Knoten-URL liefert ebenfalls automatisch ihren Dateischlüssel. Ohne ein Ziel sagt figma_selection, welche Dateien geöffnet sind, anstatt zu raten. In der Engine-CLI lautet das Flag --figma-file, nicht --file: eval und spec verwenden bereits -f, --file für einen lokalen Pfad.

Es gibt bewusst keine "Alle Dateien"-Option. Jeder Schreibvorgang benennt eine Datei, sodass ein versehentlicher Befehl nicht auf eine ganze Bibliothek ausstrahlen kann. Zwei Fenster mit derselben Datei sind für das Routing nicht unterscheidbar, daher übernimmt das neuere Fenster und dem älteren wird mitgeteilt, dass es die Brücke verloren hat. Prüfeinträge tragen den Dateischlüssel, sodass figma_history lesbar bleibt, wenn mehrere Dateien im Spiel sind.

Das Erreichen von Dateien, die Sie nicht geöffnet haben, ist nicht vorgesehen: Figmas REST-API kann keinen Dokumentinhalt schreiben, daher ist eine Massenumbenennung über dreißig Bibliotheksdateien hinweg etwas, das dieses Tool nicht ehrlich anbieten kann.

FigJam

Das Plugin läuft auch in FigJam-Boards über dieselbe Brücke – kein zweiter Transport, keine zusätzliche Berechtigung:

figma_run ["jam", "sticky", "Ship the handshake", "--color", "green"]
figma_run ["jam", "stickies", "[\"Discovery\",\"Build\",\"Ship\"]", "--columns", "3"]
figma_run ["jam", "shape", "Decide?", "--type", "DIAMOND"]
figma_run ["jam", "connector", "1:2", "3:4", "--text", "yes"]
figma_run ["jam", "table", "3", "4", "--data", "[[\"Step\",\"Owner\"],[\"Handshake\",\"Alex\"]]"]
figma_run ["jam", "board"]      # read everything back, with connectors
figma_run ["jam", "arrange"]    # arrange only the current selection
figma_run ["jam", "arrange", "--ids", "1:2,3:4"]
figma_run ["jam", "arrange", "--all"] # explicit: whole page

Neue Knoten landen rechts von dem, was bereits auf dem Board ist, es sei denn, Sie übergeben --at x,y, sodass ein Agent, der zu einem bevölkerten Board hinzufügt, nicht alles am Ursprung stapelt. Jeder Befehl prüft zuerst figma.editorType und sagt "Dies ist eine Figma-Datei, kein FigJam-Board", anstatt mit einer undefinierten API zu scheitern. figma_status berichtet, an welchen Editor die Brücke angeschlossen ist.

jam arrange ist bewusst auf die Auswahl beschränkt. Agenten können exakte Knoten-IDs übergeben, ohne die Auswahl des Benutzers zu ändern; das Neuanordnen der gesamten Seite erfordert das sichtbare --all-Flag. Abschnitte und Verbinder werden von diesem Befehl niemals verschoben. Die öffentliche Oberfläche wurde am 10.08.2026 in Figma Desktop getestet. Die Betreuer führen die detaillierten Befehls- und Rücklesebelege außerhalb des öffentlichen Repositorys.

Figma Slides Beta

Slides verwendet dieselbe authentifizierte Plugin-Brücke. Die Beta-Oberfläche umfasst die Deck-Struktur und native Folieneigenschaften, keinen separaten Präsentationsrenderer:

figma_run ["slides", "inspect"]
figma_run ["slides", "create", "Agenda", "--row", "0", "--col", "1"]
figma_run ["slides", "duplicate", "Agenda", "--label", "Agenda alternative"]
figma_run ["slides", "move", "Agenda alternative", "1", "0"]
figma_run ["slides", "transition", "Agenda", "DISSOLVE", "--duration", "0.4"]
figma_run ["slides", "skip", "Appendix", "on"]
figma_run ["slides", "delete", "1:42"]

Figma nummeriert native Foliennamen neu, sobald sich das Canvas-Raster ändert. Das optionale Argument für create und --label bei duplicate speichert daher ein dauerhaftes Bridge-Label in den Plugin-Daten; inspect meldet sowohl den nativen name als auch das stabile label. Referenzen werden nach ID, exaktem nativen Namen oder Label, dann eindeutiger Teilzeichenfolge aufgelöst. Mehrdeutigkeit ist ein Fehler, delete erfordert immer eine explizite Referenz, und duplicate/move lehnen eine nicht vorhandene Zielzeile ab, anstatt Figmas Fallback-Platzierung zu akzeptieren. Jeder Vorgang prüft figma.editorType === "slides", bevor er eine Slides-only-API berührt. Die offenen Kandidaten und die Kriterien für das Verlassen der Beta befinden sich in docs/slides-roadmap.md; die Editor-Akzeptanz wird vom Betreuer getrennt vom öffentlichen Repository verifiziert.

Token-Synchronisation (bidirektional)

tokens import erstellt nur, daher erreicht ein im Code bearbeiteter Wert niemals eine vorhandene Figma-Variable und ein in Figma bearbeiteter Wert erreicht niemals den Code. tokens sync schließt diese Lücke:

figma_run ["tokens", "sync", "src/tokens.json"]              # plan only
figma_run ["tokens", "sync", "src/tokens.json", "--apply"]   # write it

Die Importoberfläche ist breiter als die Sync-Oberfläche. Der einmalige import akzeptiert Tailwind v3-Konfiguration, Tailwind v4/CSS, Storybook-Indizes, DTCG/W3C-JSON und die DTCG-kompatiblen Token-Formen, die von Style Dictionary und Tokens Studio exportiert werden. Diese Kompatibilität umfasst keine Tokens Studio-Theme-Semantik oder willkürliche Preprozessoren; Metadaten wie $themes werden ignoriert, während Token-Sets und Aliase gelesen werden.

Neue FLOAT-Variablen in expliziten spacing/*- oder space/*-Namespaces sind nur auf Figmas GAP-Verbraucher beschränkt. radius/*- und radii/*-Variablen sind nur auf CORNER_RADIUS beschränkt. Die Inferenz ist bewusst namespace-exakt: Namen wie spacingFactor bleiben im Standard-Scope von Figma, und das Rendern ändert nicht stillschweigend die Scopes vorhandener Benutzer- oder Bibliotheksvariablen. Andere neue COLOR-, FLOAT- oder STRING-Variablen zeigen SCOPE DECISION REQUIRED mit nur den kompatiblen Figma-Optionen an. Der Agent sollte fragen, bevor er sie eingrenzt; überprüfen Sie den Katalog mit figma_reference {name:"variable-scopes"} und wenden Sie die Antwort mit figma_run ["var","update","<name>","--collection", "<collection>","--scopes","TEXT_FILL,STROKE_COLOR"] an.

Sicherer Drei-Wege-Sync akzeptiert nur DTCG / W3C-Design-Tokens (.json, was export dtcg ausgibt) und CSS-Custom-Properties (.css, was export css ausgibt). Sass $variables sind keine CSS-Custom-Properties und .scss wird abgelehnt, anstatt teilweise geparst zu werden. Beachten Sie, dass export dtcg jede lokale Variable in eine Datei schreibt, während Sync auf eine Sammlung abzielt – übergeben Sie --collection entsprechend. Wenn die meisten Namen in der Datei bereits in einer anderen Sammlung leben, teilt Sync dies mit, anstatt anzubieten, sie zu duplizieren. Tailwind-Konfigurationen sind nur eine Importquelle – ihr Parser sortiert Werte in Farbe/Abstand/Radius und kann keinen Round-Trip durchführen, daher lehnt Sync sie namentlich ab, anstatt Tokens, die es nicht verstanden hat, stillschweigend fallen zu lassen.

Warum eine Sperrdatei. Ein bidirektionaler Sync ohne Gedächtnis kann nicht unterscheiden, ob "der Code geändert wurde" oder "Figma geändert wurde" – er sieht nur, dass sich beide unterscheiden, und je nachdem, welche Richtung er wählt, zerstört er die Arbeit der anderen Seite. figma-tokens.lock.json zeichnet den Zustand zum Zeitpunkt des letzten erfolgreichen Syncs auf, sodass jede Entscheidung ein Drei-Wege-Vergleich ist:

Konflikte stoppen den gesamten Durchlauf. Lösen Sie sie auf, indem Sie eine Seite bearbeiten, oder entscheiden Sie sie alle auf einmal mit --ours (die Codedatei gewinnt) / --theirs (Figma gewinnt, und es wird nichts nach Figma geschrieben).

Löschungen benötigen --prune, und selbst dann betreffen sie nur Variablen, die der Sync selbst erstellt hat – eine Variable, die er nie verfolgt hat, wird als unverfolgt gemeldet und in Ruhe gelassen.

Die Sperrdatei speichert auch die Figma-ID jeder Variable, was eine Umbenennung zu einer Umbenennung macht, anstatt zu einem Löschen plus einem Erstellen, das jede Ebenenbindung verlieren würde. Die Paarung erfolgt nach Wert und nur, wenn eindeutig: Das Umbenennen und Neubewerten eines Tokens im selben Commit fällt auf Erstellen + Löschen zurück. Führen Sie diese also als zwei Schritte durch, wenn die Bindungen wichtig sind.

Ohne --apply beendet sich der Befehl mit Exit-Code 1, wenn Änderungen anstehen, sodass er als CI-Prüfung für "Ist Figma mit dem Repo synchron?" fungiert.

Bindung und Wechseln, welchem Design eine Sammlung folgt

tokens sync schreibt Token-Werte. Zwei benachbarte Dinge, die es bewusst nicht tut:

figma_run ["node", "bind", "12:34", "radius", "radius/lg", "--collection", "TARGET_COLLECTION"]
figma_run ["tokens", "rebind", "TARGET_COLLECTION", "--node", "12:34"]            # plan
figma_run ["tokens", "rebind", "TARGET_COLLECTION", "--node", "12:34", "--apply"] # write

node bind bindet eine Variable an eine Eigenschaft eines vorhandenen Knotens – fill, stroke, radius, gap, padding (oder eine Seite), opacity, stroke-width, width, height. Das lesende Gegenstück ist node bindings. Übergeben Sie --batch mit einem JSON-Array, um viele Eigenschaften oder Knoten in einem Aufruf zu binden.

Ein Variablenname, der nicht eindeutig ist, wird abgelehnt, nicht erraten – diese Datei hat radius/lg in zwei Sammlungen, und die Antwort nennt beide, sodass --collection es klären kann. Der Typ der Variable wird zuerst gegen die Eigenschaft geprüft, sodass ein COLOR auf radius mit einem Satz fehlschlägt, anstatt mit einem Plugin-Stack-Trace.

Typografie-Variablen haben ihren eigenen bereichsbewussten Befehl, da Text auf verschiedenen Zeichenbereichen unterschiedliche Bindungen tragen kann:

figma_run ["font", "bind", "12:36", "fontWeight", "type/weight", "--collection", "Typography"]
figma_run ["font", "bind", "12:36", "line-height", "type/line-height", "--start", "0", "--end", "12"]
figma_run ["font", "unbind", "12:36", "lineHeight", "--start", "0", "--end", "12"]

Bindbare Felder sind fontFamily, fontSize, fontStyle, fontWeight, letterSpacing, lineHeight, paragraphSpacing und paragraphIndent; Schreibweisen in Kebab-Case werden ebenfalls akzeptiert. Vorhandene Schriftarten – und für Family-/Style-/ Weight-Bindungen die relevanten verfügbaren Family-Styles – werden geladen, bevor die Bindung geändert wird. Variablemannen werden bei Mehrdeutigkeit abgelehnt, und STRING vs. FLOAT wird geprüft, bevor Figma aufgerufen wird. Eine numerische fontWeight-Bindung ist dennoch kein allgemeiner Variable-Font-Achsen-Setter: Figma wählt eine gültige Weight für die aktive Schriftart aus.

tokens rebind ist der Theme-Wechsel: Es durchläuft einen Teilbaum und zeigt jede Bindung auf die gleichnamige Variable in einer Ziel-Collection um. Entwerfen Sie eine Karte gegen SOURCE_COLLECTION, führen Sie rebind mit TARGET_COLLECTION aus, und dieselbe Karte folgt den Werten der Ziel-Collection – kein Neudesign. Standardmäßig plant es; --apply schreibt. Tokens ohne Gegenstück in der Ziel-Collection werden aufgelistet und bleiben auf ihren ursprünglichen Verweis gerichtet, sodass ein partielles Theme eher ein Bericht als ein halbkaputtes Design ist.

node set ändert Eigenschaften an Knoten, die bereits existieren – fill, stroke, strokeWidth, radius, opacity, x, y, width/height, name, visible – einen Knoten nach dem anderen oder viele durch --batch, was wichtig ist, weil die Batch-Form ein Round-Trip ist:

figma_run ["node", "set", "12:34", "--name", "Card", "--radius", "12"]
figma_run ["node", "set", "--batch", "[{\"node\":\"12:35\",\"fill\":\"var:sage/50\",\"name\":\"Badge\"}]"]

Eine Farbe akzeptiert einen Hex-Wert oder var:<name>. Der Unterschied ist nicht kosmetisch: Ein Hex-Wert ist eingefroren, ein var:-Verweis bleibt gebunden, sodass ein späteres tokens rebind ihn immer noch verschieben kann.

Lokale Styles, Variablen-Metadaten und Modi

Die lokalen Design-System-Primitiven, die früher manuelle UI-Arbeit erforderten, haben jetzt erstklassige Figma-Befehle. Sie verwenden die Live-Plugin-API, nicht REST:

figma_run ["style", "list", "--type", "TEXT"]
figma_run ["style", "show", "Heading/H1"]
figma_run ["style", "create", "PAINT", "Brand/Primary", "--properties", "{\"paints\":[{\"type\":\"SOLID\",\"color\":{\"r\":0.1,\"g\":0.3,\"b\":0.9}}]}"]
figma_run ["style", "apply", "Brand/Primary", "12:34,12:35", "--field", "fill"]
figma_run ["style", "consumers", "Brand/Primary"]
figma_run ["style", "publish-status", "Brand/Primary"]
figma_run ["style", "bind-font", "Body", "fontSize", "--variable", "type/size/body"]
figma_run ["style", "unbind-font", "Body", "fontSize"]

style umfasst lokale PAINT-, TEXT-, EFFECT- und GRID-Styles. update akzeptiert dieselben typ-spezifischen JSON-Eigenschaften wie create; apply validiert den Style-Typ gegen fill, stroke, text, effect oder grid. Namenssuchen lehnen Mehrdeutigkeit ab. Verbraucher stammen von getStyleConsumersAsync(), und der Veröffentlichungsstatus ist einer von Figmas UNPUBLISHED, CURRENT oder CHANGED-Werten.

Variablen legen die Metadaten- und Modus-Operationen offen, die der Token-Datei-Sync nicht besitzt:

figma_run ["var", "show", "space/md", "--collection", "Primitives"]
figma_run ["var", "update", "space/md", "--description", "Medium spacing", "--scopes", "GAP"]
figma_run ["var", "set-value", "space/md", "12", "--mode", "Light"]
figma_run ["var", "set-value", "space/card", "--alias", "space/md", "--mode", "Light"]
figma_run ["var", "code-syntax", "space/md", "WEB", "var(--space-md)"]
figma_run ["var", "resolve", "space/md", "12:34"]
figma_run ["col", "mode-add", "Primitives", "Dark"]
figma_run ["col", "mode-rename", "Primitives", "Dark", "Dim"]
figma_run ["col", "extend", "Primitives", "Brand"]

var show gibt Werte nach Modus, Scopes, Code-Syntax, Collection-Metadaten und Veröffentlichungsstatus zurück. var resolve erfordert bewusst einen Verbraucherknoten, weil Aliase unter den ausgewählten Modi dieses Knotens unterschiedlich aufgelöst werden können. Collection show, update, mode-add, mode-rename, mode-remove und publish-status folgen derselben ID/exakter-Name/eindeutiger-Teilstring-Suchrichtlinie. Figmas Plangrenzen für die Modusanzahl bleiben von Figma durchgesetzt und erscheinen als Fehler. Collection-Erweiterungen verwenden VariableCollection.extend() für lokale Collections und extendLibraryCollectionByKeyAsync() für veröffentlichte Keys. Figma schränkt diese Funktion auf Enterprise-Pläne ein; die CLI meldet Figmas Planfehler unverändert. Text-Style-Bindungen unterstützen genau Figmas bindbare Typografie-Felder: Family, Style, Weight, Size, Line Height, Letter Spacing und Paragraph-Werte.

Aktivierte Team-Bibliotheken

Bibliothekserkennung und -importe bleiben ebenfalls auf dem authentifizierten Plugin-Transport:

figma_run ["library", "collections"]
figma_run ["library", "variables", "Acme/Primitives", "--type", "COLOR"]
figma_run ["library", "import-variable", "<published-variable-key>"]
figma_run ["library", "import-style", "<published-style-key>"]
figma_run ["library", "import-component", "<published-component-key>"]
figma_run ["library", "import-component-set", "<published-component-set-key>"]

collections und variables sind Lesevorgänge. Die vier import-*-Befehle materialisieren veröffentlichte Assets in der aktuellen Datei und sind daher Schreibvorgänge im Capability-Katalog. Figma macht nur die Erkennung für Variable Collections und Variablen zugänglich. Veröffentlichte Styles, Komponenten und Komponenten-Sets können importiert werden, wenn ihr stabiler Key bereits bekannt ist, aber die Plugin-API kann sie nicht aufzählen.

Bibliotheken müssen in der Figma-UI für die aktuelle Datei aktiviert sein, bevor library collections sie sehen kann; die Plugin-API kann keine Bibliothek aktivieren. Das ausgelieferte Plugin deklariert bereits die erforderliche teamlibrary-Berechtigung. Die Namenssuche verwendet den Collection-Key, den exakten Collection-Namen, dann einen eindeutigen Teilstring des Collection- oder Bibliotheksnamens. Die Bibliothekserkennung hat ein 18-Sekunden-Plugin-API-Timeout unterhalb der Bridge-Frist, sodass eine hängende Figma-Bibliotheksanfrage die Operation benennt und vorschlägt zu prüfen, ob die Bibliothek aktiviert ist, anstatt in ein generisches Ausführungs-Timeout zu verfallen.

Prototypen, Dev-Mode-Messungen und Anmerkungen

Diese Dokumentfunktionen sind ebenfalls Plugin-API-first:

figma_run ["prototype", "inspect", "12:34"]
figma_run ["prototype", "add", "12:34", "--trigger", "click", "--navigate-to", "12:36"]
figma_run ["prototype", "set", "12:34", "--json", "[{\"trigger\":{\"type\":\"ON_CLICK\"},\"actions\":[{\"type\":\"BACK\"}]}]"]
figma_run ["measure", "add", "12:34:right", "12:36:left", "--offset", "16", "--text", "gap"]
figma_run ["annotate", "categories"]
figma_run ["annotate", "add", "Review spacing", "--node", "12:34", "--category", "Review", "--properties", "width,fontSize"]
figma_run ["annotate", "edit", "12:34", "0", "--text", "Resolved"]

prototype set --json ist die verlustfreie Form für Figmas mehrere Aktionen, SET_VARIABLE, SET_VARIABLE_MODE und bedingte Blöcke. Es schreibt über setReactionsAsync(), sodass dynamische Seitenmanifeste unterstützt werden. Messungs-Schreibvorgänge sind auf den Figma-Dev-Mode beschränkt und verwenden die nativen Messmethoden von PageNode. Anmerkungsindizes sind nullbasiert; benutzerdefinierte Kategorie-Erstellungs-/Bearbeitungs-/Entfernungsbefehle sind neben categories verfügbar. Diese manuellen Überprüfungsnotizen sind unabhängig von den automatischen Boundary-Fallback-Anmerkungen des semantischen Renderers, die nur von explizit optierten verlustbehafteten Mapping-Richtlinien ausgegeben werden und durch Plugin-Daten maschinenlesbar bleiben.

2026 Plugin-APIs: Video, Shader, Grid, Slots und Draw

Die aktuelle offizielle Plugin-API-Oberfläche wird als Figma-Befehle und nicht als REST-Aufrufe bereitgestellt:

figma_run ["export", "video", "12:34", "--format", "mp4", "--fps", "30", "-o", "/abs/demo.mp4"]
figma_run ["shader", "list"]
figma_run ["shader", "import", "<shader-id>"]
figma_run ["shader", "apply", "12:34", "<shader-id>", "--field", "fill", "--properties", "{\"definition-id\":0.8}"]
figma_run ["layout", "grid", "set", "12:34", "--rows", "2", "--columns", "3", "--row-gap", "12"]
figma_run ["layout", "grid", "auto-flow", "12:34", "--auto-tracks", "rows", "--positioning", "row_auto_flow"]
figma_run ["slot", "create", "12:37", "Content", "--settings", "{\"minChildren\":1,\"maxChildren\":3}"]
figma_run ["slot", "validate", "12:37"]
figma_run ["draw", "inspect", "12:38"]
figma_run ["draw", "text-path", "12:38", "--text", "Around the curve"]
figma_run ["draw", "stroke-profile", "12:38", "--preset", "TAPER"]
figma_run ["draw", "pattern", "12:38", "12:39", "--field", "fill"]

Video-Export löst einen ausgewählten Nachkommen in seinen übergeordneten animierten Frame auf und akzeptiert nur Figmas formatspezifische FPS-Werte. Shader-Eigenschaften sind nach Definitions-ID und nicht nach Anzeigename verschlüsselt, und ein verfügbarer Shader muss importiert werden, bevor er angewendet wird. layout grid bedeutet das Auto-Layout-GRID-Modell; der ältere übergeordnete grid-Befehl bleibt die Layout-Guide-Verwaltung. Slots legen GA SlotSettings, bevorzugte Werte, Zurücksetzung und Limitverletzungen offen; JSX <Slot> verwendet jetzt ComponentNode.createSlot() und validiert konfigurierte Limits nach dem Rendern. Draw-Befehle umfassen Textpfade, Repeat-Transform-Gruppen, Stretch/Scatter/Dynamic-Strokes, variable Breitenprofile und asynchrone Pattern-Fill/Stroke-Setter. Führen Sie die entsprechenden inspect/validate-Lesevorgänge vor Schreibvorgängen aus, wenn Sie ein unbekanntes Dokument ändern.

Finden, was repariert werden muss

figma_run ["analyze", "lint", "--node", "12:34"]

Ein Durchlauf für die vier Dinge, auf die ein Design-System-Review einwirkt: Farben, die mit einer vorhandenen Variable übereinstimmen, aber nicht daran gebunden sind, Ebenen, die noch einen Standardnamen tragen, Text ohne Style, Text unter 12px. --fail-on-issues macht es zu einem CI-Gate; --kind schränkt es ein; --json kürzt nie.

Eine hartcodierte Farbe wird nur gemeldet, wenn eine Variable bereits diesen exakten Wert enthält – andernfalls ist der Befund Rauschen, auf das Sie nicht reagieren können. Da die Übereinstimmung bekannt ist, kommt jede mit dem Befehl, der sie behebt:

unbound token colour — 1
  12:35    Badge  fill is #8a9a8d, which is sage/400
    fix: node bind 12:35 fill "sage/400" --collection "Sprout Primitives"

analyze colors|typography|spacing liefern immer noch die vollständige Bestandsaufnahme. Lint ist der Durchlauf, der beantwortet, ob überhaupt etwas getan werden muss.

Variable Fonts und OpenType-Fakten

Figma legt kein allgemeines Variationsachsen-Tupel durch die Plugin-API offen. Die Bridge trennt daher Fakten, die Figma tatsächlich meldet, von Achsenabsichten, die ein Aufrufer explizit aufzeichnet:

figma_run ["font", "inspect", "12:36"]
figma_run ["font", "inspect", "12:36", "--start", "0", "--end", "12", "--all-open-type"]

font inspect gibt formatierte Textbereiche mit fontName, numerischem schreibgeschütztem fontWeight, Größe, aktivierten OpenType-Feature-Tags und aufgelösten Typografie-Variablenbindungen zurück. --all-open-type enthält auch falsche Feature-Werte. Das Ergebnis benennt die API-Grenze explizit: Ein gemeldetes fontWeight ist kein allgemeines wght/wdth/opsz/benutzerdefiniertes Achsen-Tupel, und OpenType-Features sind schreibgeschützt.

Wenn die genauen Achsenwerte aus der UI oder einem anderen Schriftwerkzeug bekannt sind, bewahren Sie sie auf dem Textknoten als Bereichsmetadaten:

figma_run ["font", "remember-axes", "12:36", "wght=357,wdth=82", "--start", "0", "--end", "12"]
figma_run ["font", "axes", "12:36"]
figma_run ["font", "forget-axes", "12:36", "--start", "0", "--end", "12"]
figma_run ["font", "forget-axes", "12:36"]  # clear every stored range

remember-axes ändert nur Plugin-Metadaten – niemals die Schriftart oder gerenderte Glyphen – und wird daher vom Capability-Katalog als Schreibvorgang klassifiziert. figma_spec trägt diese Aufzeichnungen als axes-meta[start:end](tag=value,…), plus Figmas gemeldeten fw…-Wert und aktivierte ot(…)-Tags, sodass die Design-to-Code-Erfassung die dokumentierte Absicht nicht stillschweigend verwirft.

Native Plugin-API-Fakten

Zwei Lesebefehle geben Figmas eigene Darstellungen preis, ohne die REST-API zu kontaktieren:

figma_run ["node", "css", "12:34"]
figma_run ["node", "css", "12:34", "--json"]
figma_run ["export", "node-json", "12:34"]
figma_run ["export", "node-json", "12:34", "-o", "facts/card.json"]

node css ruft getCSSAsync() auf und gibt die Deklarationen zurück, die Figma für sein Inspect-Panel bereitstellt. Dies ist bewusst getrennt von export css, das Design-Token-Custom-Properties exportiert. export node-json verwendet exportAsync({format:"JSON_REST_V1"}): Die Form ähnelt dem REST-Dateischema, aber die Bytes stammen aus dem Live-Plugin-Dokument und benötigen weder einen Token noch eine Netzwerkanfrage.

Versionsgeschichte und Diffs

Figmas Plugin-API kann eine Version schreiben, aber nicht zurücklesen, daher hat "was hat sich seit heute Morgen geändert" keine Antwort allein von der Bridge. history liefert eine ohne jegliche Anmeldeinformationen: Zeichnen Sie die Struktur eines Teilbaums auf, zeichnen Sie sie später erneut auf, differenzieren Sie die beiden.

figma_run ["history", "save", "Before refactor", "--description", "Agent restore point"]
figma_run ["history", "snapshot", "--label", "before refactor"]
# … agent works …
figma_run ["history", "diff", "latest", "live"]

history save erstellt den benannten Eintrag direkt über saveVersionHistoryAsync() und ist ein Figma-Schreibvorgang. snapshot, list und diff bleiben lokale/schreibgeschützte Figma-Operationen; das Lesen von Figmas nativen historischen Versionen erfordert immer noch das optionale REST-Add-on.

Ein Snapshot speichert einen normalisierten Datensatz pro Knoten – Geometrie, Layout, Paints, Typografie, Komponenten-Keys – plus einen Content-Hash und einen Teilbaum-Hash, sodass der Differ ein unberührtes Segment melden kann, anstatt es zu durchlaufen. Sie leben in ~/.figma-bridge-mcp/snapshots/<fileKey>/, gzip-komprimiert, die neuesten 20 werden behalten.

Referenzen sind latest, previous, ein Index aus history list, ein Dateiname oder live für das Dokument genau jetzt. Der Bericht trennt hinzugefügt, entfernt, ersetzt, verschoben und geändert – diese letzte Unterscheidung ist diejenige, die in der Praxis zählt: Ein Agent, der einen Frame löscht und neu rendert, behält den Namenpfad, erhält aber neue Knoten-IDs, und ohne die Ersetzungserkennung würde jedes Neurendern wie hundert Löschungen aussehen. --changelog gibt stattdessen Markdown aus; diff beendet sich mit 1, wenn sich etwas unterscheidet, sodass es auch als CI-Gate funktioniert.

Über MCP ist dies ein Parameter, kein dreizehntes Werkzeug:

figma_history {diff: {from: "latest", to: "live"}}
figma_history {diff: {from: "version:1234", to: "version:5678"}}   # REST add-on

version:-Referenzen gehen durch die REST-Ebene und differenzieren, was Designer gespeichert haben, unter Verwendung desselben Differs. Die beiden Quellen können nicht in einem Diff gemischt werden: Ein REST-Dokument und ein Plugin-Snapshot legen unterschiedliche Eigenschaften offen, sodass jeder Knoten geändert aussehen würde – das Werkzeug sagt dies, anstatt eine irreführende Wand von Ausgaben zu produzieren.

Motion

Figma Motion (Config 2026 Beta) ist über figma_run mit ["motion", …] erreichbar: Keyframe-Tracks (add), ganze Spezifikationen aus JSON (apply), benannte Presets (preset), choreografierte Offsets über Knoten hinweg (stagger), Figmas First-Party-Animation-Styles (styles, style), Frame-Dauer (timeline), Rücklesen (inspect) und Entfernung (clear).

Wie jeder andere Befehl läuft es über die Plugin-Bridge – es gibt keinen separaten Transport dafür. styles und inspect sind Lesevorgänge; alles andere, einschließlich timeline (es liest oder setzt, abhängig von seinen Argumenten), zählt als Schreibvorgang unter FIGMA_WRITE_CONFIRM=1.

Motion wird hinter einem Figma-Beta-Flag ausgerollt. Ohne Zugriff schlagen die Befehle mit einem benannten MOTION_DISABLED-Fehler fehl, der Ihnen mitteilt, Figma Desktop zu aktualisieren, anstatt eines generischen API-Fehlers.

REST-Add-on (optional)

Alles oben Genannte funktioniert mit null Figma-Anmeldeinformationen. Drei Dinge, die die lokale Plugin-Bridge strukturell nicht erreichen kann, befinden sich hinter Figmas REST-API und können mit einem persönlichen Zugriffstoken freigeschaltet werden:

Aktivierung – der Token verlässt niemals Ihren Rechner:

1. Erstellen Sie einen persönlichen Zugriffstoken in Figma (Einstellungen → Sicherheit → Persönliche Zugriffstoken) mit den Bereichen: Dateiinhalt (lesen), Dateiversionen (lesen), Kommentare (lesen und schreiben). Aktueller Benutzer (lesen) ist optional – es bewirkt nur, dass figma_status Ihren Handle anzeigt.

2. Öffnen Sie das Figma Bridge Plugin in Figma Desktop, verbinden Sie sich (das Feld erscheint, sobald das Plugin authentifiziert ist), und erweitern Sie „REST-Token (optional)“. Fügen Sie den Token ein, Token speichern.

3. figma_status meldet, dass der Token konfiguriert ist, ohne eine Remote-Anfrage zu stellen. Führen Sie figma_status {validateRest:true} aus, wenn Sie eine explizite Gültigkeitsprüfung wünschen; es meldet Ihren Handle oder überprüft den Dateizugriff, wenn der optionale Aktueller Benutzer-Bereich fehlt.

Der Token gelangt vom Plugin über den authentifizierten localhost-WebSocket zum Daemon, der ihn in ~/.figma-bridge-mcp/rest-token (Modus 0600) speichert. Er wird niemals im Chat eingegeben, niemals in Ihrer MCP-Client-Konfiguration gespeichert, niemals von einem Tool zurückgesendet und niemals im Audit-Log protokolliert (REST-Aufrufe werden nur als Methode + Pfad protokolliert). Token löschen im Plugin entfernt die Datei.

Headless/CI-Alternative: Setzen Sie die Umgebungsvariable FIGMA_REST_TOKEN – sie überschreibt die Datei.

Umfang: Standardmäßig zielen REST-Aufrufe auf die aktuell in Figma Desktop geöffnete Datei (das Plugin übermittelt seinen Dateischlüssel). Andere Dateien erfordern einen expliziten fileKey-Parameter (bloßer Schlüssel oder vollständige Figma-URL). Beachten Sie, dass ein PAT selbst jede Datei lesen kann, auf die sein Konto Zugriff hat – halten Sie die Bereiche minimal.

Der REST-Client ist eine geschlossene interne Whitelist, keine generische HTTP-Notluke. Er erlaubt Token-Health, Versionslisten, versionsgebundene Dokumentinhalte, Kommentare und dateiweite Metadaten veröffentlichter Komponenten. Ein bloßer Abruf der aktuellen Datei sowie alle Knoten-/CSS-/Export-/Variablen-/Style-/Dev-Resource-Endpunkte werden abgelehnt, bevor der Token gelesen oder das Netzwerk berührt wird; diese Operationen müssen die oben genannten lokalen Plugin-API-Befehle verwenden.

Sicherheitsmodell

• Kein Figma-API-Token erforderlich – Figma wird über das lokale Plugin gesteuert, niemals über api.figma.com. Das REST-Add-on ist streng opt-in: Ohne Token ist der Codepfad inaktiv, und mit einem Token lebt der Token in einer 0600-Datei (oder Ihrer eigenen Umgebungsvariablen), nicht in der MCP-Client-Konfiguration.

• Kein Binary-Patching – Der Yolo/CDP-Modus wurde aus der eingebundenen Engine entfernt.

• Fähigkeitsgesteuerte Befehle – figma_run akzeptiert nur Befehle, die vom Capability-Katalog bereitgestellt werden; connect wird nicht bereitgestellt, sodass eine Verbindung nur im Safe-Modus erzwungen wird. Derselbe aufgelöste Plan steuert das Write-Confirm-Gate, die Zielanforderung und die Wiederholungsrichtlinie und verhindert so Adapter-Drift.

• Keine Shell – Die Engine wird mit execFile (shell:false) gestartet.

• Zweischichtige Daemon-Authentifizierung, kein Geheimnis auf der Leitung – Signierte HTTP-Anfragen (pro Anfrage HMAC über Methode/Pfad/Body, geschlüsselt mit dem Session-Token, Nonce-Replay-Schutz) + ein gegenseitiger Challenge-Response-Handshake auf dem Plugin-Socket (Origin/Host-Whitelist). Weder der Session-Token noch der Zugriffsschlüssel wird jemals in eine der beiden Richtungen übertragen – siehe Handshake.

• Localhost-gesperrtes Plugin – plugin/manifest.json beschränkt networkAccess.allowedDomains auf ws://127.0.0.1:3456–3460.

• Isolierter Zustand – Token, PID, Schlüssel und Audit-Log leben unter ~/.figma-bridge-mcp/, getrennt von einer etwaigen upstream-figma-ds-cli-Installation.

• Audit-Log – Jeder ausgeführte Befehl wird an ~/.figma-bridge-mcp/audit.log angehängt (mit berührten Knoten-IDs, optionalen Labels und einem Abschlusseintrag, der Erfolg/Misserfolg festhält – die Datenquelle für figma_history). Rotiert bei 5 MB; eine vorherige Generation (audit.log.1) wird aufbewahrt und weiterhin von figma_history gelesen.

Port-Fallback. Der Daemon bindet den ersten freien Port im Bereich 3456–3460 und veröffentlicht ihn in ~/.figma-bridge-mcp/daemon-port; die CLI-/MCP-Ebenen lösen den Port pro Aufruf auf (env DAEMON_PORT > Port-Datei > 3456), und das Plugin scannt den gesamten Bereich, sodass ein fremder Prozess, der 3456 belegt, die Verbindung nicht mehr blockiert. Die Belegungsprüfung ist ein unauthentifizierter /health-Probe, und authentifizierte Anfragen sind HMAC-signiert – ein Beleger auf einem Bereichsport sieht weder den Session-Token noch etwas Wiederholbares (Signaturen binden Zeitstempel, Nonce, Methode, Pfad und Body; der Daemon lehnt wiederverwendete Nonces ab). Der Plugin-Socket ist auf jedem Bereichsport aus demselben Grund sicher: Der untenstehende Handshake trägt kein Geheimnis und bindet den Port, auf dem er ausgeführt wurde. Das explizite Setzen von DAEMON_PORT deaktiviert den Fallback; Werte außerhalb von 3456–3460 werden nicht unterstützt – das Plugin-Manifest wird von Figma erzwungen und kann diese nicht erreichen.

Handshake

Der Plugin-Socket führt einen gegenseitigen Challenge-Response (Proto 2, engine/src/lib/plugin-handshake.js) durch:

daemon → plugin   {type:'challenge', proto:2, nonce:<dNonce>, port:<bound>}
plugin → daemon   {type:'hello', proto:2, nonce:<pNonce>, version, proof}
daemon → plugin   {type:'hello-ack', proof, restTokenConfigured}

wobei proof = HMAC-SHA256(access key, transcript) über beide Nonces, den gebundenen Port und die Plugin-Version – mit unterschiedlichen Rollenbezeichnungen und Nonce-Reihenfolge pro Richtung, sodass kein Proof als der andere wiederverwendet werden kann. Drei Eigenschaften folgen daraus:

• Der Schlüssel überquert niemals die Leitung. Ein Prozess, der vor dem Daemon einen Bereichsport bindet und die gesamte Austausch aufzeichnet, lernt einen HMAC über Nonces, die er nie wieder sehen wird. Dies beseitigt das Restrisiko, das frühere Versionen dokumentierten, bei dem der rohe Schlüssel der erste Frame war, den das Plugin sendete.

• Der Daemon beweist sich ebenfalls. Vor Proto 2 vertraute das Plugin dem, was antwortete, und würde jedes eval ausführen, das ihm gesendet wurde – eine Imitation des Daemons benötigte überhaupt keinen Schlüssel. Das Panel verweigert nun jeden Befehl, bis die Bestätigung verifiziert ist.

• Der gebundene Port befindet sich im Transcript. Ein Beleger auf 3456, der an den echten Daemon auf 3457 weiterleitet, lässt das Plugin 3456 signieren, während der Daemon 3457 verifiziert, sodass das Relay zusammenbricht.

Es gibt keinen Proto-1-Fallback. figma_connect aktualisiert die installierten Plugin-Dateien bei jedem Lauf, sodass ein Upgrade wie folgt abläuft: Führen Sie figma_connect aus, schließen Sie dann das Plugin-Fenster und öffnen Sie es erneut – ein veraltetes Panel erhält einen benannten Fehler, der genau das besagt, anstatt eines stillschweigend schwächeren Handshakes.

Das Panel enthält eine eigene SHA-256/HMAC-Implementierung: Die Plugin-UI ist ein sandboxed Null-Origin-Iframe, in dem die Verfügbarkeit von WebCrypto nicht garantiert werden kann, und ein stillschweigender Fallback auf etwas Schwächeres ist das schlechteste Ergebnis für einen Auth-Handshake. tests/plugin-handshake.test.js führt diesen ausgelieferten Code gegen Node's crypto aus, sodass die beiden Implementierungen nicht auseinanderdriften können.

Bekannte Einschränkungen

• Figma Slides ist Beta und bewusst begrenzt. Rasterinspektion, Folien erstellen/duplizieren/verschieben/löschen, Überspringen-Status und Übergänge werden unterstützt. Sprechernotizen, interaktive Umfragen/Einbettungen, Präsentationssteuerungen und ein vollständiger Content-Authoring-Workflow sind nicht enthalten. Siehe die Slides-Roadmap für umsetzbare Kandidaten im Vergleich zu Plugin-API-Grenzen.

• Nicht-Localhost-Netzwerkaktionen sind wenige und explizit: api setup (einmaliges Git-Klonen des Figma Plugin API Docs-Mirrors für figma_reference; api gap misst stattdessen gegen das installierte offizielle @figma/plugin-typings-Paket), der Storybook-Index-Abruf von import/map storybook (die URL/das Verzeichnis, das Sie übergeben), und – nur wenn Sie sich für das REST-Add-on entscheiden – Aufrufe an api.figma.com. Nichts anderes spricht mit dem Netzwerk – die Iconify/Unsplash/remove.bg/Screenshot-URL-Integrationen des Upstreams wurden vollständig entfernt; <Icon> in figma_render JSX rendert als benannter Platzhalter (echte Icons stammen aus der Figma-Datei über export assets).

• Ein Transport, keine CDP-Überreste. Jeder Befehl erreicht Figma auf demselben Weg: Engine → Daemon → Plugin-Eval. Der Chrome-DevTools-Client des Upstreams, sein figma-use-Shell-Roundtrip, der Binary-Patching-init-Assistent und die figma-use-Abhängigkeit sind alle entfernt (~5.600 Zeilen gelöscht), sodass es keinen zweiten Codepfad gibt, der die Plugin-Bridge umgehen könnte.

Entwicklung

npm run check:contracts       # static JavaScript seam + plugin contracts
npm run check:architecture-latency # warmed latency budget in an idle process
npm run measure:architecture  # context, payload and local latency baselines
npm test                      # all contracts and regression suites

Die aktuelle Domänensprache befindet sich in CONTEXT.md, akzeptierte Architekturentscheidungen in docs/adr/, API-Abdeckung in docs/figma-plugin-api-coverage.md und Release-Anweisungen in docs/releasing.md. Das öffentliche Dokumentationsverzeichnis ist docs/README.md.

Vermeiden Sie es, gleichzeitig ein upstream figma-cli auszuführen. Der Daemon fällt jetzt innerhalb von 3456–3460 zurück, wenn 3456 belegt ist, sodass beide koexistieren können, aber das Plugin scannt den gesamten Bereich und die beiden Daemons verwenden unterschiedliche Zugriffsschlüssel – welchen das Plugin zuerst erreicht, ist ein Münzwurf. Dieser Build isoliert seine eigenen Token-/PID-/Port-Dateien unter ~/.figma-bridge-mcp/.

Lizenz

figma-bridge-mcp wird unter der MIT-Lizenz veröffentlicht. Es wird „wie besehen“ ohne Gewährleistung bereitgestellt; die genauen Gewährleistungs- und Haftungsbedingungen finden Sie in der Lizenz selbst. Urheberrechts- und Lizenzhinweise Dritter werden in NOTICE und engine/LICENSE aufbewahrt.

Inspiration & Zuschreibung

Zwei Projekte haben dieses auf unterschiedliche Weise geprägt.

figma-cli (Sil Bormüller) ist der Ursprung des engine/-Verzeichnisses: Es wurde im Juli 2026 in Version 2.1.0 eingebunden und hat sich seitdem weiterentwickelt – der CDP-Transport und der Binary-Patching-Installer sind entfernt, der Plugin-Socket ist authentifiziert, und der Großteil dessen, was die Engine jetzt tut, wurde hier geschrieben. Vier Dateien sind byteidentisch zum Upstream. Die upstream MIT-Lizenz ist vollständig in engine/LICENSE enthalten, und NOTICE dokumentiert, was geändert wurde.

figma-console-mcp hat eher eine Idee als Code beigetragen: dass eine Figma-Bridge wirklich lokal sein kann – ein Plugin-Socket auf der Loopback-Schnittstelle, kein Cloud-Relay, kein gepatchtes Binary. Nichts hier ist von dessen Quelle abgeleitet; die Tool-Oberflächen, der Transport und das Plugin sind unabhängig. Wo sich dieses Projekt unterscheidet, ist, dass der Socket auch beweist, wer sich am anderen Ende befindet.

Plugin-Identität. Die Entwicklungs-Manifeste verwenden die produktausgerichteten IDs figma-bridge-mcp und figma-bridge-mcp-dev. Figma schlüsselt clientStorage – wo der gepaarte Zugriffsschlüssel lebt – auf die Plugin-ID. Installationen vor Version 0.5.0 müssen daher das Manifest erneut importieren und ihren vorhandenen Bridge-Zugriffsschlüssel einmal einfügen.