Repository-Erkundung — Bitten Sie Ihren Assistenten, Code zu durchsuchen, Dateien zu suchen und Commits in jedem Repository zu analysieren, auf das Sie Zugriff haben.
Issue- und PR-Verwaltung — Lassen Sie KI Issues und Pull Requests erstellen, aktualisieren und priorisieren, einschließlich der Überprüfung von Codeänderungen.
CI/CD-Überwachung — Erhalten Sie Einblicke in GitHub Actions-Workflow-Läufe, analysieren Sie Build-Fehler und verwalten Sie Releases.
Sicherheitsanalyse — Untersuchen Sie Code-Scanning-Ergebnisse und prüfen Sie Dependabot-Warnungen auf Schwachstellen.
Team-Zusammenarbeit — Greifen Sie auf Diskussionen zu, verwalten Sie Benachrichtigungen und analysieren Sie Teamaktivitäten in Ihren Projekten.
Gehosteter MCP-Server
npx add-mcp 'https://api.githubcopilot.com/mcp/'
Installiert in Claude Code, Codex, Cursor und mehr
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, Repositorys und Codedateien zu lesen, Issues und PRs zu verwalten, Code zu analysieren und Arbeitsabläufe 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 bei der Triage von Fehlern, der Überprüfung von Codeänderungen und der Pflege von Projektboards helfen.
CI/CD- & Workflow-Intelligenz: Überwachen von GitHub Actions-Workflow-Läufen, Analysieren von Build-Fehlern, Verwalten von Releases und Gewinnen von Einblicken in Ihre Entwicklungspipeline.
Code-Analyse: Untersuchen von Sicherheitsbefunden, Überprüfen von Dependabot-Warnungen, Verstehen von Codemustern und Gewinnen 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 natürlichen Sprachabfragen bis hin zu komplexen mehrstufigen Agenten-Workflows.
Verwendung des Go-Moduls
Der Go-Modulpfad ist github.com/github/github-mcp-server/v2. Bibliotheksnutzer
müssen dieses Präfix in Imports verwenden, zum Beispiel
github.com/github/github-mcp-server/v2/pkg/github, und in go get-Befehlen.
Kein /v2-Unterverzeichnis ist erforderlich, wenn aus einem Repository-Checkout gebaut wird.
Das bestehende v2.0.0-Tag stammt aus der Zeit vor dieser Modulpfad-Korrektur und kann nicht
als Go-Modul verwendet werden. Nachdem diese Änderung zusammengeführt wurde, muss ein neues Release wie v2.0.1 von
einem Commit getaggt werden, der den korrigierten Modulpfad enthält. Bis dahin
können Verbraucher eine Pseudo-Version aus einem Commit verwenden, der diese Änderung enthält.
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.)
Für eine schnelle Installation verwenden Sie einen der Ein-Klick-Installationsbuttons oben. Sobald Sie diesen Ablauf abgeschlossen haben, aktivieren Sie den Agentenmodus (befindet sich neben dem Copilot Chat-Textfeld) und der Server startet. Stellen Sie sicher, dass Sie VS Code 1.101 oder neuer für Remote-MCP- und OAuth-Unterstützung verwenden.
Alternativ können Sie VS Code manuell konfigurieren. Wählen Sie den passenden JSON-Block aus den Beispielen unten und fügen Sie ihn zu 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 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. Konsultieren Sie 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 enthält 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 die Standard-Toolsets verwendet.
Insiders-Modus
Neue Funktionen früh ausprobieren! Der Remote-Server bietet eine Insiders-Version mit frühzeitigem Zugriff auf neue Funktionen und experimentelle Tools.
Hinweis: Bei der Verwendung von OAuth mit GitHub Enterprise in VS Code und GitHub Copilot müssen Sie auch Ihre VS Code-Einstellungen konfigurieren, um auf Ihre GitHub-Enterprise-Instanz zu verweisen – siehe Authentifizierung von VS Code aus
Um den Server in einem Container auszuführen, müssen Sie Docker installiert haben.
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 Fehler beim Pull erhalten, haben Sie möglicherweise ein abgelaufenes Token und müssen docker logout ghcr.io.
Authentifizierung. Auf github.com müssen Sie nichts im Voraus erstellen – die Ein-Klick-Buttons oben melden Sie bei der ersten Verwendung mit OAuth an (ein browserbasierter Ablauf; das Token wird nur im Speicher gehalten). Die Docker-Buttons veröffentlichen einen festen Callback-Port (127.0.0.1:8085), sodass der Login-Callback des Containers erreichbar ist. Siehe Lokaler Server OAuth-Login für die Funktionsweise, den Headless-/Gerätecode-Fallback und das Mitbringen 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 GitHub Personal Access Token authentifizieren, indem Sie stattdessen GITHUB_PERSONAL_ACCESS_TOKEN setzen (dies hat Vorrang vor OAuth). Der MCP-Server kann viele der GitHub-APIs verwenden. Aktivieren Sie daher die Berechtigungen, die Sie Ihren KI-Tools gewähren möchten (weitere Informationen zu Zugriffstokens finden Sie in der Dokumentation).
Sichere Handhabung von PATs
Umgebungsvariablen (Empfohlen)
Um Ihr GitHub-PAT sicher zu halten und über verschiedene MCP-Hosts hinweg wiederverwendbar zu machen:
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-Anwendung und IDE. Einige Anwendungen (wie Windsurf) erfordern fest codierte Tokens in Konfigurationsdateien.
Best Practices für Token-Sicherheit
Mindestumfang: Nur notwendige Berechtigungen erteilen
repo – Repository-Operationen
read:packages – Docker-Image-Zugriff
read:org – Organisations-Teamzugriff
Getrennte Tokens: Verwenden Sie verschiedene PATs für verschiedene Projekte/Umgebungen
Regelmäßige Rotation: Aktualisieren Sie Tokens regelmäßig
Nie committen: Halten Sie Tokens aus der Versionskontrolle heraus
Dateiberechtigungen: Beschränken Sie den Zugriff auf Konfigurationsdateien, die Tokens 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.
Für GitHub Enterprise Server präfixieren Sie den Hostnamen mit dem https://-URI-Schema. HTTPS ist erforderlich und wird erzwungen: Nicht-HTTPS-Hosts werden abgelehnt, damit Anmeldeinformationen niemals im Klartext gesendet werden (die einzige Ausnahme ist ein Loopback-Host wie http://localhost für die lokale Entwicklung).
Für GitHub Enterprise Cloud mit Datenresidenz verwenden Sie https://YOURSUBDOMAIN.ghe.com als Hostnamen.
Für eine schnelle Installation verwenden Sie einen der Ein-Klick-Installationsbuttons oben. Sobald Sie diesen Ablauf abgeschlossen haben, aktivieren Sie den Agentenmodus (befindet sich neben dem Copilot Chat-Textfeld) und der Server startet.
Weitere Informationen zur Verwendung von MCP-Server-Tools in VS Code finden Sie in der Agentenmodus-Dokumentation.
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 Token erstellen oder speichern). Auf github.com enthält das offizielle Image bereits die App-Anmeldeinformationen, sodass Sie selbst keine bereitstellen müssen: Es führt bei der ersten Verwendung einen browserbasierten Login durch und hält das resultierende Token nur im Speicher. In Docker muss dafür ein fester Callback-Port auf Loopback veröffentlicht werden, 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 Mitbringen eigener OAuth- oder GitHub-Apps.
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.
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. Viele folgen möglicherweise einem ähnlichen Format wie die obigen Beispiele, dies ist jedoch nicht garantiert. Bitte konsultieren Sie die Dokumentation Ihrer Host-Anwendung für die korrekte MCP-Konfigurationssyntax und den Einrichtungsprozess.
Aus dem Quellcode erstellen
Wenn Sie kein Docker 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 Umgebungsvariable GITHUB_PERSONAL_ACCESS_TOKEN verwenden, die auf Ihr Token gesetzt ist. 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.
STDIO-API-Anfragen identifizieren den Server als github-mcp-server/<version> und behalten den Namen/die Version des vorgelagerten MCP-Clients in Klammern bei, wenn verfügbar. Steuerzeichen, Anführungszeichen, Backslashes und Klammern in Client-Metadaten werden maskiert, sodass der HTTP-Header gültig bleibt; gewöhnliche Namen, Versionen, Leerzeichen und druckbares Unicode werden beibehalten. Release-Builds behalten ihre Release-Version. Quell- und Standard-Docker-Builds mit Revisionsmetadaten verwenden vcs-<full-commit-sha>. Der Docker-Publishing-Workflow bewahrt Tag-Versionen, einschließlich Vorabversionen, und ermöglicht Branch-, Pull-Request- und Nightly-Builds, die verknüpfte Quellrevision zu verwenden. Der Marker -dirty gilt nur, wenn sowohl die Revision als auch der geänderte Zustand aus eingebetteten VCS-Metadaten stammen, niemals für eine gültige, explizit angegebene main.commit. Dies ist eine VCS-Build-Kennung, keine Release-Nummer.
Erstellen Sie das vollständige Paket mit go build -o github-mcp-server ./cmd/github-mcp-server aus einem Git-Checkout, um seine VCS-Revision einzubetten. Für Builds ohne VCS-Metadaten geben Sie das tatsächliche Release mit -ldflags '-X main.version=<release>' oder die vollständige Quellrevision mit -ldflags '-X main.commit=<sha>' an. Gültige Metadaten werden in dieser Reihenfolge ausgewählt: explizites Release, explizite Quellrevision, eingebettete VCS-Revision, dann installierte Hauptmodulversion. Gültige explizite Revisionen bleiben maßgeblich, auch wenn die Build-Kontextfilterung eingebettete VCS-Metadaten ändert. Fehlende oder fehlerhafte Kandidaten fallen auf die nächste verwendbare Quelle zurück. Wenn keine verfügbar ist, startet STDIO trotzdem mit dem Entwicklungs-Label dev und gibt eine Warnung auf stderr aus, sodass stdout für das MCP-Protokoll verfügbar bleibt. Geben Sie echte Release- oder Revisionsmetadaten an, wenn eine versionsspezifische Zuordnung erforderlich ist.
Der GitHub MCP-Server unterstützt das Aktivieren oder Deaktivieren bestimmter Funktionsgruppen über das Flag --toolsets. Dies ermöglicht Ihnen zu steuern, welche GitHub-API-Funktionen Ihren KI-Tools zur Verfügung stehen. Das Aktivieren nur der benötigten Toolsets kann 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 ebenfalls enthalten, wo zutreffend.
Wenn keine Toolsets angegeben sind, werden Standard-Toolsets verwendet.
Auf der Suche nach Beispielen? Siehe den Server-Konfigurationsleitfaden für gängige Rezepte wie minimale Setups, Nur-Lese-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 spezifische Tools mit dem Flag --tools konfigurieren. Tools können unabhängig oder in Kombination mit Toolsets für eine feingranulare 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 Nur-Lese-Modus hat Priorität: 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 dazu, dass der Server beim Start mit einer Fehlermeldung fehlschlägt
Wenn Tools umbenannt werden, bleiben alte Namen als Aliase für die Abwärtskompatibilität erhalten. Siehe Tool-Umbenennung für Details.
Toolsets mit Docker verwenden
Bei Verwendung von Docker können Sie die Toolsets als Umgebungsvariablen übergeben:
Dringend empfohlen: Tools, die Kontext über den aktuellen Benutzer und den GitHub-Kontext bieten, in dem Sie arbeiten
actions
GitHub Actions-Workflows und CI/CD-Operationen
code_quality
Tools zur GitHub-Codequalität
code_security
Tools zur Codesicherheit, wie GitHub Code Scanning
copilot
Copilot-bezogene Tools
copilot_issue_intents
Opt-in-Copilot-Issue-Zuweisungstools, die Intent-Metadaten tragen (Begründung, Konfidenz, Vorschlag)
dependabot
Dependabot-Tools
discussions
Tools zu GitHub Discussions
gists
Tools zu GitHub Gist
git
Tools zur GitHub-Git-API für Low-Level-Git-Operationen
governance
Repository-Governance-Tools zur Verwaltung von Rulesets und benutzerdefinierten Eigenschaften auf Repository-, Organisations- und Unternehmensebene
issues
Tools zu GitHub Issues
labels
Tools zu GitHub Labels
notifications
Tools zu GitHub-Benachrichtigungen
orgs
Tools zu GitHub-Organisationen
projects
Tools zu GitHub-Projekten
pull_requests
Tools zu GitHub Pull Requests
repos
Tools zu GitHub-Repositories
secret_protection
Tools zum Geheimnisschutz, wie GitHub Secret Scanning
security_advisories
Tools zu Sicherheitshinweisen
stargazers
Tools zu GitHub-Stargazern
users
Tools zu GitHub-Benutzern
Zusätzliche Toolsets im Remote-GitHub-MCP-Server
Toolset
Beschreibung
copilot
Copilot-bezogene Tools (z. B. Copilot Coding Agent)
copilot_spaces
Tools zu Copilot Spaces
github_support_docs_search
Durchsuchen Sie Dokumentationen, um GitHub-Produkt- und Supportfragen zu beantworten
Tools
Repository-Tools legen Ausgabeschemata und typisierte structuredContent offen, wenn die ausgehandelte MCP-Protokollversion eine unterstützte Version 2026-07-28 oder neuer ist. Ältere Clients, Clients mit unbekannter Protokollversion und Clients, die die Version weglassen, erhalten den vorhandenen Inhalt ohne Ausgabeschema oder strukturierte Ausgabe. Unbekannte Versionen werden nicht nur deshalb als unterstützt behandelt, weil sie nach 2026-07-28 sortieren.
Für get_file_contents sind Verzeichnisergebnisse (einschließlich Feldprojektionen) strukturierte Arrays. Dateidownloads und Nur-Metadaten-Antworten verwenden ein content-Array aus typisierten Text-, eingebetteten Ressourcen- oder Ressourcenlink-Blöcken, das Statusmeldungen, Text, Base64-Blobs, leere Dateien und Download-Links bewahrt. Nur-Text-Repository-Mutationen wie Sternvergabe und Löschung geben ebenfalls eine strukturierte message zurück; Fork-Antworten unterscheiden eine Repository-Referenz von einer laufenden Nachricht. Das Löschen eines Repositorys erfordert weiterhin seinen bestehenden Bestätigungsablauf, bevor ein abgeschlossenes Ergebnis zurückgegeben wird.
Strukturierte Repository-Ergebnisse verwenden kompakte DTOs anstelle von rohen REST-Objekten. Release-Abfragen teilen sich die kompakte Release-Form mit Release-Listen; Git-Referenzen behalten die Referenz, den Objekttyp und den SHA; annotierte Tags behalten Tag-/Nachrichten-/Tagger-/Zielinformationen; Lösch-Commits behalten SHA, Nachricht, Autoren, Baum-SHA, Eltern-SHAs und eine menschenlesbare html_url, wenn verfügbar. Verzeichniseinträge behalten Dateimetadaten und nützliche HTML-/Download-Links, lassen jedoch API- und Hypermedia-Routing-URLs weg, selbst wenn diese Felder in einer Projektion angefordert wurden. Legacy- und unbekannte Protokollversionen behalten den ursprünglichen Text bytegenau; moderne reine Text-JSON-Antworten serialisieren dasselbe kompakte DTO wie structuredContent. Nicht-Text-Ressourcenblöcke und Tool-Fehler behalten ihr bestehendes Inhaltsverhalten. Strukturierte Projektionen verwenden dieselbe bereinigte und gefilterte Quelle wie der Legacy-Formatierer.
Für get_repository_tree, list_gists, get_gist, create_gist und update_gist behalten Gist-Ergebnisse Dateinamen, Inhalte, Größen, Sprach-/Typinformationen, Zeitstempel, Sichtbarkeit und kompakte Besitzerprofile bei, während API-/Node- und Git-Transport-URLs weggelassen werden. Baum-Einträge lassen ihre ableitbaren API-URLs weg. Ergebnisse zum Erstellen/Aktualisieren von Gists enthalten die Gist-ID und die HTML-URL. Moderne JSON-Text- und strukturierte Inhalte serialisieren dasselbe kompakte Ergebnis. Ältere oder unbekannte Protokollversionen behalten bytegenauen Legacy-Text ohne Ausgabeschema oder strukturierten Inhalt.
Die Issue-Metadaten-Tools (list_issue_types, list_issue_fields), Kommentar-Tools (add_issue_comment, update_issue_comment), Abhängigkeits-Tools (issue_dependency_read, issue_dependency_write) und Duplikaterkennungs-Tools (find_duplicate) bieten typisierte outputSchema und structuredContent für ausgehandelte unterstützte Protokollversionen 2026-07-28 oder neuer. Ältere oder unbekannte Protokollversionen behalten dieselben Textantworten ohne diese Felder. Tool-Fehler geben keinen strukturierten Inhalt zurück. Abhängigkeits- und Duplikaterkennungs-Tools behalten ihre bestehenden Feature-Gates.
Für ausgehandelte unterstützte Protokollversionen 2026-07-28 oder neuer geben die konsolidierten Actions-Tools (actions_list, actions_get, actions_run_trigger) strukturierte Objekte mit einem method-Diskriminator und einem methodenspezifischen typisierten Feld zurück; JSON-Text enthält dieselbe kompakte Projektion. Workflow-, Job- und Artefakt-Projektionen lassen API-/Hypermedia-URLs weg, behalten aber Browser-Links und nützliche Kennungen, Zustände, Zeitstempel und Nutzungsdauern bei. Lauf-Nutzungslisten führen abrechenbare Runner-Umgebungen in deterministischer Namensreihenfolge auf. Ältere und unbekannte Protokoll-Textantworten bleiben unverändert; get_job_logs behält seine typisierten Inhalts-, URL- oder fehlgeschlagenen Job-Sammlungsvarianten.
Actions
actions_get – Details zu GitHub-Actions-Ressourcen abrufen (Workflows, Workflow-Läufe, Jobs und Artefakte)
OAuth-Challenge-Bereiche: repo
method: Die auszuführende Methode (Zeichenfolge, erforderlich)
resource_id: Die eindeutige Kennung der Ressource. Diese variiert je nach bereitgestellter „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-Lauf-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.
(Zeichenfolge, erforderlich)
actions_list – GitHub-Actions-Workflows in einem Repository auflisten
OAuth-Challenge-Bereiche: repo
method: Die auszuführende Aktion (Zeichenfolge, erforderlich)
resource_id: Die eindeutige Kennung der Ressource. Diese variiert je nach bereitgestellter „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 das Feld leer, um alle Workflow-Läufe im Repository aufzulisten.
Geben Sie eine Workflow-Lauf-ID für die Methoden „list_workflow_jobs" und „list_workflow_run_artifacts" an.
(Zeichenfolge, optional)
workflow_jobs_filter: Filter für Workflow-Jobs. NUR verwendet, wenn die Methode „list_workflow_jobs" ist (Objekt, optional)
workflow_runs_filter: Filter für Workflow-Läufe. NUR verwendet, wenn die Methode „list_workflow_runs" ist (Objekt, optional)
ref: Die Git-Referenz für den Workflow. Die Referenz kann ein Zweig- oder Tag-Name sein. Erforderlich für die Methode „run_workflow". (Zeichenfolge, optional)
run_id: Die ID des Workflow-Laufs. 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". (Zeichenfolge, optional)
failed_only: Wenn „true", werden Protokolle für alle fehlgeschlagenen Jobs im durch run_id angegebenen Workflow-Lauf abgerufen. Erfordert, dass run_id angegeben wird. (Boolescher Wert, optional)
job_id: Die eindeutige Kennung des Workflow-Jobs. Erforderlich beim Abrufen von Protokollen für einen einzelnen Job. (Zahl, optional)
return_content: Gibt tatsächlichen Protokollinhalt anstelle von URLs zurück (Boolescher Wert, optional)
run_id: Die eindeutige Kennung des Workflow-Laufs. Erforderlich, wenn failed_only „true" ist, um Protokolle für alle fehlgeschlagenen Jobs im Lauf abzurufen. (Zahl, optional)
tail_lines: Anzahl der Zeilen, die vom Ende des Protokolls zurückgegeben werden sollen (Zahl, optional)
org: Organisations-Login (Besitzer), der das Team enthält. (Zeichenfolge, erforderlich)
team_slug: Team-Slug (Zeichenfolge, erforderlich)
get_teams – Teams abrufen
OAuth-Challenge-Bereiche: read:org
user: Benutzername, für den Teams abgerufen werden sollen. Wenn nicht angegeben, wird der authentifizierte Benutzer verwendet. (Zeichenfolge, optional)
ui_get – Benutzeroberflächendaten abrufen
OAuth-Challenge-Bereiche: repo, read:org
method: Die Art der abzurufenden Daten (Zeichenfolge, erforderlich)
owner: Repository-Besitzer (erforderlich für alle Methoden) (Zeichenfolge, erforderlich)
assign_copilot_to_issue – Copilot einem Issue zuweisen
OAuth-Challenge-Bereiche: repo
base_ref: Git-Referenz (z. B. Zweig), von der der Agent seine Arbeit startet. Wenn nicht angegeben, wird standardmäßig der Standardzweig des Repositorys verwendet (Zeichenfolge, optional)
custom_instructions: Optionale benutzerdefinierte Anweisungen, um den Agenten über den Issue-Text hinaus zu führen. Verwenden Sie dies, um zusätzlichen Kontext, Einschränkungen oder Anleitungen bereitzustellen, die nicht in der Issue-Beschreibung enthalten sind (Zeichenfolge, optional)
Copilot-Issue-Absichten
- **assign_copilot_to_issue_with_intent** - Copilot einem Issue mit Absicht zuweisen
- **OAuth Challenge Scopes**: `repo`
- `base_ref`: Git-Referenz (z. B. Branch), von der der Agent seine Arbeit startet. Wenn nicht angegeben, wird der Standard-Branch des Repositorys verwendet. Wird ignoriert, wenn is_suggestion true ist (string, optional)
- `confidence`: Wie sicher Sie sich bei dieser Wahl sind. 'HIGH' für ein klares Signal oder eine explizite Benutzeranfrage, 'MEDIUM' für eine vernünftige Schlussfolgerung mit etwas Mehrdeutigkeit, 'LOW' für eine beste Vermutung mit begrenztem Signal. (string, erforderlich)
- `custom_instructions`: Optionale benutzerdefinierte Anweisungen, um den Agenten über den Issue-Text hinaus zu führen. Wird ignoriert, wenn is_suggestion true ist (string, optional)
- `is_suggestion`: Wenn true, wird eine ausstehende Copilot-Zuweisungsabsicht aufgezeichnet, anstatt den Agenten zu starten. Die Genehmigung liefert später den Startkontext; base_ref und custom_instructions werden in diesem Fall ignoriert. (boolean, erforderlich)
- `issue_number`: Issue-Nummer (number, erforderlich)
- `owner`: Repository-Besitzer (string, erforderlich)
- `rationale`: Ein prägnanter Satz, der erklärt, was genau an dem Issue zur Auswahl von Copilot geführt hat. Geben Sie das konkrete Signal an (z. B. 'Gut abgegrenzte Aufgabe mit klaren Abnahmekriterien'). (string, erforderlich)
- `repo`: Repository-Name (string, erforderlich)
Dependabot
get_dependabot_alert - Dependabot-Alert abrufen
OAuth Challenge Scopes: security_events
alertNumber: Die Nummer des Alerts. (number, erforderlich)
owner: Der Besitzer des Repositorys. (string, erforderlich)
repo: Der Name des Repositorys. (string, erforderlich)
after: Cursor für die Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (string, optional)
owner: Der Besitzer des Repositorys. (string, erforderlich)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Der Name des Repositorys. (string, erforderlich)
severity: Dependabot-Alerts nach Schweregrad filtern (string, optional)
state: Dependabot-Alerts nach Status filtern. Standardmäßig offen (string, optional)
Discussions
discussion_comment_write - Diskussionskommentare verwalten
OAuth Challenge Scopes: repo
body: Kommentarinhalt (erforderlich für die Methoden 'add', 'reply' und 'update') (string, optional)
commentNodeID: Die Node-ID des Diskussionskommentars (erforderlich für die Methoden 'reply', 'update', 'delete', 'mark_answer' und 'unmark_answer'). Für 'reply' ist dies der Top-Level-Kommentar, auf den geantwortet werden soll; GitHub Discussions unterstützt nur eine Verschachtelungsebene. (string, optional)
discussionNumber: Diskussionsnummer (erforderlich für die Methoden 'add' und 'reply') (number, optional)
method: Schreiboperation, die an einem Diskussionskommentar durchgefü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 vorhandenen Diskussionskommentar.
'delete' - löscht einen Diskussionskommentar.
'mark_answer' - markiert einen Diskussionskommentar als Antwort (nur Q&A).
'unmark_answer' - entfernt die Markierung eines Diskussionskommentars als Antwort (nur Q&A).
(string, erforderlich)
owner: Repository-Besitzer (erforderlich für die Methoden 'add' und 'reply') (string, optional)
repo: Repository-Name (erforderlich für die Methoden 'add' und 'reply') (string, optional)
includeReplies: Wenn true, enthält jeder Top-Level-Kommentar seine Antworten verschachtelt darin (bis zu 100 Antworten pro Kommentar, das ist das GitHub-API-Maximum). Standardmäßig false. (boolean, optional)
owner: Repository-Besitzer (string, erforderlich)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Repository-Name. Wenn nicht angegeben, werden Diskussionskategorien auf Organisationsebene abgefragt. (string, optional)
list_discussions - Diskussionen auflisten
OAuth Challenge Scopes: repo
after: Cursor für die Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (string, optional)
category: Optionaler Filter nach Diskussionskategorie-ID. Wenn angegeben, werden nur Diskussionen mit dieser Kategorie aufgelistet. (string, optional)
direction: Sortierrichtung. (string, optional)
orderBy: Diskussionen nach Feld sortieren. Wenn angegeben, muss auch die 'direction' angegeben werden. (string, optional)
owner: Repository-Besitzer (string, erforderlich)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Repository-Name. Wenn nicht angegeben, werden Diskussionen auf Organisationsebene abgefragt. (string, optional)
Gists
create_gist - Gist erstellen
OAuth Challenge Scopes: gist
content: Inhalt für die einfache Erstellung eines einzeiligen Gists (string, erforderlich)
description: Beschreibung des Gists (string, optional)
filename: Dateiname für die einfache Erstellung eines einzeiligen Gists (string, erforderlich)
public: Ob das Gist öffentlich ist (boolean, optional)
get_gist - Gist-Inhalt abrufen
gist_id: Die ID des Gists (string, erforderlich)
list_gists - Gists auflisten
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
since: Nur Gists, die nach diesem Zeitpunkt aktualisiert wurden (ISO-8601-Zeitstempel) (string, optional)
username: GitHub-Benutzername (weglassen für Gists des authentifizierten Benutzers) (string, optional)
update_gist - Gist aktualisieren
OAuth Challenge Scopes: gist
content: Inhalt für die Datei (string, erforderlich)
description: Aktualisierte Beschreibung des Gists (string, optional)
filename: Dateiname zum Aktualisieren oder Erstellen (string, erforderlich)
gist_id: ID des zu aktualisierenden Gists (string, erforderlich)
Git
get_repository_tree - Repository-Baum abrufen
OAuth Challenge Scopes: repo
owner: Repository-Besitzer (Benutzername oder Organisation) (string, erforderlich)
path_filter: Optionales Pfadpräfix zum Filtern der Baum-Ergebnisse (z. B. 'src/', um nur Dateien im src-Verzeichnis anzuzeigen) (string, optional)
recursive: Wenn dieser Parameter auf true gesetzt ist, werden die Objekte oder Unterbäume zurückgegeben, auf die der Baum verweist. Standard ist false (boolean, optional)
repo: Repository-Name (string, erforderlich)
tree_sha: Der SHA1-Wert oder der Ref-Name (Branch oder Tag) des Baums. Standardmäßig wird der Standard-Branch des Repositorys verwendet (string, optional)
bypass_actors: Die Akteure, die die Regeln in diesem Regelsatz umgehen können (object[], optional)
conditions: Bedingungen, wann dieser Regelsatz gilt, z. B. {"ref_name": {"include": ["refs/heads/main"], "exclude": []}} (object, optional)
enforcement: Die Durchsetzungsstufe des Regelsatzes. 'evaluate' ermöglicht Administratoren, Regeln zu testen, bevor sie durchgesetzt werden (string, erforderlich)
enterprise: Enterprise-Slug. Erforderlich, wenn die Ebene 'enterprise' ist. (string, optional)
level: Die Ebene, auf der der Regelsatz konfiguriert ist:
'repository': Ein Regelsatz für ein einzelnes Repository (erfordert 'owner' und 'repo').
'organization': Ein Regelsatz, der Repositorys in einer Organisation abdeckt (erfordert 'org').
'enterprise': Ein Regelsatz, der Repositorys in einem Unternehmen abdeckt (erfordert 'enterprise'). (string, erforderlich)
name: Der Name des Regelsatzes (string, erforderlich)
org: Organisationsname. Erforderlich, wenn die Ebene 'organization' ist. (string, optional)
owner: Repository-Besitzer. Erforderlich, wenn die Ebene 'repository' ist. (string, optional)
repo: Repository-Name. Erforderlich, wenn die Ebene 'repository' ist. (string, optional)
rules: Ein Array von Regeln innerhalb des Regelsatzes. Jede Regel ist ein Objekt mit einem 'type' (z. B. 'creation', 'deletion', 'non_fast_forward', 'required_signatures', 'pull_request', 'required_status_checks') und, für Regeln, die eine Konfiguration benötigen, ein 'parameters'-Objekt (object[], erforderlich)
target: Das Ziel des Regelsatzes. Standardmäßig 'branch'. 'repository' ist nur für Regelsätze der Ebene 'organization' und 'enterprise' gültig. (string, optional)
enterprise: Enterprise-Slug. Erforderlich, wenn die Ebene „enterprise“ ist. (Zeichenfolge, optional)
level: Die Ebene, auf der benutzerdefinierte Eigenschaften verwaltet werden:
„repository“: Die benutzerdefinierten Eigenschaftswerte, die einem Repository zugewiesen sind (erfordert „owner“ und „repo“).
„organization“: Die Definitionen (Schema) benutzerdefinierter Eigenschaften für eine Organisation (erfordert „org“).
„enterprise“: Die Definitionen (Schema) benutzerdefinierter Eigenschaften für ein Enterprise (erfordert „enterprise“). (Zeichenfolge, erforderlich)
org: Organisationsname. Erforderlich, wenn die Ebene „organization“ ist. (Zeichenfolge, optional)
owner: Repository-Besitzer. Erforderlich, wenn die Ebene „repository“ ist. (Zeichenfolge, optional)
properties: Die zu erstellenden oder zu aktualisierenden benutzerdefinierten Eigenschaften. Auf Repository-Ebene weist jedes Element einen Wert zu („property_name“ und „value“); auf Organisations- und Enterprise-Ebene definiert jedes Element das Schema („property_name“ und „value_type“ sowie optionale Definitionsfelder). (Objekt[], erforderlich)
repo: Repository-Name. Erforderlich, wenn die Ebene „repository“ ist. (Zeichenfolge, optional)
actor_name: Der Handle für das GitHub-Benutzerkonto, nach dem Regelsuiten gefiltert werden sollen. Wird von der Methode „list_rule_suites“ verwendet. (Zeichenfolge, optional)
branch: Zweigname. Erforderlich für die Methode „get_rules_for_branch“. (Zeichenfolge, optional)
enterprise: Enterprise-Slug. Erforderlich, wenn die Ebene „enterprise“ ist. (Zeichenfolge, optional)
evaluate_status: Regelsuiten nach dem Bewertungsmodus des Regelsatzes filtern. Wird von der Methode „list_rule_suites“ verwendet. (Zeichenfolge, optional)
includes_parents: Regelsätze einbeziehen, die auf höheren Ebenen konfiguriert sind und ebenfalls gelten. Standardmäßig true. Wird von den Methoden „get“ und „list“ auf Repository-Ebene verwendet. (Boolescher Wert, optional)
level: Die Ebene, auf der der Regelsatz konfiguriert ist:
„repository“: Ein Regelsatz für ein einzelnes Repository (erfordert „owner“ und „repo“).
„organization“: Ein Regelsatz, der Repositorys in einer Organisation abdeckt (erfordert „org“).
„enterprise“: Ein Regelsatz, der Repositorys in einem Enterprise abdeckt (erfordert „enterprise“). (Zeichenfolge, erforderlich)
method: Auszuführende Operation:
„get“: Einen bestimmten Regelsatz anhand der ID abrufen (erfordert „ruleset_id“). Auf jeder Ebene unterstützt.
„list“: Alle Regelsätze auflisten. Auf jeder Ebene unterstützt.
„get_rules_for_branch“: Alle Regeln abrufen, die für einen Zweig gelten (erfordert „branch“). Nur auf Repository-Ebene.
„list_rule_suites“: Regelsuiten auflisten, also die Bewertungen von Regeln gegenüber Pushes. Nur auf Repository- und Organisationsebene.
„get_rule_suite“: Eine bestimmte Regelsuite anhand der ID abrufen (erfordert „rule_suite_id“). Nur auf Repository- und Organisationsebene. (Zeichenfolge, erforderlich)
org: Organisationsname. Erforderlich, wenn die Ebene „organization“ ist. (Zeichenfolge, optional)
owner: Repository-Besitzer. Erforderlich, wenn die Ebene „repository“ ist. (Zeichenfolge, optional)
page: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
ref: Der Name des Refs (Zweig, Tag usw.), nach dem Regelsuiten gefiltert werden sollen. Wird von der Methode „list_rule_suites“ verwendet. (Zeichenfolge, optional)
repo: Repository-Name. Erforderlich, wenn die Ebene „repository“ ist. (Zeichenfolge, optional)
repository_name: Repository-Name, nach dem Regelsuiten gefiltert werden sollen. Wird von der Methode „list_rule_suites“ auf Organisationsebene verwendet. (Zeichenfolge, optional)
rule_suite_id: Regelsuiten-ID. Erforderlich für die Methode „get_rule_suite“. (Zahl, optional)
rule_suite_result: Das Regelsuitenergebnis, nach dem gefiltert werden soll. Wird von der Methode „list_rule_suites“ verwendet. (Zeichenfolge, optional)
ruleset_id: Regelsatz-ID. Erforderlich für die Methode „get“. (Zahl, optional)
time_period: Der Zeitraum, nach dem Regelsuiten gefiltert werden sollen. Wird von der Methode „list_rule_suites“ verwendet. (Zeichenfolge, optional)
Issues
add_issue_comment – Kommentar zu Issue oder Pull-Request hinzufügen
OAuth-Challenge-Bereiche: repo
body: Kommentarinhalt. Erforderlich, sofern keine Reaktion angegeben ist. (Zeichenfolge, 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 das Issue oder den Pull-Request selbst zu reagieren. Kann nicht mit body kombiniert werden. (Ganzzahl, optional)
issue_number: Issue- oder Pull-Request-Nummer, zu der ein Kommentar hinzugefügt 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, und closed_by_pull_requests fasst die Pull-Requests zusammen, die so konfiguriert sind, dass sie das Issue als total_count schließen, plus bis zu 5 references.
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 – Die dem Issue zugewiesenen Labels abrufen.
(Zeichenfolge, erforderlich)
owner: Der Besitzer des Repositorys (Zeichenfolge, erforderlich)
page: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Der Name des Repositorys (Zeichenfolge, erforderlich)
issue_write – Issue/Pull-Request erstellen oder aktualisieren
assignees: Benutzernamen, die diesem Issue zugewiesen werden sollen (Zeichenfolge[], optional)
body: Inhalt des Issue-Textes (Zeichenfolge, optional)
duplicate_of: Issue-Nummer, von der dieses Issue ein Duplikat ist. Erforderlich, wenn state_reason „duplicate“ ist. (Zahl, optional)
issue_fields: Issue-Feldwerte, die festgelegt oder gelöscht werden sollen. Jedes Element erfordert „field_name“ und genau eines von „value“, „field_option_name“ oder „delete: true“. (Objekt[], optional)
issue_number: Zu aktualisierende Issue-Nummer (Zahl, optional)
labels: Labels, die auf dieses Issue angewendet werden sollen (Zeichenfolge[], optional)
method: Schreiboperation, die für ein einzelnes Issue ausgeführt werden soll.
Optionen sind:
„create“ – erstellt ein neues Issue.
„update“ – aktualisiert ein vorhandenes Issue.
(Zeichenfolge, erforderlich)
parent_issue_number: Issue-Nummer des übergeordneten Issues. Nur verwendet, wenn die Methode „create“ ist, und kann nicht mit issue_fields kombiniert werden. Das neue Issue wird erstellt und in derselben Operation an dieses übergeordnete Issue angehängt. (Zahl, optional)
parent_owner: Repository-Besitzer des übergeordneten Issues. Muss mit parent_repo angegeben werden. Lassen Sie beide weg, um owner und repo zu verwenden. Nur verwendet, wenn die Methode „create“ ist und parent_issue_number angegeben ist. (Zeichenfolge, optional)
parent_repo: Repository-Name des übergeordneten Issues. Muss mit parent_owner angegeben werden. Lassen Sie beide weg, um owner und repo zu verwenden. Nur verwendet, wenn die Methode „create“ ist und parent_issue_number angegeben ist. (Zeichenfolge, optional)
state_reason: Grund für die Statusänderung. Wird ignoriert, sofern der Status nicht geändert wird. (Zeichenfolge, optional)
title: Issue-Titel (Zeichenfolge, optional)
type: Typ dieses Issues. Bei Aktualisierungen null übergeben, um den aktuellen Typ zu entfernen. Nur verwenden, wenn Issuetypen für dieses Repository aktiviert sind. Verwenden Sie list_issue_types, um gültige Typwerte für dieses Repository oder dessen Besitzerorganisation zu erhalten. Wenn das Repository keine Issuetypen unterstützt, lassen Sie diesen Parameter weg. (Zeichenfolge | null, optional)
list_issue_fields – Issue-Felder auflisten
OAuth-Challenge-Bereiche: repo, read:org
owner: Der Kontobesitzer des Repositorys oder der Organisation. Der Name ist nicht case-sensitiv. (Zeichenfolge, erforderlich)
repo: Der Name des Repositorys. Wenn angegeben, werden Felder für dieses spezifische Repository zurückgegeben (von seiner Organisation geerbt). Wenn weggelassen, werden direkt Organisationsebenen-Felder zurückgegeben. (Zeichenfolge, optional)
owner: Der Kontobesitzer des Repositorys oder der Organisation. (Zeichenfolge, erforderlich)
repo: Der Name des Repositorys. Wenn angegeben, werden Issuetypen für dieses spezifische Repository zurückgegeben. Wenn weggelassen, werden direkt Organisationsebenen-Issuetypen zurückgegeben. (Zeichenfolge, optional)
list_issues – Issues auflisten
OAuth-Challenge-Bereiche: repo
after: Cursor für die Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (Zeichenfolge, optional)
direction: Sortierrichtung. Wenn angegeben, muss auch „orderBy“ angegeben werden. (Zeichenfolge, optional)
field_filters: Nach benutzerdefinierten Issue-Feldwerten filtern. Jeder Eintrag nimmt einen field_name und einen Wert; der Server sucht das Feld und wandelt den Wert in seinen Typ um (Name einer Einzelauswahloption, Text, Zahl oder Datum im Format JJJJ-MM-TT). (Objekt[], optional)
fields: Teilmenge der Felder, die für jedes Issue zurückgegeben werden sollen. Wenn weggelassen, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen; insbesondere das Weglassen von „body“ und „field_values“ reduziert die größten Datenmengen pro Ergebnis. (Zeichenfolge[], optional)
labels: Nach Labels filtern (Zeichenfolge[], optional)
orderBy: Issues nach Feld sortieren. Wenn angegeben, muss auch „direction“ angegeben werden. (Zeichenfolge, optional)
since: Nach Datum filtern (ISO-8601-Zeitstempel) (Zeichenfolge, optional)
state: Nach Status filtern; standardmäßig werden sowohl offene als auch geschlossene Issues zurückgegeben, wenn nicht angegeben (Zeichenfolge, optional)
search_issues - Issues suchen
OAuth Challenge Scopes: repo
fields: Teilmenge der Felder, die für jedes Issue-Ergebnis zurückgegeben werden sollen. Wenn nicht angegeben, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen; insbesondere das Weglassen von 'body', 'reactions' und 'labels' reduziert die größten Datenmengen pro Ergebnis. (string[], optional)
order: Sortierreihenfolge (string, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Issues für dieses Repository aufgelistet. (string, optional)
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
query: Die Suchanfrage als natürliche Sprache. Wenn der Benutzer alternative Formulierungen angibt, nehmen Sie diese als einfache Wörter auf, anstatt sie mit OR zu verknüpfen. (string, erforderlich)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Issues für dieses Repository aufgelistet. (string, optional)
sort: Sortierfeld nach Anzahl der Übereinstimmungen von Kategorien, standardmäßig beste Übereinstimmung (string, optional)
sub_issue_write - Unter-Issue ändern
OAuth Challenge Scopes: repo
after_id: Die ID des Unter-Issues, das danach priorisiert werden soll (entweder after_id ODER before_id sollte angegeben werden) (number, optional)
before_id: Die ID des Unter-Issues, das davor priorisiert werden soll (entweder after_id ODER before_id sollte angegeben werden) (number, optional)
issue_number: Die Nummer des übergeordneten Issues (number, erforderlich)
method: Die Aktion, die an einem einzelnen Unter-Issue ausgeführt werden soll
Optionen sind:
'add' - fügt ein Unter-Issue zu einem übergeordneten Issue in einem GitHub-Repository hinzu.
'remove' - entfernt ein Unter-Issue aus einem übergeordneten Issue in einem GitHub-Repository.
'reprioritize' - ändert die Reihenfolge von Unter-Issues innerhalb eines übergeordneten Issues in einem GitHub-Repository. 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 Issue zu verschieben, verwenden Sie add mit replace_parent=true; es gibt kein beschreibbares übergeordnetes Feld.
(string, erforderlich)
owner: Repository-Besitzer (string, erforderlich)
replace_parent: Wenn true, ersetzt das aktuelle übergeordnete Issue des Unter-Issues. Nur mit der Methode 'add' verwenden. (boolean, optional)
repo: Repository-Name (string, erforderlich)
sub_issue_id: Die ID des hinzuzufügenden Unter-Issues. Die ID ist nicht dasselbe wie die Issue-Nummer (number, erforderlich)
comment_id: Die numerische ID des Issue- oder Pull-Request-Konversationskommentars, der aktualisiert werden soll. Verwenden Sie keine Pull-Request-Review-Kommentar-ID. (integer, erforderlich)
owner: Repository-Besitzer (string, erforderlich)
repo: Repository-Name (string, erforderlich)
Labels
get_label - Ein bestimmtes Label aus einem Repository abrufen
OAuth Challenge Scopes: repo
name: Label-Name. (string, erforderlich)
owner: Repository-Besitzer (Benutzername oder Organisationsname) (string, erforderlich)
repo: Repository-Name (string, erforderlich)
label_write - Schreiboperationen an Repository-Labels
OAuth Challenge Scopes: repo
color: Label-Farbe als 6-stelliger Hex-Code ohne '#'-Präfix (z. B. 'f29513'). Erforderlich für 'create', optional für 'update'. (string, optional)
description: Beschreibungstext des Labels. Optional für 'create' und 'update'. (string, optional)
method: Auszuführende Operation: 'create', 'update' oder 'delete' (string, erforderlich)
name: Label-Name - erforderlich für alle Operationen (string, erforderlich)
new_name: Neuer Name für das Label (nur mit der Methode 'update' zum Umbenennen verwendet) (string, optional)
owner: Repository-Besitzer (Benutzername oder Organisationsname) (string, erforderlich)
repo: Repository-Name (string, erforderlich)
list_label - Labels aus einem Repository auflisten
OAuth Challenge Scopes: repo
after: Cursor für die Paginierung. Verwenden Sie den Cursor aus der vorherigen Antwort. (string, optional)
owner: Repository-Besitzer (Benutzername oder Organisationsname) - erforderlich für alle Operationen (string, erforderlich)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Repository-Name - erforderlich für alle Operationen (string, erforderlich)
Benachrichtigungen
dismiss_notification - Benachrichtigung verwerfen
OAuth Challenge Scopes: notifications
state: Der neue Status der Benachrichtigung (read/done) (string, erforderlich)
threadID: Die ID des Benachrichtigungsthreads (string, erforderlich)
notificationID: Die ID der Benachrichtigung (string, erforderlich)
list_notifications - Benachrichtigungen auflisten
OAuth Challenge Scopes: notifications
before: Nur Benachrichtigungen anzeigen, die vor dem angegebenen Zeitpunkt aktualisiert wurden (ISO-8601-Format) (string, optional)
filter: Benachrichtigungen filtern, Standard verwenden, sofern nicht angegeben. Gelesene Benachrichtigungen sind solche, die vom Benutzer bereits bestätigt wurden. Teilnehmende Benachrichtigungen sind solche, an denen der Benutzer direkt beteiligt ist, z. B. Issues oder Pull Requests, die er kommentiert oder erstellt hat. (string, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Benachrichtigungen für dieses Repository aufgelistet. (string, optional)
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Benachrichtigungen für dieses Repository aufgelistet. (string, optional)
since: Nur Benachrichtigungen anzeigen, die nach dem angegebenen Zeitpunkt aktualisiert wurden (ISO-8601-Format) (string, optional)
manage_notification_subscription - Benachrichtigungsabonnement verwalten
OAuth Challenge Scopes: notifications
action: Auszuführende Aktion: ignore, watch oder delete des Benachrichtigungsabonnements. (string, erforderlich)
notificationID: Die ID des Benachrichtigungsthreads. (string, erforderlich)
manage_repository_notification_subscription - Repository-Benachrichtigungsabonnement verwalten
OAuth Challenge Scopes: notifications
action: Auszuführende Aktion: ignore, watch oder delete des Repository-Benachrichtigungsabonnements. (string, erforderlich)
owner: Der Kontobesitzer des Repositorys. (string, erforderlich)
repo: Der Name des Repositorys. (string, erforderlich)
mark_all_notifications_read - Alle Benachrichtigungen als gelesen markieren
OAuth Challenge Scopes: notifications
lastReadAt: Beschreibt den letzten Zeitpunkt, zu dem Benachrichtigungen geprüft wurden (optional). Standard: Jetzt (string, optional)
owner: Optionaler Repository-Besitzer. Wenn zusammen mit repo angegeben, werden nur Benachrichtigungen für dieses Repository als gelesen markiert. (string, optional)
repo: Optionaler Repository-Name. Wenn zusammen mit owner angegeben, werden nur Benachrichtigungen für dieses Repository als gelesen markiert. (string, optional)
Organisationen
search_orgs - Organisationen suchen
OAuth Challenge Scopes: read:org
order: Sortierreihenfolge (string, optional)
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
query: Suchanfrage für Organisationen. Beispiele: 'microsoft', 'location:california', 'created:>=2025-01-01'. Die Suche wird automatisch auf type:org eingegrenzt. (string, erforderlich)
sort: Sortierfeld nach Kategorie (string, optional)
Projekte
projects_get - Details von GitHub-Projektenressourcen abrufen
OAuth Challenge Scopes: read:project
field_id: Die ID des Felds. Erforderlich für die Methode 'get_project_field'. (number, 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 zu Feld-IDs aufgelöst – übergeben Sie dies anstelle von 'fields', wenn Sie nur die menschenlesbaren Namen kennen. Schließt sich gegenseitig mit 'fields' aus – geben Sie eines an, nicht beide. 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 ist, wird nur das Titelfeld aufgenommen. Schließt sich gegenseitig mit 'field_names' aus – geben Sie eines an, nicht beide. 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'. (number, optional)
method: Die auszuführende Methode (string, erforderlich)
owner: Der Besitzer (Benutzer- oder Organisationslogin). Der Name ist nicht case-sensitiv. (string, optional)
owner_type: Besitzertyp (user oder org). Wenn nicht angegeben, wird er automatisch erkannt. (string, optional)
project_number: Die Nummer des Projekts. (number, optional)
status_update_id: Die Knoten-ID der Projektstatusaktualisierung. Erforderlich für die Methode 'get_project_status_update'. (string, optional)
view_id: Die Knoten-ID der Projektansicht. Erforderlich für die Methode 'get_project_view'. (string, optional)
after: Vorwärts-Paginierungscursor von der vorherigen Seite pageInfo.nextCursor. (string, optional)
before: Rückwärts-Paginierungscursor von der vorherigen Seite pageInfo.prevCursor (selten). (string, optional)
field_names: Feldnamen, die beim Auflisten von Projektelementen eingeschlossen werden sollen (z. B. ["Status", "Priorität"]). Werden serverseitig zu Feld-IDs aufgelöst – übergeben Sie dies anstelle von 'fields', wenn Sie nur die menschenlesbaren 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 nur eines an, nicht beide. Wird nur für die Methode 'list_project_items' verwendet. (string[], optional)
fields: Feld-IDs, die beim Auflisten von Projektelementen eingeschlossen werden sollen (z. B. ["102589", "985201"]). KRITISCH: Immer angeben, um Feldwerte zu erhalten. Ohne diese (und ohne 'field_names') werden nur Titel zurückgegeben. Schließt sich gegenseitig mit 'field_names' aus – geben Sie nur eines an, nicht beide. Wird nur für die Methode 'list_project_items' verwendet. (string[], optional)
method: Die auszuführende Aktion (string, erforderlich)
owner: Der Eigentümer (Benutzer- oder Organisationsanmeldung). Der Name ist nicht case-sensitiv. (string, erforderlich)
owner_type: Eigentümertyp (Benutzer oder Organisation). Wenn nicht angegeben, werden automatisch beide versucht. (string, optional)
perPage: Ergebnisse pro Seite (max. 50) (number, optional)
project_number: Die Nummer des Projekts. Erforderlich für die Methoden 'list_project_fields', 'list_project_items', 'list_project_views' und 'list_project_status_updates'. (number, optional)
query: Filter-/Abfragezeichenfolge. Für list_projects: nach Titeltext und Status filtern (z. B. "roadmap is:open"). Für list_project_items: erweiterte Filterung mit der GitHub-Projektfilter-Syntax. (string, optional)
projects_write - GitHub-Projekte verwalten
OAuth Challenge Scopes: project
body: Der Text der Statusaktualisierung (Markdown). Wird für die Methode 'create_project_status_update' verwendet. (string, optional)
field_name: Der Name des Iterationsfelds (z. B. 'Sprint'). Erforderlich für die Methode 'create_iteration_field'. (string, optional)
filter: Gespeicherter Ansichtsfilter; bei Aktualisierung weglassen, um ihn zu erhalten, oder null übergeben, um ihn zu löschen. (string | null, 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). (number, optional)
item_id: Die Projekt-Element-ID. Erforderlich für 'delete_project_item'. Für 'update_project_item' entweder item_id oder (item_owner + item_repo + issue_number) angeben, um das Element anhand des Issues aufzulösen. (number, optional)
item_owner: Der Eigentümer (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)
items: Die Elemente, die mit dem übergeordneten 'updated_field' aktualisiert werden sollen. Erforderlich für 'update_project_items'; bevorzugen Sie dies gegenüber dem Aufruf von 'update_project_item' in einer Schleife. Jeder Eintrag muss genau einer Referenzvariante entsprechen: 'node_id', numerische 'item_id' oder 'item_owner' + 'item_repo' + 'issue_number'. Limit: 50 Elemente pro Aufruf. (object[], optional)
iteration_duration: Dauer in Tagen für Iterationen des Felds (z. B. 7 für wöchentlich, 14 für zweiwöchentlich). Erforderlich für die Methode 'create_iteration_field'. (number, optional)
iterations: Benutzerdefinierte Iterationen für die Methode 'create_iteration_field'. Nur setzen, wenn Sie Iterationen mit unterschiedlichen Dauern, Pausen dazwischen oder spezifischen Titeln benötigen. Andernfalls weglassen: GitHub erstellt automatisch drei Iterationen von 'iteration_duration' Tagen ab 'start_date', was für die meisten Fälle die richtige Wahl ist. (object[], optional)
layout: Ansichtslayout; erforderlich beim Erstellen einer Ansicht. (string, optional)
method: Die auszuführende Methode (string, erforderlich)
name: Ansichtsname; erforderlich beim Erstellen einer Ansicht. (string, optional)
owner: Der Projekteigentümer (Benutzer- oder Organisationsanmeldung). Der Name ist nicht case-sensitiv. (string, erforderlich)
owner_type: Eigentümertyp (Benutzer oder Organisation). 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'. (number, 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. (number, optional)
start_date: Startdatum im Format YYYY-MM-DD. 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 YYYY-MM-DD. 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: Das anzuwendende Feld/der anzuwendende Wert, unter Verwendung von {"id": 123, "value": ...} oder {"name": "Status", "value": ...}; null löscht das Feld. Erforderlich für 'update_project_item' und 'update_project_items', wobei ein übergeordnetes Feld/übergeordneter Wert für jedes Element in einem Batch gilt. Für 'update_project_item' SINGLE_SELECT-Felder akzeptiert die Namensform Optionsnamen; die ID-Form erwartet eine Options-ID. (object, optional)
view_id: Projektansichts-Knoten-ID für Aktualisierung oder Löschung; muss zu owner/project_number gehören. (string, optional)
visible_field_names: Geordnete Projektfeldnamen, die beim Erstellen angezeigt oder bei Aktualisierung ersetzt werden sollen; bei Aktualisierung weglassen, um sie zu erhalten, oder [] übergeben, um zurückzusetzen. Schließt sich gegenseitig mit visible_fields aus. Roadmap akzeptiert nur []. (string[], optional)
visible_fields: Geordnete Projektfeld-Datenbank-IDs, die beim Erstellen angezeigt oder bei Aktualisierung ersetzt werden sollen; bei Aktualisierung weglassen, um sie zu erhalten, oder [] übergeben, um zurückzusetzen. Schließt sich gegenseitig mit visible_field_names aus. Roadmap akzeptiert nur []. (string[], optional)
Pull Requests
add_comment_to_pending_review - Review-Kommentar zur neuesten ausstehenden Pull-Request-Überprüfung des Anforderers hinzufügen
OAuth Challenge Scopes: 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 (number, optional)
side: Die Seite des Diffs, auf der 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 (number, 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 zu Pull-Request-Kommentar hinzufügen
OAuth Challenge Scopes: repo
body: Der Text der Antwort. Erforderlich, sofern keine Reaktion angegeben ist. (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_...). (number, 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
OAuth Challenge Scopes: repo
base: Nach Basis-Branch filtern (string, optional)
direction: Sortierrichtung (string, optional)
fields: Teilmenge der Felder, die für jeden Pull Request zurückgegeben werden sollen. Wenn weggelassen, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen; das Weglassen von 'body' reduziert insbesondere die größten Daten pro Ergebnis. (string[], optional)
head: Nach Head-Benutzer/Organisation und Branch filtern (string, optional)
pull_request_read – Details zu einem einzelnen Pull Request abrufen
OAuth Challenge Scopes: repo
after: Cursor für die Paginierung, wird nur von der Methode get_review_comments verwendet. Übergeben Sie den endCursor aus dem PageInfo der vorherigen Seite, um die nächste Seite abzurufen. (string, optional)
method: Aktion, die angibt, 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 – Den kombinierten Commit-Status eines Head-Commits in einem Pull Request abrufen.
get_files – Die Liste der in einem Pull Request geänderten Dateien abrufen. Mit Paginierungsparametern verwenden, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_commits – Die Liste der Commits in einem Pull Request abrufen. Mit Paginierungsparametern verwenden, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_review_comments – Review-Threads zu einem Pull Request abrufen. Jeder Thread enthält logisch gruppierte Review-Kommentare, die während Pull-Request-Reviews an derselben Codestelle erstellt wurden. Gibt Thread-Metadaten und Kommentare mit nullable aktuellen und ursprünglichen Zeilenbereichskoordinaten (line, start_line, original_line, original_start_line) zurück. Aktuelle Koordinaten werden weggelassen, wenn sie nicht verfügbar sind, z. B. bei veralteten Kommentaren. Verwenden Sie cursor-basierte Paginierung (perPage, after), um die Ergebnisse zu steuern.
get_reviews – Die Reviews zu einem Pull Request abrufen. Wenn nach Review-Kommentaren gefragt wird, verwenden Sie die Methode get_review_comments. Mit Paginierungsparametern verwenden, um die Anzahl der zurückgegebenen Ergebnisse zu steuern.
get_comments – Kommentare zu einem Pull Request abrufen. Verwenden Sie dies, wenn der Benutzer nicht speziell Review-Kommentare möchte. Mit Paginierungsparametern verwenden, 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 Checks, die auf dem PR ausgeführt werden.
(string, erforderlich)
owner: Repository-Besitzer (string, erforderlich)
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
threadId: Die Knoten-ID des Review-Threads (z. B. PRRT_kwDOxxx). Erforderlich für die Methoden resolve_thread und unresolve_thread. Thread-IDs von pull_request_read mit der Methode get_review_comments abrufen. (string, optional)
search_pull_requests – Pull Requests durchsuchen
OAuth Challenge Scopes: repo
fields: Teilmenge der Felder, die für jedes Pull-Request-Ergebnis zurückgegeben werden sollen. Wenn weggelassen, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen; das Weglassen von 'body', 'reactions' und 'labels' reduziert insbesondere die größten Daten pro Ergebnis. (string[], optional)
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 die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
query: Suchanfrage unter Verwendung der GitHub-Suchsyntax für Pull Requests (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 Übereinstimmungen von Kategorien, standardmäßig beste Übereinstimmung (string, optional)
update_pull_request – Pull Request bearbeiten
OAuth Challenge Scopes: repo
MCP App UI: ui://github-mcp-server/pr-edit
base: Neuer Basis-Branch-Name (string, optional)
body: Neue Beschreibung (string, optional)
draft: Pull Request als Entwurf markieren (true) oder für die Überprüfung bereit machen (false) (boolean, optional)
maintainer_can_modify: Bearbeitungen durch Maintainer zulassen (boolean, optional)
owner: Repository-Besitzer (string, erforderlich)
pullNumber: Pull-Request-Nummer, die aktualisiert werden soll (number, erforderlich)
repo: Repository-Name (string, erforderlich)
reviewers: GitHub-Benutzernamen oder ORG/team-slug-Team-Reviewer, von denen Reviews angefordert werden sollen (string[], optional)
branch: Name für den neuen Branch (string, erforderlich)
from_branch: Quell-Branch (standardmäßig der Standard-Branch des Repos) (string, optional)
owner: Repository-Besitzer (string, erforderlich)
repo: Repository-Name (string, erforderlich)
create_or_update_file – Datei erstellen oder aktualisieren
OAuth Challenge Scopes: repo, workflow
allow_symlink_write: Auf true setzen, um einen symbolischen Link selbst zu aktualisieren; der Inhalt muss dessen neuer Zielpfad sein. (boolean, optional)
branch: Branch, in dem die Datei erstellt/aktualisiert werden soll (string, erforderlich)
content: Inhalt der Datei, genau wie er nach dem Schreiben erscheinen soll. Nicht base64-kodieren; dieser Server übernimmt das vor dem Aufruf der REST-API. (string, erforderlich)
message: Commit-Nachricht (string, erforderlich)
owner: Repository-Besitzer (Benutzername oder Organisation) (string, erforderlich)
path: Pfad, an dem die Datei erstellt/aktualisiert werden soll (string, erforderlich)
repo: Repository-Name (string, erforderlich)
sha: Die Blob-SHA der zu ersetzenden Datei. Erforderlich, wenn die Datei bereits existiert. Rufen Sie sie mit get_file_contents unter Verwendung desselben Besitzers, Repos und Pfads ab, wobei ref auf den Branch-Wert dieses Tools gesetzt ist. (string, optional)
create_repository – Repository erstellen
OAuth Challenge Scopes: repo
autoInit: Mit README initialisieren (boolean, optional)
organization: Organisation, in der das Repository erstellt werden soll (weglassen, um in Ihrem 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
OAuth Challenge Scopes: repo, workflow
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)
delete_repository – Repository löschen
OAuth Challenge Scopes: delete_repo, repo
owner: Repository-Besitzer (Benutzername oder Organisation) (string, erforderlich)
repo: Repository-Name (string, erforderlich)
fork_repository – Repository forken
OAuth Challenge Scopes: 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
OAuth Challenge Scopes: repo
detail: Detailgrad für geänderte Dateien. "none" lässt Statistiken und Dateien vollständig weg. "stats" (Standard) enthält Metadaten pro Datei: Dateiname, Status und Zeilenanzahl (additions, deletions, changes), ohne Patch-Inhalt. "full_patch" enthält zusätzlich den Unified-Diff-Inhalt für jede Datei und kann sehr groß sein. (string, optional)
owner: Repository-Besitzer (string, erforderlich)
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Repository-Name (string, erforderlich)
sha: Commit-SHA, Branch-Name oder Tag-Name (string, erforderlich)
get_file_contents – Datei- oder Verzeichnisinhalte abrufen
OAuth Challenge Scopes: repo
fields: Teilmenge der Felder, die für jeden Eintrag zurückgegeben werden sollen, wenn der Pfad ein Verzeichnis ist. Wenn weggelassen, werden alle Felder zurückgegeben. Wird ignoriert, wenn der Pfad eine einzelne Datei ist. Verwenden Sie dies, um die Antwortgröße beim Auflisten von Verzeichnissen zu reduzieren, wenn Sie nur bestimmte Felder benötigen, z. B. nur 'name' und 'type'. (string[], optional)
owner: Repository-Besitzer (Benutzername oder Organisation) (string, erforderlich)
path: Pfad zur Datei/zum Verzeichnis (string, optional)
ref: Akzeptiert optionale Git-Refs wie refs/tags/{tag}, refs/heads/{branch} oder refs/pull/{pr_number}/head (string, optional)
repo: Repository-Name (string, erforderlich)
sha: Akzeptiert optionale Commit-SHA. Wenn angegeben, wird sie anstelle von ref verwendet (string, optional)
get_latest_release – Neueste Version abrufen
OAuth Challenge Scopes: repo
owner: Repository-Besitzer (string, erforderlich)
repo: Repository-Name (string, erforderlich)
get_release_by_tag – Eine Version nach Tag-Namen abrufen
OAuth Challenge Scopes: 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
OAuth Challenge Scopes: repo
owner: Repository-Besitzer (string, erforderlich)
repo: Repository-Name (string, erforderlich)
tag: Tag-Name (string, erforderlich)
list_branches – Branches auflisten
OAuth Challenge Scopes: repo
owner: Repository-Besitzer (string, erforderlich)
page: Seitennummer für die Paginierung (min 1) (number, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min 1, max 100) (number, optional)
repo: Repository-Name (string, erforderlich)
list_commits - Commits auflisten
OAuth Challenge Scopes: repo
author: Autor-Benutzername oder E-Mail-Adresse, nach der Commits gefiltert werden sollen (Zeichenkette, optional)
fields: Teilmenge der Felder, die für jeden Commit zurückgegeben werden sollen. Wenn nicht angegeben, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen, z. B. nur 'sha' und 'html_url'. (Zeichenketten[], optional)
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 ist, werden Commits bis zu diesem SHA aufgelistet. (Zeichenkette, optional)
since: Nur Commits nach diesem Datum werden zurückgegeben (ISO-8601-Format: YYYY-MM-DDTHH:MM:SSZ oder YYYY-MM-DD) (Zeichenkette, optional)
until: Nur Commits vor diesem Datum werden zurückgegeben (ISO-8601-Format: YYYY-MM-DDTHH:MM:SSZ oder YYYY-MM-DD) (Zeichenkette, optional)
list_releases - Releases auflisten
OAuth Challenge Scopes: repo
fields: Teilmenge der Felder, die für jedes Release zurückgegeben werden sollen. Wenn nicht angegeben, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen; insbesondere das Weglassen von 'body' entfernt die größten Daten pro Release. (Zeichenketten[], 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' (Zeichenkette, optional)
fields: Teilmenge der Felder, die für jedes Code-Suchergebnis zurückgegeben werden sollen. Wenn nicht angegeben, werden alle Felder zurückgegeben. Verwenden Sie dies, um die Antwortgröße zu reduzieren, wenn Sie nur bestimmte Felder benötigen; insbesondere das Weglassen von 'repository' und 'text_matches' entfernt die größten Daten pro Ergebnis. (Zeichenketten[], optional)
order: Sortierreihenfolge für Ergebnisse (Zeichenkette, optional)
page: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
query: Suchabfrage (GitHub-Code-Such-REST). Implizites UND zwischen Begriffen; unterstützt OR, NOT und "quoted phrase" für exakte Übereinstimmung. Qualifizierer: repo:owner/repo, org:, user:, language:, path:dir (Präfix-Übereinstimmung), filename:exact.ext, extension:, in:file, in:path, size:, is:archived, is:fork. Max. 256 Zeichen. Beispiele: WithContext language:go org:github; "package main" repo:o/r; func extension:go path:cmd repo:o/r; NOT TODO language:go repo:o/r. (Zeichenkette, erforderlich)
page: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
query: Commit-Suchabfrage (GitHub-Commit-Such-REST). Durchsucht Commit-Nachrichten nur auf dem Standard-Branch. Eingrenzen der Suche mit repo:owner/repo, org: oder user: (Abfragen ohne Bereichsqualifizierer stimmen mit ganz GitHub überein und sind normalerweise nicht das, was Sie möchten). Andere 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: Nach Autor- oder Committer-Datum sortieren (Standard: beste Übereinstimmung) (Zeichenkette, optional)
search_repositories - Repositorys durchsuchen
OAuth Challenge Scopes: repo
minimal_output: Minimale Repository-Informationen zurückgeben (Standard: true). Bei false erhalten moderne Clients zusätzliche kuratierte Repository-Details, nicht das vollständige GitHub-API-Objekt. Legacy-Clients behalten vollständige GitHub-API-Repository-Objekte. (Boolesch, optional)
owner: Der Besitzer des Repositorys. (Zeichenkette, erforderlich)
page: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
repo: Der Name des Repositorys. (Zeichenkette, erforderlich)
resolution: Nach Auflö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)
Sicherheitshinweise
get_global_security_advisory - Einen globalen Sicherheitshinweis abrufen
owner: Der Besitzer des Repositorys. (Zeichenkette, erforderlich)
repo: Der Name des Repositorys. (Zeichenkette, erforderlich)
sort: Sortierfeld. (Zeichenkette, optional)
state: Nach Hinweisstatus filtern. (Zeichenkette, optional)
Stargazer
list_starred_repositories - Mit Stern markierte Repositorys auflisten
OAuth Challenge Scopes: repo
direction: Die Richtung, in die die Ergebnisse sortiert werden sollen. (Zeichenkette, optional)
page: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
perPage: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
sort: Wie die Ergebnisse sortiert werden sollen. Kann entweder 'created' (wann das Repository mit einem Stern markiert wurde) oder 'updated' (wann zuletzt in das Repository gepusht wurde) sein. (Zeichenkette, optional)
username: Benutzername, für den mit Stern markierte Repositorys aufgelistet werden sollen. Standard: der authentifizierte Benutzer. (Zeichenkette, optional)
Benutzer
- **search_users** - Benutzer suchen
- **OAuth Challenge Scopes**: `repo`
- `order`: Sortierreihenfolge (Zeichenkette, optional)
- `page`: Seitennummer für die Paginierung (min. 1) (Zahl, optional)
- `perPage`: Ergebnisse pro Seite für die Paginierung (min. 1, max. 100) (Zahl, optional)
- `query`: Suchanfrage für die Benutzersuche. Beispiele: 'john smith', 'location:seattle', 'followers:>100'. Die Suche wird automatisch auf type:user eingegrenzt. (Zeichenkette, erforderlich)
- `sort`: Benutzer nach Anzahl der Follower oder Repositories sortieren, oder danach, wann die Person GitHub beigetreten ist. (Zeichenkette, optional)
Zusätzliche Tools im Remote GitHub MCP Server
Copilot
create_pull_request_with_copilot - Aufgabe mit dem GitHub Copilot Coding Agent ausführen
owner: Repository-Besitzer. Du kannst den Besitzer erraten, aber bestätige ihn mit dem Benutzer, bevor du fortfährst. (Zeichenkette, erforderlich)
repo: Repository-Name. Du kannst den Repository-Namen erraten, aber bestätige ihn mit dem Benutzer, bevor du fortfährst. (Zeichenkette, erforderlich)
problem_statement: Detaillierte Beschreibung der auszuführenden Aufgabe (z. B. 'Implementiere eine Funktion, die X tut', 'Behebe Fehler Y' usw.) (Zeichenkette, erforderlich)
title: Titel für den Pull Request, der erstellt wird (Zeichenkette, erforderlich)
base_ref: Git-Referenz (z. B. Branch), von der der Agent seine Arbeit startet. Wenn nicht angegeben, wird der Standard-Branch des Repositories verwendet (Zeichenkette, optional)
Copilot Spaces
Authentifizierungshinweis
Fein granulierte PATs werden nicht durch die klassische PAT-Bereichsfilterung verborgen, daher können diese Tools auch dann angezeigt werden, wenn das Token sie nicht verwenden kann.
Für organisationseigene Spaces müssen fein granulierte PATs auf der besitzenden Organisation installiert sein und organization_copilot_spaces: read enthalten.
Wenn ein organisationseigener Space repository-gestützte Ressourcen enthält, muss das Token auch Zugriff auf jedes referenzierte Repository haben, sonst kann der Space als nicht gefunden behandelt werden.
get_copilot_space - Copilot Space abrufen
owner: Der Besitzer des Spaces. (Zeichenkette, erforderlich)
name: Der Name des Spaces. (Zeichenkette, erforderlich)
list_copilot_spaces - Copilot Spaces auflisten
GitHub Support Docs Suche
github_support_docs_search - Dokumentation abrufen, die für die Beantwortung von GitHub-Produkt- und Supportfragen relevant ist. Supportthemen umfassen: GitHub Actions Workflows, Authentifizierung, GitHub Supportanfragen, Pull-Request-Praktiken, Repository-Wartung, GitHub Pages, GitHub Packages, GitHub Discussions, Copilot Spaces
query: Eingabe vom Benutzer zu der Frage, die beantwortet werden muss. Dies ist die neueste rohe, unveränderte Benutzernachricht. Du solltest die Benutzernachricht IMMER so lassen, wie sie ist, und sie niemals ändern. (Zeichenkette, erforderlich)
Nur-Lese-Modus
Um den Server im Nur-Lese-Modus auszuführen, kannst du das --read-only-Flag verwenden. Dies bietet nur Lese-Tools an und verhindert Änderungen an Repositories, Issues, Pull Requests usw.
./github-mcp-server --read-only
Bei Verwendung von Docker kannst du den Nur-Lese-Modus als Umgebungsvariable übergeben:
Der Lockdown-Modus begrenzt den Inhalt, den 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 nicht betroffen, und Mitarbeiter behalten vollen Zugriff auf ihre eigenen Inhalte.
Der Lockdown-Modus ist ein Best-Effort-Inhaltsfilter, der das Risiko von Prompt-Injection aus nicht vertrauenswürdigen Repository-Inhalten (Issues, Pull Requests, Kommentare, Commits usw.) verringern soll. Er ist keine Autorisierungsgrenze: Er ändert nicht, was die zugrunde liegenden GitHub-Anmeldedaten lesen oder schreiben können, und Inhalte, die aus einer gefilterten Tool-Antwort zurückgehalten werden, können möglicherweise über andere Tools oder direkten GitHub-API-Zugriff mit denselben Anmeldedaten erreicht werden.
Als beabsichtigte Ausnahme werden Inhalte, die von einer kleinen Gruppe vertrauenswürdiger Bot-Konten (derzeit github-actions[bot] und copilot) verfasst wurden, unabhängig vom Schreibzugriff immer als sicher behandelt. Dies vermeidet das Filtern von routinemäßigen Automatisierungsausgaben (z. B. CI-generierte Commits oder Kommentare), die andernfalls im Lockdown-Modus zurückgehalten würden.
./github-mcp-server --lockdown-mode
Bei der Ausführung mit Docker setze die entsprechende Umgebungsvariable:
Im HTTP-Modus ist dieses Flag (oder GITHUB_LOCKDOWN_MODE) eine Obergrenze: Der X-MCP-Lockdown-Anfrageheader kann den Lockdown-Modus aktivieren, wenn der Betreiber dies nicht getan hat, aber er kann den Lockdown-Modus nicht deaktivieren, den der Betreiber bereits aktiviert hat. Siehe den Server-Konfigurationsleitfaden für Details.
Das Verhalten des Lockdown-Modus hängt vom aufgerufenen Tool ab.
Die folgenden Tools geben einen Fehler zurück, wenn dem Autor der Schreibzugriff fehlt:
issue_read:get
pull_request_read:get
pull_request_read:get_diff
pull_request_read:get_files
pull_request_read:get_commits
Die folgenden Tools 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 Tools 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 mit den Toolnamen als Schlüssel und den neuen
Beschreibungen als Werte enthalten. Zum Beispiel:
{
"TOOL_ADD_ISSUE_COMMENT_DESCRIPTION": "an alternative description",
"TOOL_CREATE_BRANCH_DESCRIPTION": "Create a new branch in a GitHub repository"
}
Du kannst einen Export der aktuellen Übersetzungen erstellen, indem du die Binärdatei mit
dem --export-translations-Flag ausführst.
Dieses Flag bewahrt alle Übersetzungen/Überschreibungen, die du vorgenommen hast, und fügt
gleichzeitig alle neuen Übersetzungen hinzu, die seit dem letzten Export zur Binärdatei
hinzugefügt wurden.
Du kannst auch ENV-Variablen verwenden, um die Beschreibungen zu überschreiben. Die Namen
der Umgebungsvariablen sind dieselben wie die Schlüssel in der JSON-Datei, mit dem Präfix
GITHUB_MCP_ und in Großbuchstaben.
Zum Beispiel, um das TOOL_ADD_ISSUE_COMMENT_DESCRIPTION-Tool zu überschreiben, kannst du
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 name- und
title-Felder 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 zwischen ihnen 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 bahnbrechenden Änderungen unterliegen. In Zukunft bieten wir möglicherweise Stabilität an; bitte melde ein Issue, wenn es einen Anwendungsfall gibt, bei dem dies wertvoll wäre.
Mitwirken
Beiträge sind willkommen. Bevor du einen Pull Request eröffnest, lies bitte den Mitwirkungsleitfaden für Anweisungen zu Einrichtung, Tests, Linting und Dokumentationsgenerierung.
Support
Für Hilfe bei der Verwendung des GitHub MCP Servers siehe den Support-Leitfaden. Wenn du einen Fehler gefunden hast oder eine Funktion anfragen möchtest, durchsuche bitte vorhandene Issues, bevor du ein neues eröffnest.
Sicherheit
Bitte melde Sicherheitslücken nicht über öffentliche Issues. Folge den Anweisungen in der Sicherheitsrichtlinie, um Schwachstellen verantwortungsvoll zu melden.
Lizenz
Dieses Projekt ist unter den Bedingungen der MIT Open Source Lizenz lizenziert. Bitte beziehe dich auf MIT für die vollständigen Bedingungen.