Outil gratuit

Calculateur de tokens MCP

Les définitions d'outils sont envoyées à chaque requête, pas une seule fois. Collez l'URL de votre serveur MCP pour voir combien de tokens cela représente, quels outils pèsent le plus et ce que cela coûte.

Fonctionne avec les endpoints HTTP en streaming et SSE, par exemple https://mcp.example.com/mcp
Ce serveur nécessite une authentification
Utilisé pour cette seule requête et jamais conservé.

Les schémas sont allégés. Montrez maintenant ce qu'il reste.

Réduire le coût de contexte rend votre serveur moins cher à exploiter. Cela ne montre toujours pas à un client ce qu'il fait. Pointez MCP Showcase sur la même URL pour un playground en direct avec une documentation par outil.

Comment ça marche

link
Collez l'URL

Nous lisons les définitions d'outils annoncées par le serveur — exactement celles que reçoit un agent.

play_circle
Chaque outil est mesuré

Nom, description et schéma JSON d'entrée complet, car les trois sont envoyés au modèle à chaque tour.

checklist
Voyez le coût et les responsables

Total de tokens par requête, coût estimé pour 1 000 tours, et les outils classés selon le contexte que chacun consomme.

Les définitions d'outils se paient à chaque tour

C'est la partie qui surprend. Les définitions d'outils d'un serveur MCP ne sont pas chargées une fois au début d'une conversation : le modèle ne s'en souvient pas d'un tour à l'autre, si bien que la liste complète, avec toutes les descriptions et tous les schémas JSON d'entrée, est renvoyée à chaque requête. Quarante outils bavards ne sont pas un coût ponctuel ; c'est une taxe fixe sur chaque tour de chaque conversation que votre agent aura un jour.

Collez ci-dessus l'URL d'un serveur MCP : ce calculateur lit exactement ce que reçoit un agent, le mesure, et montre où se trouve réellement le poids.

Ce qui est mesuré

  • Total de tokens par requête — ce qui s'ajoute à votre fenêtre de contexte avant tout prompt système, historique de conversation ou résultat d'outil.
  • Coût pour 1 000 tours — le même chiffre exprimé en argent, ce qui est généralement ce qui fait comprendre le problème.
  • Tokens par outil, classés — presque toujours, quelques outils représentent l'essentiel du total, et ce sont rarement ceux auxquels on pense.

Comment le réduire

Par ordre d'efficacité. Supprimez les outils que personne n'appelle. Les serveurs les accumulent, et chacun est facturé à chaque tour, utile ou non. Raccourcissez les descriptions à une phrase claire indiquant ce que fait l'outil et quand l'utiliser : au delà, c'est généralement écrit pour un lecteur humain qui ne le verra jamais. Allégez les schémas d'entrée : les longues descriptions par propriété et les objets optionnels profondément imbriqués constituent le gros d'un outil lourd, et ils s'accumulent parce qu'un schéma est du JSON verbeux, pas de la prose.

Il y a une seconde raison, sans rapport avec l'argent : la justesse de la sélection d'outil baisse à mesure que la liste s'allonge. Un modèle qui choisit parmi quatre-vingts outils décrits de façon similaire se trompe bien plus souvent qu'un modèle qui choisit parmi huit — alléger la liste rend donc généralement l'agent meilleur, pas seulement moins cher.

À propos de l'estimation

Le calcul approxime environ 3,6 caractères par token, ce qui convient au texte très dense en JSON des définitions d'outils, et tombe généralement à 10–15 % près d'un vrai tokenizer. C'est l'outil adapté pour comparer des outils entre eux et repérer le superflu. Ce n'est pas l'outil adapté pour vérifier une facture, et la page le dit sur chaque résultat plutôt que de vous laisser le supposer.

Outils et guides associés

Moins d'outils, plus clairs, demandent plus de documentation, pas moins

Raccourcir les descriptions pour économiser du contexte rend votre serveur moins cher et votre agent plus précis. Cela le rend aussi plus difficile à comprendre pour un humain, ce qui devient un problème dès que quelqu'un doit l'évaluer. MCP Showcase règle cette tension : le modèle reçoit vos schémas allégés, tandis que vos prospects obtiennent un playground en direct avec une documentation générée et lisible pour chaque outil. Vous n'écrivez donc pas une description unique censée satisfaire deux lecteurs très différents.

Questions fréquentes

Parce que le modèle ne s'en souvient pas d'un tour à l'autre. La liste complète des outils, descriptions et schémas JSON compris, est envoyée à chaque requête pour que le modèle sache ce qu'il peut appeler. Cent outils bavards constituent une taxe fixe sur chaque tour de chaque conversation.

C'est une estimation, généralement à 10–15 % près d'un vrai tokenizer. Elle approxime à environ 3,6 caractères par token, ce qui correspond au texte très riche en JSON des définitions d'outils. Elle sert à comparer et à repérer le superflu, pas à vérifier une facture.

Trois choses, par ordre d'efficacité : supprimez les outils qu'un agent n'appellera jamais, ramenez les descriptions à une phrase claire disant ce que fait l'outil et quand l'utiliser, et allégez les schémas d'entrée — les longues descriptions par propriété et les objets optionnels profondément imbriqués en représentent généralement l'essentiel.

Non. Seules les définitions d'outils sont mesurées, c'est-à-dire la part du contexte que vous maîtrisez en modifiant votre serveur. Le prompt système, la conversation en cours et les résultats d'outils viennent s'y ajouter.

Aucune dans le protocole, mais deux en pratique. Le coût croît linéairement à chaque tour, et la justesse de la sélection baisse à mesure que la liste s'allonge : un modèle qui choisit parmi quatre-vingts outils décrits de façon similaire se trompe bien plus souvent qu'un modèle qui choisit parmi huit.

Autres outils MCP gratuits