Exécution de code avec MCP: une nouvelle approche de l'efficacité des agents IA
Anthropic a introduit une méthode dans laquelle les agents IA interagissent avec des serveurs Model Context Protocol (MCP) en écrivant du code exécutable plutôt que de faire des appels directs aux outils. L'agent traite les outils comme des fichiers sur un ordinateur, trouve ce dont il a besoin et les utilise directement avec du code, de sorte que les données intermédiaires n'ont pas à passer par la mémoire du modèle. Nous avons testé cette approche pour voir si elle réduit le coût en tokens tout en maintenant le même taux de réussite.
Exécution de code avec MCP par rapport au MCP classique
Métrique | MCP classique | MCP avec exécution de code | Différence |
|---|---|---|---|
Taux de réussite | 100 % | 100 % | Identique |
Latence moyenne | 9.66s | 10.37s | +7 % |
Tokens d'entrée moyens | 15 417 | 3 310 | -78,5 % |
Tokens de sortie moyens | 87 | 192 | +120 % |
Total des tokens d'entrée | 770 852 | 165 496 | -78,5 % |
Total des tokens de sortie | 4 345 | 9 585 | +120 % |
Total de tous les tokens | 775 197 | 175 081 | -77,4 % |
Nous avons comparé deux approches pour créer des agents IA qui interagissent avec des outils externes via le MCP :
- MCP classique : approche traditionnelle où toutes les définitions d'outils sont chargées dans la fenêtre de contexte du modèle
- MCP avec exécution de code : approche nouvelle où le modèle écrit du code qui appelle des outils, en gardant les données intermédiaires hors du contexte
Outils utilisés
Ce benchmark a été réalisé en utilisant le Bright Data MCP Server avec le mode Pro, car il a obtenu la meilleure précision dans notre benchmark navigateur MCP.
Principaux résultats
Économies de tokens d'entrée : l'exécution de code utilise 78,5 % de tokens d'entrée en moins (165K contre 771K) :
- L'approche classique charge environ 15 400 tokens de définitions d'outils par appel
- L'exécution de code ne nécessite qu'environ 3 300 tokens par appel
Plus de tokens de sortie : l'approche d'exécution de code utilise 2.2× plus de tokens de sortie car le modèle écrit du code + des explications
Économies nettes de tokens : 77,4 % de réduction totale des tokens (175K contre 775K)
Implication sur le coût :
- Les tokens d'entrée sont généralement moins chers que les tokens de sortie
- Mais des économies de 78 % sur les tokens d'entrée compensent largement l'augmentation de 2× des tokens de sortie
- Estimation d'environ 70 % de réduction de coût avec l'exécution de code
Les deux ont atteint un taux de réussite de 100 % sur ces requêtes avec GPT-4.1.
L'approche d'exécution de code s'inspire de l'article de Anthropic sur l'utilisation de l'exécution de code avec MCP pour réduire l'utilisation de la fenêtre de contexte tout en maintenant les capacités de l'agent.1
Méthodologie de la comparaison de l'exécution de code avec MCP
Tâches
Nous exécutons chaque tâche 50 fois pour chaque approche :
- Aller sur https://aimultiple.com/open-source-embedding-models, indiquez-moi les cinq meilleurs modèles parfaits (c'est-à-dire les modèles avec une précision top-5 de 100 %)
- Aller sur https://aimultiple.com/open-source-embedding-models, indiquez-moi quel modèle a la latence la plus élevée.
Configuration de la comparaison
Pour les deux approches, nous avons utilisé le Bright Data MCP Server avec le mode Pro et GPT-4.1 comme LLM en raison de sa grande fenêtre de contexte.
Configuration de l'environnement : Nous avons effacé toute donnée mise en cache et assuré une nouvelle connexion au serveur MCP à chaque exécution. Chaque requête est exécutée en tant que sous-processus séparé.
Comparaison des architectures
Architecture du MCP classique
Dans l'approche MCP classique, l'agent suit un flux simple : la requête de l'utilisateur entre dans un agent LangGraph ReAct, qui a accès aux 63 définitions d'outils dans sa fenêtre de contexte. L'agent sélectionne et appelle des outils via la session client MCP, et les résultats des outils reviennent par la fenêtre de contexte pour informer l'action suivante de l'agent.
Architecture MCP avec exécution de code
L'approche d'exécution de code ajoute une couche intermédiaire : la requête de l'utilisateur va à un agent d'exécution de code avec un contexte compact (uniquement les noms d'outils, pas les schémas complets). L'agent écrit du code Python qui appelle des outils. Ce code s'exécute dans un environnement d'exécution de code en bac à sable, qui communique avec la session client MCP. Seuls les résultats finaux ou les résumés reviennent dans le contexte de l'agent, pas les données intermédiaires brutes.
L'implémentation de l'exécution de code utilise la divulgation progressive. Seuls les noms d'outils et des descriptions tronquées (60 caractères) sont inclus dans le prompt système. Lorsque le modèle a besoin d'utiliser un outil, il écrit du code Python qui appelle une fonction async call_tool() fournie dans l'environnement d'exécution.
Limites de notre approche
- Diversité des requêtes : Seuls 2 types de requêtes ont été testés ; les résultats peuvent varier pour d'autres types de tâches.
- Modèle unique : Testé uniquement avec GPT-4.1 ; d'autres modèles peuvent présenter des schémas différents.
- Qualité du code : Le succès de l'exécution de code dépend de la capacité de génération de code du modèle, ce qui peut entraîner une baisse des taux de réussite dans des tâches plus complexes.
Pourquoi le MCP traditionnel gaspille des ressources
Problème 1 : Les définitions d'outils consomment un contexte excessif
Chaque outil a besoin d'instructions dans la mémoire du modèle. Un exemple simple :
gdrive.getDocument
Gets a file from Google Drive
Needs: document ID
Returns: the file content
Exemple : Un agent connecté à 50 serveurs avec 20 outils chacun représente 1 000 définitions d'outils. À raison d'environ 150 tokens par définition, cela fait 150 000 tokens consommés avant que l'agent ne lise votre première requête.
Problème 2 : Les données sont traitées plusieurs fois
Tâche : « Récupérer mes notes de réunion depuis Google Drive et les ajouter à Salesforce. »
Ce qui se passe :
- L'agent obtient le document (50 000 tokens)
- Le modèle lit
- L'agent l'envoie à Salesforce (encore 50 000 tokens)
Le modèle traite 100 000+ tokens pour déplacer des données d'un endroit à un autre.
Les implémentations MCP traditionnelles exigent que le modèle sélectionne des outils à partir de définitions JSONSchema chargées dans la fenêtre de contexte, ce qui dégrade la précision à mesure que le nombre d'outils augmente.1 Des recherches ont confirmé que les taux de réussite des tâches diminuent fortement à mesure que le nombre d'outils disponibles augmente en raison de l'inondation du contexte par les définitions de schémas.2 Exposer les outils MCP en tant que fonctions appelables et permettre au modèle d'écrire du code Python qui invoque directement les outils tire parti de la capacité de génération de code existante du modèle plutôt que de forcer la sélection à partir de schémas prédéfinis.
Quand utiliser l'exécution de code avec MCP ?
L'exécution de code avec MCP corrige deux inefficacités fondamentales des implémentations MCP traditionnelles :
- Les définitions d'outils n'encombrent plus la fenêtre de contexte
- Les données intermédiaires cessent de circuler inutilement dans le modèle
L'approche fonctionne le mieux lorsque :
- Vous avez de nombreux outils MCP connectés
- Vos workflows impliquent un traitement de données en plusieurs étapes
- De grands documents ou datasets circulent entre les outils
- Les limites de la fenêtre de contexte affectent vos agents
Les exigences en matière d'infrastructure signifient que cette approche n'est pas automatiquement meilleure pour tous les cas d'usage. Les déploiements à petite échelle avec peu d'outils pourraient ne pas justifier la complexité opérationnelle.
Pour les organisations qui exécutent déjà des agents avec de vastes catalogues d'outils MCP, le potentiel de réduction des tokens de plus de 98 % et les économies de coûts correspondantes font que cette approche mérite d'être étudiée.
Frameworks et protocoles alternatifs
Les équipes qui souhaitent une couche d'exécution de code séparée de leur framework d'agent peuvent utiliser des services de sandbox autonomes tels que CoreWeave Sandboxes, qui propose des SDKs Python et TypeScript et permet de restreindre l'accès sortant de chaque sandbox par adresse IP, port et nom d'hôte HTTPS.3 En avril 2026, OpenAI a mis à jour son SDK Agents pour ajouter des capacités d'exécution natives en sandbox, offrant des espaces de travail isolés avec un accès restreint aux fichiers et au code.4
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{alper2026,
author = {Alper, Şevval},
title = {{Exécution de code avec MCP: une nouvelle approche de l'efficacité des agents IA}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/code-execution-with-mcp}},
note = {AIMultiple. Consulté le 16 octobre 2026}
}Résultats et horodatages de 7 points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant un fichier CSV.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
2 mises à jourLa section « Comparaison : UTCP vs MCP vs Exécution de code MCP » a été supprimée.
Liens de référence
Şevval se concentre sur les outils de codage IA, les agents IA et les technologies quantiques.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.