TokenLab pour les agents : modèles lisibles par machine, tarification, SDK et MCP

TokenLab MCP est un serveur de protocole de contexte de modèle (MCP) en lecture seule qui donne à un agent de codage un accès direct et structuré au catalogue de modèles publics, à la tarification et à l'aperçu de l'API de TokenLab avant même qu'il n'écrive une seule ligne de code d'intégration. Il répond aux questions de découverte — quels ID de modèles existent actuellement, combien coûtent-ils, quelle modalité prennent-ils en charge — et il n'appelle pas d'API d'inférence payantes en votre nom.

De nombreux bugs d'intégration d'agents ne commencent pas au premier appel d'API, ils commencent plus tôt, lorsque l'agent choisit un ID de modèle à partir d'un exemple obsolète, d'une mémoire cache ou d'un tutoriel vieux de six mois, et ne découvre l'inadéquation qu'après une erreur 404 ou une surprise tarifaire.

Les agents de codage écrivent vite. Ils ne lisent pas toujours en premier. Parallèlement à TokenLab MCP, TokenLab publie un llms.txt compact, un llms-full.txt plus complet et des fichiers JSON de données de modèles publics — les mêmes surfaces de catalogue de modèles et de tarification que vous pouvez parcourir vous-même — afin qu'un agent puisse vérifier les ID de modèles et les coûts actuels avant de coder quoi que ce soit en dur.

Cet article couvre ce que sont ces surfaces, ce qu'elles ne sont pas, et comment connecter un agent pour les utiliser avant qu'il ne code en dur un nom de modèle. Pour la référence complète des points de terminaison, consultez la documentation d'intégration.

Points clés à retenir

• TokenLab publie des aperçus d'API lisibles par les agents sur api.tokenlab.sh/llms.txt et llms-full.txt, le domaine web redirigeant vers la même source.
• Les fichiers du centre de données de modèles publics (JSON du catalogue, JSON le plus récent, JSON des tendances, markdown récapitulatif) donnent aux agents un instantané interrogeable de ce que TokenLab propose actuellement.
• Le serveur TokenLab MCP expose list_models, get_model, get_model_pricing et get_api_overview — et il est en lecture seule. Il ne relaie pas l'inférence payante.
• La documentation publique recommande aux agents d'appeler /v1/models ou de lire llms.txt avant de coder en dur un nom de modèle, et d'utiliser le filtrage recommended_for pour les tâches autres que le chat, comme l'image, la vidéo ou l'embedding.
• La lecture des points de terminaison de modèle et de tarification avant de réessayer une requête non-chat ayant échoué évite les appels répétés et infructueux vers la mauvaise famille de modèles.

Pourquoi les agents choisissent-ils des ID de modèles obsolètes en premier lieu ?

Les agents de codage génèrent des ID de modèles à partir de ce qu'ils ont appris pendant leur entraînement, et non à partir de ce qui est actuellement disponible. Ces données d'entraînement ont une date limite, donc le sens interne de l'agent de ce qu'est « le modèle actuel » est fixé à ce qui était vrai lors de la dernière mise à jour de ses poids. Lorsque vous demandez à un agent d'appeler une API de modèle, il utilisera avec confiance l'ID dont il se souvient — même si cet ID a été renommé, déprécié ou remplacé depuis.

Ce n'est pas un bug dans le raisonnement de l'agent ; c'est une limitation structurelle de tout système qui repose sur des connaissances mémorisées au lieu d'une recherche en direct. La solution n'est pas un prompt plus intelligent — c'est donner à l'agent un endroit où vérifier avant d'écrire du code.

C'est à cela que servent les fichiers de données de modèles et l'API de TokenLab. Avant de générer une requête, un agent (ou l'humain examinant sa sortie) peut interroger un point de terminaison en direct pour confirmer que l'ID du modèle existe réellement, quelle modalité il prend en charge et ce qu'il coûte — au lieu de faire confiance à un nom tiré de la mémoire.

Point de terminaison	Objectif
https://tokenlab.sh/model-data/catalog.json	Catalogue complet des modèles suivis, structuré pour une recherche programmatique
https://tokenlab.sh/model-data/latest.json	Liste actuelle des modèles dans un format léger et adapté aux agents
https://tokenlab.sh/en/models	Navigateur de modèles lisible par l'humain
https://tokenlab.sh/en/pricing	Tarification actuelle par modèle et par modalité

Un article de blog — y compris celui-ci — est un instantané. Il reflète ce qui était vrai au moment où il a été écrit, et il deviendra obsolète de la même manière que les données d'entraînement d'un agent. Les points de terminaison en direct n'ont pas ce problème : ils reflètent ce qui est vrai en ce moment, c'est pourquoi il est plus sûr de les vérifier avant de déployer du code, plutôt qu'un article statique.

Ce que TokenLab expose pour la découverte par les agents

La couche llms.txt

https://api.tokenlab.sh/llms.txt est un aperçu compact et lisible par les agents de l'API : quels points de terminaison existent, à quoi ressemble une requête et où trouver des détails plus approfondis. Il est conçu pour être suffisamment court pour qu'un agent puisse le lire dans une seule fenêtre de contexte sans brûler un gros budget de jetons juste pour s'orienter.

https://api.tokenlab.sh/llms-full.txt est la version plus complète — plus de détails sur les points de terminaison, plus d'exemples, plus de surface nécessaire à un agent avant de générer une intégration fonctionnelle plutôt qu'un brouillon.

Si vous arrivez sur le domaine web au lieu de l'hôte API, tokenlab.sh/llms.txt et tokenlab.sh/llms-full.txt redirigent vers les mêmes sources hébergées par l'API. C'est important pour les agents : quel que soit le point d'entrée qu'ils parcourent ou récupèrent, ils arrivent sur le même texte canonique, et non sur deux copies divergentes.

Le centre de données de modèles

Au-delà de l'aperçu textuel, TokenLab publie des fichiers JSON structurés qu'un agent (ou un script de build) peut récupérer directement :

• https://tokenlab.sh/model-data/catalog.json — le catalogue de modèles complet.
• https://tokenlab.sh/model-data/latest.json — un instantané orienté vers ce qui est actuel en ce moment.
• https://tokenlab.sh/model-data/summary.md — un résumé markdown lisible par l'humain et l'agent, utile lorsque vous souhaitez un diff rapide par rapport à ce que votre base de code code actuellement en dur.

Ce sont des fichiers statiques et récupérables. Un agent construisant un fichier de configuration, un modèle .env ou une liste déroulante de sélection de modèles peut récupérer le JSON directement au lieu de demander à un humain de coller une liste de modèles qui sera à nouveau obsolète dans deux semaines.

Le serveur MCP — en lecture seule, et il vaut mieux être précis à ce sujet

https://github.com/hedging8563/tokenlab-mcp-server est public. Il expose quatre outils pertinents pour la découverte :

• list_models — énumérer ce qui est disponible, éventuellement filtré.
• get_model — récupérer les détails sur un ID de modèle spécifique.
• get_model_pricing — récupérer la tarification actuelle pour un modèle spécifique.
• get_api_overview — l'équivalent natif MCP de la lecture de llms.txt.

La contrainte importante : ce serveur est en lecture seule. Il n'appelle pas d'API d'inférence payantes en votre nom et ne relaie pas les requêtes de génération. Il répond aux questions sur les modèles, la tarification et la forme de l'API. Si votre agent doit réellement exécuter une inférence, il passe toujours par l'API normale de TokenLab avec votre propre clé — le serveur MCP est une couche de découverte, pas une couche d'exécution. Confondre les deux est une erreur courante qu'il vaut mieux éviter explicitement dans tout prompt d'agent ou fichier de compétence que vous écrivez.

Exemple de découverte TokenLab MCP

TokenLab expose un serveur de protocole de contexte de modèle (MCP) en lecture seule qui permet aux agents de codage de découvrir les modèles et la tarification disponibles sans effectuer d'inférence. Le serveur MCP fournit quatre outils :

• list_models — lister les modèles disponibles, éventuellement filtrés par recommended_for (par ex. image, video, embedding, rerank, translation)
• get_model — récupérer les détails d'un modèle spécifique
• get_model_pricing — récupérer les informations de tarification d'un modèle spécifique
• get_api_overview — récupérer un résumé de l'API TokenLab

Exemple : lister les modèles via MCP

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

Exemple : filtrer les modèles par utilisation recommandée

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

Si vous préférez interroger l'API directement au lieu de passer par MCP, les appels REST équivalents sont :

# Lister tous les modèles
curl https://api.tokenlab.sh/v1/models \
  -H "Authorization: Bearer sk-KEY"

# Lister les modèles recommandés pour les tâches d'image
curl "https://api.tokenlab.sh/v1/models?recommended_for=image" \
  -H "Authorization: Bearer sk-KEY"

Notez que le serveur MCP est strictement en lecture seule — il est destiné à la découverte (lister les modèles, inspecter la tarification et examiner les capacités de l'API) et n'effectue aucune inférence lui-même.

Pour les instructions de configuration et les détails d'intégration, voir :

• Serveur TokenLab MCP
• Compétence d'agent de codage

Le dépôt de compétences

https://github.com/hedging8563/tokenlab-skills regroupe ce modèle de découverte dans quelque chose qu'un framework d'agent de codage peut charger directement — une définition de compétence qui dit à l'agent « lis ceci avant d'écrire du code d'intégration TokenLab », plutôt que de compter sur l'agent pour décider indépendamment de vérifier.

Le flux de travail recommandé pour l'agent

La documentation publique décrit une séquence spécifique, qui tient bien la route en pratique :

1. Avant de coder en dur un nom de modèle, appelez /v1/models ou lisez llms.txt pour confirmer que l'ID existe réellement en ce moment.
2. Pour les tâches autres que le chat — image, vidéo, musique, 3D, TTS, STT, embedding, rerank, traduction — filtrez avec /v1/models?recommended_for=<task> au lieu de supposer qu'un modèle orienté chat gère la tâche, ou de deviner un nom de modèle de mémoire.
3. Avant de réessayer une requête non-chat ayant échoué, lisez /v1/models/:model et /v1/models/:model/pricing. Une requête ayant échoué contre un modèle de mauvaise modalité échouera souvent à nouveau lors d'une nouvelle tentative avec la même entrée ; vérifier la modalité et la tarification réelles du modèle permet d'économiser une boucle de nouvelle tentative.

Cette séquence est importante car elle anticipe les deux modes de défaillance les plus courants : mauvais ID de modèle et mauvaise famille de modèles pour la tâche.

Check-list pratique pour intégrer cela dans un agent

Étape	Quoi vérifier	Où
1	Cet ID de modèle se résout-il toujours ?	/v1/models ou llms.txt
2	Est-ce la bonne famille de modèles pour la tâche (chat vs image vs embedding, etc.) ?	/v1/models?recommended_for=<task>
3	Quelle est la tarification actuelle d'entrée/sortie pour ce modèle ?	/v1/models/:model/pricing ou get_model_pricing (MCP)
4	Quelle est la fenêtre de contexte et la modalité ?	/v1/models/:model ou get_model (MCP)
5	Existe-t-il un modèle plus récent avec un nom similaire qui a remplacé celui-ci ?	catalog.json / latest.json
6	L'agent a-t-il lu llms.txt avant de générer le code d'intégration ?	Confirmer dans le journal d'appels d'outils de l'agent

Si un agent saute les étapes 1 et 2, tout ce qui suit — nouvelles tentatives, gestion des erreurs, estimations de coûts — est basé sur une supposition plutôt que sur un fait.

Pourquoi cela est important spécifiquement pour les tâches non-chat

Les modèles de chat reçoivent la plupart de l'attention, mais le filtre recommended_for existe parce que les tâches non-chat échouent de manières moins évidentes. Un modèle conçu pour la génération texte-à-texte renvoyant une réponse malformée à une requête d'image ne génère pas toujours une erreur claire et explicite. Parfois, il renvoie simplement quelque chose que l'agent ne sait pas analyser.

Filtrer par recommended_for=image, recommended_for=video, recommended_for=embedding, etc., réduit l'ensemble des candidats avant même que l'agent n'écrive un corps de requête. Étant donné le nombre d'entrées distinctes de génération d'images qui peuvent exister dans le catalogue de modèles à tout moment — 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 — deviner lequel est « le modèle d'image » de mémoire est exactement le mode de défaillance que ce flux de travail est conçu pour prévenir. La génération vidéo a son propre ensemble de modèles spécifiques à la tâche (seedance, veo-3, entre autres) avec des tarifications et des formes de modalité différentes ; la même logique de filtrage s'applique.

Pour la tarification actuelle exacte, les limites de contexte et la modalité sur tout modèle spécifique nommé ici, consultez directement le catalogue de modèles et la page de tarification — c'est tout l'intérêt de ne pas le coder en dur dans un article de blog non plus. Si vous évaluez des modèles spécifiquement pour un travail de développement piloté par agent, consultez les meilleurs modèles d'IA pour le codage 2026.

Ce que cela ne fait pas

Être précis ici est tout aussi important que le flux de travail lui-même :

• Le serveur MCP n'exécute pas d'inférence payante. Il répond aux questions de découverte. L'exécution d'une requête de génération réelle passe toujours par l'API standard avec vos propres identifiants.
• llms.txt et les fichiers du centre de données de modèles sont des instantanés périodiques, pas une connexion à une base de données en direct. Le timing de rafraîchissement n'est pas fixé à un calendrier strict, donc traitez toute date sur ces pages comme approximative. Pour tout ce qui est sensible au prix ou à la sécurité, le point de terminaison de tarification et l'API du tableau de bord restent la source de vérité au moment de la requête.
• Rien de tout cela ne remplace la lecture de la documentation complète de l'API pour l'authentification, les limites de débit ou la sémantique de gestion des erreurs. Les surfaces de découverte disent à un agent ce qui existe ; elles ne remplacent pas la documentation d'intégration sur la façon de l'appeler correctement.

FAQ

Que doit lire un agent avant de choisir un modèle TokenLab ? Lisez llms.txt (ou llms-full.txt pour plus de détails) et appelez /v1/models avant de coder en dur un ID de modèle. Pour les tâches non-chat, filtrez avec recommended_for plutôt que de deviner un nom de modèle de mémoire.

TokenLab MCP appelle-t-il des API d'inférence payantes ? Non. Le serveur public TokenLab MCP est en lecture seule. Ses outils (list_models, get_model, get_model_pricing, get_api_overview) répondent aux questions de découverte sur les modèles et la tarification. Les appels d'inférence réels passent par l'API standard avec votre propre clé.

Quand un agent doit-il utiliser recommended_for ? Chaque fois que la tâche n'est pas du simple chat — image, vidéo, musique, 3D, TTS, STT, embedding, rerank ou traduction. Filtrer par tâche réduit la liste des modèles aux variantes réellement construites pour cette modalité, au lieu de supposer qu'un modèle orienté chat la gérera.

Comment cela réduit-il les ID de modèles obsolètes dans le code généré ? En faisant de la découverte la première étape plutôt qu'une réflexion après coup. Un agent qui lit llms.txt, vérifie /v1/models et confirme la tarification avant d'écrire du code travaille à partir d'un instantané actuel plutôt que d'une mémoire au moment de l'entraînement qui peut déjà avoir plusieurs générations de modèles de retard.

Sources et fraîcheur

• TokenLab llms.txt — https://api.tokenlab.sh/llms.txt — observé le 09/07/2026
• TokenLab llms-full.txt — https://api.tokenlab.sh/llms-full.txt — observé le 09/07/2026
• Documentation du serveur TokenLab MCP — https://docs.tokenlab.sh/integrations/tokenlab-mcp-server — observé le 09/07/2026
• Documentation de la compétence d'intégration API TokenLab — https://docs.tokenlab.sh/integrations/coding-agent-skill — observé le 09/07/2026
• Dépôt du serveur TokenLab MCP — https://github.com/hedging8563/tokenlab-mcp-server — observé le 09/07/2026
• Dépôt des compétences TokenLab — https://github.com/hedging8563/tokenlab-skills — observé le 09/07/2026
• Centre de données de modèles TokenLab — https://tokenlab.sh/model-data/catalog.json, https://tokenlab.sh/model-data/latest.json, https://tokenlab.sh/model-data/summary.md — observé le 09/07/2026

Les ID de modèles, la tarification et les détails de modalité dans cet article reflètent un instantané pris au moment de la rédaction. Les pages d'instantanés comme celle-ci et llms.txt sont mises à jour périodiquement, mais pas selon un rythme fixe ou garanti — ne construisez pas de logique de nouvelle tentative ou d'estimations de coûts autour d'un intervalle de rafraîchissement supposé. Vérifiez les valeurs actuelles par rapport à la page de tarification et au catalogue de modèles avant de déployer du code d'intégration. Pour un examen plus approfondi de la façon dont la tarification est structurée à travers les familles de modèles, voir Tarification de l'API Gemini pour les développeurs.

Prochaines étapes avec TokenLab MCP

Pour commencer à utiliser TokenLab MCP pour la découverte de modèles :

1. Obtenez une clé API depuis le tableau de bord TokenLab.
2. Connectez votre agent en suivant le guide d'intégration de l'agent de codage.
3. Parcourez le catalogue directement sur tokenlab.sh/en/models pour voir la couverture actuelle des modèles et les métadonnées.
4. Vérifiez la tarification pour les modèles que vous prévoyez d'utiliser sur tokenlab.sh/en/pricing.

Si vous décidez quels modèles correspondent à votre flux de travail, consultez nos analyses sur les meilleurs modèles d'IA pour le codage en 2026 et la tarification de l'API Gemini pour les développeurs.

Gardez à l'esprit que MCP est strictement une couche de découverte — il fait apparaître les métadonnées, les capacités et la tarification des modèles afin que votre agent puisse prendre des décisions éclairées. Les appels d'inférence réels passent toujours par l'API TokenLab standard en utilisant votre propre clé API ; MCP ne route ni ne relaie les requêtes.