TokenLab für Agents: Maschinenlesbare Modelle, Preise, SDKs und MCP

TokenLab MCP ist ein schreibgeschützter Model Context Protocol (MCP) Server, der einem Coding-Agent direkten, strukturierten Zugriff auf den öffentlichen Modellkatalog, die Preisgestaltung und die API-Übersicht von TokenLab bietet, noch bevor er eine einzige Zeile Integrationscode schreibt. Er beantwortet Discovery-Fragen – welche Modell-IDs existieren aktuell, was kosten sie, welche Modalitäten werden unterstützt – und er führt keine kostenpflichtigen Inference-API-Aufrufe in Ihrem Namen aus.

Viele Integrationsfehler bei Agents entstehen nicht erst beim ersten API-Aufruf, sondern früher: wenn der Agent eine Modell-ID aus einem veralteten Beispiel, einem zwischengespeicherten Speicher oder einem sechs Monate alten Tutorial auswählt und die Diskrepanz erst nach einem 404-Fehler oder einer unerwarteten Preisgestaltung bemerkt.

Coding-Agents schreiben schnell. Sie lesen nicht immer zuerst. Neben TokenLab MCP veröffentlicht TokenLab eine kompakte llms.txt, eine ausführlichere llms-full.txt sowie öffentliche Model-Data-JSON-Dateien – dieselben Oberflächen für den Modellkatalog und die Preisgestaltung, die Sie selbst durchsuchen können –, damit ein Agent aktuelle Modell-IDs und Kosten prüfen kann, bevor er irgendetwas hartcodiert.

Dieser Artikel behandelt, was diese Oberflächen sind, was sie nicht sind und wie man einen Agent so konfiguriert, dass er sie nutzt, bevor er einen Modellnamen hartcodiert. Die vollständige Endpunkt-Referenz finden Sie in der Integrationsdokumentation.

Wichtige Erkenntnisse

• TokenLab veröffentlicht agentenlesbare API-Übersichten unter api.tokenlab.sh/llms.txt und llms-full.txt, wobei die Web-Domain auf dieselbe Quelle weiterleitet.
• Die Dateien des Public Model Data Center (Katalog-JSON, Latest-JSON, Trends-JSON, Summary-Markdown) geben Agents einen abfragbaren Schnappschuss dessen, was TokenLab aktuell anbietet.
• Der TokenLab MCP Server stellt list_models, get_model, get_model_pricing und get_api_overview bereit – und er ist schreibgeschützt. Er fungiert nicht als Proxy für kostenpflichtige Inference.
• Die öffentliche Dokumentation empfiehlt Agents, /v1/models aufzurufen oder llms.txt zu lesen, bevor ein Modellname hartcodiert wird, und recommended_for-Filter für Nicht-Chat-Aufgaben wie Bild-, Video- oder Embedding-Erstellung zu verwenden.
• Das Lesen von Modell- und Preis-Endpunkten vor dem erneuten Versuch einer fehlgeschlagenen Nicht-Chat-Anfrage vermeidet wiederholte fehlerhafte Aufrufe bei der falschen Modellfamilie.

Warum Agents überhaupt veraltete Modell-IDs wählen

Coding-Agents generieren Modell-IDs basierend auf dem, was sie während des Trainings gelernt haben, nicht basierend auf dem, was aktuell verfügbar ist. Diese Trainingsdaten haben ein Cutoff-Datum, daher ist das interne Verständnis eines Agents von „dem aktuellen Modell“ auf den Stand fixiert, der zum Zeitpunkt der letzten Aktualisierung der Gewichte galt. Wenn Sie einen Agent bitten, eine Modell-API aufzurufen, wird er selbstbewusst nach der ID greifen, an die er sich erinnert – selbst wenn diese ID inzwischen umbenannt, als veraltet markiert oder ersetzt wurde.

Dies ist kein Fehler in der Logik des Agents; es ist eine strukturelle Einschränkung jedes Systems, das sich auf auswendig gelerntes Wissen statt auf eine Live-Abfrage verlässt. Die Lösung ist kein intelligenterer Prompt – es ist, dem Agent einen Ort zu geben, an dem er nachsehen kann, bevor er Code schreibt.

Genau dafür existieren die Model-Data-Dateien und die API von TokenLab. Vor dem Generieren einer Anfrage kann ein Agent (oder der Mensch, der die Ausgabe überprüft) einen Live-Endpunkt abfragen, um zu bestätigen, dass die Modell-ID tatsächlich existiert, welche Modalität sie unterstützt und was sie kostet – anstatt einem aus dem Gedächtnis abgerufenen Namen zu vertrauen.

Endpunkt	Zweck
https://tokenlab.sh/model-data/catalog.json	Vollständiger Katalog der verfolgten Modelle, strukturiert für programmatische Abfragen
https://tokenlab.sh/model-data/latest.json	Aktuelle Modellliste in einem leichtgewichtigen, agentenfreundlichen Format
https://tokenlab.sh/en/models	Menschenlesbarer Modell-Browser
https://tokenlab.sh/en/pricing	Aktuelle Preisgestaltung nach Modell und Modalität

Ein Blog-Beitrag – einschließlich dieses hier – ist ein Schnappschuss. Er spiegelt wider, was zum Zeitpunkt des Schreibens wahr war, und er wird genauso veralten wie die Trainingsdaten eines Agents. Live-Endpunkte haben dieses Problem nicht: Sie spiegeln wider, was genau jetzt wahr ist, weshalb sie die sicherere Anlaufstelle vor dem Deployment von Code sind, nicht ein statischer Artikel.

Was TokenLab für die Agent-Discovery bereitstellt

Die llms.txt-Ebene

https://api.tokenlab.sh/llms.txt ist eine kompakte, agentenlesbare Übersicht der API: welche Endpunkte existieren, wie eine Anfrage aussieht und wo man tiefere Details findet. Sie ist so konzipiert, dass sie kurz genug ist, damit ein Agent sie in einem einzigen Kontextfenster lesen kann, ohne ein großes Token-Budget nur für die Orientierung zu verbrauchen.

https://api.tokenlab.sh/llms-full.txt ist die ausführlichere Version – mehr Endpunkt-Details, mehr Beispiele, mehr von der Oberfläche, die ein Agent benötigt, bevor er eine funktionierende Integration statt eines groben Entwurfs generiert.

Wenn Sie auf der Web-Domain statt auf dem API-Host landen, leiten tokenlab.sh/llms.txt und tokenlab.sh/llms-full.txt auf dieselben API-gehosteten Quellen weiter. Das ist wichtig für Agents: Egal welchen Einstiegspunkt sie crawlen oder abrufen, sie landen beim selben kanonischen Text, nicht bei zwei auseinanderlaufenden Kopien.

Das Model Data Center

Über die Textübersicht hinaus veröffentlicht TokenLab strukturierte JSON-Dateien, die ein Agent (oder ein Build-Skript) direkt abrufen kann:

• https://tokenlab.sh/model-data/catalog.json — der ausführlichere Modellkatalog.
• https://tokenlab.sh/model-data/latest.json — ein Schnappschuss, der sich auf das aktuell Verfügbare konzentriert.
• https://tokenlab.sh/model-data/summary.md — eine für Mensch und Agent lesbare Markdown-Zusammenfassung, nützlich, wenn Sie einen schnellen Abgleich mit dem benötigen, was Ihre Codebasis aktuell hartcodiert hat.

Dies sind statische, abrufbare Dateien. Ein Agent, der eine Konfigurationsdatei, ein .env-Template oder ein Dropdown zur Modellauswahl erstellt, kann das JSON direkt abrufen, anstatt einen Menschen zu bitten, eine Modellliste einzufügen, die in zwei Wochen wieder veraltet sein wird.

Der MCP-Server – schreibgeschützt, und es lohnt sich, dabei präzise zu sein

https://github.com/hedging8563/tokenlab-mcp-server ist öffentlich. Er stellt vier für die Discovery relevante Tools bereit:

• list_models — auflisten, was verfügbar ist, optional gefiltert.
• get_model — Details zu einer spezifischen Modell-ID abrufen.
• get_model_pricing — aktuelle Preise für ein spezifisches Modell abrufen.
• get_api_overview — das MCP-native Äquivalent zum Lesen von llms.txt.

Die wichtige Einschränkung: Dieser Server ist schreibgeschützt. Er ruft keine kostenpflichtigen Inference-APIs in Ihrem Namen auf und fungiert nicht als Proxy für Generierungsanfragen. Er beantwortet Fragen zu Modellen, Preisen und API-Struktur. Wenn Ihr Agent tatsächlich Inference ausführen muss, nutzt er weiterhin die normale API von TokenLab mit Ihrem eigenen Schlüssel – der MCP-Server ist eine Discovery-Ebene, keine Ausführungsebene. Beide zu vermischen ist ein häufiger Fehler, den man in jedem Agent-Prompt oder Skill-File, das man schreibt, explizit vermeiden sollte.

Beispiel für TokenLab MCP Discovery

TokenLab stellt einen schreibgeschützten Model Context Protocol (MCP) Server bereit, der es Coding-Agents ermöglicht, verfügbare Modelle und Preise zu entdecken, ohne Inference durchzuführen. Der MCP-Server bietet vier Tools:

• list_models — verfügbare Modelle auflisten, optional gefiltert nach recommended_for (z. B. image, video, embedding, rerank, translation)
• get_model — Details für ein spezifisches Modell abrufen
• get_model_pricing — Preisinformationen für ein spezifisches Modell abrufen
• get_api_overview — eine Zusammenfassung der TokenLab API abrufen

Beispiel: Modelle via MCP auflisten

{
  "tool": "list_models",
  "arguments": {}
}

Beispiel: Modelle nach empfohlener Verwendung filtern

{
  "tool": "list_models",
  "arguments": {
    "recommended_for": "image"
  }
}

Wenn Sie die API lieber direkt abfragen möchten, anstatt über MCP zu gehen, lauten die äquivalenten REST-Aufrufe:

# Alle Modelle auflisten
curl https://api.tokenlab.sh/v1/models \
  -H "Authorization: Bearer sk-KEY"

# Modelle auflisten, die für Bildaufgaben empfohlen werden
curl "https://api.tokenlab.sh/v1/models?recommended_for=image" \
  -H "Authorization: Bearer sk-KEY"

Beachten Sie, dass der MCP-Server strikt schreibgeschützt ist – er ist für die Discovery gedacht (Modelle auflisten, Preise prüfen und API-Fähigkeiten sichten) und führt selbst keine Inference durch.

Für Einrichtungsanweisungen und Integrationsdetails siehe:

• TokenLab MCP Server
• Coding Agent Skill

Das Skills-Repo

https://github.com/hedging8563/tokenlab-skills verpackt dieses Discovery-Muster in etwas, das ein Coding-Agent-Framework direkt laden kann – eine Skill-Definition, die dem Agent sagt: „Lies das, bevor du TokenLab-Integrationscode schreibst“, anstatt sich darauf zu verlassen, dass der Agent unabhängig entscheidet, dies zu prüfen.

Der empfohlene Agent-Workflow

Die öffentliche Dokumentation beschreibt eine spezifische Sequenz, die sich in der Praxis bewährt hat:

1. Bevor Sie einen Modellnamen hartcodieren, rufen Sie /v1/models auf oder lesen Sie llms.txt, um zu bestätigen, dass die ID aktuell tatsächlich existiert.
2. Für Nicht-Chat-Aufgaben – Bild, Video, Musik, 3D, TTS, STT, Embedding, Rerank, Translation – filtern Sie mit /v1/models?recommended_for=<task>, anstatt anzunehmen, dass ein auf Chat ausgerichtetes Modell die Aufgabe bewältigt, oder einen Modellnamen aus dem Gedächtnis zu raten.
3. Bevor Sie eine fehlgeschlagene Nicht-Chat-Anfrage wiederholen, lesen Sie /v1/models/:model und /v1/models/:model/pricing. Eine fehlgeschlagene Anfrage bei einem Modell mit falscher Modalität wird bei einem erneuten Versuch mit derselben Eingabe oft wieder fehlschlagen; das vorherige Prüfen der tatsächlichen Modalität und Preisgestaltung des Modells spart eine Wiederholungsschleife.

Diese Sequenz ist wichtig, weil sie die zwei häufigsten Fehlermodi vorab abfängt: falsche Modell-ID und falsche Modellfamilie für die Aufgabe.

Praktische Checkliste für die Einbindung in einen Agent

Schritt	Was zu prüfen ist	Wo
1	Löst diese Modell-ID noch auf?	/v1/models oder llms.txt
2	Ist dies die richtige Modellfamilie für die Aufgabe (Chat vs. Bild vs. Embedding etc.)?	/v1/models?recommended_for=<task>
3	Was ist die aktuelle Input/Output-Preisgestaltung für dieses Modell?	/v1/models/:model/pricing oder get_model_pricing (MCP)
4	Was ist das Kontextfenster und die Modalität?	/v1/models/:model oder get_model (MCP)
5	Gibt es ein neueres Modell mit ähnlichem Namen, das dieses ersetzt hat?	catalog.json / latest.json
6	Hat der Agent llms.txt gelesen, bevor er Integrationscode generiert hat?	Im Tool-Call-Log des Agents bestätigen

Wenn ein Agent Schritt 1 und 2 überspringt, basiert alles nachgelagerte – Wiederholungen, Fehlerbehandlung, Kostenschätzungen – auf einer Annahme statt auf einer Tatsache.

Warum dies speziell für Nicht-Chat-Aufgaben wichtig ist

Chat-Modelle erhalten die meiste Aufmerksamkeit, aber der recommended_for-Filter existiert, weil Nicht-Chat-Aufgaben auf weniger offensichtliche Weise fehlschlagen. Ein Modell, das für Text-zu-Text-Generierung gebaut wurde und eine fehlerhafte Antwort auf eine Bildanfrage zurückgibt, wirft nicht immer einen sauberen, selbsterklärenden Fehler. Manchmal gibt es einfach etwas zurück, das der Agent nicht parsen kann.

Das Filtern nach recommended_for=image, recommended_for=video, recommended_for=embedding usw. schränkt die Kandidatenmenge ein, bevor der Agent überhaupt einen Request-Body schreibt. Angesichts der vielen verschiedenen Bildgenerierungs-Einträge, die zu jedem Zeitpunkt im Modellkatalog existieren können – nano-banana-2 (Gemini 3.1 Flash Image), nano-banana-pro (Gemini 3 Pro Image), nano-banana-2-lite (Gemini 3.1 Flash Lite Image), openai/gpt-image-2, reve/reve-2.0, microsoft/mai-image-2.5 – ist das Raten, welches davon „das Bildmodell“ ist, genau der Fehlermodus, den dieser Workflow verhindern soll. Videogenerierung hat ihre eigene Reihe aufgabenspezifischer Modelle (seedance, veo-3, unter anderen) mit unterschiedlichen Preis- und Modalitätsstrukturen; dieselbe Filterlogik findet Anwendung.

Für exakte aktuelle Preise, Kontextlimits und Modalitäten zu jedem hier genannten spezifischen Modell prüfen Sie direkt den Modellkatalog und die Preisseite – genau das ist der Grund, warum man dies nicht in einem Blog-Beitrag hartcodiert. Wenn Sie Modelle speziell für agentengesteuerte Entwicklungsarbeit evaluieren, siehe best AI models for coding 2026.

Was dies nicht tut

Hier präzise zu sein ist genauso wichtig wie der Workflow selbst:

• Der MCP-Server führt keine kostenpflichtige Inference aus. Er beantwortet Discovery-Fragen. Das Ausführen einer tatsächlichen Generierungsanfrage läuft weiterhin über die Standard-API mit Ihren eigenen Anmeldedaten.
• llms.txt und die Model-Data-Dateien sind periodische Schnappschüsse, keine Live-Datenbankverbindung. Der Aktualisierungszeitpunkt ist nicht an einen strikten Zeitplan gebunden, betrachten Sie also jedes Datum auf diesen Seiten als ungefähr. Für alles, was preis- oder sicherheitssensibel ist, bleiben der Preis-Endpunkt und die Dashboard-API zum Zeitpunkt der Anfrage die Quelle der Wahrheit.
• Nichts davon ersetzt das Lesen der vollständigen API-Dokumentation für Authentifizierung, Rate Limits oder Fehlerbehandlungssemantik. Discovery-Oberflächen sagen einem Agent, was existiert; sie ersetzen nicht die Integrationsdokumentation für die korrekte Aufrufweise.

FAQ

Was sollte ein Agent lesen, bevor er ein TokenLab-Modell auswählt? Lesen Sie llms.txt (oder llms-full.txt für mehr Details) und rufen Sie /v1/models auf, bevor Sie eine Modell-ID hartcodieren. Filtern Sie bei Nicht-Chat-Aufgaben mit recommended_for, anstatt einen Modellnamen aus dem Gedächtnis zu raten.

Ruft TokenLab MCP kostenpflichtige Inference-APIs auf? Nein. Der öffentliche TokenLab MCP Server ist schreibgeschützt. Seine Tools (list_models, get_model, get_model_pricing, get_api_overview) beantworten Discovery-Fragen zu Modellen und Preisen. Tatsächliche Inference-Aufrufe gehen über die Standard-API mit Ihrem eigenen Schlüssel.

Wann sollte ein Agent recommended_for verwenden? Wann immer die Aufgabe nicht reiner Chat ist – Bild, Video, Musik, 3D, TTS, STT, Embedding, Rerank oder Translation. Das Filtern nach Aufgabe schränkt die Modellliste auf Varianten ein, die tatsächlich für diese Modalität gebaut wurden, anstatt anzunehmen, dass ein auf Chat ausgerichtetes Modell dies bewältigt.

Wie reduziert dies veraltete Modell-IDs in generiertem Code? Indem Discovery zum ersten Schritt statt zum nachträglichen Einfall gemacht wird. Ein Agent, der llms.txt liest, /v1/models prüft und die Preise bestätigt, bevor er Code schreibt, arbeitet mit einem aktuellen Schnappschuss statt mit einem Speicher aus der Trainingszeit, der bereits mehrere Modellgenerationen alt sein könnte.

Quellen und Aktualität

• TokenLab llms.txt — https://api.tokenlab.sh/llms.txt — beobachtet 2026-07-09
• TokenLab llms-full.txt — https://api.tokenlab.sh/llms-full.txt — beobachtet 2026-07-09
• TokenLab MCP Server docs — https://docs.tokenlab.sh/integrations/tokenlab-mcp-server — beobachtet 2026-07-09
• TokenLab API Integration Skill docs — https://docs.tokenlab.sh/integrations/coding-agent-skill — beobachtet 2026-07-09
• TokenLab MCP Server repository — https://github.com/hedging8563/tokenlab-mcp-server — beobachtet 2026-07-09
• TokenLab Skills repository — https://github.com/hedging8563/tokenlab-skills — beobachtet 2026-07-09
• TokenLab Model Data Center — https://tokenlab.sh/model-data/catalog.json, https://tokenlab.sh/model-data/latest.json, https://tokenlab.sh/model-data/summary.md — beobachtet 2026-07-09

Modell-IDs, Preise und Modalitätsdetails in diesem Artikel spiegeln einen Schnappschuss zum Zeitpunkt des Schreibens wider. Schnappschuss-Seiten wie diese und llms.txt werden periodisch aktualisiert, aber nicht in einem festen oder garantierten Rhythmus – bauen Sie keine Wiederholungslogik oder Kostenschätzungen auf ein angenommenes Aktualisierungsintervall auf. Überprüfen Sie aktuelle Werte gegen die Preisseite und den Modellkatalog, bevor Sie Integrationscode ausliefern. Für einen tieferen Einblick, wie die Preisgestaltung über Modellfamilien hinweg strukturiert ist, siehe Gemini API pricing for developers.

Nächste Schritte mit TokenLab MCP

Um mit der Nutzung von TokenLab MCP für die Modell-Discovery zu beginnen:

1. Holen Sie sich einen API-Schlüssel aus dem TokenLab-Dashboard.
2. Verbinden Sie Ihren Agent gemäß der Coding-Agent-Integrationsanleitung.
3. Durchsuchen Sie den Katalog direkt unter tokenlab.sh/en/models, um die aktuelle Modellabdeckung und Metadaten zu sehen.
4. Prüfen Sie die Preise für die Modelle, die Sie verwenden möchten, unter tokenlab.sh/en/pricing.

Wenn Sie entscheiden, welche Modelle zu Ihrem Workflow passen, sehen Sie sich unsere Analysen zu best AI models for coding in 2026 und Gemini API pricing for developers an.

Denken Sie daran, dass MCP strikt eine Discovery-Ebene ist – sie stellt Modell-Metadaten, Fähigkeiten und Preise bereit, damit Ihr Agent fundierte Entscheidungen treffen kann. Tatsächliche Inference-Aufrufe laufen weiterhin über die Standard-TokenLab-API unter Verwendung Ihres eigenen API-Schlüssels; MCP routet oder proxyt keine Anfragen.