MCP-Server einrichten: GitHub, Jira, Figma und vier weitere

Artikel-Übersicht

Diese Anleitung macht aus „MCP klingt interessant" ein laufendes Setup. Sie beginnt mit der Vorbereitung, die für alle Server gleich ist: wo die Konfigurationsdatei liegt, wie ein Eintrag aufgebaut ist, und warum Zugangsdaten über Umgebungsvariablen gehören und nicht in die Datei. Danach folgen sieben Server einzeln — GitHub, GitLab, Atlassian mit Jira und Confluence, Figma, Playwright und n8n. Jeder Abschnitt steht für sich und wiederholt lieber zwei Zeilen, als auf „siehe oben" zu verweisen, denn niemand liest so einen Artikel von vorn. Bei jedem Server steht, welche Token-Rechte tatsächlich nötig sind — das ist regelmäßig deutlich weniger, als die Dokumentation vorschlägt. Eine Sammeltabelle deckt acht weitere Server ab. Zum Schluss die Frage nach lokalen Modellen und die fünf häufigsten Fehler mit je einem Prüfschritt.

Was MCP ist, wie das Protokoll aufgebaut ist und warum die Sicherheitsfrage nicht nebensächlich ist, steht im Grundlagenartikel Das Model Context Protocol verständlich erklärt. Dieser Text hier setzt das voraus.

Vorbereitung: Client, Konfiguration, Token

Ein MCP-Server wird nicht „installiert" wie ein Programm, sondern in einem Client eingetragen. Der Client startet ihn dann bei Bedarf. Wo dieser Eintrag steht, hängt vom Client ab:

Client	Ort der Konfiguration
Claude Desktop	JSON-Datei im Anwendungsverzeichnis des Benutzerprofils
Claude Code	Projekt- oder Benutzerkonfiguration, per Befehl oder Datei
VS Code / Erweiterungen	Einstellungen der jeweiligen Erweiterung

Der Aufbau eines Eintrags ist überall derselbe: ein Name, ein Befehl, Argumente, optional Umgebungsvariablen.

{
  "mcpServers": {
    "beispiel": {
      "command": "npx",
      "args": ["-y", "@beispiel/mcp-server"],
      "env": {
        "BEISPIEL_TOKEN": "${BEISPIEL_TOKEN}"
      }
    }
  }
}

In Claude Code geht dasselbe ohne Dateibearbeitung:

claude mcp add beispiel -- npx -y @beispiel/mcp-server

Nach jeder Änderung gilt: Client neu starten. Die Konfiguration wird beim Start gelesen, nicht laufend überwacht. Das ist die Ursache für einen erheblichen Teil aller „es funktioniert nicht"-Meldungen.

Zugangsdaten sicher hinterlegen

Zwei Regeln, die den Unterschied machen:

Erstens: Token gehören in Umgebungsvariablen, nicht in die Konfigurationsdatei. Die Datei landet sonst im Repository, in einem Backup oder in einem Screenshot. Setze die Variable in deiner Shell-Konfiguration und verweise in der MCP-Konfiguration darauf.

Zweitens: Der Umfang eines Tokens ist eine Sicherheitsentscheidung, keine Formalität. Ein MCP-Server bekommt genau die Rechte, die im Token stehen — und das Modell entscheidet, wann es sie nutzt. Bei jedem der folgenden Server steht deshalb, welcher Umfang wirklich nötig ist. Warum das die wirksamste Schutzmaßnahme überhaupt ist, steht im Sicherheitsabschnitt des Grundlagenartikels.

GitHub

Der meistgenutzte MCP-Server, und der mit dem größten Schadenspotenzial bei falsch gesetzten Rechten.

Konfiguration:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Die Rechtefrage — und hier lohnt es sich, langsam zu lesen:

Ein klassisches Token mit dem Umfang repo gibt dem Modell Lese- und Schreibrechte auf alle Repositories, auf die du Zugriff hast. Das ist die Voreinstellung, die überall empfohlen wird, und sie ist für die meisten Anwendungsfälle deutlich zu weit.

Die bessere Wahl sind feingranulare Token, bei denen du einzelne Repositories auswählst und je Bereich zwischen Lese- und Schreibzugriff unterscheidest. Für reine Recherche — Issues lesen, Code durchsuchen, Pull Requests zusammenfassen — genügt Lesezugriff auf ausgewählte Repositories. Schreibrechte brauchst du nur, wenn das Modell tatsächlich Issues anlegen oder Kommentare schreiben soll.

Praktische Empfehlung: Ein eigenes Token je Zweck. Eines mit Leserechten für den Alltag, eines mit Schreibrechten für die Fälle, in denen du es brauchst — und das zweite nur dann aktiv.

Was schiefgeht: Ein abgelaufenes Token meldet sich nicht als Konfigurationsfehler, sondern als leere Antwort. Wenn der Server läuft, aber keine Repositories findet, ist das Token die erste Adresse.

GitLab

Funktional das Gegenstück, und in der Einrichtung angenehmer, weil GitLab die Rechteverwaltung feiner auflöst.

{
  "mcpServers": {
    "gitlab": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-gitlab"],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "${GITLAB_TOKEN}",
        "GITLAB_API_URL": "https://gitlab.example.com/api/v4"
      }
    }
  }
}

Für self-hosted Installationen ist die GITLAB_API_URL der entscheidende Eintrag — ohne sie zeigt der Server auf gitlab.com und findet nichts.

Rechte: Ein Projekt-Token mit read_api reicht für Recherche. Für Schreibzugriff kommt api hinzu — das ist ein deutlicher Sprung, denn api umfasst praktisch alles. Wenn möglich, ein Projekt-Token statt eines persönlichen Tokens verwenden: Es ist auf ein Projekt beschränkt und lässt sich getrennt widerrufen.

Jira und Confluence

Beide gehören zu Atlassian und teilen sich die Zugangsdaten.

{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "@atlassian/mcp-server"],
      "env": {
        "ATLASSIAN_SITE_URL": "https://deinefirma.atlassian.net",
        "ATLASSIAN_USER_EMAIL": "${ATLASSIAN_EMAIL}",
        "ATLASSIAN_API_TOKEN": "${ATLASSIAN_TOKEN}"
      }
    }
  }
}

Der häufigste Fehler ist die Site-URL. Sie muss die vollständige Adresse deiner Instanz sein, ohne Pfad dahinter. Ein Tippfehler dort führt zu einer Authentifizierungsmeldung, die aussieht, als wäre das Token falsch.

Rechte: Ein API-Token erbt die Berechtigungen des Kontos, zu dem es gehört. Es gibt keine feinere Abstufung — das Token kann alles, was du kannst. Für Unternehmensinstanzen bedeutet das: Wenn du weitreichende Rechte hast, hat der Server sie auch. Ein eigenes Dienstkonto mit Zugriff auf genau die Projekte, um die es geht, ist hier die saubere Lösung.

Bei Data-Center-Installationen (also selbst gehostet statt Cloud) unterscheidet sich die Authentifizierung; dort wird meist ein persönliches Zugriffstoken ohne E-Mail-Adresse verwendet.

Figma

Für die Strecke von Design zu Code.

{
  "mcpServers": {
    "figma": {
      "command": "npx",
      "args": ["-y", "figma-developer-mcp", "--stdio"],
      "env": {
        "FIGMA_API_KEY": "${FIGMA_TOKEN}"
      }
    }
  }
}

Was der Server liefert und was nicht: Er gibt den Knotenbaum einer Datei zurück — Rahmen, Komponenten, Abstände, Farben, Schriftgrößen. Das ist genug, um daraus Layout und Gestaltungsregeln abzuleiten. Was er nicht liefert, sind Rasterbilder in Originalqualität; eingebettete Grafiken kommen als Verweise oder in reduzierter Auflösung.

Rechte: Ein Token mit Lesezugriff auf Dateien genügt. Figma bietet inzwischen Token mit einstellbarem Umfang an — nutze das, statt ein Vollzugriffstoken zu erzeugen.

Praktischer Hinweis: Der Server arbeitet mit Datei- und Knoten-Schlüsseln, die in der Figma-URL stehen. Wer dem Modell einfach den Link zur Designdatei gibt, erspart sich das Heraussuchen.

Playwright

Der Server, der einen echten Browser steuert — und damit der mit dem größten Sicherheitsgewicht in diesem Artikel.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--isolated"]
    }
  }
}

Warum --isolated nicht optional ist: Ohne diesen Schalter kann der Server auf ein bestehendes Browserprofil zugreifen — mit allen angemeldeten Sitzungen. Ein Modell, das eine Webseite besucht, auf der versteckte Anweisungen stehen, hat dann Zugriff auf dein E-Mail-Postfach, dein Onlinebanking und alles andere, wo du gerade angemeldet bist. Mit einem isolierten Profil startet jede Sitzung leer.

Rechte: Der Server braucht kein Token, dafür Zugriff auf das Netzwerk und die Fähigkeit, einen Browser zu starten. Das ist mehr Macht als jedes API-Token in diesem Artikel.

Sinnvolle Einsatzfälle: Oberflächen testen, Formulare ausfüllen, Seiten auslesen, die keine API haben. Nicht sinnvoll: unbeaufsichtigt auf beliebigen Webseiten laufen lassen.

n8n

Die Brücke zwischen MCP und Automatisierung: Ein Modell kann Abläufe anstoßen und deren Ergebnisse auswerten.

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": ["-y", "n8n-mcp"],
      "env": {
        "N8N_API_URL": "https://n8n.example.com/api/v1",
        "N8N_API_KEY": "${N8N_TOKEN}"
      }
    }
  }
}

Die Rechtefrage ist hier indirekt und deshalb heikel: Der Server selbst braucht nur Zugriff auf die n8n-API. Aber die Abläufe dahinter können alles Mögliche tun — Mails versenden, Datensätze ändern, Zahlungen auslösen. Der tatsächliche Wirkungsbereich ist die Summe aller Abläufe, die über die API erreichbar sind.

Praktische Konsequenz: Eine eigene n8n-Instanz oder zumindest ein eigener Projektbereich für alles, was ein Modell anstoßen darf. Und keine Abläufe mit unumkehrbaren Wirkungen ohne vorgeschaltete Bestätigung.

Wie Agenten solche Werkzeuge in einer Schleife nutzen und was dabei zu beachten ist, steht im Vergleich der KI-Agenten-Frameworks.

Was die Server tatsächlich anbieten

Ein Punkt, der beim ersten Anbinden überrascht: Ein Server stellt nicht „Zugriff auf GitHub" bereit, sondern eine feste Liste einzelner Werkzeuge mit jeweils eigener Beschreibung und eigenen Parametern. Das Modell sieht diese Liste und wählt daraus.

Praktisch heißt das zweierlei. Erstens kannst du nachsehen, was ein Server kann, bevor du ihm Rechte gibst — die meisten Clients zeigen die Werkzeugliste an. Zweitens erklärt es, warum ein Modell manchmal etwas nicht tut, das der Dienst grundsätzlich könnte: Wenn es kein Werkzeug dafür gibt, existiert die Fähigkeit für das Modell nicht.

Typische Werkzeuggruppen:

Server	Lesend	Schreibend
GitHub / GitLab	Repositories durchsuchen, Dateien lesen, Issues und Pull Requests abrufen, Commits ansehen	Issues anlegen, kommentieren, Dateien ändern, Pull Requests erstellen
Atlassian	Vorgänge suchen und lesen, Confluence-Seiten abrufen	Vorgänge anlegen, Status ändern, Kommentare schreiben
Figma	Dateien und Knotenbäume auslesen, Styles abrufen	—
Playwright	Seite öffnen, Text und Struktur auslesen, Screenshot	klicken, tippen, Formulare absenden
n8n	Abläufe auflisten, Ausführungen abrufen	Abläufe starten

Die Spalte „Schreibend" ist die, für die es eine Bestätigung braucht. Wenn dein Client vor solchen Aufrufen nachfragt, lass diese Nachfrage aktiv — es ist die wirksamste einzelne Schutzmaßnahme im ganzen Aufbau.

Server aus einem Container betreiben

Nicht jeder Server muss über npx laufen. Für Umgebungen, in denen keine Node-Laufzeit erwünscht ist, oder wenn der Server vom restlichen System abgeschottet werden soll, ist ein Container die sauberere Wahl:

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Drei Details: -i ist zwingend, weil die Kommunikation über die Standardeingabe läuft. --rm räumt den Container nach dem Beenden auf. Und die Umgebungsvariable wird mit -e ohne Wert durchgereicht — der Wert kommt aus dem env-Block, steht also nicht in der Prozessliste.

Der Nebeneffekt ist nützlich: Ein Server im Container sieht dein Dateisystem nicht, solange du ihm nichts hineinmountest. Beim Dateisystem-Server ist genau das der saubere Weg, ein Verzeichnis freizugeben — ein -v /pfad/zum/projekt:/workspace statt einer Pfadangabe, auf die man sich verlassen muss.

Weitere Server im Überblick

Server	Wofür	Rechte	Herkunft
Filesystem	Dateien lesen und schreiben	auf ein Verzeichnis beschränken — zwingend	offiziell
Slack	Nachrichten lesen und senden	Bot-Token, Kanalumfang wählbar	Community
Gmail	Postfach lesen, Mails senden	OAuth-Umfang des Kontos	Community
Chrome / Browser	offene Tabs und Verlauf	greift auf angemeldete Sitzungen zu	Community
Azure	Ressourcen verwalten	Dienstprinzipal mit minimaler Rolle	offiziell
Postgres	Abfragen ausführen	eigener Datenbankbenutzer, nur lesend	offiziell
WordPress	Beiträge lesen und anlegen	Anwendungspasswort, Rolle beschränken	Community
Sequential Thinking	Aufgaben strukturiert zerlegen	keine — kein Außenzugriff	offiziell

Stand 10/2026. Die Zuordnung offiziell/Community ändert sich; mehrere ursprüngliche Community-Server wurden von den Anbietern übernommen.

MCP mit lokalen Modellen

Ob das funktioniert, hängt nicht an MCP, sondern am Modell: Es muss Tool Calling zuverlässig beherrschen — aus einer Werkzeugbeschreibung einen korrekt formatierten Aufruf erzeugen, das Ergebnis bewerten, entscheiden, ob es weitermacht.

Kleinere Modelle scheitern daran reproduzierbar. Sie erfinden Parameternamen, liefern falsches Format oder rufen dasselbe Werkzeug wiederholt auf. Als Faustregel: unter etwa 14 Milliarden Parametern für automatisierte Abläufe zu unzuverlässig, und auch darüber nur mit Modellen, die Tool Calling ausdrücklich unterstützen.

Den Unterbau dafür findest du in Ollama: lokale Sprachmodelle betreiben, die Modellauswahl in Welches Ollama-Modell?.

Wenn es nicht läuft

Fünf Ursachen decken fast alle Fälle ab.

1. Der Client wurde nicht neu gestartet. Die Konfiguration wird beim Start gelesen. Prüfschritt: Client vollständig beenden und neu starten, nicht nur das Fenster schließen.

2. Der Server startet nicht. Fehlende Laufzeitumgebung, falscher Pfad, Paketname vertippt. Prüfschritt: Den Befehl aus der Konfiguration im Terminal von Hand ausführen. Startet er dort nicht, liegt es nicht am MCP-Client.

3. Das Token ist abgelaufen oder zu eng. Meldet sich meist als leeres Ergebnis, nicht als Fehler. Prüfschritt: Denselben Aufruf mit curl gegen die API des Anbieters, mit demselben Token.

4. Falscher Transport oder falsche URL. Bei entfernten Servern ist die Adresse die häufigste Fehlerquelle, bei Atlassian speziell die Site-URL. Prüfschritt: Adresse im Browser aufrufen.

5. Die Werkzeugbeschreibungen sprengen den Kontext. Jeder angebundene Server legt seine Werkzeugbeschreibungen in den Modellkontext. Bei vielen Servern gleichzeitig bleibt für die eigentliche Aufgabe wenig übrig, und die Antwortqualität sinkt spürbar — ohne dass eine Fehlermeldung erscheint. Prüfschritt: Server, die gerade nicht gebraucht werden, deaktivieren und vergleichen. Warum der Kontext eine begrenzte Ressource ist, steht in Context Window und lange Kontexte bei LLMs.

Häufige Fragen

Wie füge ich einen MCP-Server hinzu? Über einen Eintrag in der Konfigurationsdatei des Clients oder, bei Claude Code, über claude mcp add. Danach den Client neu starten.

Welche Rechte braucht der GitHub-Server? Für Recherche Lesezugriff auf ausgewählte Repositories. Der oft empfohlene Umfang repo gibt Schreibrechte auf alles — das ist selten nötig.

Funktioniert MCP mit lokalen Modellen? Grundsätzlich ja, praktisch erst ab Modellen, die Tool Calling zuverlässig beherrschen. Unter etwa 14 Milliarden Parametern ist es für automatisierte Abläufe zu fehleranfällig.

Warum findet der Server nichts, obwohl er läuft? Fast immer ein Token-Problem: abgelaufen, falscher Umfang oder für die falsche Instanz ausgestellt.

Kann ich mehrere Server gleichzeitig betreiben? Ja, aber jeder legt seine Werkzeugbeschreibungen in den Kontext. Ab einer gewissen Anzahl sinkt die Antwortqualität, ohne dass ein Fehler erscheint.

Zusammenfassung und praktische Tipps

MCP-Server einzurichten ist technisch einfach — der Aufwand steckt in den Rechten, nicht in der Konfiguration. Die wichtigsten Punkte:

• Ein Eintrag, ein Neustart. Die Konfiguration wird beim Start des Clients gelesen; ohne Neustart passiert nichts.
• Token gehören in Umgebungsvariablen. Nie im Klartext in die Konfigurationsdatei, die landet sonst irgendwann im Repository.
• Der Umfang eines Tokens ist die eigentliche Sicherheitsentscheidung. repo bei GitHub und api bei GitLab sind fast immer zu viel.
• Playwright nur isoliert betreiben. Ohne --isolated bekommt das Modell Zugriff auf alle angemeldeten Sitzungen im Browserprofil.
• Bei n8n zählt nicht der Server, sondern was die Abläufe dahinter dürfen.
• Viele Server gleichzeitig kosten Kontext — und damit Antwortqualität, ohne Fehlermeldung.

Mein Rat für den Einstieg: Fang mit einem Server an, und zwar mit Leserechten. GitHub oder GitLab sind dafür die dankbarsten, weil man den Nutzen sofort merkt und der Schaden bei einem Fehler begrenzt bleibt. Erweitere erst, wenn du verstanden hast, wann das Modell welches Werkzeug aufruft — diese Beobachtung ist mehr wert als jede Konfigurationsvorlage.

Ressourcen

• Model Context Protocol – Spezifikation – der offizielle Standard mit Referenzimplementierungen
• MCP – Server-Verzeichnis – offizielle und Community-Server im Überblick
• GitHub – Feingranulare Token – Rechte einzeln vergeben
• Playwright MCP – Quellcode und Optionen des Browser-Servers