Ein Diagramm gehört zu den Artefakten, die sich selbst aktualisieren sollten. Die Architektur ändert sich mit jedem Merge, die Doku-Seite hinkt ein Release hinterher, und irgendwann öffnet jemand ein Zeichentool, um es von Hand zu korrigieren. LetDraw hat eine API und einen MCP-Server, damit stattdessen ein Skript oder ein KI-Agent diese Arbeit übernimmt, und zwar jedes Mal, wenn sich die Quelle ändert.
Wenn du Diagramme bereits aus einer Compose-Datei oder einer Spezifikation generierst, ist der nächste Schritt, nicht mehr selbst auf den Knopf zu drücken. Ein persönliches API-Token macht aus derselben Generierung einen Aufruf, den jede Maschine machen kann: ein Build-Schritt, ein nächtlicher Job oder ein Assistent, der deine Anfrage liest und das Ergebnis zeichnet. Das Token trägt nur die Berechtigungen, die du ihm gibst, sodass Automatisierung standardmäßig nach dem Least-Privilege-Prinzip läuft.
Persönliche API-Tokens und Scopes
Du erstellst ein Token in den Entwicklereinstellungen, gibst ihm einen Namen und wählst seine Scopes. Das ist die ganze Einrichtung. Der Name dient dazu, Tokens später auseinanderzuhalten; nenn eines "CI-Skript" und ein anderes nach dem Assistenten, der es bekommt, und ein widerrufenes Token legt genau einen Aufrufer lahm und sonst nichts.
Mit Scopes bleibt ein Token bei minimalen Rechten. Statt eines allmächtigen Schlüssels bekommt jedes Token nur die Fähigkeiten, die seine Aufgabe braucht:
- Diagramme lesen für einen Job, der nur den aktuellen Stand einer Zeichnung abruft
- Diagramme erstellen und bearbeiten für Automatisierung, die Leinwände erzeugt oder aktualisiert
- Exportieren nach Mermaid oder D2 für eine Doku-Pipeline, die eine Datei zum Committen braucht
- Aus einem Prompt generieren für den KI-Weg, bei dem aus einer Anfrage ein Diagramm wird
Ein Token, eine Aufgabe, ein Name, den du widerrufen kannst. Das ist der Unterschied zwischen Automatisierung, der du vertraust, und einem Schlüssel, den du nur ungern herausgibst.
Diagramme in der CI-Pipeline: aus CI oder Cron aufrufen
Die REST API ist ein schlichter HTTP-Endpoint. Authentifiziere dich mit einem Bearer-Token, schick einen JSON-Body und bekomm ein Diagramm zurück. Hier ist der Weg "aus einem Prompt generieren", also die Art Aufruf, die du in einen Build-Schritt einbaust, damit die Architektur bei jedem Push aus einer Spezifikation gezeichnet wird:
# $LD_TOKEN holds a token with the "generate" and "export" scopes # 1) prompt to diagram (uses the AI key stored on your account) curl https://api.letdraw.com/api-v1/documents/generate \ -H "Authorization: Bearer $LD_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "prompt": "web -> api -> postgres, redis cache on api", "name": "Architecture" }' # 2) export it as text to commit next to the code (format=mermaid or d2) curl "https://api.letdraw.com/api-v1/documents/$DOC_ID/export?format=mermaid" \ -H "Authorization: Bearer $LD_TOKEN"
Pack das hinter einen Cronjob, und ein veraltetes Doku-Diagramm gibt es einfach nicht mehr. Der Job läuft, das Diagramm wird aus dem neu generiert, was die Eingabe heute sagt, und das Bild, das deine Teammitglieder öffnen, entspricht der Realität. Der erste Aufruf liefert das neue Dokument mit seiner id zurück; der Export-Aufruf macht daraus mermaid- oder d2-Text, den du neben dem Code committen kannst.
Eine Pipeline, die aktuell bleibt
Der Ablauf ist derselbe, ob der Auslöser ein Merge oder ein Zeitplan ist: Etwas ändert sich, die Pipeline ruft die API auf, und das Diagramm wird neu gebaut. Niemand muss an einen erneuten Export denken, weil es nichts zu denken gibt.
Per MCP an einen KI-Assistenten anbinden
Dieselben Fähigkeiten werden über das Model Context Protocol bereitgestellt, sodass ein KI-Assistent im Gespräch Diagramme für dich zeichnen und bearbeiten kann. Du registrierst LetDraw einmal als MCP-Server, gibst ihm ein Token, und der Assistent bekommt die Tools, die seine Scopes erlauben: Er kann eine Leinwand erstellen, Vorhandenes bearbeiten, nach Mermaid oder D2 exportieren oder ein Diagramm aus einer Beschreibung generieren, die du in einfacher Sprache eintippst.
{
"mcpServers": {
"letdraw": {
"url": "https://api.letdraw.com/mcp",
"headers": {
"Authorization": "Bearer $LD_TOKEN"
}
}
}
}
Weil der Assistent immer nur das Token hat, das du ihm gegeben hast, ist seine Reichweite auf die Scopes dieses Tokens begrenzt. Gib einem Entwurfs-Assistenten Erstellen-und-Bearbeiten plus Generieren, und er kann den ganzen Tag Diagramme bauen und überarbeiten; gib einem Review-Assistenten nur Lesen und Exportieren, und er kann sich alles ansehen und eine Datei erzeugen, aber nie deine Leinwand ändern. Benenne das Token nach dem Client, der es hält, und wenn du ihn jemals abschneiden willst, widerrufst du ein Token, und dieser Assistent verliert beim nächsten Aufruf den Zugriff.
Widerrufen, rotieren, wiederholen
Jedes Token lässt sich auf derselben Seite der Entwicklereinstellungen widerrufen, auf der du es erstellt hast. Genau das macht es angenehm, Skripten und Assistenten Tokens zu geben: Nichts, was du gewährst, ist dauerhaft, und nichts ist mit etwas anderem verflochten. Eine geleakte CI-Variable, ein Client, den du nicht mehr nutzt, ein zu großzügig vergebener Scope; in jedem Fall besteht die Lösung darin, dieses eine Token zu widerrufen und ein neues mit den Scopes zu erstellen, die du eigentlich gemeint hast.
Zusammengenommen ist es eine kleine Oberfläche mit einer klaren Regel. Maschinen und Assistenten bekommen Diagramme auf demselben Weg wie du, über benannte Tokens, die nur die Berechtigungen tragen, die ihre Aufgabe braucht, und du kannst jedes davon zurückziehen, sobald du willst. Das Diagramm ist nicht mehr etwas, das du pflegst, sondern etwas, das deine Pipeline produziert.