Die meiste SDK-Dokumentation ist für einen Menschen geschrieben, der sie an einem Dienstag um 14 Uhr liest. Immer öfter ist der erste Leser aber ein Coding-Assistent, und der hat ein anderes Problem: Er muss sich sicher sein, und Fließtext gibt ihm diese Sicherheit nicht.
Früher habe ich das gelöst, indem ich die gesamte SDK-Referenz als eine einzige Textdatei veröffentlicht habe, die ein Assistent in einem Rutsch abrufen konnte. Die Idee war vernünftig und ist schlecht gealtert. Ein flacher Textdump bleibt Fließtext: Der Assistent liest ihn, komprimiert ihn und schreibt ein paar hundert Zeilen später einen Methodennamen, der nie in der Datei stand. Und ein Dokument, das neben dem Code gepflegt wird, entfernt sich vom Code. Genau diesen Fehler kann sich eine Referenz nicht leisten.
Zwei Dinge haben die Datei ersetzt, und beide sind strenger.
Die Typen sind die Referenz
@kookee/sdk bringt TypeScript-Deklarationen mit. Installierst du das Paket, liegt die Referenz auf der Festplatte, im Kontext des Assistenten, in einer Form, an die er sich nicht falsch erinnern kann:
npm install @kookee/sdkJetzt ist der Prompt kurz, denn die Präzision steckt in den Typen und nicht im Prompt:
Bau einen Blog mit dem Paket
@kookee/sdk, das schon installiert ist. Eine Listenseite (/blog) mit Tag-Filter, Suche und Paginierung und eine Detailseite (/blog/:slug) mit gerendertem HTML-Inhalt und Emoji-Reaktionen. Next.js App Router, Daten in Server Components laden. Lies den Key ausprocess.env.KOOKEE_API_KEY.
Der Assistent schreibt kookee.blog.list({ page, limit, tags, search, locale }), weil das die Signatur ist, nicht weil er sich an einen Absatz erinnert hat. Und wenn ich eine Methode ändere, ändern sich die Deklarationen im selben Release. Es gibt kein zweites Artefakt, dessen Aktualisierung man vergessen kann. Das war das eigentliche Argument gegen die Textdatei: Sie konnte falsch sein. Eine Referenz, die falsch sein kann, ist schlimmer als gar keine, denn man vertraut ihr.
Die Antwortstruktur, gegen die er programmiert, ist genau die, die du bekommst:
const response = await kookee.blog.list({ page: 1, limit: 10, tags: ['engineering'] });
response.data; // BlogEntryListItem[]
response.total; // 25
response.totalPages; // 3Wenn du lieber fertige Seiten einbaust, statt sie generieren zu lassen: @kookee/react bringt serverseitig gerenderte Blog-Komponenten mit, siehe Einen Blog mit den React-Komponenten bauen.
Die Inhalte sind die andere Hälfte
Typen sagen einem Assistenten, was er aufrufen kann. Was in deinem Projekt steckt, sagen sie nicht, und die Hälfte der Fehler bei einer ersten Integration kommt aus dieser Lücke: ein Kategorie-Slug, den es nicht gibt, ein Feld, das der Code nie ausliest, eine leere Seite, hinter der sich ein leeres Projekt verbirgt.
Also verbinde den Assistenten mit deinem echten Projekt:
claude mcp add --transport http kookee https://api.kookee.dev/api/mcp \
--header "Authorization: Bearer $KOOKEE_MCP_TOKEN"Jetzt ändert sich der Prompt grundlegend. Aus „Bau eine Changelog-Seite“ wird:
Lies meine Changelog-Einträge und bau dann eine Seite, die sie so darstellt, wie sie tatsächlich aufgebaut sind.
Und er liest sie tatsächlich. Er stellt fest, dass der Release-Typ in einem Array fields steckt und nicht direkt am Eintrag, dass bei zwei Einträgen die Version fehlt und dass deine Kategorien nach einem Schema benannt sind und deine Tags nach einem anderen. Die Seite, die er schreibt, passt zu deinen Daten statt zu einem generischen Beispiel. Und er kann auch schreiben: Das Erste, was ihm als fehlend auffällt, kann er gleich selbst beheben.
Was du noch brauchst
Ein Kookee-Projekt mit mindestens einem veröffentlichten Beitrag. Ein leeres Projekt ergibt eine leere Seite, und die lässt sich kaum von einem Bug unterscheiden.
Einen API-Schlüssel aus Verbinden → API-Schlüssel für die Anwendung. Er hat nur Zugriff auf veröffentlichte Inhalte und ist deshalb auch in einem Client-Bundle sicher.
Ein persönliches MCP-Token aus Verbinden → MCP-Server, wenn der Assistent deine echten Inhalte lesen soll. Dafür reicht Nur lesen. Halte es trotzdem aus deinem Code heraus: Es hat auch Zugriff auf deine Entwürfe.
Über den Blog hinaus
Nach demselben Muster entsteht jeder andere Bereich:
Bau ein Hilfecenter mit Kategorie-Navigation, semantischer Suche und Artikelseiten.
Bau eine Changelog-Seite, gruppiert nach Release-Typ, mit Emoji-Reaktionen.
Bau sie nacheinander. Drei auf einmal ergeben einen Diff, den niemand sorgfältig prüft, und so geht ein plausibel aussehender Bug live.
Der rote Faden: Verlang von einem Assistenten nicht, sich an deine API zu erinnern. Gib ihm etwas, an das man sich nicht falsch erinnern kann: die Typen und die Daten selbst.