GitMCP: ein Remote-MCP-Server, der jedes GitHub-Repository zur Dokumentationsquelle macht

Welches Problem GitMCP adressiert

Sprachmodelle kennen Bibliotheken nur bis zu dem Punkt, an dem ihr Trainingsstand endet. Bei jungen, schnell wechselnden oder wenig verbreiteten Projekten führt das zu erfundenen Funktionssignaturen, veralteten Parameternamen und Beispielcode, der nicht kompiliert. GitMCP setzt genau dort an: Statt das Modell zu zwingen, sich an Trainingsdaten zu erinnern, liest es die Dateien im Repository selbst. Die Zielgruppe sind Entwickler, die mit einem MCP-fähigen Assistenten arbeiten (die README nennt Cursor, Claude Desktop, Windsurf, VSCode, Cline, Highlight AI, Augment Code und Msty AI) und die Antworten auf Basis des aktuellen Stands eines konkreten GitHub-Projekts brauchen. Der Anspruch im README lautet, Code-Halluzinationen zu beenden und den Assistenten auf die neueste Dokumentation und den Code direkt an der Quelle zugreifen zu lassen.

Zwei Betriebsarten: festes Repository oder generischer Server

GitMCP kennt zwei URL-Formen. Die erste bindet einen Assistenten an ein bestimmtes Projekt: gitmcp.io/{owner}/{repo} für Repositories, {owner}.gitmcp.io/{repo} für GitHub-Pages-Seiten. Die README begründet diese Variante damit, dass der Assistent immer auf das richtige Projekt zielt und keine unbeabsichtigten Repositories anfasst, was Relevanz und Sicherheit erhöht. Die zweite Form ist gitmcp.io/docs, ein generischer Endpunkt, bei dem der Assistent pro Anfrage entscheidet oder den Nutzer fragt, welches Repository gemeint ist. Das ist flexibel, aber die README weist selbst darauf hin, dass dies von der korrekten Identifikation des Ziel-Repositorys bei jeder Anfrage abhängt. Wer die generische Variante wählt, verlagert also eine Entscheidung ins Modell, die bei der festen Variante durch die Konfiguration festgelegt ist. Für ein Projekt, an dem ein Team täglich arbeitet, ist die feste URL die naheliegende Wahl.

Wie der Datenfluss aussieht

Der Assistent spricht nicht direkt mit GitHub. Er spricht mit dem GitMCP-Endpunkt, den du in der MCP-Konfiguration einträgst, und dieser Endpunkt liefert die Inhalte des Zielprojekts. Die README beschreibt den Dienst als Remote-MCP-Server, der in der Cloud läuft und keinen Download, keine Installation und keine Anmeldung erfordert. Aus der Repository-Struktur ist TypeScript als primäre Sprache ersichtlich, der Standardzweig heißt main. Eine technische Zusage, wie GitMCP die Dateien auswählt, wie es große Repositories aufteilt oder wie es mit Binärdateien umgeht, lässt sich aus dem vorliegenden Material nicht belegen. Die README spricht von eingebauter intelligenter Suche, die genau findet, was der Assistent braucht, ohne zu viele Tokens zu verbrauchen. Das ist eine Beschreibung des Zwecks, kein dokumentierter Algorithmus. Wer wissen will, welche Dateien tatsächlich in den Kontext gelangen, muss den Quellcode lesen; die README allein reicht dafür nicht.

Einrichtung in der Praxis

Die Konfiguration unterscheidet sich je nach Werkzeug. Für Cursor gehört in ~/.cursor/mcp.json ein Eintrag mit dem Schlüssel gitmcp und dem Feld url, das auf https://gitmcp.io/{owner}/{repo} zeigt. Claude Desktop braucht dagegen einen lokalen Prozess: Unter Settings > Developer > Edit Config trägst du command npx mit den Argumenten mcp-remote und der GitMCP-URL ein. Windsurf nutzt in ~/.codeium/windsurf/mcp_config.json den Schlüssel serverUrl statt url, VSCode schreibt in .vscode/mcp.json einen Eintrag mit type sse und url. Cline erwartet die Datei ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json mit url, disabled false und einem leeren autoApprove-Array. Augment Code und Msty AI folgen dem npx-mcp-remote-Muster. Diese Unterschiede sind keine Kosmetik: Wer die Felder vertauscht, bekommt einen Server, der nie antwortet, und sucht den Fehler dann im Modell statt in der JSON-Datei.

Grenzen, die man vorher kennen sollte

GitMCP ist kein Ersatz für eine lokale Abhängigkeit. Es liest Dokumentation und Code eines fremden Repositories, aber es ändert nichts daran, dass die Antwort nur so gut ist wie die Dateien, die dort liegen. Ein Projekt ohne README, ohne Docs-Ordner und ohne llms.txt liefert wenig verwertbaren Kontext, und der Assistent füllt die Lücken dann mit dem, was er ohnehin zu wissen glaubt. Der generische Endpunkt gitmcp.io/docs verstärkt dieses Risiko, weil bei jeder Anfrage neu bestimmt werden muss, welches Repository gemeint ist; die README nennt das ausdrücklich als Einschränkung. Ein weiterer Punkt, der in der README nicht behandelt wird: die Frage nach der Version. Wer gegen den Standardzweig liest, arbeitet mit dem Entwicklungsstand, nicht mit dem Release, das im Projekt eingesetzt wird. Für ein Projekt, das auf einem älteren Tag festgehalten ist, ist GitMCP damit das falsche Werkzeug. Und schließlich: Für ein Repository, das nicht auf GitHub liegt, existiert kein Endpunkt.

Was ein lokaler Klon anders macht

Die naheliegende Alternative ist, das Repository lokal zu klonen und den Assistenten über einen eigenen MCP-Server oder eine Datei-Suche auf das Arbeitsverzeichnis zeigen zu lassen. Der Unterschied liegt nicht im Ergebnis, sondern in der Kontrolle: Ein lokaler Klon erlaubt dir, exakt den Commit oder Tag auszuchecken, den du brauchst, und den Index auf die Dateien zu beschränken, die für deine Frage relevant sind. GitMCP nimmt dir diese Entscheidung ab und liefert dafür den Komfort, nichts installieren zu müssen. Der Preis ist, dass du den Datenfluss nicht siehst. Für ein einzelnes, gut dokumentiertes Repository ist GitMCP schneller eingerichtet. Für ein Monorepo mit mehreren hundert Megabyte Quellcode oder für ein Projekt, dessen Doku verstreut in Unterordnern liegt, wirst du mit einem lokalen Checkout präziser arbeiten. Ein weiterer Unterschied: Der lokale Weg funktioniert offline und ohne dass eine Anfrage an einen fremden Dienst geht.

Betrieb, Wartung und Lizenz

GitMCP ist unter Apache-2.0 lizenziert. Diese Lizenz erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Für die Nutzung des gehosteten Dienstes unter gitmcp.io entstehen daraus keine Pflichten, denn du installierst nichts. Anders sieht es aus, wenn du den Server selbst betreibst: Dann greifen die Bedingungen der Lizenz auf deine Kopie. Die README nennt Self-Hosting als Option, ohne ein Verfahren zu beschreiben; aus dem vorliegenden Material lässt sich daher nicht sagen, welcher Aufwand damit verbunden ist. Zur Wartung des gehosteten Endpunkts gibt es keine Release-Notizen im Material, und der letzte Push liegt laut Repository-Angabe im Mai 2026. Ob und wie häufig sich die MCP-Spezifikation ändert und ob GitMCP dem folgt, ist auf dieser Grundlage nicht beurteilbar. Wer den Dienst produktiv einsetzt, sollte die von seinem Assistenten verwendete URL als Konfigurationswert behandeln, der sich ändern kann, und nicht als feste Schnittstelle.

Redaktionelles Fazit

Sinnvoll ist GitMCP für Teams, die mit wenigen, klar benannten Bibliotheken arbeiten und deren README, Docs-Ordner und llms.txt-Dateien gepflegt sind. Wer viele fremde Repositories spontan durchsucht oder auf aussagekräftige Antworten aus ungepflegten Projekten angewiesen ist, fährt mit einem lokalen Klon plus eigener Indexierung besser. Vor dem Rollout prüfen: ob das Zielprojekt eine llms.txt im Wurzelverzeichnis hat, ob die gewünschte IDE die URL-Variante oder den npx-mcp-remote-Weg nutzt, und ob die Antworten aus den tatsächlichen Repository-Dateien stammen.

Offizielle Quellen

1. idosal/git-mcp on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README