llms.txt ist eine vorgeschlagene Konvention für eine strukturierte Klartext-Zusammenfassung einer Website oder API, die für große Sprachmodelle und KI-gestützte Entwicklerwerkzeuge gedacht ist. Das Konzept ist analog zu robots.txt für Web-Crawler: ein bekannter Pfad, den ein Tool abrufen kann, um zu verstehen, was eine Site bietet — ohne Scraping oder das Parsen komplexer Formate.
Für APIs beschreibt llms.txt die verfügbaren Endpunkte, ihren Zweck, die wichtigsten Felder, die sie akzeptieren und zurückgeben, sowie eventuelle Authentifizierungsanforderungen — geschrieben auf eine Weise, die im Kontextfenster eines LLMs natürlich lesbar ist. Wir stellen so eine Datei für die Crowdee-API bereit. Sie ist öffentlich zugänglich und erfordert keine Authentifizierung, denn ihr gesamter Zweck besteht darin, von Tools abgerufen zu werden, die möglicherweise noch keine Zugangsdaten besitzen.
Eine vollständige API-Referenz ist das richtige Format für präzise, maschinenlesbare Verträge. Sie behandelt jeden Grenzfall: nullable Felder, Discriminated Unions, Enum-Einschränkungen, verschachtelte Arrays von Objekten. Code-Generatoren verlassen sich auf diese Präzision. Aber diese Ausdrucksstärke hat ihren Preis: Eine realistische API-Referenz umfasst Zehntausende von Tokens. Die gesamte Referenz bei jedem API-Aufruf in ein LLM einzuspeisen ist teuer und oft unnötig — die meisten Aufgaben benötigen nur einen Bruchteil der Gesamtoberfläche.
Es gibt auch eine Lesbarkeitsbarriere. Eine formale API-Spezifikation ist für Werkzeuge geschrieben, nicht für Textvorhersage. Ein LLM kann sie parsen und verstehen, aber die Ausgabequalität verbessert sich, wenn die Dokumentation in klarer, strukturierter Prosa geschrieben ist — ähnlich den Trainingsdaten des Modells. Eine llms.txt-Datei überbrückt diese Lücke: präzise genug für die Generierung korrekten Codes, aber als natürliche Sprache statt als verschachteltes Schema strukturiert.
Die beiden Formate stehen nicht im Wettbewerb. Die vollständige Referenz — verfügbar unter docs.crowdee.ai — ist die Quelle der Wahrheit für Tooling; llms.txt ist der schnelle Pfad für LLMs, die Kontext ohne den vollständigen Vertrag benötigen.
Unser llms.txt deckt die gesamte Crowdee-API-Oberfläche in komprimierter Form ab. Jeder Abschnitt entspricht einem Funktionsbereich: Authentifizierung, Projekte, Datensätze, Verifikations-Pipelines, LT-Pipelines, Crowdsourcing und Worker-Funktionen. Für jeden Bereich listet die Datei die verfügbaren Operationen, eine Ein-Satz-Beschreibung des Zwecks jeder Operation, die wichtigsten Eingaben und die erwartete Ausgabeform auf.
Die Datei behandelt auch die Authentifizierung: Sie erklärt die unterstützten Methoden und wie man sie jeweils verwendet. Ein Entwickler oder KI-Assistent, der die Datei von oben nach unten liest, hat alles, was für eine funktionierende Integration der häufigsten Workflows nötig ist — Projekt anlegen, Dateien hochladen, Pipeline ausführen, Ergebnisse lesen.
Wir halten das llms.txt manuell synchron und überarbeiten es, wenn wir Funktionen hinzufügen oder ändern. Das ist eine bewusste Entscheidung: Anders als eine vollautomatisch generierte Referenz profitiert llms.txt vom redaktionellen Urteil darüber, welche Details für ein Modell mit begrenztem Kontext am wichtigsten sind.
Die direkteste Nutzung ist das Abrufen der Datei als Kontext, bevor man ein LLM um Integrationscode bittet. In jedem Tool, das Kontext-Injection unterstützt — Claude, Cursor, Copilot und Ähnliches — kann ein Entwickler die llms.txt von Crowdee als Kontextquelle einbinden und dann Fragen zur API stellen oder Code generieren lassen. Das Modell erhält eine vollständige, genaue API-Zusammenfassung, ohne dass der Entwickler aus Dokumentationsseiten kopieren muss.
Dieselbe Datei ist für agentische Workflows nützlich. Ein Agent, der die Crowdee-API aufrufen muss, kann sie als ersten Schritt abrufen und den Inhalt nutzen, um zu planen, welche Operationen in welcher Reihenfolge aufzurufen sind. Das ergänzt den MCP-Server: Der MCP-Server stellt aufrufbare Tools bereit, während llms.txt den Kontext liefert, der einem Modell hilft zu entscheiden, welche Tools es aufrufen und wie es sie effektiv einsetzen soll. Den MCP-Server behandeln wir ausführlich in unserem Beitrag zum Crowdee MCP-Server.
Wir betrachten unsere Dokumentation als eine Hierarchie von Konsumentenbedürfnissen:
| Format | Konsument | Anwendungsfall |
|---|---|---|
| Vollständige API-Referenz | Tooling (Code-Generatoren, Linter, SDK-Generatoren) | Präziser, vollständiger Vertrag |
| Interaktive Doku unter docs.crowdee.ai | Menschliche Entwickler | Erkundung und Tests |
llms.txt | LLMs und KI-Coding-Assistenten | Kontexteffiziente API-Zusammenfassung |
Keiner der drei ersetzt die anderen. Ein Entwickler, der eine Client-Bibliothek baut, nutzt die vollständige Referenz. Ein Entwickler, der einen unbekannten Endpunkt debuggt, öffnet die interaktive Doku. Ein KI-Assistent, der Integrationscode generiert, ruft llms.txt ab. Alle drei leiten sich aus denselben zugrunde liegenden API-Definitionen ab und bleiben daher konsistent, ohne manuelle Synchronisation. Zusammen stellen sie sicher, dass ob der Konsument ein Code-Generator, ein Mensch oder ein Sprachmodell ist — er das Format erhält, das für ihn am besten funktioniert.
Artikel teilen:
