GitHub MCP Server

✓ Offiziell★ 31.389

Von GitHub selbst gepflegter MCP-Server für Repos, Pull Requests, Issues, Code-Suche und CI/CD-Einblicke — remote oder lokal, mit OAuth-Login.

Der GitHub MCP Server verbindet Agenten direkt mit der GitHub-Plattform — in zwei Betriebsarten. Der Remote-Server wird von GitHub selbst unter https://api.githubcopilot.com/mcp/ gehostet und ist laut README der einfachste Einstieg: Anmeldung per OAuth im Browser (das Token bleibt dabei nur im Speicher) oder alternativ per Personal Access Token (PAT) im Authorization: Bearer-Header. Wer alles lokal halten will, startet den Server als Docker-Container (ghcr.io/github/github-mcp-server) mit PAT oder OAuth-Callback — oder baut ihn per go build selbst aus dem Quellcode.

Die Fähigkeiten sind in Toolsets gegliedert, die sich gezielt an- und abschalten lassen: repos (Repository-Operationen), issues, pull_requests, actions (CI/CD), code_security (Code- und Secret-Scanning), dazu dependabot, discussions, gists, projects, orgs, users, notifications und labels. Ohne eigene Angabe sind standardmäßig context, repos, issues, pull_requests und users aktiv. Die Auswahl steuert man per --toolsets-Flag oder der Umgebungsvariable GITHUB_TOOLSETS; einzelne Tools lassen sich über GITHUB_TOOLS freischalten. Ein --read-only-Flag deaktiviert sämtliche schreibenden Tools — nützlich, wenn der Agent nur analysieren, aber nichts verändern soll.

Damit kann ein Agent Issues triagieren, Pull Requests anlegen und reviewen, CI-Läufe inspizieren und Code über Repos hinweg durchsuchen — mit offiziellem Vendor-Support von GitHub statt einer Community-Bastellösung.

🔧 SETUP

Einfachster Weg (Remote): den gehosteten Server im MCP-Client als HTTP-Server eintragen: `{"servers": {"github": {"type": "http", "url": "https://api.githubcopilot.com/mcp/"}}}` — Anmeldung dann per OAuth im Browser
Alternativ mit Personal Access Token statt OAuth: zusätzlich den Header `"Authorization": "Bearer <PAT>"` konfigurieren
Lokal statt remote: `docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN=<your-token> ghcr.io/github/github-mcp-server`
Toolsets nach Bedarf einschränken, z. B. `--toolsets repos,issues,pull_requests,actions` oder per Umgebungsvariable `GITHUB_TOOLSETS="repos,issues,pull_requests"`
Für reine Analyse-Aufgaben das Flag `--read-only` setzen — schreibende Tools werden dann übersprungen

✅ WANN EINSETZEN?

PR- und Issue-Arbeit direkt aus dem Agenten

„Fasse die offenen Issues mit Label ‚bug' zusammen, priorisiere sie und lege für das kritischste einen Branch samt Draft-PR an" — alles über die offiziellen GitHub-Tools, ohne Browser-Wechsel.

CI/CD-Fehler diagnostizieren

Mit dem `actions`-Toolset den fehlgeschlagenen Workflow-Lauf des letzten Pushes abrufen, die Logs analysieren und direkt einen Fix vorschlagen lassen.

⛔ WANN EHER NICHT?

Lokale Git-Operationen im Arbeitsverzeichnis

Der Server spricht die GitHub-API — Commits, Branches und Diffs im lokalen, noch nicht gepushten Arbeitsstand sieht er nicht.

Besser: Lokale Git-Arbeit über die normale Git-CLI des Agenten erledigen; den GitHub MCP Server erst für die Plattform-Seite (PRs, Issues, Actions) einsetzen.

Agent soll nur lesen, bekommt aber vollen Schreibzugriff

Mit Standard-Toolsets und einem breit berechtigten PAT kann der Agent Issues, PRs und mehr verändern — mehr Rechte als nötig sind ein unnötiges Risiko.

Besser: `--read-only` setzen, Toolsets minimal wählen und ein fein-granulares PAT mit möglichst wenigen Scopes verwenden.