cursor-talk-to-figma-mcp: Figma-Steuerung per MCP über einen WebSocket-Kanal

Welche Lücke der Kanal zwischen Agent und Figma schließt

Ein Agent, der eine Design-Datei bearbeiten soll, braucht zwei Dinge: einen strukturierten Zugriff auf das Dokument und einen Weg, Änderungen zurückzuschreiben. Das Projekt liefert beides, aufgeteilt auf drei Teile, die laut Projektstruktur in src/talk_to_figma_mcp/, src/cursor_mcp_plugin/ und src/socket.ts liegen. Der MCP-Server ist in TypeScript geschrieben und stellt die Werkzeuge bereit, das Figma-Plugin läuft in Figma selbst und führt die Operationen auf dem Dokument aus, der WebSocket-Server in src/socket.ts vermittelt zwischen beiden. Zielgruppe sind Teams, die Designarbeit wiederholbar machen wollen: Textinhalte austauschen, Instanzen angleichen, Auto-Layout-Werte setzen, Verbindungen in FigJam ziehen. Der Umfang der Werkzeugliste zeigt, dass es nicht um gelegentliches Nachschauen geht, sondern um Massenoperationen. Wer nur ein einzelnes Element auslesen möchte, braucht diesen Aufbau nicht.

Drei Prozesse, ein Kanal: wie die Verbindung tatsächlich läuft

Der Datenfluss ist in der README knapp beschrieben, aber nachvollziehbar. Der Agent spricht mit dem MCP-Server. Der MCP-Server spricht über WebSocket mit dem Figma-Plugin. Das Plugin führt die Operation im geöffneten Dokument aus. Damit die beiden Enden sich finden, muss das Plugin dem Kanal beitreten, in der README als Schritt mit join_channel bezeichnet. Diese Trennung erklärt auch, warum es einen eigenen Socket-Prozess gibt: Figma-Plugins laufen in einer Sandbox innerhalb der Figma-Anwendung und können keine beliebigen Netzwerkverbindungen nach außen öffnen. Der WebSocket-Server ist damit der einzige Punkt, an dem die beiden Welten aufeinandertreffen. Für Nutzer bedeutet das: Es gibt keinen Zustand im MCP-Server, der das Dokument überlebt. Wer den Socket-Prozess neu startet, verliert die Verbindung, und das Plugin muss erneut beitreten. Die README beschreibt keinen Wiederverbindungsmechanismus.

Einrichtung: bun setup, bun socket und der Eintrag in mcp.json

Der Einstieg ist zweistufig. Zuerst wird Bun installiert, die README nennt dafür curl -fsSL https://bun.sh/install | bash. Danach folgt bun setup, das laut README den MCP-Server auch im aktiven Cursor-Projekt einträgt. Der Socket-Prozess startet mit bun socket. Wer die Konfiguration selbst schreiben will, legt in ~/.cursor/mcp.json einen Eintrag unter mcpServers mit dem Namen TalkToFigma an, als command bunx und als args den Wert cursor-talk-to-figma-mcp@latest. Für die lokale Entwicklung zeigt die README die Variante mit command bun und dem Pfad zur Datei src/talk_to_figma_mcp/server.ts. Das Figma-Plugin wird entweder über die Figma-Community-Seite installiert oder lokal über Plugins > Development > New Plugin und die Auswahl von src/cursor_mcp_plugin/manifest.json. Für Windows mit WSL nennt die README einen zusätzlichen Schritt: In src/socket.ts muss die Zeile hostname: "0.0.0.0" auskommentiert werden, damit Verbindungen aus der WSL-Umgebung ankommen. Das ist ein Eingriff in den Quelltext, kein Konfigurationsschalter.

Was die Werkzeuge abdecken und wo die Grenze liegt

Die Werkzeugliste ist breit und in Gruppen sortiert. Lesen: get_document_info, get_selection, read_my_design, get_node_info und get_nodes_info für mehrere Knoten per ID-Array. Schreiben: create_rectangle, create_frame, create_section und create_text, dazu set_fill_color, set_stroke_color, set_corner_radius und set_image_fill, das Bilder aus einem lokalen Pfad, einer URL oder als base64 aufnimmt. Struktur: move_node, resize_node, clone_node, rename_node, delete_node und delete_multiple_nodes, außerdem set_parent, das einen Knoten in einen neuen Elternteil verschiebt und laut Beschreibung seine absolute Position standardmäßig beibehält. Auto-Layout: set_layout_mode, set_padding, set_axis_align, set_layout_sizing und set_item_spacing. Komponenten: get_local_components, create_component_instance, get_instance_overrides und set_instance_overrides. Bemerkenswert ist die Mengenorientierung: scan_text_nodes arbeitet laut README mit intelligentem Chunking für große Designs, set_multiple_text_contents aktualisiert mehrere Textknoten in einem Aufruf, set_multiple_annotations fasst Annotationen zusammen. Die README endet im Abschnitt Expor, das heißt, die Auflistung ist abgeschnitten. Ob es Exportwerkzeuge gibt und wie sie heißen, lässt sich aus dem Material nicht belegen.

Der Socket-Prozess als Betriebsrisiko

Der WebSocket-Server ist ein zusätzlicher Dienst, der laufen muss, damit überhaupt etwas passiert. Er ist nicht Teil des MCP-Servers und nicht Teil des Plugins. In einer Einzelplatzumgebung ist das unproblematisch: bun socket im Terminal, Plugin verbinden, arbeiten. Sobald mehrere Personen denselben Kanal nutzen, wird die Frage interessant, wie das Plugin eingehende Nachrichten zuordnet. Die README beschreibt den Kanalbeitritt über join_channel, sagt aber nichts über Kanalnamen, Zugriffskontrolle oder das Verhalten, wenn zwei Agenten gleichzeitig dasselbe Dokument bearbeiten. Wer das Projekt produktiv einsetzen will, muss diese Frage selbst beantworten, und zwar bevor Änderungen an einer geteilten Datei laufen. Dasselbe gilt für die Windows-WSL-Variante: hostname: "0.0.0.0" öffnet den Socket für das Netzwerk, nicht nur für localhost. Die README markiert das als notwendigen Schritt, nicht als Sicherheitsentscheidung. Das ist eine Designentscheidung, die man beim Lesen des Codes prüfen sollte, nicht nur beim Lesen der Anleitung.

Wann ein anderer Weg sinnvoller ist

Der naheliegende Vergleich ist der MCP-Server, den Figma selbst bereitstellt. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Architektur: Figmas eigener Weg kommt ohne separaten Socket-Prozess und ohne Plugin im Entwicklungsmodus aus, dafür ist der Umfang der Schreiboperationen ein anderer. Das Projekt hier ist auf Massenänderungen ausgelegt, mit Batch-Werkzeugen für Text, Annotationen und Overrides, und es bringt FigJam-Verbindungen mit: set_default_connector setzt einen kopierten Connector als Standard, create_connections zieht Linien zwischen Knoten, wahlweise entlang von Prototyp-Flows. Wenn der Bedarf genau dort liegt, ist der zusätzliche Prozess der Preis für Funktionen, die ein reiner Lesezugriff nicht bietet. Wenn der Bedarf im Lesen und Kommentieren liegt, ist der Aufwand nicht zu rechtfertigen. Eine dritte Option ist ein eigenes Figma-Plugin, das die wiederkehrende Aufgabe direkt im Plugin-Code löst. Das skaliert ohne Agent und ohne Socket, ist aber nicht dialogfähig: Der Agent kann dann nicht auf Zwischenergebnisse reagieren.

Pflege, Lizenz und der Blick auf das Repository

Das Projekt steht unter MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, den Lizenzhinweis und den Urheberrechtsvermerk in Kopien oder wesentlichen Teilen beizubehalten. Wer den Code forkt und intern verteilt, muss diese Bedingung erfüllen. Das ist keine Rechtsberatung, sondern die übliche Lesart der MIT-Bedingungen; im Zweifel gehört das in die Hände der Rechtsabteilung. Zum Pflegestand lässt sich aus dem Material nur sagen, dass der letzte Push auf den main-Branch im Juli 2026 liegt und dass keine Releases abgerufen wurden. Ob es einen Changelog gibt, wie Versionen vergeben werden und ob Breaking Changes angekündigt werden, geht daraus nicht hervor. Die Einrichtung über bunx cursor-talk-to-figma-mcp@latest zieht jeweils die aktuelle Version, ohne Versionsangabe. Wer Reproduzierbarkeit braucht, sollte auf eine feste Version pinnen. Die README nennt zwei Beiträge von @dusskapark: den Massentextersatz und die Propagierung von Instanz-Overrides. Das deutet auf eine kleine Gruppe von Beitragenden hin, mehr lässt sich über die Projektsteuerung nicht sagen. Ein Upgrade-Pfad ist nicht dokumentiert.

Redaktionelles Fazit

Wer wiederkehrende Massenänderungen in Figma skripten will, etwa Textinhalte über set_multiple_text_contents oder Overrides über set_instance_overrides, für den ist das Projekt gebaut. Wer nur ein einzelnes Dokument lesen möchte, sollte zuerst prüfen, ob der MCP-Server von Figma selbst oder ein reiner Lesezugriff nicht weniger bewegliche Teile bedeutet. Vor dem Rollout im Team zu klären: ob der WebSocket-Server dauerhaft laufen soll, wer das Figma-Plugin installiert, und ob das Verhalten des Plugins bei gleichzeitigen Änderungen mehrerer Agenten dokumentiert ist. Das Repository gibt dazu keine Angaben her.

Offizielle Quellen

1. grab/cursor-talk-to-figma-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README