35 Punkte von GN⁺ 2026-02-10 | 2 Kommentare | Auf WhatsApp teilen
  • 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 ApiNotActivatedMapError zu 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
    1. Auf der Credentials-Seite des Google-Cloud-Projekts einen API-Schlüssel für die Developer Knowledge API erstellen und Einschränkungen festlegen
    2. 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
    3. 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

 
eastkim64 2026-02-11

Wenn man sich Toss Payments ansieht, haben sie offenbar bereits Markdown-Seiten für die Anbindung vorbereitet … ihrer Zeit also voraus.

 
GN⁺ 2026-02-10
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 fetch ausfü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?

    • Ich finde, nicht einmal git oder ein Tarball sind nötig.
      HTTP/HTML selbst hat bereits eine „API“, die Markdown bereitstellen kann.
      Wenn man nginx so konfiguriert, dass $URL.md zurückgegeben wird, kann ein LLM das aktuelle Dokument direkt mit dem Befehl curl --header 'Accept: text/markdown' [https://gwern.net/archiving](https://gwern.net/archiving) abrufen. Eine einzige Zeile Konfiguration reicht.
    • Der Kern von MCP ist die Auffindbarkeit (Discoverability).
      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.
    • Schon ein Blick in den Ordner /usr/share/man/ zeigt, dass Dokumentation etwa 52 MB umfasst.
      Es gibt mit man und apropos bereits Werkzeuge, die genau so etwas leisten.
    • Ein MCP-Server ist die kanonische Art, diesen Dienst bereitzustellen.
      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 curl zugreifen können.
    • Ich frage mich, wie man Dienste behandelt, die OAuth-Authentifizierung verwenden.
      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.

  • Wenn es ein öffentlicher MCP-Server nur für Google-Dokumentation ist, gibt es dann nicht schon mehrere Dienste wie Context7?

    • Das frage ich mich auch. Mich interessiert, worin genau der Unterschied zu Context7 besteht. Ich sehe nicht so recht, welchen Vorteil das hat.
  • 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.