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

Ein MCP-Modellkatalog für Coding-Agents ist eine strukturierte, abfragbare Liste verfügbarer Modelle, die ein Agent über das Model Context Protocol lesen kann, anstatt sich auf hartcodierte Modellnamen im Quellcode zu verlassen. Er ermöglicht es einem Agenten, einem IDE-Plugin oder einer Orchestrierungsschicht, ein Modell zur Laufzeit basierend auf Aufgabentyp, Kontextfenster oder Kostenobergrenze auszuwählen, anstatt auf einen String zu setzen, den ein Entwickler vor sechs Monaten eingegeben und vergessen hat zu aktualisieren.

Das ist wichtiger, als es klingt. Coding-Agents rufen ständig Modelle auf: für Autocomplete, für Refactorings über mehrere Dateien hinweg, für die Testgenerierung oder für das Entwerfen von Commit-Nachrichten. Jede dieser Aufgaben erfordert ein anderes ideales Modell. Wenn der Agent nicht herausfinden kann, welche Modelle existieren und wofür sie gut sind, muss jemand jedes Mal eine Konfigurationsdatei bearbeiten, wenn ein Anbieter eine neue Version veröffentlicht. Dieser Artikel erläutert, was ein Modellkatalogeintrag enthalten sollte, wie MCP-artige Anfragen für diesen Katalog gestaltet sind und wie man entscheidet, welche Modelle welchen Coding-Aufgaben zugewiesen werden.

Wichtige Erkenntnisse

• Ein Modellkatalog verwandelt die Modellauswahl von einem hartcodierten String in eine Laufzeit-Abfrage, was den Wartungsaufwand reduziert, wenn Anbieter neue Modelle veröffentlichen.
• Coding-Agents profitieren davon, verschiedene Aufgabentypen (Autocomplete, Refactor, Testgenerierung, Review) an unterschiedliche Modelle weiterzuleiten, anstatt ein Modell für alles zu verwenden.
• MCP-Anfragen für Modellkatalogdaten folgen typischerweise einer resource-list- oder tool-call-Struktur; das genaue Schema sollte anhand der Dokumentation des Anbieters überprüft werden, 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, um aktuelle Modellnamen zu verifizieren, nicht diesen Artikel, da sich das Modellangebot häufig ändert.

Warum Coding-Agents maschinenlesbare Modelldaten benötigen

Die meisten Coding-Agent-Integrationen funktionieren immer noch so, wie API-Integrationen vor einem Jahrzehnt funktionierten: Ein Entwickler wählt einen Modellnamen aus, fügt ihn in eine Konfigurations- 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, für deren Einführung das Team keinen Prozess hat.

Ein maschinenlesbarer Katalog ändert das Fehlerverhalten. Anstatt dass ein Agent stillschweigend abstürzt, wenn ein Modell eingestellt wird, kann er einen Katalog abfragen, feststellen, dass das Modell nicht mehr verfügbar oder als veraltet markiert ist, und auf eine dokumentierte Alternative zurückgreifen. Anstatt dass ein Entwickler jede neue Version manuell benchmarkt, kann der Agent (oder das Tooling des Entwicklers) die aufgeführten Kontextfenster, die Modalitätsunterstützung und die Kostenfelder vergleichen, bevor er wechselt.

Dies ist auch eine Voraussetzung für jede ernsthafte Modell-Routing-Strategie. Wenn Sie kostengünstige Completions mit hohem Volumen an ein preiswertes Modell wie DeepSeek V4 Flash oder Gemini 3.5 Flash senden und ein stärkeres Modell wie Claude Sonnet 5 für Refactorings über mehrere Dateien hinweg reservieren möchten, benötigt die Routing-Logik eine Quelle der Wahrheit darüber, welche Modelle aktuell sind, was sie kosten und was sie unterstützen. Ohne dies verrotten Routing-Regeln genauso wie hartcodierte Modellnamen.

TokenLab hat direkt über dieses Problem geschrieben, im Kontext der Umwandlung von Modellinformationen in etwas, dem ein Agent vertrauen kann, anstatt etwas, das ein Mensch von Hand nachprüfen muss. Siehe agent-readable model truth für das breitere Argument über agentenlesbare Modellwahrheit und agent-first API für die Art und Weise, wie sich das API-Design ändert, wenn der primäre Aufrufer ein Agent und kein menschlicher Entwickler ist.

Was gehört in einen MCP-Modellkatalogeintrag?

Ein nützlicher Katalogeintrag für einen Coding-Agenten benötigt mehr als nur einen Modellnamen. Mindestens sollten Entwickler, die einen solchen erstellen oder nutzen, Folgendes erwarten:

• Modell-Identifikator: der exakte String, den die API erwartet, da Anbieter Modellnamen oft präzise versionieren (eine Abweichung hier ist einer der häufigsten Integrationsfehler).
• Anbieter: welches Unternehmen oder welche Plattform das Modell bereitstellt, relevant wenn ein Katalog mehrere Anbieter aggregiert.
• Modalitätsunterstützung: 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, das es einem Agenten ermöglicht, nach dem zu filtern, was er tatsächlich benötigt.
• Kontextfenster: Token-Limits sind enorm wichtig für Coding-Agents, die in großen Repositories arbeiten.
• Kostenfelder: Preise für Input- und Output-Token, idealerweise getrennt, da Coding-Agents oft asymmetrische, Input-lastige Workloads haben (großer Dateikontext, kleiner Diff-Output).
• Status: aktuell, veraltet oder zur Einstellung geplant. Dies ist das Feld, das stillschweigende Fehler 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 von Ihnen verwendeten Anbieter dokumentiert ist. Speziell für von TokenLab bereitgestellte Modelle sollten das aktuelle Feldset und die Update-Kadenz unter /models/data verifiziert werden, anstatt sie aus diesem Artikel anzunehmen, da sich Katalogschemas ändern, wenn neue Modelle und Modalitäten hinzugefügt werden.

Beispiel: Anfragen eines Modellkatalogs über MCP

MCP kommuniziert typischerweise über JSON-RPC 2.0. Ein Client, der einen Server bittet, verfügbare Modellressourcen aufzulisten, könnte eine Anfrage wie diese senden. Dieses Beispiel illustriert das allgemeine MCP-Ressourcenlisten-Muster und ist kein Anspruch auf das Live-Schema eines spezifischen 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 Antwortstruktur, 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 spezifischen oben aufgeführten Modelle nicht als bestätigte Fakten über eine Live-API. Sie existieren hier, um die Form einer Anfrage und Antwort zu zeigen, nicht um Preise oder Leistungsdaten anzugeben. Ziehen Sie diese Zahlen immer aus der aktuellen Dokumentation des Anbieters oder von /models/data zum Zeitpunkt Ihrer Entwicklung.

Modelle nach Aufgabe auswählen: 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
Autocomplete / 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-Reasoning	Claude Sonnet 5, DeepSeek V4 Pro
Testgenerierung	Konsistente Formatierung, moderates Reasoning	Kimi K2.7 Code, Claude Sonnet 5
Code-Review / PR-Zusammenfassung	Starkes Reasoning, Fähigkeit, Diffs präzise zu referenzieren	Claude Sonnet 5, Gemini 3.5 Flash
Batch-Aufgaben mit hohem Volumen (Linting, Doc-Kommentare)	Kosten pro Token wichtiger als reine Leistungsfähigkeit	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Open-Weight-Anforderung (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, damit Sie eine Einstellung 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 hartcodierten 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 die leistungsfähigste (und teuerste) Option 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 das Modellangebot im Laufe der Zeit ändert?

Wo TokenLab in diesen Workflow passt

TokenLab unterhält ein Model Data Center unter /models/data und ein Modellverzeichnis unter /models, beide beobachtet mit Stand vom 14.07.2026. Dies sind die Oberflächen, die auf aktuelle Modelllisten geprüft werden sollten, anstatt sich auf einen statischen Artikel zu verlassen, da Modellkataloge von Natur aus zeitkritisch sind. Die API-Dokumentation von TokenLab unter https://docs.tokenlab.sh ist der Ort, um exakte Anfrage- und Antwortschemas vor der Integration zu verifizieren.

Wenn Sie einen Coding-Agenten bauen, der zwischen Modellen wie Claude Sonnet 5 für Review-Aufgaben, DeepSeek V4 Flash für günstige Completions mit hohem Volumen und Kimi K2.7 Code für die Testgenerierung routen muss, ist das praktische Muster, den Modell-Identifikator als eine Variable zu behandeln, die zum Zeitpunkt der Anfrage gegen einen Katalog aufgelöst wird, nicht als eine Konstante, die in den Quellcode Ihres Agenten kompiliert wird. Beginnen Sie, indem Sie die aktuellen Listen unter /models/data überprüfen und die Anfrageform, die Ihr MCP-Client benötigt, anhand der TokenLab-API-Dokumentation bestätigen, bevor Sie die Routing-Logik in die Produktion integrieren.

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. Schemas, 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 bei dem Server oder Anbieter, in den Sie integrieren.

Sollte ein Coding-Agent immer das leistungsfähigste verfügbare Modell verwenden? Nicht unbedingt. Aufgaben wie Autocomplete sind latenz- und kostenempfindlich, während Refactorings über mehrere Dateien hinweg von stärkerem Reasoning und größerem 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? Das Modellangebot ändert 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.