DIE drei, DIE ZÄHLEN

Was er dem Agenten gibt

Repositories lesen und durchsuchen, Dateien holen, Commits und Bäume analysieren, Issues und Pull Requests anlegen und pflegen, Actions-Läufe auswerten, Code-Scanning-, Dependabot- und Secret-Scanning-Befunde einsammeln, Projects, Discussions, Notifications und Governance-Regeln bedienen. Das ist der Zustand eines Projekts, abfragbar in natürlicher Sprache.

Warum er vorn steht

Er ist der einzige Server hier, den man nicht lokal betreiben muss: der gehostete Endpunkt https://api.githubcopilot.com/mcp/ authentifiziert per OAuth, ohne dass ein Token auf der Platte landet. Und er ist der einzige, der das Kontextproblem, das alle MCP-Server haben, ausdrücklich als Design-Aufgabe behandelt.

Das Detail, das ihn gut macht

Toolsets statt Vollgas. Ohne Angabe laufen nur context, repos, issues, pull_requests, users; alles Übrige (Actions, Security, Projects, Governance … über 20 Gruppen) schaltet man einzeln zu — per --toolsets oder GITHUB_TOOLSETS. Dazu drei Schalter, die zeigen, dass hier über Risiko nachgedacht wurde:

• --read-only: nur lesende Tools, für alle, die keinen Agenten forcen lassen wollen.
• --lockdown-mode: filtert Inhalte aus öffentlichen Repos, deren Autoren keine Push-Rechte haben — eine bewusste, wenn auch nicht vollständige Bremse gegen Prompt-Injection aus fremden Issues und Kommentaren.
• Strukturierte Antworten (structuredContent) ab Protokoll-Version 2026-07-28, mit kompakten DTOs statt roher REST-Objekte — kleinerer Kontext, stabilere Felder.

Lektion für den MZP

Der MZP kann heute schon Toolsets: getCapabilities(include='minimal') und Themenschnitte existieren. Was fehlt, ist die Konsequenz — ein Auslieferungsprofil pro Seite, das festlegt, ob eine Variante Mensch-first oder Agent-minimal ist. Siehe Vorschlag 01.

Was er dem Agenten gibt

Aktuelle, versionsgenaue Dokumentation und Code-Beispiele für tausende Bibliotheken — direkt in den Kontext. Zwei Werkzeuge: resolve-library-id (Name → Context7-ID) und query-docs (ID + Frage → Dokumentation). Damit hört das Raten auf, welche Signatur eine Funktion vor zwei Major-Versionen hatte.

Warum er vorn steht

Er löst das teuerste Problem im KI-gestützten Programmieren: halluzinierte APIs. Und er tut es mit dem stimmigsten Vertriebsmodell im Feld — er lässt sich als Skill ohne MCP installieren (ctx7 setup) oder als Server betreiben, je nachdem, was der Client besser kann. Der Server hat die höchste Reichweite aller hier genannten Projekte.

Das Detail, das ihn gut macht

• Versionsbewusstsein: Nennst du „Next.js 16“ im Prompt, matcht Context7 die passende Fassung — nicht die, die im Trainingsstand zufällig aktuell war.
• Abkürzung durch die ID: /supabase/supabase im Prompt überspringt die Namenssuche komplett.
• Sprach-Ranking: language zieht Code-Beispiele in deiner Sprache nach vorn.
• Ehrliche Grenze: README und Server sind offen (MIT), Backend, Parser und Crawler sind es nicht — die Qualität der Einträge ist community-beigesteuert und ausdrücklich ohne Garantie.

Lektion für den MZP

Der MZP versioniert bereits (listVersions, rollbackArtifact) — aber die Capability-Beschreibung altert unabhängig von der Seite. Frieren wir zu jeder Version den passenden Fähigkeiten-Stand ein, bekommt ein Agent, der auf Version 3 pinnt, auch die Doku von Version 3. Siehe Vorschlag 03.

Was er dem Agenten gibt

Vollzugriff auf die Chrome DevTools: Performance-Traces aufzeichnen und in verwertbare Einsichten übersetzen, Netzwerkanfragen ansehen, Konsolenmeldungen samt source-mapped Stacktraces lesen, Screenshots machen und — über Puppeteer — zuverlässig im Browser handeln, mit automatischem Warten auf das Ergebnis jeder Aktion.

Warum er vorn steht

Weil er einem Agenten etwas gibt, das ihm sonst niemand gibt: das Innenleben einer laufenden Anwendung. Statische Analyse sagt, was der Code tun soll; DevTools sagt, was er tatsächlich tut. Und er kommt vom Chrome-Team selbst — der Betreiber ist genau der, der an einer guten Integration interessiert ist.

Das Detail, das ihn gut macht

• --slim: ein abgespecktes Toolset für einfache Browser-Aufgaben, damit die Schema-Flut nicht alles dominiert — Token-Ökonomie als Schalter, nicht als Versprechen.
• CrUX-Felddaten: echte Nutzererfahrung neben Labormessung — abschaltbar mit --no-performance-crux.
• Als Browser-Subagent baubar: wer eigenes Agent-Werkzeug baut, kann darauf aufsetzen; es gibt eine Referenzimplementierung (Gemini CLI).
• Ehrlich bei Telemetrie: Usage-Statistiken sind standardmäßig an — aber dokumentiert und per Flag, Env-Variable oder CI abschaltbar.

Lektion für den MZP

Der MZP prüft vorm Publizieren bereits im echten Browser: Erreichbarkeit, Konsolenfehler, Page-Exceptions, auf Wunsch Barrierefreiheit (axe-core). Es fehlt der Blick auf die Kosten: Ladezeit, Übertragungsvolumen, JS-Bytes. Siehe Vorschlag 06.