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

Un catalogue de modèles MCP pour les agents de codage est une liste structurée et interrogeable des modèles disponibles qu'un agent peut lire via le Model Context Protocol, plutôt que de s'appuyer sur des noms de modèles codés en dur dans le code source. Cela permet à un agent, un plugin IDE ou une couche d'orchestration de sélectionner un modèle au moment de l'exécution en fonction du type de tâche, de la fenêtre de contexte ou du plafond de coût, plutôt que d'utiliser une chaîne de caractères saisie par un développeur il y a six mois et oubliée depuis.

C'est plus important qu'il n'y paraît. Les agents de codage appellent constamment des modèles pour l'autocomplétion, les refactorisations multi-fichiers, la génération de tests ou la rédaction de messages de commit. Chacune de ces tâches nécessite un modèle idéal différent. Si l'agent ne peut pas découvrir quels modèles existent et à quoi ils servent, quelqu'un doit continuer à modifier un fichier de configuration à chaque fois qu'un fournisseur publie une nouvelle version. Cet article explique ce que doit contenir une entrée de catalogue de modèles, comment sont formées les requêtes de type MCP pour ce catalogue et comment décider quels modèles diriger vers quelles tâches de codage.

Points clés à retenir

• Un catalogue de modèles transforme la sélection de modèles, passant d'une chaîne codée en dur à une recherche au moment de 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 de l'acheminement 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 du catalogue de modèles suivent généralement une forme de liste de ressources ou d'appel d'outil ; le schéma exact doit être vérifié par rapport à la propre documentation du fournisseur avant de construire votre solution.
• TokenLab publie un Model Data Center sur /models/data et un répertoire de modèles sur /models ; considérez ces emplacements comme les sources pour vérifier les noms de modèles actuels, et non cet article, car les gammes de modèles changent fréquemment.

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 que l'équipe n'a aucun processus pour adopter.

Un catalogue lisible par machine modifie le mode de défaillance. Au lieu qu'un agent tombe en panne silencieusement lorsqu'un modèle est retiré, il peut interroger un catalogue, voir 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, l'agent (ou l'outillage du développeur) peut comparer les fenêtres de contexte listées, la prise en charge des modalités et les champs de coût avant de changer.

C'est également une condition préalable à toute stratégie sérieuse de routage de modèles. Si vous souhaitez envoyer des complétions à haut volume et à faible coût vers un modèle économique comme DeepSeek V4 Flash ou Gemini 3.5 Flash, et réserver un modèle plus puissant comme Claude Sonnet 5 pour les refactorisations multi-fichiers, la logique de routage a besoin d'une source de vérité sur les modèles actuels, leurs coûts et ce qu'ils prennent en charge. Sans cela, les règles de routage deviennent obsolètes tout comme les noms de modèles codés en dur.

TokenLab a écrit directement sur ce problème dans le contexte de rendre les informations sur les modèles dignes de confiance pour un agent, plutôt que quelque chose qu'un humain doit revérifier à la main. Voir agent-readable model truth pour l'argument plus large sur la vérité des modèles lisibles par agent, et agent-first API pour savoir comment la conception d'API change lorsque l'appelant principal est un agent plutôt qu'un développeur humain.

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 qui en construisent ou en consomment 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 inadéquation 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 ses besoins réels.
• Fenêtre de contexte : les limites de jetons (tokens) importent énormément 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 lourdes en entrée (contexte de fichier volumineux, petite sortie de diff).
• Statut : actuel, déprécié ou prévu pour le retrait. 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 "codage", "routage à faible coût" 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é par le fournisseur que vous utilisez. Pour les modèles servis spécifiquement par TokenLab, l'ensemble des champs actuels et la cadence de mise à jour doivent être vérifiés sur /models/data plutôt que supposés à partir de cet article, car 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 structurée comme suit. Cet exemple illustre le modèle général de liste de ressources MCP et ne constitue pas 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 par rapport à https://docs.tokenlab.sh ou la propre 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": "vérifier dans la doc du fournisseur",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "vérifier dans la doc du fournisseur",
        "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 existent ici pour montrer la forme d'une requête et d'une réponse, et non pour indiquer des prix ou des capacités. Récupérez toujours ces chiffres à partir de la documentation actuelle du fournisseur ou de /models/data au moment où vous construisez votre solution.

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

Un catalogue de modèles n'est utile que si l'agent (ou le développeur configurant 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 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 faire en sorte que l'agent sélectionne 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. Revérifiez-vous le catalogue selon un calendrier, et pas seulement lors de la première intégration, car les gammes de modèles changent avec le temps ?

Où TokenLab s'intègre dans ce flux de travail

TokenLab maintient un Model Data Center sur /models/data et un répertoire de modèles sur /models, tous deux observés au 14/07/2026. Ce sont les surfaces à vérifier pour les listes de modèles actuelles, plutôt que de s'appuyer sur un article statique, car 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.

Si vous construisez un agent de codage qui doit router entre des modèles comme Claude Sonnet 5 pour les tâches de revue, DeepSeek V4 Flash pour les complétions à haut volume bon marché, et Kimi K2.7 Code pour la génération de tests, le modèle pratique consiste à traiter l'identifiant du modèle comme une variable résolue au moment de la requête par rapport à un catalogue, et non comme une constante compilée dans le code source de votre agent. Commencez en examinant les listes actuelles sur /models/data et en confirmant 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.

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 de déployer, 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 façon dont le serveur implémentant MCP choisit d'exposer ces données. Vérifiez le schéma spécifique avec le serveur ou le 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.