Catalogue de modèles MCP pour les agents de codage : rendre le choix du modèle lisible par machine

Un agent de codage qui intègre des noms de modèles en dur finira inévitablement par réveiller quelqu'un à 2 heures du matin. Un catalogue de modèles MCP pour agents de codage change ce mode de défaillance. Au lieu d'une chaîne de caractères enfouie dans le code source, l'agent lit une liste structurée des modèles actuels, de leurs coûts, de leurs modalités et de leurs champs de statut au moment de la requête. Nous maintenons un catalogue similaire chez TokenLab, et nous le traitons comme la source de vérité pour le routage. Dans notre pipeline, le choix du modèle est une recherche, pas une constante.

Pourquoi les agents de codage ont besoin de données de modèles lisibles par machine

La plupart des intégrations d'agents de codage fonctionnent encore comme les intégrations API d'il y a dix ans. Un développeur choisit un nom de modèle, le colle dans une configuration ou une variable d'environnement, et déploie. Cela fonctionne jusqu'à ce que le fournisseur déprécie le modèle, modifie les tarifs ou publie une meilleure option. À ce moment-là, l'équipe n'a aucun processus pour l'adopter.

Un catalogue lisible par machine change ce mode de défaillance. Lorsqu'un modèle est retiré, l'agent peut interroger le catalogue, constater que le modèle a disparu ou est marqué comme déprécié, et basculer vers une alternative documentée. Au lieu qu'un développeur teste manuellement chaque nouvelle version, les outils peuvent comparer les fenêtres de contexte listées, la prise en charge des modalités et les champs de coût avant de basculer.

C'est également une condition préalable à un routage de modèle sérieux. Vous pourriez vouloir des complétions bon marché à haut volume sur DeepSeek V4 Flash ou Gemini 3.5 Flash. Vous pourriez réserver Claude Sonnet 5 pour des refactorisations multi-fichiers. La logique de routage a toujours besoin d'une source de vérité. Cette source doit indiquer quels modèles sont actuels, ce qu'ils coûtent et ce qu'ils prennent en charge. Sans cela, les règles de routage se dégradent de la même manière que les noms de modèles codés en dur.

TokenLab a écrit directement sur ce problème. Voir agent-readable model truth pour l'argumentation plus large, et agent-first API pour comprendre comment la conception d'une API change lorsque l'appelant principal est un agent plutôt qu'un développeur humain.

Points clés à retenir

• Un catalogue de modèles transforme la sélection de modèles d'une chaîne codée en dur en une recherche à l'exécution, ce qui réduit la charge de maintenance lorsque les fournisseurs publient de nouveaux modèles.
• Les agents de codage bénéficient du routage de différents types de tâches (autocomplétion, refactorisation, génération de tests, revue) vers différents modèles plutôt que d'utiliser un seul modèle pour tout.
• Les requêtes MCP pour les données de catalogue de modèles suivent généralement une forme de liste de ressources ou d'appel d'outil ; vérifiez le schéma exact par rapport à la documentation du fournisseur avant de construire votre solution.
• TokenLab publie un centre de données de modèles (Model Data Center) sur /models/data et un répertoire de modèles sur /models ; traitez-les comme le lieu de vérification des noms de modèles actuels, et non cet article, car les gammes de modèles changent fréquemment.

Ce qu'une entrée de catalogue de modèles MCP doit contenir

Une entrée de catalogue utile pour un agent de codage nécessite plus qu'un simple nom de modèle. Au minimum, les développeurs et les consommateurs devraient s'attendre à voir :

• Identifiant du modèle : la chaîne exacte attendue par l'API, car les fournisseurs versionnent souvent les noms avec précision (une erreur ici est l'un des bugs d'intégration les plus courants).
• Fournisseur : quelle entreprise ou plateforme sert le modèle, pertinent lorsqu'un catalogue agrège plusieurs fournisseurs.
• Prise en charge des modalités : texte, code, image ou vidéo. Un catalogue mélangeant des modèles de codage comme Kimi K2.7 Code avec des modèles d'image comme Nano Banana Pro a besoin d'un champ permettant à un agent de filtrer selon ce dont il a réellement besoin.
• Fenêtre de contexte : les limites de jetons (tokens) sont extrêmement importantes pour les agents de codage travaillant sur de grands dépôts.
• Champs de coût : tarification des jetons d'entrée et de sortie, idéalement séparés, car les agents de codage ont souvent des charges de travail asymétriques avec beaucoup d'entrées (contexte de fichier volumineux, petite sortie de diff).
• Statut : actuel, déprécié ou dont le retrait est prévu. C'est le champ qui empêche les pannes silencieuses.
• Tags d'adéquation aux tâches : métadonnées facultatives mais utiles telles que 'coding', 'low-cost routing' ou 'open-weight', afin qu'un agent puisse filtrer sans connaître les caractéristiques de chaque modèle à l'avance.

Aucun de ces champs n'est garanti d'exister dans le format de catalogue de chaque fournisseur. Avant de construire une intégration, vérifiez le schéma réel documenté chez le fournisseur que vous utilisez. Pour les modèles servis par TokenLab spécifiquement, vérifiez l'ensemble des champs actuels et la cadence de mise à jour sur /models/data plutôt que de supposer qu'ils correspondent à cet article. Les schémas de catalogue changent à mesure que de nouveaux modèles et modalités sont ajoutés.

Exemple : Demander un catalogue de modèles via MCP

MCP communique généralement via JSON-RPC 2.0. Un client demandant à un serveur de lister les ressources de modèles disponibles pourrait envoyer une requête comme celle-ci. Cet exemple suit le modèle général de liste de ressources MCP. Il ne s'agit pas d'une affirmation sur le schéma en direct d'un fournisseur spécifique. Confirmez les noms de méthodes exacts et les champs de réponse sur https://docs.tokenlab.sh ou la documentation de votre serveur MCP avant d'écrire du code de production.

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

Une forme de réponse plausible, encore une fois illustrative plutôt qu'un schéma vérifié :

{
  "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"]
      }
    ]
  }
}

Ne traitez pas les valeurs de fenêtre de contexte, les noms de champs exacts ou les modèles spécifiques listés ci-dessus comme des faits confirmés concernant une API en direct. Ils montrent la forme d'une requête et d'une réponse, pas des chiffres de tarification ou de capacité. Récupérez ces chiffres dans la documentation actuelle du fournisseur ou sur /models/data lorsque vous développez.

Choisir les modèles par tâche : une liste de contrôle décisionnelle

Un catalogue de modèles n'est utile que si l'agent ou le développeur qui configure l'agent dispose d'une règle pour faire correspondre le type de tâche au modèle. Le tableau ci-dessous est un cadre de départ, pas un résultat de benchmark. Vérifiez les tarifs actuels et les capacités revendiquées par rapport à la documentation du fournisseur et à /models avant de vous engager dans une règle de routage en production.

Tâche de l'agent de codage	Ce qui compte le plus	Exemples de modèles à évaluer
Autocomplétion / suggestions en ligne	Faible latence, faible coût par appel	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Refactorisation multi-fichiers	Fenêtre de contexte plus large, fort raisonnement sur le code	Claude Sonnet 5, DeepSeek V4 Pro
Génération de tests	Formatage cohérent, raisonnement modéré	Kimi K2.7 Code, Claude Sonnet 5
Revue de code / résumé de PR	Raisonnement fort, capacité à référencer les diffs avec précision	Claude Sonnet 5, Gemini 3.5 Flash
Tâches par lots à haut volume (linting, commentaires de doc)	Coût par jeton plutôt que capacité brute	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Exigence de poids ouverts (auto-hébergement ou contraintes de licence)	Poids ouverts, déployable en dehors d'une API gérée	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

Une liste de contrôle pratique pour construire la logique de routage elle-même :

1. L'entrée du catalogue inclut-elle un champ de statut, afin que vous puissiez détecter une dépréciation avant qu'un appel n'échoue ?
2. Le catalogue sépare-t-il les modèles capables de coder des modèles de texte ou d'image généraux, afin que le filtrage ne nécessite pas de listes codées en dur ?
3. Pouvez-vous définir un plafond de coût par type de tâche et demander à l'agent de sélectionner le modèle le moins cher qui le respecte, plutôt que de toujours choisir par défaut l'option la plus capable (et la plus chère) ?
4. Existe-t-il un modèle de secours défini pour chaque catégorie de tâche, au cas où le choix principal serait indisponible ou limité en débit ?
5. Vérifiez-vous le catalogue selon un calendrier, et non seulement lors de l'intégration initiale, car les gammes de modèles changent avec le temps ?

Où TokenLab s'inscrit dans ce flux de travail

TokenLab maintient un centre de données de modèles sur /models/data et un répertoire de modèles sur /models, tous observés au 14/07/2026. Consultez ces surfaces pour les listes de modèles actuelles plutôt que de vous fier à un article statique. Les catalogues de modèles sont intrinsèquement sensibles au temps. La documentation de l'API de TokenLab sur https://docs.tokenlab.sh est l'endroit où vérifier les schémas de requête et de réponse exacts avant l'intégration.

Vous pouvez construire un agent de codage qui route entre plusieurs modèles. Utilisez Claude Sonnet 5 pour les tâches de revue, DeepSeek V4 Flash pour les complétions bon marché à haut volume, et Kimi K2.7 Code pour la génération de tests. Traitez l'identifiant du modèle comme une variable. Résolvez-le au moment de la requête par rapport à un catalogue, et non comme une constante compilée dans le code source de votre agent. L'étape pratique consiste à vérifier /models/data et à confirmer la forme de requête dont votre client MCP a besoin par rapport à la documentation de l'API TokenLab. Intégrez la logique de routage en production seulement après ces vérifications.

Limitations

Cet article décrit un modèle général pour les catalogues de modèles MCP et le routage des agents de codage. Il ne confirme pas qu'un fournisseur spécifique, y compris TokenLab, expose chaque champ décrit ci-dessus (fenêtre de contexte, champs de coût, statut, tags de tâche) exactement sous cette forme. Les schémas, les noms de champs et les modèles disponibles changent fréquemment. Traitez les exemples JSON de cet article comme illustratifs du modèle général de requête et de réponse de MCP, et non comme un schéma vérifié pour un point de terminaison en direct. Avant le déploiement, confirmez les identifiants de modèles exacts, la tarification et les fenêtres de contexte par rapport à la documentation actuelle du fournisseur et à /models/data.

FAQ

MCP définit-il lui-même un schéma de catalogue de modèles standard ?

MCP définit des modèles généraux pour les ressources et les outils via JSON-RPC, mais les champs exacts dans un catalogue de modèles (tarification, fenêtre de contexte, statut) dépendent de la manière dont le serveur implémentant MCP choisit d'exposer ces données. Vérifiez le schéma spécifique auprès du serveur ou du fournisseur avec lequel vous vous intégrez.

Un agent de codage doit-il toujours utiliser le modèle le plus capable disponible ?

Pas nécessairement. Les tâches comme l'autocomplétion sont sensibles à la latence et au coût, tandis que les refactorisations multi-fichiers bénéficient d'un raisonnement plus fort et d'un contexte plus large. Un catalogue avec des tags de tâche et des champs de coût vous permet de router par tâche plutôt que de choisir par défaut un seul modèle pour tout.

À quelle fréquence dois-je revérifier le catalogue de modèles dont dépend mon agent ?

Les gammes de modèles changent assez souvent pour qu'une intégration unique ne soit pas suffisante. Construisez votre logique de routage pour interroger le catalogue plutôt que de mettre en cache les identifiants de modèles de façon permanente, et vérifiez /models/data ou la documentation de votre fournisseur selon un calendrier régulier.

Commencez par examiner les listes actuelles sur /models/data et confirmez la forme de requête dont votre client MCP a besoin par rapport à la documentation de l'API TokenLab avant d'intégrer la logique de routage en production.