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 les Model Context Protocol (MCP) serveurs 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 :
- Classique MCP : approche traditionnelle où toutes les définitions d’outils sont chargées dans la fenêtre de contexte du modèle
- Exécution de code MCP : approche novatrice où le modèle écrit du code qui appelle des outils, en gardant les données intermédiaires hors du contexte
Principales conclusions
Économies de tokens d’entrée : l’exécution de code utilise 78.5 % de tokens d’entrée en moins (165K vs 771K) :
- Le MCP classique charge environ 15 400 tokens de définitions d’outils par appel
- L’exécution de code n’a besoin que d’environ 3 300 tokens par appel
Davantage 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 vs 775K)
Implication sur les coûts :
- Les tokens d’entrée sont généralement moins chers que les tokens de sortie
- Mais 78 % d’économies à l’entrée l’emportent largement sur une augmentation de 2× en sortie
- Réduction de coût estimée à environ 70 % avec l’exécution de code
Les deux approches 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 d’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 :
- Va sur https://aimultiple.com/open-source-embedding-models et indique-moi les cinq meilleurs modèles (c’est-à-dire les modèles avec une précision top-5 de 100 %)
- Va sur https://aimultiple.com/open-source-embedding-models et indique-moi quel modèle a la latence la plus élevée.
Configuration de la comparaison
Nous avons utilisé le serveur Bright Data MCP avec le mode pro activé, car il offrait la plus grande précision dans notre benchmark de MCP navigateur.
Bright Data offre 5 000 requêtes gratuit MCP par mois pour tester cette approche d’exécution de code
Visitez le site webNous avons utilisé GPT-4.1 comme LLM en raison de sa grande fenêtre de contexte.
Configuration de l’environnement : Nous avons effacé toutes les données en cache et garanti une nouvelle connexion au serveur MCP à chaque exécution. Chaque requête est exécutée comme un sous-processus distinct.
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 dans la fenêtre de contexte pour éclairer l’action suivante de l’agent.
Architecture de l’exécution de code avec MCP
L’approche d’exécution de code ajoute une couche intermédiaire : la requête de l’utilisateur est envoyée à 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 sandboxé, 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 les descriptions tronquées (60 caractères) sont inclus dans le prompt système. Lorsque le modèle doit utiliser un outil, il écrit du code Python qui appelle une fonction asynchrone 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 les tâches plus complexes.
Pourquoi le MCP traditionnel gaspille des ressources
Problème 1 : les définitions d’outils consomment trop de contexte
Chaque outil nécessite des 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 même que l’agent 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 plus de 100 000 tokens pour déplacer des données d’un endroit à un autre.
Les implémentations MCP traditionnelles obligent le modèle à sélectionner 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 La recherche a confirmé que les taux de réussite des tâches diminuent fortement à mesure que le nombre d’outils disponibles augmente, en raison de la saturation du contexte par les définitions de schémas.2 Exposer les outils MCP comme des fonctions appelables et permettre au modèle d’écrire du code Python qui appelle directement les outils exploite 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 répond à 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 à travers le modèle
Cette 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 de plus de 98 % des tokens et les économies de coûts correspondantes rendent cette approche digne d’intérêt.
Frameworks et protocoles alternatifs
Au-delà de LangGraph, l’Agent Development Kit (ADK) de Google offre une prise en charge native de MCP via McpToolset et s’intègre au protocole Agent2Agent (A2A), qui normalise la communication d’agent à agent via des cartes de capacités publiées sur /.well-known/agent-card.json.3 4 En avril 2026, OpenAI a mis à jour son Agents SDK pour ajouter des capacités d’exécution sandbox natives, offrant des espaces de travail isolés avec un accès restreint aux fichiers et au code.5
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sezer2026,
author = {Sezer, Sena and Alper, Şevval},
title = {{Exécution de code avec MCP: une nouvelle approche de l'efficacité des agents IA}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/code-execution-with-mcp}},
note = {AIMultiple. Consulté le 14 Août 2026}
}
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.