Connector für EntwicklungGitHub in Claude, ChatGPT und jedem MCP-Client. Für Ihr ganzes Team.
Repositories, Code, Issues, Pull Requests, Commits, Releases, Actions, Sicherheitswarnungen. Ein Token in Loopthink, ein Login pro Person, Rollen pro Tool und ein Audit-Eintrag für jeden Aufruf.
Kostenlos für 2 Connectors, ohne Karte · Pro 19 € · in der EU betrieben · 29 Lese-Tools, 3 Schreib-Tools standardmäßig aus
“Welche offenen PRs in acme/checkout warten seit mehr als drei Tagen auf ein Review?”
Drei Pull Requests warten länger als drei Tage:
| Pull Request | Autor | Geöffnet | Wartet seit |
|---|---|---|---|
| #482 Retry failed webhooks | m.huber | 12.10.2026 | 9 T |
| #479 Rework tax rounding | s.keller | 14.10.2026 | 7 T |
| #491 Add SEPA mandate check | l.nowak | 17.10.2026 | 4 T |
- nur lesend
- protokolliert
Ein Token rein, die Tools kommen raus.
GitHub ist der Ort, an dem der Code und die Arbeit darum herum liegen: Repositories, Pull Requests, die auf Review warten, Issues, Actions-Läufe, Releases und die Sicherheitswarnungen, die Dependabot und Code Scanning melden. Die Fragen sind alltäglich, „was ist letzte Woche rausgegangen“, „ist die Schwachstelle schon gepatcht“, „wer hat noch ein Review offen“, aber heute brauchen sie ein Dutzend Tabs oder jemanden aus der Entwicklung, der die Antwort vorliest.
Mit dem GitHub-Connector fragen Entwicklung, Produkt und Sicherheit in Claude oder ChatGPT und bekommen die Antwort aus der laufenden Organisation. Loopthink hält einen Fine-grained Personal Access Token, jede Person meldet sich mit ihrer eigenen Identität an, und jeder Aufruf wird unter ihrem Namen protokolliert. Der Token erreicht den KI-Client nie.
Neunundzwanzig Lese-Tools decken Repositories, Dateien, Trees und Codesuche, Issues und Pull Requests mit ihren Reviews und Kommentaren, Commits, Releases, Actions-Workflow-Läufe sowie Dependabot- und Code-Scanning-Warnungen ab. Die drei Schreib-Tools, ein Issue anlegen, ein Issue kommentieren und Labels setzen, bleiben aus, bis Sie sie für eine Rolle einschalten.
- Entwicklung
“Welche offenen Pull Requests in acme/checkout warten seit mehr als drei Tagen auf ein Review?”
Beantwortet von
list_pull_requests - Produkt
“Welche Issues mit dem Label bug wurden in acme/app seit dem 1. Oktober geschlossen?”
Beantwortet von
search_issues - Sicherheit
“Welche offenen Dependabot-Warnungen mit Schweregrad critical oder high haben wir in der gesamten Organisation?”
Beantwortet von
list_org_dependabot_alerts - Entwicklung
“Ist der Deploy-Workflow auf main diese Woche fehlgeschlagen? Liste die fehlgeschlagenen Läufe mit ihrem Auslöser.”
Beantwortet von
list_workflow_runs - Produkt
“Was steckt in Release 4.12 von acme/app? Fass die Release Notes in fünf Stichpunkten zusammen.”
Beantwortet von
list_releases - Entwicklung
“Lege in acme/app ein Issue mit dem Titel „Invoice PDF renders blank for EU customers“ an, mit den Schritten, die ich gerade beschrieben habe.”
Beantwortet von
create_issue
Was der GitHub-Connector kann.
| Tool | Was es tut | Zugriff | Standard |
|---|---|---|---|
| get_authenticated_user | Returns the token owner's profile (login, name, company). Use to know who 'me' is. | Lesen | An |
| search_repositories | Searches repositories with GitHub search syntax in q, e.g. 'org:acme invoice', 'user:octocat language:typescript', 'org:acme pushed:>2026-09-01'. | Lesen | An |
| list_org_repositories | Lists repositories of an organization. Page through with page/per_page. | Lesen | An |
| get_repository | Gets one repository: description, default_branch, visibility, open_issues_count, topics, pushed_at. | Lesen | An |
| get_readme | Gets the README of a repository. The 'content' field is base64 encoded; decode it to read the text. | Lesen | An |
| search_issues | Searches issues and pull requests across repos with GitHub search syntax, e.g. 'repo:acme/app is:issue is:open label:bug', 'org:acme is:pr is:merged merged:>=2026-10-01', 'org:a… | Lesen | An |
| search_commits | Searches commits, e.g. 'repo:acme/app fix invoice', 'org:acme author:octocat committer-date:>2026-10-01'. | Lesen | An |
| list_my_issues | Lists issues and pull requests across all repos that involve the token user (assigned by default). filter: assigned, created, mentioned, subscribed, repos, all. | Lesen | An |
| list_repository_issues | Lists issues of one repository (the result also contains pull requests; they have a 'pull_request' key). Filter by state, labels, assignee, creator, milestone, since. | Lesen | An |
| get_issue | Gets one issue (or PR as issue) with title, body, state, labels, assignees, comments count. | Lesen | An |
| list_issue_comments | Lists comments on an issue or pull request conversation, oldest first. | Lesen | An |
| list_repository_labels | Lists labels defined in a repository. Use before add_labels_to_issue or to know which label filters exist. | Lesen | An |
| list_pull_requests | Lists pull requests of a repository. Filter by state, base branch, head (user:branch). | Lesen | An |
| get_pull_request | Gets one pull request: title, body, state, merged, mergeable, additions/deletions, changed_files, requested reviewers. | Lesen | An |
| list_pull_request_reviews | Lists reviews of a pull request (reviewer, state APPROVED / CHANGES_REQUESTED / COMMENTED, body). | Lesen | An |
| list_commits | Lists commits of a branch, newest first. Filter by path, author, since/until (YYYY-MM-DDTHH:MM:SSZ). | Lesen | An |
| get_commit | Gets one commit with message, author, stats and changed files (paginated for large commits). | Lesen | An |
| list_releases | Lists releases of a repository (tag, name, release notes body, published_at), newest first. | Lesen | An |
| get_latest_release | Gets the latest published (non-draft, non-prerelease) release of a repository. | Lesen | An |
| list_workflow_runs | Lists GitHub Actions runs (CI/CD builds, deployments) of a repository. Filter by branch, event, status (e.g. | Lesen | An |
| get_file_contents | Reads a file or lists a directory in a repository. For a file the 'content' field is base64 encoded; decode it to read the text (files up to 1 MB). | Lesen | An |
| get_repository_tree | Lists every file and directory path of a branch, tag or commit at once (recursive), with type blob/tree, size and sha. Use it to find files before reading them with get_file_con… | Lesen | An |
| search_code | Searches file contents and paths on the default branch with GitHub code search syntax, e.g. 'InvoiceService repo:acme/app', 'createOrder org:acme language:typescript', 'TODO pat… | Lesen | An |
| list_dependabot_alerts | Lists Dependabot alerts (vulnerable dependencies) of a repository, newest first: package, severity, advisory summary, CVE/GHSA ids, vulnerable and patched versions, state. Filte… | Lesen | An |
| get_dependabot_alert | Gets one Dependabot alert with the full advisory (description, CVSS, references), the affected manifest and dismissal details. | Lesen | An |
| list_org_dependabot_alerts | Lists Dependabot alerts across all repositories of an organization the token can see. Needs the token owner to be an organization owner or security manager. | Lesen | An |
| list_code_scanning_alerts | Lists code scanning alerts (CodeQL or third-party static analysis findings) of a repository: rule, severity, tool, state, file location of the latest instance. Defaults to the d… | Lesen | An |
| get_code_scanning_alert | Gets one code scanning alert with the rule description, help text, tool and the most recent instance (file, lines, message). | Lesen | An |
| list_org_code_scanning_alerts | Lists code scanning alerts on the default branches of all repositories of an organization. Needs the token owner to be an organization owner or security manager. | Lesen | An |
| create_issue | WRITE: Creates a new issue in a repository. labels/assignees are only applied if the token user has push access (otherwise silently dropped). | Schreiben | Aus |
| add_issue_comment | WRITE: Adds a comment to an issue or pull request conversation. Triggers notifications. | Schreiben | Aus |
| add_labels_to_issue | WRITE: Adds labels to an issue or PR (keeps existing labels). Use list_repository_labels for valid names. | Schreiben | Aus |
Schreib-Tools sind für jede Rolle aus, bis Sie sie einschalten, ein Tool für eine Rolle. Die Namen und Beschreibungen sind das, was das Modell sieht, deshalb bleiben sie englisch; es bekommt außerdem die vollständige Parameterbeschreibung jedes Tools.
So kommen Sie an den GitHub-Token.
Fünf Minuten, einmalig. Niemand in Ihrem Team sieht ihn je.
- 1
Auf GitHub auf das Profilbild klicken > Settings > Developer settings > Personal access tokens > Fine-grained tokens > Generate new token.
- 2
Namen und Ablaufdatum setzen. Unter „Resource owner“ die Organisation wählen (das kann eine Freigabe durch einen Admin erfordern; der Token bleibt bis dahin „pending“).
- 3
Unter „Repository access“ die Option „Only select repositories“ wählen und die Repos auswählen, die Loopthink lesen darf.
- 4
Unter „Permissions“ die unten aufgeführten Repository-Berechtigungen auf Read-only setzen, dann „Generate token“ und den Token kopieren.
- 5
In Loopthink fügen Sie GitHub aus dem Katalog hinzu und fügen den Token ein. Eine Minute später sieht Ihr Team die Tools.
Ein Fine-grained Token handelt als der Benutzer, der ihn erstellt hat, und ist auf einen Resource Owner (Benutzer oder Organisation) begrenzt. Für organisationsweiten Zugriff ist ein Machine User oder eine GitHub App sauberer. Organisationen können eine maximale Token-Laufzeit erzwingen.
Was wir in GitHub zu maskieren empfehlen.
Jeder Commit, jedes Issue und jeder Kommentar trägt seinen Autor: Name, Login und E-Mail an Commits und Committern, das Login der Person, die eine Warnung verworfen hat, und der Freitext in Issue-Beschreibungen, Kommentaren und Warnmeldungen. Die vorgeschlagenen Felder maskieren genau das und behalten Titel, Status, Labels, Daten, Dateipfade, Diff-Statistiken und Schweregrade, sodass eine Produkt-Rolle sehen kann, dass im Sprint 14 Bugs geschlossen wurden, ohne zu sehen, wer welchen Kommentar geschrieben hat.
- author.email
- committer.email
- commit.author.email
- commit.committer.email
- name
- commit.author.name
- login
- body
- dismissed_by.login
- dismissed_comment
- most_recent_instance.message.text
Was GitHubs eigener MCP-Server Ihnen nicht gibt.
- Ein Login pro Person in jedem MCP-Client: Das Loopthink-Audit zeigt, wer gefragt hat, nicht einen geteilten Token.
- Tools pro Rolle: Produkt liest Issues und Releases, niemand außerhalb der Entwicklung kann eines anlegen oder labeln.
- Maskierung von Autorennamen, E-Mails und Kommentartexten, bevor die Antwort die EU verlässt.
- Schreib-Tools standardmäßig aus, pro Tool und Rolle schaltbar.
- Derselbe Server in Claude, ChatGPT und Langdock, einmal verwaltet.
GitHub und Loopthink
- Welche Berechtigungen braucht der Fine-grained Token?
- Metadata wird automatisch gesetzt. Geben Sie Contents, Issues, Pull requests und Actions Lesezugriff für die alltäglichen Tools; Dependabot alerts und Code scanning alerts nur dann Lesezugriff, wenn eine Rolle die Sicherheits-Tools nutzen soll. Stellen Sie Issues erst auf Read and write, wenn Sie create_issue, add_issue_comment oder add_labels_to_issue einschalten; die organisationsweiten Warnungs-Tools setzen zusätzlich voraus, dass der Token-Inhaber Organization Owner oder Security Manager ist.
- Der Token steht nach dem Erstellen auf „pending“. Warum?
- Ist der Resource Owner eine Organisation, muss ein Organisations-Admin den Token unter Umständen erst freigeben; bis dahin bleibt er pending. Organisationen können außerdem eine maximale Token-Laufzeit erzwingen, notieren Sie sich also das Ablaufdatum und fügen Sie den erneuerten Token in den Connector ein, wenn er abläuft.
- Wir haben viele Repositories. Brauchen wir einen Token pro Repository?
- Nein. Wählen Sie unter Repository access die Option Only select repositories und haken Sie die Repos ab, die Loopthink lesen darf, oder alle Repositories des Owners. Ein Fine-grained Token handelt als der Benutzer, der ihn erstellt hat, und ist auf einen Resource Owner begrenzt; für organisationsweiten Zugriff ist ein Machine User oder eine GitHub App sauberer. Die Codesuche ist auf 10 Anfragen pro Minute begrenzt, andere Suchen auf 30, was das Modell berücksichtigt, indem es seine Abfragen eingrenzt.
- Braucht jedes Teammitglied einen eigenen GitHub-Account?
- Nein. Loopthink hält einen Schlüssel oder Token für GitHub. Ihre Leute melden sich mit ihrer eigenen Identität bei Loopthink an, und jeder Aufruf an GitHub wird unter ihrem Namen protokolliert. Die Lizenzen in GitHub bleiben, wie sie heute sind.
- Wo liegt der GitHub-Schlüssel?
- In Loopthink, verschlüsselt, in der EU. Er erreicht weder den KI-Client noch die Personen, die den Connector nutzen. Rotieren Sie ihn in GitHub, wann immer Sie wollen, und fügen Sie den neuen einmal ein.
- Kann jemand aus dem Chat heraus in GitHub schreiben?
- Nur, wenn Sie es einschalten. Schreibaktionen sind eine eigene Zeile in der Rechtematrix und für jede Rolle standardmäßig aus. Braucht eine Rolle ein Schreib-Tool, geben Sie genau dieses eine Tool genau dieser Rolle frei.
- Was sieht das Modell?
- Das Ergebnis des Tool-Aufrufs, nach der Maskierung. Felder, die Sie als personenbezogen markieren, etwa E-Mail-Adressen, Namen oder Kartendaten, werden maskiert, bevor die Antwort zu den KI-Client reist. Das Modell bekommt die Zahlen, nicht die Menschen.
- Was kostet es?
- Kostenlos für eine Person und zwei Connectors, ohne Karte. Pro kostet 19 € im Monat für bis zu fünf Personen und jeden Connector auf dieser Seite, mit Rollen, feldgenauer Maskierung und 30 Tagen Audit-Log. Team kostet 49 € für zehn Personen und bringt Ihre eigenen REST-APIs und SQL-Datenbanken, Ihre eigene Domain und Ihren eigenen Identity Provider dazu. Kein Gespräch nötig.
Hängen Sie fest, oder fehlt ein Tool? Ein Mensch, der diesen Connector kennt, antwortet innerhalb eines Arbeitstags.
