Google veröffentlicht Entwickler-Wissens-API und MCP-Server
(developers.googleblog.com)- Mit der Verbreitung von KI-basierten Entwicklungstools wird der präzise Zugriff auf aktuelle Entwicklerdokumentation immer wichtiger
- Google hat dafür die öffentliche Preview der Developer Knowledge API und eines Model Context Protocol (MCP)-Servers angekündigt
- Die API ermöglicht es, offizielle Entwicklerdokumentation von Google in maschinenlesbarem Markdown zu durchsuchen und abzurufen
- Der MCP-Server erlaubt es KI-Assistenten oder IDEs, Google-Dokumentation direkt zu lesen und Hilfe bei Problemlösung, Vergleichen und Implementierungsleitfäden zu bieten
- Beide Werkzeuge sind eine zentrale Infrastruktur, um Zuverlässigkeit und Aktualität in KI-Entwicklungsumgebungen sicherzustellen
Überblick über die Developer Knowledge API
- Die Developer Knowledge API bietet einen programmatischen Zugangsweg zu offizieller Entwicklerdokumentation von Google
- Statt auf Web Scraping oder veraltete Trainingsdaten angewiesen zu sein, lassen sich aktuelle Dokumente direkt durchsuchen und abrufen
- Zu den wichtigsten Funktionen gehören:
- Breite Dokumentationsabdeckung: darunter firebase.google.com, developer.android.com und docs.cloud.google.com
- Such- und Abruffunktionen: Relevante Dokumentationsseiten und Code-Snippets suchen und anschließend den vollständigen Markdown-Inhalt abrufen
- Schnelle Aktualisierungen: Während der öffentlichen Preview werden Dokumentänderungen innerhalb von 24 Stunden neu indexiert
MCP-Server und Integration mit KI-Tools
- Ein MCP-Server (Model Context Protocol) ist ein auf einem offenen Standard basierender Server, der KI-Assistenten einen sicheren Zugriff auf externe Datenquellen ermöglicht
- Wenn der Developer Knowledge MCP-Server mit einer IDE oder einem KI-Assistenten verbunden wird, kann diese bzw. dieser die Google-Entwicklerdokumentation direkt lesen
- Implementierungsleitfäden bereitstellen: zum Beispiel prüfen, wie sich Firebase-Push-Benachrichtigungen implementieren lassen
- Problemlösung unterstützen: nach Wegen suchen, den Maps-API-Fehler
ApiNotActivatedMapErrorzu beheben - Vergleichsanalysen durchführen: etwa Cloud Run und Cloud Functions für bestimmte Anwendungsfälle vergleichen
- Der MCP-Server ist mit verschiedenen KI-Tools und Assistenzsystemen kompatibel
So legt man los
- Die öffentliche Preview ist ab sofort verfügbar
- Auf der Credentials-Seite des Google-Cloud-Projekts einen API-Schlüssel für die Developer Knowledge API erstellen und Einschränkungen festlegen
- Nach der Installation der Google Cloud CLI den MCP-Server mit folgendem Befehl aktivieren
gcloud beta services mcp enable developerknowledge.googleapis.com --project=PROJECT_ID
- Die Tool-Konfigurationsdatei (z. B.
mcp_config.json,settings.json) anpassen, um die API-Verbindung einzurichten
- Detaillierte Konfigurationen für verschiedene KI-Assistenten finden sich in der offiziellen Dokumentation
Ausblick
- Die aktuelle Preview konzentriert sich auf die Bereitstellung unstrukturierter Markdown-Inhalte
- Vor dem offiziellen Release soll Unterstützung für strukturierte Inhalte wie Code-Sample-Objekte und API-Referenz-Entitäten hinzukommen
- Außerdem plant Google, die Abdeckung der Entwicklerdokumentation zu erweitern und die Verzögerung bei der Neuindexierung zu verkürzen
- Siehe offizielle Dokumentation - https://developers.google.com/knowledge/api
2 Kommentare
Wenn man sich Toss Payments ansieht, haben sie offenbar bereits Markdown-Seiten für die Anbindung vorbereitet … ihrer Zeit also voraus.
Hacker-News-Kommentare
Ich verstehe nicht, warum man es so kompliziert macht.
Man braucht einen API-Key, muss einen MCP-Server starten und den Client so konfigurieren, dass er Markdown-Dateien in Echtzeit abruft – ich verstehe nicht, warum.
Würde nicht einfach eine einzige tar-Datei mit allen Dokumenten reichen? Das wären doch nur ein paar MB.
Wenn man Updates einfach machen will, kann man daraus ein git-Repo machen. Mein Agent ist so eingerichtet, dass er in jeder neuen Session immer
git fetchausführt.Ich verstehe den Zweck von MCP immer noch nicht richtig. Codex kann bereits mit jira, confluence, gitlab, prometheus und SQL umgehen, und man braucht dafür nur eine
.netrc-Datei.Ich frage mich auch, ob MCP-Tools kombinierbar sind. Kann man Dinge wie grep oder jq in einer Pipeline verketten, oder ist eine einfache CRUD-API am Ende leistungsfähiger und einfacher?
HTTP/HTML selbst hat bereits eine „API“, die Markdown bereitstellen kann.
Wenn man nginx so konfiguriert, dass
$URL.mdzurückgegeben wird, kann ein LLM das aktuelle Dokument direkt mit dem Befehlcurl --header 'Accept: text/markdown' [https://gwern.net/archiving](https://gwern.net/archiving)abrufen. Eine einzige Zeile Konfiguration reicht.CRUD-Apps sind einfach, aber man muss dem LLM alle Details im Voraus erklären.
MCP kann nur die jeweils nötigen Informationen in den Kontext einbringen und direkt aufrufen. Wenn man Wrapper-Skripte um mehrere APIs baut, implementiert man am Ende MCP im Grunde direkt selbst.
/usr/share/man/zeigt, dass Dokumentation etwa 52 MB umfasst.Es gibt mit
manundaproposbereits Werkzeuge, die genau so etwas leisten.Webseiten sind für Menschen, und die über MCP bereitgestellte Dokumentation ist für Agenten gedacht.
Im Kern geht es bei MCP also darum, eine API bereitzustellen, auf die Agenten per
curlzugreifen können.Ich habe mir ein kleines CLI gebaut, das die
curl-Aufrufe meines Agenten umschließt und die Authentifizierung übernimmt.Mich würde interessieren, ob es dafür eine leichtere und portablere Methode gibt.
AWS betreibt ebenfalls einen eigenen MCP-Server.
AWS Documentation MCP Server
Er ist ziemlich nützlich, wenn man seltene Einstellungen oder Funktionen finden will, die in der Dokumentation versteckt sind.
Siehe Microsoft Learn MCP,
das GitHub-Repository
und den zugehörigen Blogbeitrag.
Wenn es ein öffentlicher MCP-Server nur für Google-Dokumentation ist, gibt es dann nicht schon mehrere Dienste wie Context7?
Ich würde es gern einmal ausprobieren, aber in letzter Zeit schreckt mich der Token-Verbrauch von Gemini CLI ab.
Selbst wenn Tokens etwas günstiger sind, bringt es nichts, wenn pro Prompt das Dreifache verbraucht wird.
Ich wünschte, Google würde dieses Problem zuerst lösen.
Das sehe ich genauso. Gemini 3 weiß überhaupt nichts über iOS 26 oder Liquid Glass.
Es nimmt immer an, ich wolle eine Custom View bauen, und bastelt dann irgendetwas mit ultrathinmaterial, einer API der vorherigen Generation.
Wäre es nicht besser, einfach Links zur relevanten technischen Dokumentation in eine AGENTS.md-Datei zu setzen?
Natürlich wäre es hilfreich, wenn das Ganze als eine riesige Textdatei bereitgestellt würde, damit der Agent nicht ständig Links verfolgen muss,
aber wenn eine Dokumentationsseite so etwas wie hier anbietet, sollte das doch ausreichen.
Irgendwie hat das etwas Retrohaftes.
Es ist Spitzentechnologie, aber die bürokratischen Abläufe darüber wirken, als kämen sie aus einer ganz anderen Zeit.
Das ließe sich wahrscheinlich auch als herunterladbarer Skill umsetzen.
Wenn man es aber über API-Aufrufe anbietet, kann man mehr Daten darüber sammeln, welche Dokumente Coding-Agenten lesen.
Das ist wahrscheinlich ein Beispiel für das, was gwern mit „Schreiben für KI“ gemeint hat.
Reicht nicht einfach ein HTTP-Server, der Markdown-Dateien ausliefert?
Das LLM holt die Datei per
curl, und damit ist es erledigt.