Wer „figma mcp server" oder „jira mcp server" in die Suche tippt, sucht meistens dasselbe: eine Verbindung zwischen einem Werkzeug, mit dem er täglich arbeitet, und dem KI-Assistenten, in dem er ohnehin schon sitzt. Bei einer dieser vier Suchanfragen gibt es das gesuchte Ding so gar nicht, und bei zwei weiteren führt die naheliegende Anleitung an der offiziellen Einrichtung vorbei. Deshalb hier der Reihe nach, was tatsächlich existiert.
Wofür so eine Verbindung gut ist#
Ein MCP-Server ist eine Brücke. Auf der einen Seite steht ein Programm mit Daten, auf der anderen ein KI-Assistent, und dazwischen liegt ein festgelegtes Protokoll, über das der Assistent Fragen stellen und Aktionen auslösen darf. Ohne diese Brücke musst du Inhalte selbst herüberkopieren. Mit ihr sagst du „schau dir das an" und meinst damit deine echte Datei, dein echtes Ticket, deinen echten Merge Request.
Der Unterschied ist im Alltag größer, als er klingt. Ein Assistent, der dein Figma-Design nur als Screenshot sieht, rät Abstände und Farben. Einer, der über eine Verbindung an die Datei kommt, liest die tatsächlichen Werte aus. Das ist der Punkt, an dem aus einer netten Spielerei eine Arbeitserleichterung wird.
Figma: zwei Wege, und der lokale ist nicht der empfohlene#
Figma bringt einen Server in der Desktop-App mit. Du aktivierst ihn einmal im Dev Mode, danach startet er zusammen mit der Datei und lauscht lokal unter http://127.0.0.1:3845/mcp. Für diese lokale Verbindung brauchst du keinen API-Schlüssel.
Eine Einschränkung, die man dazusagen muss, weil sie oft unterschlagen wird: lokal ist hier nur der Endpunkt. Was der Assistent aus deiner Datei liest, verarbeitet er anschließend wie jeden anderen Kontext, und bei einem Cloud-Assistenten heißt das, es geht an dessen Anbieter. „Läuft lokal" ist eine Aussage über den Verbindungsweg, keine Datenschutz-Zusage.
Daneben gibt es einen Remote-Server, und den empfiehlt Figma inzwischen als Standardweg. Für Claude Code führt der kürzeste Weg über das offizielle Plugin:
claude plugin install figma@claude-plugins-official
Was herüberkommt, sind Komponenten, Variablen und Style-Angaben. Code-Connect-Zuordnungen kommen dazu, wenn diese Integration in deinem Projekt eingerichtet ist, sonst nicht.
Und dann gibt es Voraussetzungen, die darüber entscheiden, ob die Verbindung für dich überhaupt nutzbar ist. Der Remote-Server steht in allen Plänen und für alle Seats zur Verfügung. Der Server in der Desktop-App verlangt einen bezahlten Plan und einen Dev- oder Full-Seat. Code Connect setzt zusätzlich einen Organization- oder Enterprise-Plan voraus, ebenfalls mit Dev- oder Full-Seat. Wie viel du abrufen kannst, hängt darüber hinaus an Plan und Seat. Wer im kostenlosen Plan sitzt, kommt also über den Remote-Weg weiter, nicht über den lokalen.
Jira: einen eigenen Server dafür gibt es nicht#
Das ist der Punkt, an dem die meisten Anleitungen ungenau werden. Atlassian bietet keinen separaten offiziellen Jira-Server an. Es gibt einen Server für das gesamte Haus, und Jira ist darin enthalten, zusammen mit Confluence, Jira Service Management, Bitbucket Cloud und Compass. (Server von Drittanbietern existieren, aber die sind eben nicht die offizielle Anbindung.)
Wer also „jira mcp server" sucht, richtet in Wahrheit den Atlassian-Server ein. Dasselbe gilt für „confluence mcp server" und „atlassian mcp server", das sind drei Suchanfragen für dieselbe Sache.
Bei der Anmeldung lohnt genaues Hinsehen, denn „OAuth oder API-Token, such dir was aus" stimmt nicht. Die Wahl hängt am Produkt: Jira Service Management und Bitbucket Cloud gehen nur über API-Token, Compass nur über OAuth 2.1. Und die Anmeldung per API-Token muss der Administrator deiner Organisation überhaupt erst erlauben. Je nachdem, welchen Weg du gehst, steht dir also auch nur ein Teil der Funktionen zur Verfügung. Wer das vorher nicht prüft, richtet die Verbindung ein und wundert sich, warum die Hälfte fehlt.
Wenn es passt, ist der Gewinn allerdings genau die Kombination: Ein Assistent kann ein Ticket vor dem Hintergrund der zugehörigen Confluence-Seite lesen, statt beides getrennt zu sehen.
GitLab: offiziell, aber an Voraussetzungen geknüpft#
GitLab hat einen eigenen Server, direkt in der Anwendung. Er kam mit Version 18.3 zunächst als Experiment, seit 18.6 steht er auf Beta, und mit 18.6 kam auch der direkte HTTP-Transport dazu. Beta heißt hier konkret: Rechne damit, dass sich Einzelheiten noch ändern.
Angebunden wird er über HTTP unter der Adresse deiner Instanz:
https://<deine-gitlab-instanz>/api/v4/mcp
Bei der Anmeldung wird es wichtig, und hier liegt der Fehler, den viele Anleitungen weitergeben: Der offiziell dokumentierte Weg läuft über OAuth 2.0 mit dynamischer Client-Registrierung, nicht über ein selbst angelegtes Personal Access Token. Wer nach „Token mit Scope api anlegen" sucht, folgt einer Anleitung für andere GitLab-Schnittstellen, nicht für diese.
Dazu kommen Voraussetzungen, die oft unter den Tisch fallen: GitLab Duo muss verfügbar sein, Beta- und Experimental-Funktionen müssen freigeschaltet sein, und der MCP-Zugriff muss aktiviert sein. Wer lieber über einen Zwischenweg geht, kann mcp-remote als Proxy nutzen, das setzt Node.js in Version 20 oder neuer voraus. Der direkte HTTP-Weg ist der empfohlene und kommt ohne diese Abhängigkeit aus.
Playwright: der Assistent bedient den Browser#
Playwright ist der Ausreißer in dieser Runde, weil es kein Datenspeicher ist, sondern ein Werkzeug zur Browser-Steuerung. Microsoft gibt den offiziellen Server dafür heraus; anders als bei Atlassian läuft er nicht als gehosteter Dienst, sondern bei dir auf dem Rechner. Angebunden kann ein Assistent damit Seiten aufrufen, klicken, Formulare ausfüllen und sich zurückmelden, was er vorgefunden hat.
Der interessanteste Teil daran ist weniger das Automatisieren von Tests als die Möglichkeit, einen Assistenten nachsehen zu lassen. „Ruf die Seite auf und sag mir, ob das Formular abschickt" ist eine Anweisung, die vorher eine Person gebraucht hat. Der Server liefert dafür strukturierte Momentaufnahmen der Seite statt reiner Bildschirmfotos. Das ist die Grundlage, auf der der Assistent überhaupt gezielt klicken kann. Eine echte Barrierefreiheits-Prüfung nach WCAG ersetzt es nicht, auch wenn die Datenform daran erinnert.
Was davon lohnt sich für einen Betrieb#
Ehrliche Einordnung: Diese vier Verbindungen sind Entwickler-Werkzeuge. Wenn in deinem Betrieb niemand mit Figma, Jira oder GitLab arbeitet, bringen sie dir nichts.
Interessant wird das Prinzip dahinter. Ein MCP-Server ist nicht auf Entwickler-Software beschränkt. Dieselbe Brücke lässt sich zu einer Warenwirtschaft bauen, zu einem Buchungssystem, zu einer Kundendatei. Der Unterschied ist, dass die großen Anbieter ihre Brücke inzwischen fertig mitliefern und ein kleineres Branchenprogramm in aller Regel eben nicht.
Genau an der Stelle setzt unsere Arbeit an: Wir bauen die Verbindung zu den Systemen, für die es keine fertige gibt, damit ein Assistent mit deinen echten Daten arbeitet statt mit dem, was jemand hineinkopiert hat. Wie das aussieht, steht auf der Seite zum KI-Verbinder, und wenn du wissen willst, was hinter dem Protokoll steckt, erklärt das der Beitrag MCP verständlich erklärt.
Kurz zusammengefasst#
Figma hat zwei Wege, lokal und remote, und empfiehlt inzwischen den Remote-Server; was du abrufen darfst, hängt an deinem Plan. Jira, Confluence und Bitbucket teilen sich einen einzigen Atlassian-Server, einen offiziellen Jira-only-Server gibt es nicht, und die Anmeldeart entscheidet mit, welche Funktionen du bekommst. GitLab hat seit 18.6 einen Server im Beta-Stadium, der über OAuth angebunden wird und ein aktives GitLab Duo voraussetzt. Playwright kommt von Microsoft, läuft lokal und steuert den Browser, statt Daten zu liefern.
Der eigentliche Aufwand liegt bei allen vieren ohnehin nicht in der Einrichtung, sondern danach: herauszufinden, wofür du die Verbindung im Alltag wirklich benutzt.
