MCP-Modellkatalog für Coding Agents: Modellwahl maschinenlesbar machen

Ein Coding-Agent, der Modellnamen fest im Code hinterlegt (hardcoded), wird irgendwann um 2 Uhr morgens einen Alarm auslösen. Ein MCP-Modellkatalog für Coding-Agents ändert dieses Fehlerbild. Anstatt einer Zeichenkette, die tief im Quellcode vergraben ist, liest der Agent zum Zeitpunkt der Anfrage eine strukturierte Liste aktueller Modelle, Kosten, Modalitäten und Statusfelder. Wir pflegen einen ähnlichen Katalog bei TokenLab und betrachten diesen als die „Single Source of Truth“ für das Routing. In unserer Pipeline ist die Modellwahl ein Lookup und keine Konstante.

Warum Coding-Agents maschinenlesbare Modelldaten benötigen

Die meisten Integrationen für Coding-Agents funktionieren noch wie API-Integrationen von vor einem Jahrzehnt. Ein Entwickler wählt einen Modellnamen aus, fügt ihn in eine Konfiguration oder Umgebungsvariable ein und veröffentlicht das Ganze. Das funktioniert so lange, bis der Anbieter das Modell einstellt, die Preise ändert oder eine bessere Option veröffentlicht. Dann hat das Team keinen Prozess, um darauf zu reagieren.

Ein maschinenlesbarer Katalog ändert dieses Fehlerbild. Wenn ein Modell in den Ruhestand versetzt wird, kann der Agent den Katalog abfragen, sehen, dass das Modell nicht mehr verfügbar oder als „deprecated“ markiert ist, und auf eine dokumentierte Alternative ausweichen. Anstatt dass ein Entwickler jede neue Version manuell benchmarkt, können Tools die gelisteten Kontextfenster, die Unterstützung von Modalitäten und die Kostenfelder vergleichen, bevor sie wechseln.

Dies ist auch eine Voraussetzung für ernsthaftes Modell-Routing. Vielleicht möchten Sie günstige, hochvolumige Vervollständigungen mit DeepSeek V4 Flash oder Gemini 3.5 Flash durchführen. Vielleicht reservieren Sie Claude Sonnet 5 für Refactorings über mehrere Dateien hinweg. Die Routing-Logik benötigt dennoch eine „Single Source of Truth“. Diese Quelle muss angeben, welche Modelle aktuell sind, was sie kosten und was sie unterstützen. Ohne sie veralten Routing-Regeln genauso wie fest codierte Modellnamen.

TokenLab hat sich direkt zu diesem Problem geäußert. Siehe agent-readable model truth für das umfassendere Argument und agent-first API für die Frage, wie sich das API-Design ändert, wenn der primäre Aufrufer ein Agent und kein menschlicher Entwickler ist.

Wichtige Erkenntnisse

• Ein Modellkatalog macht die Modellauswahl von einer fest codierten Zeichenkette zu einem Laufzeit-Lookup, was den Wartungsaufwand reduziert, wenn Anbieter neue Modelle veröffentlichen.
• Coding-Agents profitieren davon, verschiedene Aufgabentypen (Autovervollständigung, Refactoring, Testgenerierung, Review) an unterschiedliche Modelle zu routen, anstatt ein Modell für alles zu verwenden.
• MCP-Anfragen für Modellkatalogdaten folgen typischerweise der Form einer Ressourcenliste oder eines Tool-Aufrufs; überprüfen Sie das genaue Schema anhand der Dokumentation des Anbieters, bevor Sie darauf aufbauen.
• TokenLab veröffentlicht ein Model Data Center unter /models/data und ein Modellverzeichnis unter /models; betrachten Sie diese als den Ort, an dem aktuelle Modellnamen zu überprüfen sind, nicht diesen Artikel, da sich Modellangebote häufig ändern.

Was in einen MCP-Modellkatalog-Eintrag gehört

Ein nützlicher Katalogeintrag für einen Coding-Agenten benötigt mehr als nur einen Modellnamen. Mindestens sollten Entwickler und Konsumenten Folgendes erwarten:

• Modell-Identifikator: die exakte Zeichenkette, die die API erwartet, da Anbieter Modellnamen oft präzise versionieren (eine Nichtübereinstimmung hier ist einer der häufigsten Integrationsfehler).
• Anbieter: welches Unternehmen oder welche Plattform das Modell bereitstellt, relevant, wenn ein Katalog mehrere Anbieter aggregiert.
• Unterstützung von Modalitäten: Text, Code, Bild oder Video. Ein Katalog, der Coding-Modelle wie Kimi K2.7 Code mit Bildmodellen wie Nano Banana Pro mischt, benötigt ein Feld, mit dem ein Agent nach dem filtern kann, was er tatsächlich benötigt.
• Kontextfenster: Token-Limits sind für Coding-Agents, die in großen Repositories arbeiten, enorm wichtig.
• Kostenfelder: Preise für Eingabe- und Ausgabetoken, idealerweise getrennt, da Coding-Agents oft asymmetrische, eingabelastige Arbeitslasten haben (großer Dateikontext, kleine Diff-Ausgabe).
• Status: aktuell, veraltet (deprecated) oder für die Außerbetriebnahme geplant. Dies ist das Feld, das stille Ausfälle verhindert.
• Tags zur Aufgabeneignung: optionale, aber nützliche Metadaten wie „coding“, „low-cost routing“ oder „open-weight“, damit ein Agent filtern kann, ohne die Eigenschaften jedes Modells im Voraus zu kennen.

Keines dieser Felder ist in jedem Katalogformat eines Anbieters garantiert vorhanden. Bevor Sie eine Integration aufbauen, prüfen Sie das tatsächliche Schema, das beim verwendeten Anbieter dokumentiert ist. Überprüfen Sie für TokenLab-Modelle spezifisch den aktuellen Feldsatz und den Update-Rhythmus unter /models/data, anstatt anzunehmen, dass sie mit diesem Artikel übereinstimmen. Katalogschemata ändern sich, wenn neue Modelle und Modalitäten hinzugefügt werden.

Beispiel: Abfrage eines Modellkatalogs über MCP

MCP kommuniziert typischerweise über JSON-RPC 2.0. Ein Client, der einen Server auffordert, verfügbare Modellressourcen aufzulisten, könnte eine Anfrage wie diese senden. Dieses Beispiel folgt dem allgemeinen MCP-Muster für Ressourcenlisten. Es ist kein Anspruch auf das Live-Schema eines bestimmten Anbieters. Bestätigen Sie exakte Methodennamen und Antwortfelder anhand von https://docs.tokenlab.sh oder der Dokumentation Ihres MCP-Servers, bevor Sie Produktionscode dagegen schreiben.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

Eine plausible Antwortform, wiederum illustrativ und kein verifiziertes Schema:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

Behandeln Sie die Kontextfenster-Werte, exakten Feldnamen oder die oben aufgeführten spezifischen Modelle nicht als bestätigte Fakten über eine Live-API. Sie zeigen die Form einer Anfrage und Antwort, nicht Preise oder Leistungsdaten. Ziehen Sie diese Zahlen aus der aktuellen Dokumentation des Anbieters oder von /models/data, wenn Sie bauen.

Modellauswahl nach Aufgabe: Eine Entscheidungs-Checkliste

Ein Modellkatalog ist nur nützlich, wenn der Agent oder der Entwickler, der den Agenten konfiguriert, eine Regel für die Zuordnung von Aufgabentyp zu Modell hat. Die folgende Tabelle ist ein Rahmenwerk für den Anfang, kein Benchmark-Ergebnis. Überprüfen Sie aktuelle Preis- und Leistungsversprechen anhand der Anbieterdokumentation und /models, bevor Sie sich in der Produktion auf eine Routing-Regel festlegen.

Coding-Agent-Aufgabe	Was am wichtigsten ist	Beispielmodelle zur Evaluierung
Autovervollständigung / Inline-Vorschläge	Geringe Latenz, niedrige Kosten pro Aufruf	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Refactoring über mehrere Dateien	Größeres Kontextfenster, starkes Code-Verständnis	Claude Sonnet 5, DeepSeek V4 Pro
Testgenerierung	Konsistente Formatierung, moderates Verständnis	Kimi K2.7 Code, Claude Sonnet 5
Code-Review / PR-Zusammenfassung	Starkes Verständnis, Fähigkeit, Diffs präzise zu referenzieren	Claude Sonnet 5, Gemini 3.5 Flash
Hochvolumige Batch-Aufgaben (Linting, Doc-Kommentare)	Kosten pro Token wichtiger als reine Leistungsfähigkeit	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Anforderung an offene Gewichte (Self-Host oder Lizenzbeschränkungen)	Offene Gewichte, außerhalb einer verwalteten API einsetzbar	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

Eine praktische Checkliste für den Aufbau der Routing-Logik selbst:

1. Enthält der Katalogeintrag ein Statusfeld, sodass Sie eine Veraltung (Deprecation) erkennen können, bevor ein Aufruf fehlschlägt?
2. Trennt der Katalog Coding-fähige Modelle von allgemeinen Text- oder Bildmodellen, sodass das Filtern keine fest codierten Listen erfordert?
3. Können Sie eine Kostenobergrenze pro Aufgabentyp festlegen und den Agenten das günstigste Modell auswählen lassen, das diese erfüllt, anstatt immer standardmäßig das leistungsfähigste (und teuerste) Modell zu wählen?
4. Ist für jede Aufgabenkategorie ein Fallback-Modell definiert, falls die primäre Wahl nicht verfügbar oder ratenbegrenzt ist?
5. Überprüfen Sie den Katalog regelmäßig und nicht nur bei der ersten Integration, da sich Modellangebote im Laufe der Zeit ändern?

Wo TokenLab in diesen Workflow passt

TokenLab pflegt ein Model Data Center unter /models/data und ein Modellverzeichnis unter /models, beide beobachtet mit Stand vom 14.07.2026. Überprüfen Sie diese Oberflächen auf aktuelle Modelllisten, anstatt sich auf einen statischen Artikel zu verlassen. Modellkataloge sind von Natur aus zeitkritisch. Die API-Dokumentation von TokenLab unter https://docs.tokenlab.sh ist der Ort, an dem exakte Anfrage- und Antwortschemata vor der Integration zu überprüfen sind.

Sie können einen Coding-Agenten bauen, der zwischen mehreren Modellen routet. Verwenden Sie Claude Sonnet 5 für Review-Aufgaben, DeepSeek V4 Flash für günstige, hochvolumige Vervollständigungen und Kimi K2.7 Code für die Testgenerierung. Behandeln Sie den Modell-Identifikator als Variable. Lösen Sie ihn zum Zeitpunkt der Anfrage gegen einen Katalog auf, nicht als Konstante, die in den Quellcode Ihres Agenten kompiliert wurde. Der praktische Schritt besteht darin, /models/data zu prüfen und die Anforderungsform, die Ihr MCP-Client benötigt, anhand der TokenLab-API-Dokumentation zu bestätigen. Implementieren Sie die Routing-Logik erst nach diesen Prüfungen in die Produktion.

Einschränkungen

Dieser Artikel beschreibt ein allgemeines Muster für MCP-Modellkataloge und das Routing von Coding-Agents. Er bestätigt nicht, dass ein spezifischer Anbieter, einschließlich TokenLab, jedes oben beschriebene Feld (Kontextfenster, Kostenfelder, Status, Aufgaben-Tags) exakt in dieser Form bereitstellt. Schemata, Feldnamen und verfügbare Modelle ändern sich häufig. Betrachten Sie die JSON-Beispiele in diesem Artikel als illustrativ für das allgemeine Anfrage- und Antwortmuster von MCP, nicht als verifiziertes Schema für einen Live-Endpunkt. Bestätigen Sie vor der Veröffentlichung exakte Modell-Identifikatoren, Preise und Kontextfenster anhand der aktuellen Dokumentation des Anbieters und anhand von /models/data.

FAQ

Definiert MCP selbst ein Standard-Modellkatalogschema?

MCP definiert allgemeine Muster für Ressourcen und Tools über JSON-RPC, aber die exakten Felder in einem Modellkatalog (Preise, Kontextfenster, Status) hängen davon ab, wie der Server, der MCP implementiert, diese Daten bereitstellt. Überprüfen Sie das spezifische Schema mit dem Server oder Anbieter, in den Sie integrieren.

Sollte ein Coding-Agent immer das leistungsfähigste verfügbare Modell verwenden?

Nicht unbedingt. Aufgaben wie Autovervollständigung sind latenz- und kostenempfindlich, während Refactorings über mehrere Dateien hinweg von stärkerem logischen Verständnis und einem größeren Kontext profitieren. Ein Katalog mit Aufgaben-Tags und Kostenfeldern ermöglicht es Ihnen, nach Aufgabe zu routen, anstatt standardmäßig ein Modell für alles zu verwenden.

Wie oft sollte ich den Modellkatalog, von dem mein Agent abhängt, erneut überprüfen?

Modellangebote ändern sich oft genug, dass eine einmalige Integration nicht ausreicht. Bauen Sie Ihre Routing-Logik so auf, dass sie den Katalog abfragt, anstatt Modell-Identifikatoren dauerhaft zu cachen, und überprüfen Sie /models/data oder die Dokumentation Ihres Anbieters in regelmäßigen Abständen.

Beginnen Sie damit, die aktuellen Listen unter /models/data zu überprüfen und die Anforderungsform, die Ihr MCP-Client benötigt, anhand der TokenLab-API-Dokumentation zu bestätigen, bevor Sie die Routing-Logik in die Produktion integrieren.