Repository durchsuchen und suchen — Bitten Sie Ihren Assistenten, Dateien zu finden, Code zu lesen oder die Commit-Historie mit Werkzeugen aus dem repos-Werkzeugsatz zu analysieren.
Issues und Pull Requests verwalten — Erstellen, aktualisieren und priorisieren Sie Issues oder PRs mit Werkzeugen aus den Werkzeugsätzen issues und pull_requests.
CI/CD-Workflows überwachen — Überprüfen Sie den Ausführungsstatus von GitHub Actions, untersuchen Sie Build-Fehler und verwalten Sie Releases über den actions-Werkzeugsatz.
Code-Sicherheitswarnungen prüfen — Untersuchen Sie Code-Scanning-Ergebnisse, Dependabot-Warnungen und Secret-Scanning-Ergebnisse mit den Werkzeugsätzen code_security, dependabot und secret_protection.
An Diskussionen und Projekten mitarbeiten — Greifen Sie auf Teamdiskussionen zu, verwalten Sie Projektboards und bearbeiten Sie Benachrichtigungen über die Werkzeugsätze discussions, projects und notifications.
Dokumentation
GitHub MCP Server
Der GitHub MCP Server verbindet KI-Tools direkt mit der GitHub-Plattform. Dadurch erhalten KI-Agenten, Assistenten und Chatbots die Möglichkeit, Repositories und Code-Dateien zu lesen, Issues und PRs zu verwalten, Code zu analysieren und Workflows zu automatisieren – alles über natürliche Sprachinteraktionen.
Anwendungsfälle
Repository-Verwaltung: Durchsuchen und Abfragen von Code, Suchen von Dateien, Analysieren von Commits und Verstehen der Projektstruktur in jedem Repository, auf das Sie Zugriff haben.
Issue- & PR-Automatisierung: Erstellen, Aktualisieren und Verwalten von Issues und Pull Requests. Lassen Sie KI beim Triage von Bugs, der Überprüfung von Codeänderungen und der Pflege von Projektboards helfen.
CI/CD & Workflow-Intelligenz: Überwachen von GitHub Actions-Workflow-Ausführungen, Analysieren von Build-Fehlern, Verwalten von Releases und Gewinnen von Einblicken in Ihre Entwicklungspipeline.
Code-Analyse: Untersuchen von Sicherheitsergebnissen, Überprüfen von Dependabot-Warnungen, Verstehen von Codemustern und Erhalten umfassender Einblicke in Ihre Codebasis.
Team-Zusammenarbeit: Zugriff auf Diskussionen, Verwalten von Benachrichtigungen, Analysieren von Teamaktivitäten und Optimieren von Prozessen für Ihr Team.
Entwickelt für Entwickler, die ihre KI-Tools mit GitHub-Kontext und -Funktionen verbinden möchten, von einfachen Abfragen in natürlicher Sprache bis hin zu komplexen mehrstufigen Agenten-Workflows.
Remote GitHub MCP Server
Der Remote GitHub MCP Server wird von GitHub gehostet und bietet die einfachste Methode für den Einstieg. Wenn Ihr MCP-Host keine Remote-MCP-Server unterstützt, keine Sorge! Sie können stattdessen die lokale Version des GitHub MCP Servers verwenden.
Voraussetzungen
Ein kompatibler MCP-Host mit Remote-Server-Unterstützung (VS Code 1.101+, Claude Desktop, Cursor, Windsurf usw.)
Verwenden Sie für eine schnelle Installation eine der oben stehenden Ein-Klick-Installationsschaltflächen. Sobald Sie diesen Ablauf abgeschlossen haben, schalten Sie den Agent-Modus ein (befindet sich neben der Copilot Chat-Texteingabe) und der Server wird gestartet. Stellen Sie sicher, dass Sie VS Code 1.101 oder höher für Remote-MCP- und OAuth-Unterstützung verwenden.
Alternativ, um VS Code manuell zu konfigurieren, wählen Sie den entsprechenden JSON-Block aus den folgenden Beispielen und fügen Sie ihn Ihrer Host-Konfiguration hinzu:
Rovo Dev CLI – Installationsanleitung für Rovo Dev CLI
Hinweis: Jede MCP-Host-Anwendung muss eine GitHub App oder OAuth App konfigurieren, um den Remote-Zugriff über OAuth zu unterstützen. Jede Host-Anwendung, die Remote-MCP-Server unterstützt, sollte den Remote-GitHub-Server mit PAT-Authentifizierung unterstützen. Konfigurationsdetails und Unterstützungsgrade variieren je nach Host. Beachten Sie unbedingt die Dokumentation der Host-Anwendung für weitere Informationen.
Konfiguration
Toolset-Konfiguration
Siehe Remote Server-Dokumentation für vollständige Details zur Remote-Server-Konfiguration, Toolsets, Headern und erweiterter Nutzung. Diese Datei bietet umfassende Anweisungen und Beispiele zum Verbinden, Anpassen und Installieren des Remote GitHub MCP Servers in VS Code und anderen MCP-Hosts.
Wenn keine Toolsets angegeben sind, werden Standard-Toolsets verwendet.
Insiders-Modus
Neue Funktionen frühzeitig testen! Der Remote-Server bietet eine Insiders-Version mit frühzeitigem Zugriff auf neue Funktionen und experimentelle Tools.
Hinweis: Bei Verwendung von OAuth mit GitHub Enterprise mit VS Code und GitHub Copilot müssen Sie auch Ihre VS Code-Einstellungen so konfigurieren, dass sie auf Ihre GitHub Enterprise-Instanz verweisen – siehe Authentifizierung von VS Code aus
Um den Server in einem Container auszuführen, muss Docker installiert sein.
Sobald Docker installiert ist, müssen Sie außerdem sicherstellen, dass Docker ausgeführt wird. Das Docker-Image ist verfügbar unter ghcr.io/github/github-mcp-server. Das Image ist öffentlich; wenn Sie beim Pull Fehler erhalten, haben Sie möglicherweise ein abgelaufenes Token und müssen docker logout ghcr.io.
Authentifizierung. Auf github.com müssen Sie im Voraus nichts erstellen – die Ein-Klick-Schaltflächen oben melden Sie bei der ersten Verwendung mit OAuth an (ein browserbasierter Ablauf; das Token wird nur im Speicher gehalten). Die Docker-Schaltflächen veröffentlichen einen festen Callback-Port (127.0.0.1:8085), damit der Login-Callback des Containers erreichbar ist. Siehe Lokaler Server OAuth-Login für die Funktionsweise, Headless-/Gerätecode-Fallback und das Einbringen eigener OAuth- oder GitHub-Apps (erforderlich für GitHub Enterprise Server und ghe.com).
Bevorzugen Sie ein Token? Sie können sich weiterhin mit einem persönlichen GitHub-Zugriffstoken authentifizieren, indem Sie stattdessen GITHUB_PERSONAL_ACCESS_TOKEN setzen (dies hat Vorrang vor OAuth). Der MCP-Server kann viele der GitHub-APIs nutzen, aktivieren Sie daher die Berechtigungen, die Sie Ihren KI-Tools gerne gewähren möchten (um mehr über Zugriffstoken zu erfahren, lesen Sie bitte die Dokumentation).
Sicherer Umgang mit PATs
Umgebungsvariablen (Empfohlen)
Um Ihr GitHub-PAT sicher und wiederverwendbar über verschiedene MCP-Hosts hinweg zu halten:
Speichern Sie Ihr PAT in Umgebungsvariablen
export GITHUB_PAT=your_token_here
Oder erstellen Sie eine .env-Datei:
GITHUB_PAT=your_token_here
Schützen Sie Ihre .env-Datei
# Add to .gitignore to prevent accidental commits
echo ".env" >> .gitignore
Referenzieren Sie das Token in Konfigurationen
# CLI usage
claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PAT -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server
# In config files (where supported)
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "$GITHUB_PAT"
}
Hinweis: Die Unterstützung von Umgebungsvariablen variiert je nach Host-App und IDE. Einige Anwendungen (wie Windsurf) erfordern hartcodierte Token in Konfigurationsdateien.
Bewährte Methoden zur Token-Sicherheit
Minimale Bereiche: Gewähren Sie nur notwendige Berechtigungen
repo – Repository-Operationen
read:packages – Docker-Image-Zugriff
read:org – Organisations-Teamzugriff
Separate Token: Verwenden Sie unterschiedliche PATs für verschiedene Projekte/Umgebungen
Regelmäßige Rotation: Aktualisieren Sie Token regelmäßig
Niemals committen: Halten Sie Token aus der Versionskontrolle fern
Dateiberechtigungen: Beschränken Sie den Zugriff auf Konfigurationsdateien, die Token enthalten
chmod 600 ~/.your-app/config.json
GitHub Enterprise Server und Enterprise Cloud mit Datenresidenz (ghe.com)
Das Flag --gh-host und die Umgebungsvariable GITHUB_HOST können verwendet werden, um den Hostnamen für GitHub Enterprise Server oder GitHub Enterprise Cloud mit Datenresidenz festzulegen.
Verwenden Sie für GitHub Enterprise Server das Präfix https:// URI-Schema für den Hostnamen, da er sonst standardmäßig http:// verwendet, was GitHub Enterprise Server nicht unterstützt.
Verwenden Sie für GitHub Enterprise Cloud mit Datenresidenz https://YOURSUBDOMAIN.ghe.com als Hostnamen.
Verwenden Sie für eine schnelle Installation eine der oben stehenden Ein-Klick-Installationsschaltflächen. Sobald Sie diesen Ablauf abgeschlossen haben, schalten Sie den Agent-Modus ein (befindet sich neben der Copilot Chat-Texteingabe) und der Server wird gestartet.
Installation in GitHub Copilot in anderen IDEs (JetBrains, Visual Studio, Eclipse usw.)
Fügen Sie einen der folgenden JSON-Blöcke zu den MCP-Einstellungen Ihrer IDE hinzu.
Mit OAuth anmelden (kein zu erstellendes oder zu speicherndes Token). Auf github.com enthält das offizielle Image bereits die App-Anmeldeinformationen, sodass Sie selbst keine angeben müssen: Es führt bei der ersten Verwendung einen browserbasierten Login durch und behält das resultierende Token nur im Speicher. In Docker erfordert dies einen festen Callback-Port, der auf Loopback veröffentlicht wird, damit der Login-Callback des Containers erreichbar ist:
Siehe Lokaler Server OAuth-Login für den nativen Binärablauf (kein fester Port erforderlich), den Headless-/Gerätecode-Fallback, GitHub Enterprise Server / ghe.com und das Einbringen eigener OAuth- oder GitHub-Apps.
Oder authentifizieren Sie sich mit einem persönlichen Zugriffstoken. Setzen Sie stattdessen GITHUB_PERSONAL_ACCESS_TOKEN (dies hat Vorrang vor OAuth):
Optional können Sie ein ähnliches Beispiel (d. h. ohne den MCP-Schlüssel) zu einer Datei namens .vscode/mcp.json in Ihrem Arbeitsbereich hinzufügen. Dadurch können Sie die Konfiguration mit anderen Host-Anwendungen teilen, die dasselbe Format akzeptieren.
Beispiel-JSON-Block ohne enthaltenen MCP-Schlüssel
Hinweis: Jede Host-Anwendung, die lokale MCP-Server unterstützt, sollte auf den lokalen GitHub MCP Server zugreifen können. Der spezifische Konfigurationsprozess, die Syntax und die Stabilität der Integration variieren jedoch je nach Host-Anwendung. Während viele einem ähnlichen Format wie die obigen Beispiele folgen, ist dies nicht garantiert. Beachten Sie die Dokumentation Ihrer Host-Anwendung für die korrekte MCP-Konfigurationssyntax und den Einrichtungsprozess.
Aus dem Quellcode erstellen
Wenn Sie Docker nicht haben, können Sie go build verwenden, um die Binärdatei im Verzeichnis
cmd/github-mcp-server zu erstellen, und den Befehl github-mcp-server stdio mit der auf Ihr Token gesetzten Umgebungsvariable GITHUB_PERSONAL_ACCESS_TOKEN nutzen. Um den Ausgabeort des Builds anzugeben, verwenden Sie das Flag -o. Sie sollten Ihren Server so konfigurieren, dass er die erstellte ausführbare Datei als seine command verwendet. Zum Beispiel:
Die Binärdatei github-mcp-server enthält einige CLI-Unterbefehle, die beim Debuggen und Erkunden des Servers hilfreich sind.
github-mcp-server tool-search "<query>" durchsucht Tools nach Name, Beschreibung und Eingabeparameternamen. Verwenden Sie --max-results, um mehr Treffer zurückzugeben.
Beispiel (Farbausgabe erfordert ein TTY; verwenden Sie docker run -t (oder -it), wenn Sie in Docker ausführen):
Der GitHub MCP Server unterstützt das Aktivieren oder Deaktivieren bestimmter Funktionsgruppen über das Flag --toolsets. Dadurch können Sie steuern, welche GitHub-API-Funktionen Ihren KI-Tools zur Verfügung stehen. Wenn Sie nur die benötigten Toolsets aktivieren, kann dies dem LLM bei der Tool-Auswahl helfen und die Kontextgröße reduzieren.
Toolsets sind nicht auf Tools beschränkt. Relevante MCP-Ressourcen und Prompts sind, sofern zutreffend, ebenfalls enthalten.
Wenn keine Toolsets angegeben sind, werden Standard-Toolsets verwendet.
Suchen Sie nach Beispielen? Lesen Sie den Server-Konfigurationsleitfaden für gängige Rezepte wie minimale Setups, schreibgeschützten Modus und die Kombination von Tools mit Toolsets.
Toolsets angeben
Um Toolsets anzugeben, die dem LLM zur Verfügung stehen sollen, können Sie eine Zulassungsliste auf zwei Arten übergeben:
Die Umgebungsvariable GITHUB_TOOLSETS hat Vorrang vor dem Befehlszeilenargument, wenn beide angegeben sind.
Einzelne Tools angeben
Sie können auch bestimmte Tools mit dem Flag --tools konfigurieren. Tools können unabhängig oder in Kombination mit Toolsets für eine fein abgestufte Steuerung verwendet werden.
Dies registriert alle Tools aus den Toolsets repos und issues sowie get_gist.
Wichtige Hinweise:
Tools und Toolsets können zusammen verwendet werden
Der schreibgeschützte Modus hat Vorrang: Schreib-Tools werden übersprungen, wenn --read-only gesetzt ist, selbst wenn sie explizit über --tools angefordert wurden
Tool-Namen müssen exakt übereinstimmen (z. B. get_file_contents, nicht getFileContents). Ungültige Tool-Namen führen beim Start zu einem Serverfehler mit einer Fehlermeldung
Wenn Tools umbenannt werden, bleiben alte Namen aus Gründen der Abwärtskompatibilität als Aliase erhalten. Siehe Tool-Umbenennung für Details.
Toolsets mit Docker verwenden
Bei der Verwendung von Docker können Sie die Toolsets als Umgebungsvariablen übergeben:
Dringend empfohlen: Tools, die Kontext über den aktuellen Benutzer und den GitHub-Kontext, in dem Sie arbeiten, bereitstellen
actions
GitHub Actions-Workflows und CI/CD-Operationen
code_quality
Tools im Zusammenhang mit GitHub Code Quality
code_security
Tools im Zusammenhang mit Codesicherheit, wie GitHub Code Scanning
copilot
Copilot-bezogene Tools
dependabot
Dependabot-Tools
discussions
Tools im Zusammenhang mit GitHub Discussions
gists
Tools im Zusammenhang mit GitHub Gist
git
Tools im Zusammenhang mit der GitHub Git-API für Low-Level-Git-Operationen
issues
Tools im Zusammenhang mit GitHub Issues
labels
Tools im Zusammenhang mit GitHub Labels
notifications
Tools im Zusammenhang mit GitHub Notifications
orgs
Tools im Zusammenhang mit GitHub Organization
projects
Tools im Zusammenhang mit GitHub Projects
pull_requests
Tools im Zusammenhang mit GitHub Pull Request
repos
Tools im Zusammenhang mit GitHub Repository
secret_protection
Tools im Zusammenhang mit Geheimnisschutz, wie GitHub Secret Scanning
security_advisories
Tools im Zusammenhang mit Sicherheitshinweisen
stargazers
Tools im Zusammenhang mit GitHub Stargazers
users
Tools im Zusammenhang mit GitHub User
Zusätzliche Toolsets im Remote GitHub MCP Server
Toolset
Beschreibung
copilot
Copilot-bezogene Tools (z. B. Copilot Coding Agent)
copilot_spaces
Tools im Zusammenhang mit Copilot Spaces
github_support_docs_search
Dokumentation durchsuchen, um GitHub-Produkt- und Supportfragen zu beantworten
Tools
Actions
actions_get - Details zu GitHub Actions-Ressourcen abrufen (Workflows, Workflow-Ausführungen, Jobs und Artefakte)
Erforderliche OAuth-Bereiche: repo
method: Die auszuführende Methode (String, erforderlich)
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
resource_id: Die eindeutige Kennung der Ressource. Diese variiert je nach angegebener "Methode". Stellen Sie daher sicher, dass Sie die richtige ID angeben:
Geben Sie eine Workflow-ID oder einen Workflow-Dateinamen (z. B. ci.yaml) für die Methode 'get_workflow' an.
Geben Sie eine Workflow-Ausführungs-ID für die Methoden 'get_workflow_run', 'get_workflow_run_usage' und 'get_workflow_run_logs_url' an.
Geben Sie eine Artefakt-ID für die Methode 'download_workflow_run_artifact' an.
Geben Sie eine Job-ID für die Methode 'get_workflow_job' an.
(String, erforderlich)
actions_list - GitHub Actions-Workflows in einem Repository auflisten
Erforderliche OAuth-Bereiche: repo
method: Die auszuführende Aktion (String, erforderlich)
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (Standard: 1) (Zahl, optional)
per_page: Ergebnisse pro Seite für Paginierung (Standard: 30, max: 100) (Zahl, optional)
repo: Repository-Name (String, erforderlich)
resource_id: Die eindeutige Kennung der Ressource. Diese variiert je nach angegebener "Methode". Stellen Sie daher sicher, dass Sie die richtige ID angeben:
Geben Sie keine Ressourcen-ID für die Methode 'list_workflows' an.
Geben Sie eine Workflow-ID oder einen Workflow-Dateinamen (z. B. ci.yaml) für die Methode 'list_workflow_runs' an, oder lassen Sie sie weg, um alle Workflow-Ausführungen im Repository aufzulisten.
Geben Sie eine Workflow-Ausführungs-ID für die Methoden 'list_workflow_jobs' und 'list_workflow_run_artifacts' an.
(String, optional)
workflow_jobs_filter: Filter für Workflow-Jobs. NUR verwenden, wenn die Methode 'list_workflow_jobs' ist (Objekt, optional)
workflow_runs_filter: Filter für Workflow-Ausführungen. NUR verwenden, wenn die Methode 'list_workflow_runs' ist (Objekt, optional)
inputs: Eingaben, die der Workflow akzeptiert. Nur für die Methode 'run_workflow' verwendet. (Objekt, optional)
method: Die auszuführende Methode (String, erforderlich)
owner: Repository-Besitzer (String, erforderlich)
ref: Die Git-Referenz für den Workflow. Die Referenz kann ein Branch- oder Tag-Name sein. Erforderlich für die Methode 'run_workflow'. (String, optional)
repo: Repository-Name (String, erforderlich)
run_id: Die ID der Workflow-Ausführung. Erforderlich für alle Methoden außer 'run_workflow'. (Zahl, optional)
workflow_id: Die Workflow-ID (numerisch) oder der Workflow-Dateiname (z. B. main.yml, ci.yaml). Erforderlich für die Methode 'run_workflow'. (String, optional)
failed_only: Wenn true, werden Protokolle für alle fehlgeschlagenen Jobs in der durch run_id angegebenen Workflow-Ausführung abgerufen. Erfordert die Angabe von run_id. (Boolean, optional)
job_id: Die eindeutige Kennung des Workflow-Jobs. Erforderlich, wenn Protokolle für einen einzelnen Job abgerufen werden. (Zahl, optional)
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
return_content: Gibt den tatsächlichen Protokollinhalt anstelle von URLs zurück (Boolean, optional)
run_id: Die eindeutige Kennung der Workflow-Ausführung. Erforderlich, wenn failed_only true ist, um Protokolle für alle fehlgeschlagenen Jobs in der Ausführung abzurufen. (Zahl, optional)
tail_lines: Anzahl der Zeilen, die vom Ende des Protokolls zurückgegeben werden sollen (Zahl, optional)
Code Quality
- **get_code_quality_finding** – Code-Qualitätsbefund abrufen
- **Erforderliche OAuth-Bereiche**: `repo`
- `findingNumber`: Die Nummer des Befunds. (Zahl, erforderlich)
- `owner`: Der Besitzer des Repositorys. (Zeichenkette, erforderlich)
- `repo`: Der Name des Repositorys. (Zeichenkette, erforderlich)
Code-Sicherheit
user: Benutzername, für den Teams abgerufen werden sollen. Falls nicht angegeben, wird der authentifizierte Benutzer verwendet. (Zeichenkette, optional)
Copilot
assign_copilot_to_issue – Copilot einem Issue zuweisen
Erforderliche OAuth-Bereiche: repo
base_ref: Git-Referenz (z. B. Branch), von der aus der Agent seine Arbeit beginnt. Falls nicht angegeben, wird der Standard-Branch des Repositorys verwendet (Zeichenkette, optional)
custom_instructions: Optionale benutzerdefinierte Anweisungen, um den Agenten über den Issue-Text hinaus zu leiten. Verwenden Sie dies, um zusätzlichen Kontext, Einschränkungen oder Anleitungen bereitzustellen, die nicht in der Issue-Beschreibung enthalten sind (Zeichenkette, optional)
after: Cursor für Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (Zeichenkette, optional)
owner: Der Besitzer des Repositorys. (Zeichenkette, erforderlich)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Der Name des Repositorys. (Zeichenkette, erforderlich)
severity: Dependabot-Warnungen nach Schweregrad filtern (Zeichenkette, optional)
state: Dependabot-Warnungen nach Status filtern. Standardmäßig „open“ (Zeichenkette, optional)
Diskussionen
discussion_comment_write – Diskussionskommentare verwalten
Erforderliche OAuth-Bereiche: repo
body: Kommentarinhalt (erforderlich für die Methoden „add“, „reply“ und „update“) (Zeichenkette, optional)
commentNodeID: Die Node-ID des Diskussionskommentars (erforderlich für die Methoden „reply“, „update“, „delete“, „mark_answer“ und „unmark_answer“). Bei „reply“ ist dies der übergeordnete Kommentar, auf den geantwortet wird; GitHub Discussions unterstützt nur eine Verschachtelungsebene. (Zeichenkette, optional)
discussionNumber: Diskussionsnummer (erforderlich für die Methoden „add“ und „reply“) (Zahl, optional)
method: Schreiboperation, die für einen Diskussionskommentar ausgeführt werden soll.
Optionen sind:
„add“ – fügt einen neuen Top-Level-Kommentar zu einer Diskussion hinzu.
„reply“ – antwortet auf einen Top-Level-Diskussionskommentar (GitHub Discussions unterstützt nur eine Verschachtelungsebene).
„update“ – aktualisiert einen bestehenden Diskussionskommentar.
„delete“ – löscht einen Diskussionskommentar.
„mark_answer“ – markiert einen Diskussionskommentar als Antwort (nur Q&A).
„unmark_answer“ – hebt die Markierung eines Diskussionskommentars als Antwort auf (nur Q&A).
(Zeichenkette, erforderlich)
owner: Repository-Besitzer (erforderlich für die Methoden „add“ und „reply“) (Zeichenkette, optional)
repo: Repository-Name (erforderlich für die Methoden „add“ und „reply“) (Zeichenkette, optional)
includeReplies: Wenn true, enthält jeder Top-Level-Kommentar seine Antworten verschachtelt (bis zu 100 Antworten pro Kommentar, was dem Maximum der GitHub-API entspricht). Standardmäßig false. (Boolean, optional)
repo: Repository-Name. Falls nicht angegeben, werden Diskussionskategorien auf Organisationsebene abgefragt. (Zeichenkette, optional)
list_discussions – Diskussionen auflisten
Erforderliche OAuth-Bereiche: repo
after: Cursor für Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (Zeichenkette, optional)
category: Optionaler Filter nach Diskussionskategorie-ID. Falls angegeben, werden nur Diskussionen mit dieser Kategorie aufgelistet. (Zeichenkette, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Repository-Name. Falls nicht angegeben, werden Diskussionen auf Organisationsebene abgefragt. (Zeichenkette, optional)
Gists
create_gist – Gist erstellen
Erforderliche OAuth-Bereiche: gist
content: Inhalt für die einfache Erstellung eines Einzeldatei-Gists (Zeichenkette, erforderlich)
description: Beschreibung des Gists (Zeichenkette, optional)
filename: Dateiname für die einfache Erstellung eines Einzeldatei-Gists (Zeichenkette, erforderlich)
public: Ob der Gist öffentlich ist (Boolean, optional)
get_gist – Gist-Inhalt abrufen
gist_id: Die ID des Gists (Zeichenkette, erforderlich)
list_gists – Gists auflisten
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
since: Nur Gists, die nach diesem Zeitpunkt aktualisiert wurden (ISO-8601-Zeitstempel) (Zeichenkette, optional)
username: GitHub-Benutzername (weglassen für Gists des authentifizierten Benutzers) (Zeichenkette, optional)
update_gist – Gist aktualisieren
Erforderliche OAuth-Bereiche: gist
content: Inhalt für die Datei (Zeichenkette, erforderlich)
description: Aktualisierte Beschreibung des Gists (Zeichenkette, optional)
filename: Zu aktualisierender oder zu erstellender Dateiname (Zeichenkette, erforderlich)
gist_id: ID des zu aktualisierenden Gists (Zeichenkette, erforderlich)
Git
get_repository_tree – Repository-Baum abrufen
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (Benutzername oder Organisation) (Zeichenkette, erforderlich)
path_filter: Optionales Pfadpräfix, um die Baumergebnisse zu filtern (z. B. „src/“, um nur Dateien im src-Verzeichnis anzuzeigen) (Zeichenkette, optional)
recursive: Wenn dieser Parameter auf true gesetzt wird, werden die vom Baum referenzierten Objekte oder Unterbäume zurückgegeben. Standard ist false (Boolean, optional)
tree_sha: Der SHA1-Wert oder der Ref-Name (Branch oder Tag) des Baums. Standardmäßig der Standard-Branch des Repositorys (Zeichenkette, optional)
Issues
add_issue_comment – Kommentar zu Issue oder Pull Request hinzufügen
Erforderliche OAuth-Bereiche: repo
body: Kommentarinhalt. Erforderlich, es sei denn, eine Reaktion wird angegeben. (Zeichenkette, optional)
comment_id: Die numerische ID des Issue- oder Pull-Request-Kommentars, auf den reagiert werden soll. Verwenden Sie dies für Reaktionen auf Kommentare; lassen Sie es weg, um auf den Issue oder Pull Request selbst zu reagieren. Kann nicht mit body kombiniert werden. (Zahl, optional)
issue_number: Issue- oder Pull-Request-Nummer, die kommentiert oder auf die reagiert werden soll. (Zahl, erforderlich)
issue_number: Die Nummer des Issues (Zahl, erforderlich)
method: Die Leseoperation, die für ein einzelnes Issue ausgeführt werden soll.
Optionen sind:
get – Issue-Details abrufen. Gibt auch Best-Effort-Hierarchie-Flags zurück (has_parent, has_children); parent und sub_issues_summary sind optionale Beziehungszusammenfassungen.
get_comments – Issue-Kommentare abrufen.
get_sub_issues – Unter-Issues (Kinder) des Issues abrufen.
get_parent – Das übergeordnete Issue abrufen, falls dieses Issue ein Unter-Issue eines anderen ist.
get_labels – Dem Issue zugewiesene Labels abrufen.
(Zeichenkette, erforderlich)
owner: Der Besitzer des Repositorys (Zeichenkette, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Der Name des Repositorys (Zeichenkette, erforderlich)
issue_write – Issue/Pull-Request erstellen oder aktualisieren
Erforderliche OAuth-Bereiche: repo
assignees: Benutzernamen, die diesem Issue zugewiesen werden sollen (Zeichenketten-Array, optional)
body: Inhalt des Issue-Texts (Zeichenkette, optional)
duplicate_of: Issue-Nummer, von der dieses Issue ein Duplikat ist. Wird nur verwendet, wenn state_reason 'duplicate' ist. (Zahl, optional)
issue_fields: Issue-Feldwerte, die gesetzt oder gelöscht werden sollen. Jedes Element erfordert 'field_name' und genau eines von 'value', 'field_option_name' oder 'delete: true'. (Objekt-Array, optional)
issue_number: Zu aktualisierende Issue-Nummer (Zahl, optional)
labels: Auf dieses Issue anzuwendende Labels (Zeichenketten-Array, optional)
method: Schreiboperation, die für ein einzelnes Issue ausgeführt werden soll.
Optionen sind:
'create' – erstellt ein neues Issue.
'update' – aktualisiert ein bestehendes Issue.
(Zeichenkette, erforderlich)
state_reason: Grund für die Statusänderung. Wird ignoriert, es sei denn, der Status wird geändert. (Zeichenkette, optional)
title: Issue-Titel (Zeichenkette, optional)
type: Typ dieses Issues. Nur verwenden, wenn Issue-Typen für dieses Repository aktiviert sind. Verwenden Sie das Tool list_issue_types, um gültige Typwerte für dieses Repository oder seine Besitzerorganisation zu erhalten. Wenn das Repository keine Issue-Typen unterstützt, lassen Sie diesen Parameter weg. (Zeichenkette, optional)
owner: Der Kontoinhaber des Repositorys oder der Organisation. Der Name unterscheidet nicht zwischen Groß- und Kleinschreibung. (Zeichenkette, erforderlich)
repo: Der Name des Repositorys. Wenn angegeben, werden Felder für dieses spezifische Repository zurückgegeben (von seiner Organisation geerbt). Wenn weggelassen, werden Felder auf Organisationsebene direkt zurückgegeben. (Zeichenkette, optional)
owner: Der Kontoinhaber des Repositorys oder der Organisation. (Zeichenkette, erforderlich)
repo: Der Name des Repositorys. Wenn angegeben, werden Issue-Typen für dieses spezifische Repository zurückgegeben. Wenn weggelassen, werden Issue-Typen auf Organisationsebene direkt zurückgegeben. (Zeichenkette, optional)
list_issues – Issues auflisten
Erforderliche OAuth-Bereiche: repo
after: Cursor für Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (Zeichenkette, optional)
direction: Sortierrichtung. Falls angegeben, muss auch 'orderBy' angegeben werden. (Zeichenkette, optional)
field_filters: Nach benutzerdefinierten Issue-Feldwerten filtern. Jeder Eintrag benötigt einen field_name und einen value; der Server sucht das Feld und wandelt den Wert in seinen Typ um (Einzelauswahl-Optionsname, Text, Zahl oder YYYY-MM-DD-Datum). (Objekt-Array, optional)
labels: Nach Labels filtern (Zeichenketten-Array, optional)
orderBy: Issues nach Feld sortieren. Falls angegeben, muss auch 'direction' angegeben werden. (Zeichenkette, optional)
since: Nach Datum filtern (ISO-8601-Zeitstempel) (Zeichenkette, optional)
state: Nach Status filtern, standardmäßig werden sowohl offene als auch geschlossene Issues zurückgegeben, wenn nichts angegeben wird (Zeichenkette, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Issues für dieses Repository aufgelistet. (Zeichenkette, optional)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
query: Suchanfrage unter Verwendung der GitHub-Issues-Suchsyntax (Zeichenkette, erforderlich)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Issues für dieses Repository aufgelistet. (Zeichenkette, optional)
sort: Sortierfeld nach Anzahl der Treffer in Kategorien, standardmäßig beste Übereinstimmung (Zeichenkette, optional)
sub_issue_write – Unter-Issue ändern
Erforderliche OAuth-Bereiche: repo
after_id: Die ID des Unter-Issues, das danach priorisiert werden soll (entweder after_id ODER before_id sollte angegeben werden) (Zahl, optional)
before_id: Die ID des Unter-Issues, das davor priorisiert werden soll (entweder after_id ODER before_id sollte angegeben werden) (Zahl, optional)
issue_number: Die Nummer des übergeordneten Issues (Zahl, erforderlich)
method: Die Aktion, die für ein einzelnes Unter-Issue ausgeführt werden soll
Optionen sind:
'add' – ein Unter-Issue zu einem übergeordneten Issue in einem GitHub-Repository hinzufügen.
'remove' – ein Unter-Issue aus einem übergeordneten Issue in einem GitHub-Repository entfernen.
'reprioritize' – die Reihenfolge der Unter-Issues innerhalb eines übergeordneten Issues in einem GitHub-Repository ändern. Verwenden Sie entweder 'after_id' oder 'before_id', um die neue Position anzugeben.
Schreibt die Issue-Hierarchie. Um ein Unter-Issue zu einem neuen übergeordneten Element zu verschieben, verwenden Sie add mit replace_parent=true; es gibt kein beschreibbares übergeordnetes Feld.
(Zeichenkette, erforderlich)
label_write – Schreiboperationen auf Repository-Labels
Erforderliche OAuth-Bereiche: repo
color: Label-Farbe als 6-stelliger Hex-Code ohne '#'-Präfix (z. B. 'f29513'). Erforderlich für 'create', optional für 'update'. (Zeichenkette, optional)
description: Text der Label-Beschreibung. Optional für 'create' und 'update'. (Zeichenkette, optional)
method: Auszuführende Operation: 'create', 'update' oder 'delete' (Zeichenkette, erforderlich)
name: Label-Name – erforderlich für alle Operationen (Zeichenkette, erforderlich)
new_name: Neuer Name für das Label (wird nur mit der 'update'-Methode zum Umbenennen verwendet) (Zeichenkette, optional)
owner: Repository-Besitzer (Benutzername oder Organisationsname) (Zeichenkette, erforderlich)
notificationID: Die ID der Benachrichtigung (Zeichenkette, erforderlich)
list_notifications – Benachrichtigungen auflisten
Erforderliche OAuth-Bereiche: notifications
before: Nur Benachrichtigungen anzeigen, die vor dem angegebenen Zeitpunkt aktualisiert wurden (ISO-8601-Format) (Zeichenkette, optional)
filter: Benachrichtigungen filtern nach, Standard verwenden, sofern nicht anders angegeben. Gelesene Benachrichtigungen sind solche, die der Benutzer bereits zur Kenntnis genommen hat. Beteiligungsbenachrichtigungen sind solche, an denen der Benutzer direkt beteiligt ist, z. B. Issues oder Pull-Requests, die er kommentiert oder erstellt hat. (Zeichenkette, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Benachrichtigungen für dieses Repository aufgelistet. (Zeichenkette, optional)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Benachrichtigungen für dieses Repository aufgelistet. (Zeichenkette, optional)
since: Nur Benachrichtigungen anzeigen, die nach dem angegebenen Zeitpunkt aktualisiert wurden (ISO-8601-Format) (Zeichenkette, optional)
manage_notification_subscription – Benachrichtigungsabonnement verwalten
Erforderliche OAuth-Bereiche: notifications
action: Auszuführende Aktion: ignore, watch oder delete des Benachrichtigungsabonnements. (Zeichenkette, erforderlich)
notificationID: Die ID des Benachrichtigungs-Threads. (Zeichenkette, erforderlich)
manage_repository_notification_subscription – Repository-Benachrichtigungsabonnement verwalten
Erforderliche OAuth-Bereiche: notifications
action: Auszuführende Aktion: ignore, watch oder delete des Repository-Benachrichtigungsabonnements. (Zeichenkette, erforderlich)
owner: Der Kontoinhaber des Repositorys. (Zeichenkette, erforderlich)
repo: Der Name des Repositorys. (Zeichenkette, erforderlich)
mark_all_notifications_read – Alle Benachrichtigungen als gelesen markieren
Erforderliche OAuth-Bereiche: notifications
lastReadAt: Beschreibt den letzten Zeitpunkt, zu dem Benachrichtigungen überprüft wurden (optional). Standard: Jetzt (Zeichenkette, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Benachrichtigungen für dieses Repository als gelesen markiert. (Zeichenkette, optional)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Benachrichtigungen für dieses Repository als gelesen markiert. (Zeichenkette, optional)
page: Seitennummer für Paginierung (min 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min 1, max 100) (Zahl, optional)
query: Suchanfrage für Organisationen. Beispiele: 'microsoft', 'location:california', 'created:>=2025-01-01'. Die Suche wird automatisch auf type:org beschränkt. (String, erforderlich)
sort: Sortierfeld nach Kategorie (String, optional)
Projekte
projects_get - Details zu GitHub Projects-Ressourcen abrufen
Erforderliche OAuth-Bereiche: read:project
Akzeptierte OAuth-Bereiche: project, read:project
field_id: Die ID des Feldes. Erforderlich für die Methode 'get_project_field'. (Zahl, optional)
field_names: Spezifische Liste von Feldnamen, die in die Antwort aufgenommen werden sollen, wenn ein Projektelement abgerufen wird (z. B. ["Status", "Priorität"]). Wird serverseitig in Feld-IDs aufgelöst – übergeben Sie dies anstelle von 'fields', wenn Sie nur die lesbaren Namen kennen. Schließt sich gegenseitig mit 'fields' aus – geben Sie eines an, nicht beides. Wird nur für die Methode 'get_project_item' verwendet. (String[], optional)
fields: Spezifische Liste von Feld-IDs, die in die Antwort aufgenommen werden sollen, wenn ein Projektelement abgerufen wird (z. B. ["102589", "985201", "169875"]). Wenn weder 'fields' noch 'field_names' angegeben wird, wird nur das Titelfeld aufgenommen. Schließt sich gegenseitig mit 'field_names' aus – geben Sie eines an, nicht beides. Wird nur für die Methode 'get_project_item' verwendet. (String[], optional)
item_id: Die ID des Elements. Erforderlich für die Methode 'get_project_item'. (Zahl, optional)
method: Die auszuführende Methode (String, erforderlich)
owner: Der Besitzer (Benutzer- oder Organisations-Login). Bei der Groß-/Kleinschreibung wird nicht unterschieden. (String, optional)
owner_type: Besitzertyp (user oder org). Wenn nicht angegeben, wird er automatisch erkannt. (String, optional)
project_number: Die Nummer des Projekts. (Zahl, optional)
status_update_id: Die Knoten-ID der Projektstatusaktualisierung. Erforderlich für die Methode 'get_project_status_update'. (String, optional)
after: Vorwärts-Paginierungs-Cursor vom vorherigen pageInfo.nextCursor. (String, optional)
before: Rückwärts-Paginierungs-Cursor vom vorherigen pageInfo.prevCursor (selten). (String, optional)
field_names: Feldnamen, die beim Auflisten von Projektelementen aufgenommen werden sollen (z. B. ["Status", "Priorität"]). Wird serverseitig in Feld-IDs aufgelöst – übergeben Sie dies anstelle von 'fields', wenn Sie nur die lesbaren Namen kennen. Namen, die nicht aufgelöst werden können, geben einen strukturierten Fehler zurück. Schließt sich gegenseitig mit 'fields' aus – geben Sie eines an, nicht beides. Wird nur für die Methode 'list_project_items' verwendet. (String[], optional)
fields: Feld-IDs, die beim Auflisten von Projektelementen aufgenommen werden sollen (z. B. ["102589", "985201"]). KRITISCH: Geben Sie dies immer an, um Feldwerte zu erhalten. Ohne dies (und ohne 'field_names') werden nur Titel zurückgegeben. Schließt sich gegenseitig mit 'field_names' aus – geben Sie eines an, nicht beides. Wird nur für die Methode 'list_project_items' verwendet. (String[], optional)
method: Die auszuführende Aktion (String, erforderlich)
owner: Der Besitzer (Benutzer- oder Organisations-Login). Bei der Groß-/Kleinschreibung wird nicht unterschieden. (String, erforderlich)
owner_type: Besitzertyp (user oder org). Wenn nicht angegeben, werden automatisch beide versucht. (String, optional)
per_page: Ergebnisse pro Seite (max 50) (Zahl, optional)
project_number: Die Nummer des Projekts. Erforderlich für die Methoden 'list_project_fields', 'list_project_items' und 'list_project_status_updates'. (Zahl, optional)
query: Filter-/Abfragezeichenfolge. Für list_projects: Filtern nach Titeltext und Status (z. B. "roadmap is:open"). Für list_project_items: Erweiterte Filterung mit der GitHub-Projektfiltersyntax. (String, optional)
projects_write - GitHub Projects verwalten
Erforderliche OAuth-Bereiche: project
body: Der Text der Statusaktualisierung (Markdown). Wird für die Methode 'create_project_status_update' verwendet. (String, optional)
field_name: Der Name des Iterationsfeldes (z. B. 'Sprint'). Erforderlich für die Methode 'create_iteration_field'. (String, optional)
issue_number: Die Issue-Nummer. Erforderlich für 'add_project_item', wenn item_type 'issue' ist. Wird auch von 'update_project_item' akzeptiert, um das Element anhand der Issue-Nummer aufzulösen (kombinieren mit item_owner und item_repo). (Zahl, optional)
item_id: Die Projekt-Element-ID. Erforderlich für 'delete_project_item'. Für 'update_project_item' geben Sie entweder item_id oder (item_owner + item_repo + issue_number) an, um das Element anhand des Issues aufzulösen. (Zahl, optional)
item_owner: Der Besitzer (Benutzer oder Organisation) des Repositorys, das das Issue oder den Pull Request enthält. Erforderlich für die Methode 'add_project_item'. Wird auch von 'update_project_item' akzeptiert, wenn das Element anhand der Issue-Nummer aufgelöst wird. (String, optional)
item_repo: Der Name des Repositorys, das das Issue oder den Pull Request enthält. Erforderlich für die Methode 'add_project_item'. Wird auch von 'update_project_item' akzeptiert, wenn das Element anhand der Issue-Nummer aufgelöst wird. (String, optional)
item_type: Der Typ des Elements, entweder issue oder pull_request. Erforderlich für die Methode 'add_project_item'. (String, optional)
iteration_duration: Dauer in Tagen für Iterationen des Feldes (z. B. 7 für wöchentlich, 14 für zweiwöchentlich). Erforderlich für die Methode 'create_iteration_field'. (Zahl, optional)
iterations: Benutzerdefinierte Iterationen für die Methode 'create_iteration_field'. Setzen Sie dies nur, wenn Sie Iterationen mit unterschiedlicher Dauer, Pausen dazwischen oder spezifischen Titeln benötigen. Andernfalls lassen Sie es weg: GitHub erstellt automatisch drei Iterationen mit der Dauer 'iteration_duration' Tage, beginnend am 'start_date', was für die meisten Fälle die richtige Wahl ist. (Objekt[], optional)
method: Die auszuführende Methode (String, erforderlich)
owner: Der Projektbesitzer (Benutzer- oder Organisations-Login). Bei der Groß-/Kleinschreibung wird nicht unterschieden. (String, erforderlich)
owner_type: Besitzertyp (user oder org). Erforderlich für die Methode 'create_project'. Wenn für andere Methoden nicht angegeben, wird er automatisch erkannt. (String, optional)
project_number: Die Nummer des Projekts. Erforderlich für alle Methoden außer 'create_project'. (Zahl, optional)
pull_request_number: Die Pull-Request-Nummer (verwenden, wenn item_type 'pull_request' für die Methode 'add_project_item' ist). Geben Sie entweder issue_number oder pull_request_number an. (Zahl, optional)
start_date: Startdatum im Format JJJJ-MM-TT. Wird für die Methoden 'create_project_status_update' und 'create_iteration_field' verwendet. (String, optional)
status: Der Status des Projekts. Wird für die Methode 'create_project_status_update' verwendet. (String, optional)
target_date: Das Zieldatum der Statusaktualisierung im Format JJJJ-MM-TT. Wird für die Methode 'create_project_status_update' verwendet. (String, optional)
title: Der Projekttitel. Erforderlich für die Methode 'create_project'. (String, optional)
updated_field: Objekt, das das zu aktualisierende Feld und seinen neuen Wert beschreibt. Erforderlich für 'update_project_item'. Zwei Formen werden akzeptiert: (1) nach ID — {"id": 123456, "value": "..."}; (2) nach Name — {"name": "Status", "value": "In Bearbeitung"}. Für Einfachauswahlfelder erfordert die Auflösung des Optionsnamens die Form nach Name; bei der Form nach ID übergeben Sie die Options-ID. Setzen Sie value auf null, um das Feld zu leeren. (Objekt, optional)
Pull Requests
add_comment_to_pending_review - Review-Kommentar zur letzten ausstehenden Pull-Request-Überprüfung des Anforderers hinzufügen
Erforderliche OAuth-Bereiche: repo
body: Der Text des Review-Kommentars (String, erforderlich)
line: Die Zeile des Blobs im Pull-Request-Diff, auf die sich der Kommentar bezieht. Bei mehrzeiligen Kommentaren die letzte Zeile des Bereichs (Zahl, optional)
owner: Repository-Besitzer (String, erforderlich)
path: Der relative Pfad zur Datei, die einen Kommentar erfordert (String, erforderlich)
side: Die Seite des Diffs, die kommentiert werden soll. LEFT zeigt den vorherigen Zustand an, RIGHT den neuen Zustand (String, optional)
startLine: Bei mehrzeiligen Kommentaren die erste Zeile des Bereichs, auf den sich der Kommentar bezieht (Zahl, optional)
startSide: Bei mehrzeiligen Kommentaren die Startseite des Diffs, auf die sich der Kommentar bezieht. LEFT zeigt den vorherigen Zustand an, RIGHT den neuen Zustand (String, optional)
subjectType: Die Ebene, auf die der Kommentar abzielt (String, erforderlich)
add_reply_to_pull_request_comment - Antwort auf Pull-Request-Kommentar hinzufügen
Erforderliche OAuth-Bereiche: repo
body: Der Text der Antwort. Erforderlich, es sei denn, es wird eine Reaktion bereitgestellt. (String, optional)
commentId: Die numerische ID des Pull-Request-Review-Kommentars, auf den geantwortet oder reagiert werden soll. Verwenden Sie die Nummer aus einem #discussion_r...-Anker, nicht die GraphQL-Thread-Knoten-ID (PRRT_...). (Zahl, erforderlich)
owner: Repository-Besitzer (String, erforderlich)
pullNumber: Pull-Request-Nummer. Erforderlich, wenn body bereitgestellt wird. (Zahl, optional)
reaction: Emoji-Reaktion, die hinzugefügt werden soll. Erforderlich, es sei denn, body wird bereitgestellt. (String, optional)
repo: Repository-Name (String, erforderlich)
create_pull_request - Neuen Pull Request eröffnen
Erforderliche OAuth-Bereiche: repo
base: Branch, in den zusammengeführt werden soll (String, erforderlich)
body: PR-Beschreibung (String, optional)
draft: Als Draft-PR erstellen (Boolean, optional)
head: Branch, der die Änderungen enthält (String, erforderlich)
maintainer_can_modify: Bearbeitungen durch Maintainer zulassen (Boolean, optional)
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
reviewers: GitHub-Benutzernamen oder ORG/Team-Slug-Team-Reviewer, von denen Reviews angefordert werden sollen (String[], optional)
title: PR-Titel (String, erforderlich)
list_pull_requests - Pull Requests auflisten
Erforderliche OAuth-Bereiche: repo
base: Nach Basis-Branch filtern (String, optional)
direction: Sortierrichtung (String, optional)
head: Nach Head-Benutzer/Org und Branch filtern (String, optional)
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (min 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min 1, max 100) (Zahl, optional)
repo: Repository-Name (String, erforderlich)
sort: Sortieren nach (String, optional)
state: Nach Status filtern (String, optional)
merge_pull_request - Pull Request zusammenführen
Erforderliche OAuth-Bereiche: repo
commit_message: Zusätzliches Detail für Merge-Commit (String, optional)
commit_title: Titel für Merge-Commit (String, optional)
pull_request_read – Details zu einem einzelnen Pull Request abrufen
Erforderliche OAuth-Bereiche: repo
after: Cursor für Paginierung, wird nur von der Methode get_review_comments verwendet. Übergeben Sie den endCursor aus der PageInfo der vorherigen Seite, um die nächste Seite abzurufen. (String, optional)
method: Aktion, um festzulegen, welche Pull-Request-Daten von GitHub abgerufen werden sollen.
Mögliche Optionen:
get – Details eines bestimmten Pull Requests abrufen.
get_diff – Den Diff eines Pull Requests abrufen.
get_status – Kombinierten Commit-Status eines Head-Commits in einem Pull Request abrufen.
get_files – Liste der in einem Pull Request geänderten Dateien abrufen. Verwenden Sie Paginierungsparameter, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_commits – Liste der Commits eines Pull Requests abrufen. Verwenden Sie Paginierungsparameter, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_review_comments – Review-Threads eines Pull Requests abrufen. Jeder Thread enthält logisch gruppierte Review-Kommentare, die während Pull-Request-Reviews an derselben Code-Stelle gemacht wurden. Gibt Threads mit Metadaten (isResolved, isOutdated, isCollapsed) und den zugehörigen Kommentaren zurück. Verwenden Sie cursor-basierte Paginierung (perPage, after), um die Ergebnisse zu steuern.
get_reviews – Die Reviews eines Pull Requests abrufen. Wenn nach Review-Kommentaren gefragt wird, verwenden Sie die Methode get_review_comments. Verwenden Sie Paginierungsparameter, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_comments – Kommentare eines Pull Requests abrufen. Verwenden Sie dies, wenn der Benutzer nicht ausdrücklich Review-Kommentare wünscht. Verwenden Sie Paginierungsparameter, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_check_runs – Check-Runs für den Head-Commit eines Pull Requests abrufen. Check-Runs sind die einzelnen CI/CD-Jobs und -Prüfungen, die im PR ausgeführt werden.
(String, erforderlich)
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
threadId: Die Knoten-ID des Review-Threads (z. B. PRRT_kwDOxxx). Erforderlich für die Methoden resolve_thread und unresolve_thread. Thread-IDs erhalten Sie von pull_request_read mit der Methode get_review_comments. (String, optional)
search_pull_requests – Pull Requests suchen
Erforderliche OAuth-Bereiche: repo
order: Sortierreihenfolge (String, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Pull Requests für dieses Repository aufgelistet. (String, optional)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
query: Suchanfrage unter Verwendung der GitHub-Pull-Request-Suchsyntax (String, erforderlich)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Pull Requests für dieses Repository aufgelistet. (String, optional)
sort: Sortierfeld nach Anzahl der Treffer in Kategorien, standardmäßig beste Übereinstimmung (String, optional)
update_pull_request – Pull Request bearbeiten
Erforderliche OAuth-Bereiche: repo
base: Neuer Name des Basis-Branches (String, optional)
body: Neue Beschreibung (String, optional)
draft: Pull Request als Entwurf markieren (true) oder als bereit für Review (false) (Boolean, optional)
maintainer_can_modify: Bearbeitungen durch Maintainer erlauben (Boolean, optional)
owner: Repository-Besitzer (String, erforderlich)
pullNumber: Zu aktualisierende Pull-Request-Nummer (Zahl, erforderlich)
repo: Repository-Name (String, erforderlich)
reviewers: GitHub-Benutzernamen oder ORG/Team-Slug-Team-Reviewer, die zum Review angefordert werden sollen (String[], optional)
organization: Organisation, in der das Repository erstellt werden soll (weglassen, um es im persönlichen Konto zu erstellen) (String, optional)
private: Ob das Repository privat sein soll. Standardmäßig true (privat), wenn weggelassen. (Boolean, optional)
delete_file – Datei löschen
Erforderliche OAuth-Bereiche: repo
branch: Branch, aus dem die Datei gelöscht werden soll (String, erforderlich)
message: Commit-Nachricht (String, erforderlich)
owner: Repository-Besitzer (Benutzername oder Organisation) (String, erforderlich)
path: Pfad zur zu löschenden Datei (String, erforderlich)
repo: Repository-Name (String, erforderlich)
fork_repository – Repository forken
Erforderliche OAuth-Bereiche: repo
organization: Organisation, in die geforkt werden soll (String, optional)
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
get_commit – Commit-Details abrufen
Erforderliche OAuth-Bereiche: repo
detail: Detaillierungsgrad für geänderte Dateien. "none" lässt Statistiken und Dateien vollständig weg. "stats" (Standard) enthält Metadaten pro Datei: Dateiname, Status und Codezeilen-Zählungen (Hinzufügungen, Löschungen, Änderungen), ohne Patch-Inhalt. "full_patch" enthält zusätzlich den einheitlichen Diff-Inhalt für jede Datei und kann sehr groß sein. (String, optional)
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Repository-Name (String, erforderlich)
sha: Commit-SHA, Branch-Name oder Tag-Name (String, erforderlich)
get_file_contents – Datei- oder Verzeichnisinhalte abrufen
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (Benutzername oder Organisation) (String, erforderlich)
path: Pfad zur Datei/zum Verzeichnis (String, optional)
ref: Akzeptiert optionale Git-Referenzen wie refs/tags/{tag}, refs/heads/{branch} oder refs/pull/{pr_number}/head (String, optional)
repo: Repository-Name (String, erforderlich)
sha: Akzeptiert optionalen Commit-SHA. Falls angegeben, wird dieser anstelle von ref verwendet (String, optional)
get_latest_release – Neuestes Release abrufen
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
get_release_by_tag – Release anhand des Tag-Namens abrufen
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
tag: Tag-Name (z. B. 'v1.0.0') (String, erforderlich)
get_tag – Tag-Details abrufen
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (String, erforderlich)
repo: Repository-Name (String, erforderlich)
tag: Tag-Name (String, erforderlich)
list_branches – Branches auflisten
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Repository-Name (String, erforderlich)
list_commits – Commits auflisten
Erforderliche OAuth-Bereiche: repo
author: Autor-Benutzername oder E-Mail-Adresse, um Commits zu filtern (String, optional)
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
path: Nur Commits, die diesen Dateipfad enthalten, werden zurückgegeben (String, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Repository-Name (String, erforderlich)
sha: Commit-SHA, Branch- oder Tag-Name, dessen Commits aufgelistet werden sollen. Wenn nicht angegeben, wird der Standard-Branch des Repositorys verwendet. Wenn ein Commit-SHA angegeben wird, werden Commits bis zu diesem SHA aufgelistet. (String, optional)
since: Nur Commits nach diesem Datum werden zurückgegeben (ISO-8601-Format: YYYY-MM-DDTHH:MM:SSZ oder YYYY-MM-DD) (String, optional)
until: Nur Commits vor diesem Datum werden zurückgegeben (ISO-8601-Format: YYYY-MM-DDTHH:MM:SSZ oder YYYY-MM-DD) (String, optional)
list_releases – Releases auflisten
Erforderliche OAuth-Bereiche: repo
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
affiliation: Nach Zugehörigkeit filtern. Kann einer der folgenden Werte sein: 'outside' (externe Mitarbeiter), 'direct' (alle mit Berechtigungen, unabhängig von der Organisationsmitgliedschaft), 'all' (alle Mitarbeiter). Standard: 'all' (String, optional)
owner: Repository-Besitzer (String, erforderlich)
page: Seitennummer für Paginierung (Standard 1, min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (Standard 30, min. 1, max. 100) (Zahl, optional)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
query: Commit-Suchanfrage (GitHub Commit Search REST). Durchsucht Commit-Nachrichten nur auf dem Standard-Branch. Grenzen Sie die Suche mit repo:owner/repo, org: oder user: ein (Anfragen ohne Bereichsqualifizierer durchsuchen ganz GitHub und sind normalerweise nicht das, was Sie wollen). Weitere Qualifizierer: author:, committer:, author-name:, committer-name:, author-email:, committer-email:, author-date:, committer-date: (unterstützt >, <, >=, <= und YYYY-MM-DD..YYYY-MM-DD-Bereiche), merge:true|false, hash:, tree:, parent:, is:public. Beispiele: repo:owner/repo fix panic; org:github author:defunkt committer-date:>=2024-01-01; "refactor cache" repo:o/r; hash:abc1234 repo:o/r. (Zeichenkette, erforderlich)
sort: Sortieren nach Autor- oder Committer-Datum (Standard: beste Übereinstimmung) (Zeichenkette, optional)
search_repositories – Repositories durchsuchen
Erforderliche OAuth-Bereiche: repo
minimal_output: Minimale Repository-Informationen zurückgeben (Standard: true). Wenn false, werden vollständige GitHub-API-Repository-Objekte zurückgegeben. (boolean, optional)
owner: Der Besitzer des Repositorys. (Zeichenkette, erforderlich)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Der Name des Repositorys. (Zeichenkette, erforderlich)
resolution: Nach Lösung filtern (Zeichenkette, optional)
secret_type: Eine durch Kommas getrennte Liste von Geheimnistypen, die zurückgegeben werden sollen. Alle Standard-Geheimnismuster werden zurückgegeben. Um generische Muster zurückzugeben, übergeben Sie den/die Token-Namen im Parameter. (Zeichenkette, optional)
state: Nach Status filtern (Zeichenkette, optional)
owner: Der Besitzer des Repositorys. (Zeichenkette, erforderlich)
repo: Der Name des Repositorys. (Zeichenkette, erforderlich)
sort: Sortierfeld. (Zeichenkette, optional)
state: Nach Hinweisstatus filtern. (Zeichenkette, optional)
Stargazers
list_starred_repositories – Mit Stern markierte Repositories auflisten
Erforderliche OAuth-Bereiche: repo
direction: Die Richtung, in der die Ergebnisse sortiert werden sollen. (Zeichenkette, optional)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
sort: Wie die Ergebnisse sortiert werden sollen. Kann entweder 'created' (wann das Repository mit Stern markiert wurde) oder 'updated' (wann zuletzt ins Repository gepusht wurde) sein. (Zeichenkette, optional)
username: Benutzername, für den die mit Stern markierten Repositories aufgelistet werden sollen. Standardmäßig der authentifizierte Benutzer. (Zeichenkette, optional)
page: Seitennummer für Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für Paginierung (min. 1, max. 100) (Zahl, optional)
query: Benutzersuchanfrage. Beispiele: 'john smith', 'location:seattle', 'followers:>100'. Die Suche wird automatisch auf type:user beschränkt. (Zeichenkette, erforderlich)
sort: Benutzer nach Anzahl der Follower oder Repositories sortieren oder nach dem Datum, an dem die Person GitHub beigetreten ist. (Zeichenkette, optional)
Zusätzliche Tools im Remote-GitHub-MCP-Server
Copilot
create_pull_request_with_copilot – Aufgabe mit GitHub Copilot Coding Agent ausführen
owner: Repository-Besitzer. Sie können den Besitzer erraten, bestätigen Sie ihn aber mit dem Benutzer, bevor Sie fortfahren. (Zeichenkette, erforderlich)
repo: Repository-Name. Sie können den Repository-Namen erraten, bestätigen Sie ihn aber mit dem Benutzer, bevor Sie fortfahren. (Zeichenkette, erforderlich)
problem_statement: Detaillierte Beschreibung der auszuführenden Aufgabe (z. B. 'Eine Funktion implementieren, die X tut', 'Fehler Y beheben' usw.) (Zeichenkette, erforderlich)
title: Titel für den zu erstellenden Pull Request (Zeichenkette, erforderlich)
base_ref: Git-Referenz (z. B. Branch), von der der Agent seine Arbeit beginnt. Wenn nicht angegeben, wird der Standard-Branch des Repositorys verwendet (Zeichenkette, optional)
Copilot Spaces
Hinweis zur Authentifizierung
Feingranulare PATs werden nicht durch die Bereichsfilterung klassischer PATs ausgeblendet, daher können diese Tools auch dann angezeigt werden, wenn das Token sie nicht verwenden kann.
Für organisations eigene Spaces müssen feingranulare PATs in der besitzenden Organisation installiert sein und organization_copilot_spaces: read enthalten.
Wenn ein organisations eigener Space repository-gestützte Ressourcen enthält, muss das Token auch Zugriff auf jedes referenzierte Repository haben, andernfalls kann der Space als nicht gefunden behandelt werden.
get_copilot_space – Copilot Space abrufen
owner: Der Besitzer des Space. (Zeichenkette, erforderlich)
name: Der Name des Space. (Zeichenkette, erforderlich)
list_copilot_spaces – Copilot Spaces auflisten
GitHub Support-Dokumentation durchsuchen
- **github_support_docs_search** – Ruft Dokumentation ab, die für die Beantwortung von Fragen zu GitHub-Produkten und -Support relevant ist. Zu den Supportthemen gehören: GitHub Actions-Workflows, Authentifizierung, GitHub-Supportanfragen, Pull-Request-Praktiken, Repository-Wartung, GitHub Pages, GitHub Packages, GitHub Discussions, Copilot Spaces
- `query`: Eingabe des Benutzers zu der Frage, die beantwortet werden soll. Dies ist die letzte unbearbeitete Benutzernachricht. Sie SOLLTEN die Benutzernachricht IMMER unverändert lassen und niemals ändern. (Zeichenkette, erforderlich)
Nur-Lese-Modus
Um den Server im Nur-Lese-Modus auszuführen, können Sie das Flag --read-only verwenden. Dadurch werden nur lesende Werkzeuge angeboten, sodass Änderungen an Repositories, Issues, Pull Requests usw. verhindert werden.
./github-mcp-server --read-only
Bei Verwendung von Docker können Sie den Nur-Lese-Modus als Umgebungsvariable übergeben:
Der Lockdown-Modus beschränkt die Inhalte, die der Server aus öffentlichen Repositories anzeigt. Wenn aktiviert, prüft der Server, ob der Autor jedes Elements Schreibzugriff auf das Repository hat. Private Repositories sind davon nicht betroffen, und Mitarbeiter behalten vollen Zugriff auf ihre eigenen Inhalte.
./github-mcp-server --lockdown-mode
Bei Ausführung mit Docker setzen Sie die entsprechende Umgebungsvariable:
Das Verhalten des Lockdown-Modus hängt vom aufgerufenen Werkzeug ab.
Die folgenden Werkzeuge geben einen Fehler zurück, wenn dem Autor der Schreibzugriff fehlt:
issue_read:get
pull_request_read:get
Die folgenden Werkzeuge filtern Inhalte von Benutzern ohne Schreibzugriff heraus:
issue_read:get_comments
issue_read:get_sub_issues
pull_request_read:get_comments
pull_request_read:get_review_comments
pull_request_read:get_reviews
i18n / Überschreiben von Beschreibungen
Die Beschreibungen der Werkzeuge können überschrieben werden, indem eine
github-mcp-server-config.json-Datei im selben Verzeichnis wie die Binärdatei erstellt wird.
Die Datei sollte ein JSON-Objekt enthalten, wobei die Werkzeugnamen die Schlüssel und die neuen
Beschreibungen die Werte sind. Zum Beispiel:
{
"TOOL_ADD_ISSUE_COMMENT_DESCRIPTION": "an alternative description",
"TOOL_CREATE_BRANCH_DESCRIPTION": "Create a new branch in a GitHub repository"
}
Sie können einen Export der aktuellen Übersetzungen erstellen, indem Sie die Binärdatei mit
dem Flag --export-translations ausführen.
Dieses Flag bewahrt alle von Ihnen vorgenommenen Übersetzungen/Überschreibungen und fügt
alle neuen Übersetzungen hinzu, die seit dem letzten Export zur Binärdatei hinzugefügt wurden.
Sie können auch Umgebungsvariablen verwenden, um die Beschreibungen zu überschreiben. Die Namen der
Umgebungsvariablen entsprechen den Schlüsseln in der JSON-Datei, mit dem Präfix
GITHUB_MCP_ und in Großbuchstaben.
Um beispielsweise das Werkzeug TOOL_ADD_ISSUE_COMMENT_DESCRIPTION zu überschreiben, können Sie
die folgende Umgebungsvariable setzen:
export GITHUB_MCP_TOOL_ADD_ISSUE_COMMENT_DESCRIPTION="an alternative description"
Überschreiben von Servername und -titel
Derselbe Überschreibungsmechanismus kann verwendet werden, um die Felder name und
title des MCP-Servers in der Initialisierungsantwort anzupassen. Dies ist nützlich, wenn
mehrere GitHub MCP Server-Instanzen ausgeführt werden (z. B. eine für github.com und eine für
GitHub Enterprise Server), damit Agenten sie unterscheiden können.
Schlüssel
Umgebungsvariable
Standard
SERVER_NAME
GITHUB_MCP_SERVER_NAME
github-mcp-server
SERVER_TITLE
GITHUB_MCP_SERVER_TITLE
GitHub MCP Server
Zum Beispiel, um eine Serverinstanz für GitHub Enterprise Server zu konfigurieren:
Die exportierte Go-API dieses Moduls sollte derzeit als instabil betrachtet werden und kann breaking changes unterliegen. In Zukunft bieten wir möglicherweise Stabilität an; bitte erstellen Sie ein Issue, wenn es einen Anwendungsfall gibt, bei dem dies wertvoll wäre.
Mitwirken
Beiträge sind willkommen. Bevor Sie einen Pull Request öffnen, lesen Sie bitte den Leitfaden zum Mitwirken für Anweisungen zu Einrichtung, Tests, Linting und Dokumentationsgenerierung.
Support
Hilfe zur Nutzung des GitHub MCP Servers finden Sie im Support-Leitfaden. Wenn Sie einen Fehler gefunden haben oder eine Funktion anfordern möchten, durchsuchen Sie bitte bestehende Issues, bevor Sie einen neuen öffnen.
Sicherheit
Bitte melden Sie Sicherheitslücken nicht über öffentliche Issues. Befolgen Sie die Anweisungen in der Sicherheitsrichtlinie, um Schwachstellen verantwortungsvoll zu melden.
Lizenz
Dieses Projekt ist unter den Bedingungen der MIT Open-Source-Lizenz lizenziert. Die vollständigen Bedingungen finden Sie unter MIT.