Utilisation des outils par les AI agents : MCP, CLI, Skills et exécution de code

Viacheslav Dubrov

2026-03-24 · Mis à jour 2026-08-01 · 24 min · Agents IA

Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

La Partie 1 présentait les boucles de raisonnement, et la Partie 2 la mémoire. Cet article ajoute la couche d’action : comment un agent expose, sélectionne et exécute des outils. La mémoire détermine ce que l’agent sait au début d’un tour ; cette couche détermine ce qu’il peut en faire. La Partie 4 traite de la vérification qui décide si un appel nommé est réellement exécuté, et la Partie 6 du harness qui exécute à la fois l’appel et la vérification. Dans cet article, le harness désigne le programme de contrôle qui assemble chaque prompt, distribue les tool calls qu’il accepte et décide quand la tâche est terminée — autrement dit, tout le code ordinaire que vous écrivez autour du modèle.

Le paysage des outils a changé en 2025–2026. MCP, le Model Context Protocol, a fourni aux éditeurs une manière commune d’exposer des services externes. Les agents capables d’exécuter du code ont montré qu’un modèle peut parfois composer un petit programme plus efficacement qu’en émettant une longue séquence d’appels JSON. Anthropic a annoncé une réduction de 98,7 % des tokens pour un workflow Google Drive vers Salesforce, et l’article CodeAct a rapporté des gains allant jusqu’à 20 % dans sa configuration de benchmark. Ces résultats concernent leurs tâches et leurs harnesses, et ne démontrent pas un avantage universel de l’exécution de code.

Je compare les tool calls JSON, MCP, Skills, les outils CLI et l’exécution de code, dans cet ordre. Une section ultérieure applique les principes de conception de l’Agent-Computer Interface (ACI) au Market Analyst Agent, un petit agent de recherche LangGraph que j’ai développé pour la Partie 1 afin de récupérer des données de marché et de rédiger un rapport d’analyste.

Pour une décision rapide concernant l’interface, consultez AI Agent Tool Interfaces.

En bref : cinq modèles d’interface utiles couvrent la plupart des usages d’outils par les agents. Les Skills transportent les instructions, les outils CLI conviennent au développement local, MCP connecte les services partagés et l’exécution de code compose des opérations en plusieurs étapes dans un sandbox. Les tool calls JSON restent le choix le plus simple pour les petites actions atomiques. Quel que soit le protocole, l’Agent-Computer Interface (ACI) doit rendre les actions claires, les retours compacts et les erreurs récupérables.

Cinq façons pour les AI agents d’utiliser des outils

Dans la Partie 1, la boucle de raisonnement choisissait l’étape suivante. La Partie 2 stockait l’état nécessaire pour reprendre cette boucle. La frontière des outils se situe entre les deux : elle valide ce que la boucle a proposé, transmet ensuite l’appel pour exécution et renvoie le résultat à la boucle. Ces cinq modèles effectuent des compromis différents en matière de coût en tokens, de flexibilité et de contrôle.

1. Tool calls JSON : la référence

Le modèle d’origine : vous définissez les tool schemas en JSON, le LLM émet des function calls structurés et votre code les exécute. Le fonctionnement est bien compris et convient parfaitement aux petits ensembles d’outils.

# Traditional tool definition — each tool consumes ~550-1,400 tokens (Apideck benchmark)
tools = [
    {
        "name": "get_stock_price",
        "description": "Get the current stock price for a ticker symbol",
        "input_schema": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker (e.g., NVDA)"}
            },
            "required": ["ticker"]
        }
    }
]

Avec 5 à 10 outils, la surcharge reste acceptable. Le problème apparaît à l’échelle : chaque définition d’outil coûte 550 à 1 400 tokens. Avec 20 outils, vous dépensez 11 à 28 K tokens avant même que l’agent ne commence à raisonner.

2. MCP pour les intégrations partagées

MCP est le standard vers lequel la plupart des éditeurs ont convergé. Un serveur MCP est un processus qui publie une liste d’outils via un protocole filaire défini — stdio pour un processus local, HTTP pour un processus distant. Votre agent exécute un client MCP qui se connecte au serveur, lui demande quels outils sont disponibles, puis lui transmet les appels du modèle ; le même serveur fonctionne donc avec tout client parlant le protocole. Anthropic a donné le protocole à la Linux Foundation en décembre 2025, dans le cadre de l’Agentic AI Foundation qu’elle a cofondée avec OpenAI et Block. Google, Microsoft et AWS soutiennent la fondation en tant que membres platinum. OpenAI a ajouté la prise en charge de MCP dans sa Responses API. Selon l’annonce du don d’Anthropic en décembre 2025, l’écosystème comptait plus de 10 000 serveurs MCP publics actifs et plus de 97 millions de téléchargements mensuels des SDK, répartis entre les SDK Python et TypeScript.

MCP convient aux intégrations SaaS interéditeurs (Figma, Notion, Salesforce), aux services ne disposant pas d’équivalent CLI et aux environnements nécessitant une orchestration OAuth. Sa valeur réside dans une couche partagée de découverte et de transport. La gouvernance dépend toujours de l’authentification, de l’autorisation, de la journalisation et des contrôles de déploiement du serveur.

La réalité en production est plus complexe que ne le suggèrent ces chiffres.

La surface d’attaque est le premier problème. Le Vulnerable MCP Project recense 50 vulnérabilités dans des serveurs MCP, dont 13 classées Critical, signalées par 32 chercheurs en sécurité. Les classes d’attaque couvrent la prompt injection, les défaillances de validation des entrées, les lacunes d’authentification et les failles de sécurité réseau. Le premier serveur MCP malveillant observé dans le monde réel est apparu en septembre 2025 : un package nommé postmark-mcp qui envoyait en BCC chaque e-mail sortant vers l’adresse d’un attaquant.

Le tool poisoning est la classe d’attaque qui m’inquiète le plus. Invariant Labs a démontré que des outils MCP empoisonnés peuvent exfiltrer des données même lorsqu’ils ne sont jamais invoqués. Il suffit que le modèle lise les métadonnées de l’outil pour déclencher l’attaque. Les benchmarks MCPTox, qui ont testé 20 agents LLM contre 45 serveurs MCP réels, ont relevé des taux de réussite des attaques pouvant atteindre 72,8 %.

La surcharge en tokens est le problème opérationnel. Une équipe exploitant des serveurs MCP pour GitHub, Slack et Sentry (environ 40 outils au total) a constaté que 55 000 tokens de définitions de schemas étaient injectés avant même la moindre question utilisateur. Une autre a rapporté que 143 000 tokens sur 200 000 disponibles (72 %) étaient consommés par les seules définitions d’outils.

Le rapport d’Anthropic sur le Tool Search Tool a mesuré une réduction de 85 % de la consommation totale du contexte — d’environ 77 000 tokens avant le début du travail à 8 700 — alors que la configuration traditionnelle incluait environ 72 000 tokens de définitions d’outils. Cette approche ne charge que les trois à cinq outils nécessaires à une requête, mais ajoute une étape de découverte avant l’invocation ; elle est moins utile pour les petits ensembles d’outils compacts, utilisés fréquemment à chaque session.

3. Les Skills empaquettent l’expertise, pas l’exécution

Les agent skills sont un format ouvert destiné à empaqueter des instructions et des fichiers de support. Les outils fournissent des capacités (ce que les agents peuvent faire), tandis que les Skills fournissent une expertise (ce que les agents savent sur la manière d’accomplir des tâches complexes).

Le format SKILL.md définit une Skill comme un fichier Markdown doté d’un en-tête YAML. Le standard ouvert n’exige que name et description ; l’exemple ci-dessous utilise également deux extensions de Claude Code, argument-hint et user-invocable, ainsi que son placeholder d’argument positionnel $0 :

---
name: deploy
description: Deploy the application to production
argument-hint: "[environment]"
user-invocable: true
---
Deploy the application to the $0 environment (default: staging).
Steps:
1. Run the test suite
2. Build the production bundle
3. Deploy using the deploy script
4. Verify the deployment health check

Les Skills utilisent la progressive disclosure. Environ 100 tokens de métadonnées sont chargés au démarrage ; les instructions complètes ne sont chargées que lorsque la Skill est active. À comparer aux environ 55 000 tokens que près de 40 outils MCP peuvent consommer avant le début du raisonnement.

Utilisez les Skills pour les connaissances métier, les procédures en plusieurs étapes et les tâches récurrentes telles que les migrations de bases de données ou les intégrations de paiement. Elles conviennent lorsque l’agent a besoin d’instructions sur la manière d’utiliser une capacité existante.

4. Outils CLI et shell

Les interfaces CLI peuvent coûter beaucoup moins cher en contexte lorsque le modèle connaît déjà la commande. Scalekit a rapporté une différence de 4 à 32 fois plus de tokens entre ses parcours CLI et MCP sur 75 exécutions. Cette étude de cas mesure ses propres outils et tâches ; elle ne remplace pas une comparaison effectuée avec vos propres tool schemas et sorties de commandes.

Les commandes largement documentées telles que git, docker, kubectl, gh, curl et jq nécessitent souvent peu de texte de schema introductif. Les CLI moins courantes ou internes ont toutefois besoin d’une aide découvrable, d’exemples et d’une sortie machine-readable stable.

Le guide d’Ugo Enyioha, “Writing CLI Tools That AI Agents Actually Want to Use”, formalise huit règles de conception :

1. La sortie structurée est obligatoire — prendre en charge --json
2. Les codes de sortie constituent le control flow — utiliser des codes distincts pour les différents types d’erreur
3. Les commandes doivent être idempotentes
4. Les commandes doivent être auto-documentées --help avec des exemples réalistes
5. Concevoir pour la composabilité — --quiet pour les valeurs brutes, prise en charge de stdin
6. Fournir les flags --dry-run et --yes
7. Prendre en charge l’introspection de version
8. Gérer l’authentification via des variables d’environnement

La CLI ne dispose d’aucune découverte au niveau du protocole. Les tool calls JSON peuvent transporter des schemas typés, tandis que MCP standardise la découverte des outils et, pour les transports HTTP, un modèle d’autorisation. Aucun des deux ne fournit à lui seul une gouvernance : l’hôte, le serveur ou le harness doit appliquer la politique et enregistrer les appels nécessaires à l’audit. Le modèle vers lequel convergent le plus souvent les équipes est la CLI pour le développement et les opérations locales, MCP pour l’intégration de services externes partagés.

5. Exécution de code pour les tâches en plusieurs étapes

C’est l’évolution de l’outillage agentic que je considère comme la plus importante. Au lieu d’émettre du JSON structuré pour invoquer une à une des fonctions prédéfinies, l’agent écrit un script Python ou bash. Le script appelle plusieurs outils, traite les résultats avec des boucles et des conditions, puis ne renvoie au contexte du modèle que le résumé final.

Anthropic a introduit le Programmatic Tool Calling (PTC) comme l’une des trois fonctionnalités bêta de la Claude API. Le fondement académique est l’article CodeAct (Wang et al., ICML 2024), qui a évalué 17 LLMs et constaté que les actions sous forme de code atteignaient des taux de réussite supérieurs de 20 % et nécessitaient 30 % d’étapes en moins que les alternatives JSON.

Trois études de cas de première partie montrent où ce modèle peut être utile : Vercel et Cloudflare ci-dessous, puis l’exemple d’analyse de dépenses d’Anthropic. Considérez-les comme des éléments de preuve fournis par les éditeurs et reproduisez la comparaison sur vos propres tâches.

• Vercel a reconstruit d0, son agent de données en langage naturel vers SQL. Son ancien exemple de code nomme 17 outils ; son nouvel exemple expose ExecuteCommand et ExecuteSQL. Vercel présente cette refonte comme une suppression de 80 % de ses outils, mais ce chiffre est le message principal de Vercel et ne découle pas d’un calcul fondé sur les outils nommés dans les exemples. Sur cinq requêtes représentatives, Vercel indique que la réussite des tâches est passée de 4/5 à 5/5, que le temps d’exécution moyen a été divisé par 3,5 (274,8 s à 77,4 s) et que l’utilisation moyenne de tokens a baissé de 37 % (environ 102 K à environ 61 K). Leur formulation : « Les meilleurs agents sont peut-être ceux qui disposent du moins d’outils. »

• Cloudflare a développé « Code Mode », qui permet aux agents d’écrire du TypeScript pour appeler son API plutôt que de définir des tool schemas, ce qui réduit la surcharge de contexte. Leur raisonnement : « Les LLMs disposent d’une quantité énorme de TypeScript réel dans leurs données d’entraînement, mais seulement d’un petit nombre d’exemples artificiels de tool calls. »

Voici le modèle présenté dans la documentation PTC d’Anthropic. Dans l’illustration séquentielle d’analyse de dépenses d’Anthropic, les appels d’outils traditionnels nécessitent plus de 20 passes d’inférence distinctes, les données intermédiaires transitant par le contexte. Après la recherche de l’équipe, un hôte prenant en charge les appels d’outils parallèles peut regrouper les requêtes de dépenses indépendantes ; le chiffre de plus de 20 ne rend pas cela impossible. Anthropic indique que le code généré pour répondre à la même question réduit ce qui atteint le contexte : de 200 Ko de lignes de dépenses brutes — plus de 2 000 lignes — à 1 Ko de résultats. Avec l’exécution de code, l’agent écrit un script unique :

# Agent generates this code, executes in sandbox
import asyncio
import json

async def main() -> None:
    team = await get_team_members("engineering")
    levels = list(set(member["level"] for member in team))
    budgets = dict(zip(
        levels,
        await asyncio.gather(*(get_budget_by_level(level) for level in levels)),
    ))
    expenses = await asyncio.gather(
        *(get_expenses(member["id"], "Q3") for member in team)
    )
    over_budget = []
    for member, employee_expenses in zip(team, expenses):
        total = sum(expense["amount"] for expense in employee_expenses)
        limit = budgets[member["level"]]["travel_limit"]
        if total > limit:
            over_budget.append(
                {"name": member["name"], "spent": total, "limit": limit}
            )
    # Only this final summary returns to the LLM context
    print(json.dumps(over_budget))

asyncio.run(main())

Le LLM ne voit que le résumé JSON final, et non les milliers de lignes de dépenses traitées dans le sandbox. Le gain ne concerne pas uniquement les rapports de dépenses : le bilan séparé d’Anthropic sur l’exécution de code fournit le chiffre le plus marquant, avec un workflow Google Drive vers Salesforce passé d’environ 150 000 tokens à environ 2 000, soit une réduction de 98,7 %.

L’efficacité en tokens est le gain le plus évident. Les boucles et les conditions ne coûtent rien de plus, et l’exécution de code peut gérer les erreurs avec des handlers explicites au lieu de contraindre le modèle à raisonner sur les échecs en langage naturel. Un parcours d’exécution de code peut maintenir les données intermédiaires sensibles hors du contexte du modèle, mais cela ne constitue pas une confidentialité : l’isolation, les contrôles d’egress, les credentials limités et la journalisation doivent faire l’objet de contrôles distincts.

Quand les tool calls JSON restent pertinents : opérations atomiques uniques, environnements sans infrastructure de sandbox, modèles plus petits dont la génération de code est faible, ou exigences d’audit nécessitant la journalisation de chaque invocation d’outil.

Tableau comparatif des tool calls des AI agents

Dans la ligne consacrée à la surcharge en tokens, « meta-tools » désigne les quelques points d’entrée génériques dont un agent exécutant du code a besoin — ExecuteCommand et ExecuteSQL chez Vercel, par exemple — à la place d’un schema par opération sous-jacente. Les lignes relatives à la composabilité et à la latence concernent les appels dont les arguments ultérieurs dépendent des résultats précédents dans le harness ou la boucle considérés. Les tool calls JSON et MCP peuvent émettre simultanément des appels indépendants, et un hôte peut les exécuter en parallèle ; les appels dépendants nécessitent généralement un nouveau tour de modèle pour choisir l’action suivante. Le PTC déplace le control flow dépendant et le filtrage côté code dans le script, puis renvoie un résumé au modèle ; il peut également émettre des appels indépendants en parallèle. Les cellules relatives aux tokens et à la réussite des tâches résument les exemples cités, et non un benchmark contrôlé unique comparant les cinq colonnes.

L’Agent-Computer Interface (ACI) pour les outils des AI agents

Le terme « Agent-Computer Interface » (ACI) a été créé par John Yang, Carlos E. Jimenez et leurs collègues de Princeton dans leur article sur SWE-agent (NeurIPS 2024). La qualité des interfaces humaines dispose de toute une discipline — l’interaction humain-machine, ou IHM. L’article soutient que les agents fondés sur des language models méritent le même traitement : ce sont « une nouvelle catégorie d’utilisateurs finaux, avec leurs propres besoins et capacités, qui bénéficieraient d’interfaces conçues spécialement pour eux ».

Leurs résultats d’ablation donnent un ordre de grandeur. Avec le même modèle de base GPT-4 Turbo, l’ablation SWE-bench Lite de l’article atteignait 18,0 % avec l’ACI complète de SWE-agent sur 300 tâches, contre 7,3 % dans la condition shell-only sans démonstration détaillée et 11,0 % avec une démonstration. La comparaison montre que l’interface et les conditions de démonstration modifiaient significativement les performances dans cette configuration ; elle n’isole pas la conception de l’interface de toutes les autres différences et ne montre pas que le modèle n’effectuait aucun travail. Dans la même ablation de l’interface, l’activation du linting a fait passer la condition d’édition de 15,0 % à 18,0 % ; sur l’ensemble de test SWE-bench, 51,7 % des exécutions de SWE-agent ont rencontré au moins une modification rejetée par le linter avant sa propagation.

Anthropic a adopté l’ACI comme concept fondamental dans son guide “Building Effective Agents”, en le citant comme l’un des trois principes centraux : « Concevez soigneusement votre agent-computer interface au moyen d’une documentation et de tests approfondis des outils. » Leur recommandation pratique : « Une bonne règle empirique consiste à réfléchir à l’effort consacré aux interfaces humain-machine et à prévoir d’investir autant d’efforts dans la création de bonnes agent-computer interfaces. »

Quatre principes ACI en pratique

1. Les actions doivent être simples et faciles à comprendre. L’erreur la plus courante consiste à encapsuler les endpoints API un par un. Au lieu de list_users, list_events, create_event, implémentez schedule_event, qui recherche les disponibilités et effectue la réservation en un seul appel. Au lieu de read_logs, implémentez search_logs, qui ne renvoie que les lignes pertinentes avec leur contexte.

2. Les actions doivent être compactes et efficaces. Regroupez les opérations importantes dans un nombre d’actions aussi réduit que possible. Dans le Market Analyst Agent, je combine la récupération des prix et les métriques de base dans un outil get_stock_snapshot unique, plutôt que d’exiger des appels séparés pour le prix, le volume, la capitalisation et le ratio PE.

3. Les retours de l’environnement doivent être informatifs, mais concis. Évitez de renvoyer du HTML brut ou des payloads API complets. Résolvez les identifiants cryptiques en noms sémantiques. Les tests d’Anthropic ont ajouté un enum response_format afin que l’agent puisse demander une réponse concise (environ 72 tokens) ou détaillée (environ 206 tokens), soit environ trois fois plus de tokens.

4. La validation doit limiter la propagation des erreurs. La détection automatique des erreurs aide les agents à reconnaître et corriger rapidement leurs erreurs. Dans SWE-agent, un éditeur de fichiers personnalisé intégrant le linting rejette automatiquement les erreurs de syntaxe — c’est l’étape de validation à l’origine du chiffre de 51,7 % indiqué plus haut. Il s’agit ici de valider les entrées et les sorties d’un outil, et non du filtrage du contenu autour d’un appel au modèle assuré par les produits de guardrails de la Partie 4 ; le même terme est utilisé dans les deux cas. J’applique le même principe au Market Analyst Agent en validant les arguments des outils avec des schemas Pydantic avant exécution :

from pydantic import BaseModel, Field, field_validator

from market_analyst.utils import normalize_ticker

class StockQuery(BaseModel):
    """Validated input for stock queries.

    Pydantic catches malformed tickers before the API call,
    preventing error propagation through the reasoning loop.
    """
    ticker: str = Field(description="Stock ticker symbol (e.g., NVDA)")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        return normalize_ticker(v)

class StockHistoryQuery(StockQuery):
    """Validated input for price history queries."""

    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 6mo, 1y")

    @field_validator("period")
    @classmethod
    def validate_period(cls, v: str) -> str:
        valid = {"1d", "5d", "1mo", "3mo", "6mo", "1y"}
        if v not in valid:
            raise ValueError(f"Invalid period: {v}. Must be one of {valid}")
        return v

Le normalizer partagé supprime les espaces et convertit la valeur en majuscules, puis accepte les chiffres dans les tickers et les suffixes contenant des points ou des tirets, tels que BRK.B et BF-B ; StockHistoryQuery, et non StockQuery, est propriétaire de period.

Patterns de conception d’outils pour AI agents qui fonctionnent

Le guide d’Anthropic “Writing effective tools for agents” décrit les outils comme « un nouveau type de logiciel qui matérialise un contrat entre des systèmes déterministes et des agents non déterministes ».

Traiter les descriptions d’outils comme du prompt engineering

Les descriptions devraient comporter au moins trois ou quatre phrases, indiquant quand utiliser l’outil, quels paramètres sont obligatoires ou facultatifs, le format de sortie et les cas limites. Anthropic rapporte que le choix entre les noms avec namespace en préfixe ou en suffixe (asana_search contre search_asana) a eu des « effets non triviaux » dans ses propres évaluations d’utilisation d’outils. L’article ne précise pas quel schéma est meilleur ; testez donc les deux sur votre ensemble d’outils au lieu de supposer que les préfixes sont préférables. Anthropic a également réinjecté dans Claude Code les transcriptions de ses agents d’évaluation et l’a laissé réécrire les outils. Sur des jeux de test non vus, cette boucle a trouvé de nouvelles améliorations, « allant même au-delà de ce que nous avions obtenu avec des implémentations d’outils “expertes” » — que ces outils aient été écrits par ses chercheurs ou générés par Claude.

# Bad: vague, no context for when to use
tools = [{
    "name": "search",
    "description": "Search for items",
}]

# Good: specific, with input examples and edge cases
tools = [{
    "name": "search_news",
    "description": (
        "Search for recent news articles about a specific stock or company. "
        "Use this tool when the user asks about recent events, earnings, "
        "announcements, or market-moving news for a specific ticker. "
        "Returns up to 10 articles sorted by relevance. "
        "For company competitors rather than news, use search_competitors instead."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "Search query. Examples: 'NVDA earnings Q3 2025', 'Tesla delivery numbers'"
            },
            "max_results": {
                "type": "integer",
                "description": "Max articles to return (1-10, default 5)",
                "default": 5
            }
        },
        "required": ["query"]
    }
}]

Les tests internes d’Anthropic ont montré que l’ajout d’un champ input_examples faisait passer la précision sur la gestion de paramètres complexes de 72 % à 90 %.

Renvoyer une sortie à forte valeur informative et lisible par machine

Évitez les identifiants de bas niveau (uuid, mime_type). Résolvez les identifiants cryptiques en noms sémantiques. Structurez la réponse afin que l’agent puisse la traiter sans parser du boilerplate :

# Bad: raw API response dumped to agent
def get_stock_snapshot(ticker: str) -> dict:
    response = api.get(f"/v1/quotes/{ticker}")
    return response.json()  # 500+ tokens of nested JSON

# Good: high-signal summary the agent can immediately reason about
def get_stock_snapshot(ticker: str) -> dict:
    data = api.get(f"/v1/quotes/{ticker}").json()
    return {
        "ticker": ticker,
        "price": data["regularMarketPrice"],
        "change_pct": round(data["regularMarketChangePercent"], 2),
        "volume": data["regularMarketVolume"],
        "market_cap_b": round(data["marketCap"] / 1e9, 1),
        "pe_ratio": data.get("trailingPE"),
        "summary": f"{ticker} at ${data['regularMarketPrice']:.2f} "
                   f"({'up' if data['regularMarketChangePercent'] > 0 else 'down'} "
                   f"{abs(data['regularMarketChangePercent']):.1f}%)"
    }

Renvoyer des erreurs exploitables par la boucle

La gestion des erreurs nécessite quatre mécanismes distincts, car chacun traite une classe de défaillance différente :

1. Retry avec backoff exponentiel pour les erreurs transitoires
2. Chaînes de fallback de modèles en cas d’indisponibilité d’un fournisseur
3. Routage par classification d’erreur — les erreurs transitoires sont retentées, les erreurs récupérables par le LLM sont renvoyées à l’agent avec leur contexte, et les erreurs nécessitant une intervention humaine sont escaladées
4. Récupération depuis un checkpoint pour survivre aux crashs

Le guide d’Anthropic “Writing effective tools for agents” préconise des erreurs d’outils claires et une conception pilotée par l’évaluation, mais ne fournit aucun chiffre universel sur ce que ces quatre mécanismes permettent de récupérer. Mesurez le taux de récupération, les retries et les escalades sur votre propre suite de tâches.

import httpx
from tenacity import retry, retry_if_exception, stop_after_attempt, wait_exponential

def is_transient_error(error: BaseException) -> bool:
    if isinstance(error, (httpx.TimeoutException, httpx.NetworkError)):
        return True
    if isinstance(error, httpx.HTTPStatusError):
        return error.response.status_code == 429 or 500 <= error.response.status_code < 600
    return False

@retry(
    retry=retry_if_exception(is_transient_error),
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=2, max=10),
    reraise=True,
)
def call_stock_api(ticker: str) -> dict:
    """Fetch stock data with automatic retry on transient failures.

    Mechanism 1 of the four above: exponential backoff for rate limits
    and network blips.
    If all retries fail, the error propagates to the agent with
    enough context to decide whether to try a different approach.
    """
    response = httpx.get(
        f"https://api.example.com/v1/quotes/{ticker}",
        timeout=10.0,
    )
    response.raise_for_status()
    return response.json()

Application des patterns au Market Analyst Agent

Le Market Analyst Agent de la Partie 1 rend l’effet de l’interface visible.

Consolidation des outils

Les modules d’outils d’origine définissaient get_stock_price, get_company_metrics, get_price_history, deux outils de recherche et execute_trade. Pour une analyse de base, l’agent devait choisir à la fois les appels de prix et de métriques ; la capitalisation et le P/E étaient des champs de get_company_metrics, et non des outils autonomes. Le code source antérieur à la consolidation montre cette ancienne surface.

J’ai remodelé la surface de données de marché en 5 outils de haut niveau, conformément au principe ACI d’actions compactes et efficaces. La liste d’outils ReAct du dépôt en contient quatre autres — un chargeur de Skill, deux wrappers CLI et un évaluateur Python restreint exécuté in-process (une allowlist AST, pas un sandbox ; la Partie 4 traite ce point) — couvrant trois des cinq modalités ci-dessus. MCP apparaît comme sidecar plutôt que comme un outil de cette liste :

Cette modification regroupe le prix et la valorisation dans une définition orientée tâche et ajoute les états financiers comme action explicite. Il reste à tester, sur des requêtes et des traces représentatives, si cela améliore effectivement la sélection des outils.

Sorties structurées pour les résultats d’outils

Les outils d’actions et d’actualités renvoient des réponses validées par Pydantic. Les wrappers CLI et d’exécution de code renvoient str ; les modèles ci-dessous décrivent donc les résultats structurés des outils, et non chaque wrapper du dépôt :

from pydantic import BaseModel

class StockSnapshot(BaseModel):
    """Structured tool response — the agent never sees raw API noise."""
    ticker: str
    price: float
    change_pct: float
    volume: int
    market_cap_b: float
    pe_ratio: float | None
    summary: str  # Human-readable one-liner for direct use in reports

class NewsItem(BaseModel):
    """One news item pre-processed for agent consumption."""
    headline: str
    source: str
    date: str
    relevance_score: float  # Pre-ranked so the agent doesn't waste tokens sorting
    key_points: list[str]  # Extracted by the tool, not the agent

class NewsSearchResult(BaseModel):
    query: str
    results: list[NewsItem]
    summary: str

Le champ summary fournit à l’agent une chaîne prête à l’emploi, qui peut être insérée directement dans un rapport. Les NewsItem.key_points sont extraits par l’outil plutôt que par l’agent, ce qui économise des tokens d’inférence qui auraient autrement servi à parser le corps des articles.

Compromis et considérations

Au-delà des réserves propres à chaque modèle présentées plus haut, quelques considérations transversales influencent le choix :

• Le coût opérationnel varie selon la dimension considérée. L’exécution de code économise des tokens, mais ajoute une latence de cold start du sandbox. MCP réduit le temps de développement pour les intégrations SaaS, mais ajoute la surcharge liée au déploiement du serveur. La CLI est gratuite à démarrer, mais plus difficile à gouverner à grande échelle. Optimisez en fonction de votre véritable goulot d’étranglement : coût en tokens, latence ou complexité opérationnelle.

• Les compétences de l’équipe comptent. L’exécution de code suppose que vos agents (et les modèles qui les sous-tendent) puissent générer du Python ou du TypeScript fiable. La CLI suppose une bonne connaissance des conventions Unix. MCP exige de comprendre les protocoles de transport et les flux OAuth. Adaptez la modalité aux points forts de votre équipe.

• La consolidation des outils peut aller trop loin. Si un outil accumule des modes et des arguments sans rapport, l’agent se retrouve face à un autre problème de sélection à l’intérieur du schema. Utilisez des évaluations de sélection d’outils et de réussite des tâches pour trouver la surface adaptée à votre workload.

• Les Skills reposent sur le prompt et ne sont pas imposées. Une Skill contient des instructions que l’agent devrait suivre, et non des guardrails qu’il doit respecter. Un bundle de Skill peut inclure des fichiers arbitraires et des scripts exécutables : faites donc confiance à sa source, examinez le bundle et demandez à l’hôte d’appliquer les permissions pour chaque ressource qu’il peut lire, modifier ou exécuter. Pour les workflows critiques, combinez les Skills avec une validation déterministe.

• Les exigences d’audit influencent le choix. Les appels MCP et JSON structurés sont des événements faciles à journaliser, mais aucun des deux protocoles ne crée d’emblée une piste d’audit complète. L’hôte, le serveur ou le harness doit enregistrer les invocations et les résultats, puis appliquer l’autorisation, la politique, la rétention et la revue. L’exécution de code nécessite la même instrumentation autour du sandbox ; son script et sa sortie ne constituent pas à eux seuls un dossier de conformité.

Trois orientations pour l’outillage des AI agents à grande échelle

La première est le tool RAG pour passer à l’échelle. Dans les tâches de benchmark et le stress test MCP de RAG-MCP, la précision de sélection des outils de référence était de 13,62 % ; la retrieval l’a portée à 43,13 %, soit une amélioration de 3,2 fois, tout en réduisant de plus de 50 % le nombre de tokens des prompts. Ce résultat constitue une observation propre à cette configuration d’évaluation, et non un taux universel de sélection naïve lorsque les ensembles d’outils grandissent.

La deuxième est la création de leurs propres outils par les agents. Le framework LATM (« LLMs As Tool Makers ») a établi un paradigme en deux phases dans lequel un LLM puissant crée des fonctions Python réutilisables et un LLM léger les utilise. Sur le benchmark de ToolMaker, composé de 15 tâches portant sur des articles disposant de dépôts de code publics, fournis sous forme d’URLs GitHub et de courtes descriptions, il a implémenté correctement 80 % des tâches. Ces deux approches dépassent l’utilisation d’outils pour aller vers leur création, puis vers la gestion d’une bibliothèque d’outils générés.

La troisième est la stack dual-protocole A2A + MCP. Google a transféré A2A à la Linux Foundation en juin 2025. La documentation du protocole A2A sépare leurs responsabilités : MCP connecte un agent à des outils et à des ressources, tandis que A2A permet à des agents indépendants de se découvrir, de négocier des interactions, de gérer des tâches partagées et de déléguer du travail.

Points clés à retenir

1. Choisissez l’interface en fonction de l’action : appels JSON pour les petites opérations typées, MCP pour les services partagés, Skills pour les procédures, CLI pour les commandes établies et code exécuté dans un sandbox pour la composition locale.
2. Conservez les conditions du benchmark avec le résultat. CodeAct, Anthropic, Vercel, Cloudflare, Apideck et Scalekit ont mesuré des modèles, tâches, outils et harnesses différents.
3. La qualité de l’ACI résiste aux changements de protocole. Des actions claires, des retours compacts, une validation et des erreurs utiles aident toutes les modalités.
4. Ne consolidez les outils qui se recouvrent que lorsque les évaluations montrent que la surface réduite améliore la sélection ou la réussite des tâches.
5. La sécurité évolue avec le pouvoir d’exécution. Les interfaces shell et code nécessitent un sandbox ; MCP nécessite une identité limitée et une politique serveur ; les Skills restent des instructions, pas un mécanisme d’application.

La couche suivante est la policy

La Partie 4, AI Agent Security, place une vérification de policy entre un tool call proposé et son exécution. Il s’agit de la même frontière d’outil que celle décrite plus haut, mais vue du côté qui peut répondre non. La Partie 5 place ensuite l’outil et son sandbox dans un runtime capable de reprise, tandis que la Partie 6 ajoute un second contrat que le modèle ne voit jamais : une catégorie d’effet, une règle de retry et un résultat structuré qu’une vérification d’acceptation peut lire sans parser de prose.

Références

Articles de recherche

• Executable Code Actions Elicit Better LLM Agents (CodeAct) — Wang et al., ICML 2024 — Les actions sous forme de code atteignent jusqu’à 20 % de réussite supplémentaire par rapport au JSON
• SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — Yang, Jimenez et al., NeurIPS 2024 — Principes de conception ACI et évaluation SWE-bench (18,0 % pour SWE-agent contre 7,3 % pour shell-only sans démonstration dans l’ablation SWE-bench Lite de 300 tâches présentée dans l’article ; les conditions d’interface et de démonstration diffèrent)
• RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection — Ses tâches de benchmark et son stress test MCP ont amélioré la précision de sélection de 13,62 % à 43,13 %
• LLMs As Tool Makers (LATM) — Cai et al., 2023 — Paradigme en deux phases pour la création d’outils par des agents
• ToolMaker: LLM Agents Making Agent Tools — Wolflein et al., ACL 2025 — 80 % sur son benchmark de 15 tâches portant sur des articles disposant de dépôts de code publics
• MCPTox: A Comprehensive MCP Toxicity Benchmark — Taux de réussite des attaques de 72,8 % sur 20 agents LLM et 45 serveurs MCP

Ingénierie Anthropic

• Advanced Tool Use / Programmatic Tool Calling — Tool Search (85 % de réduction du contexte total, environ 77 K à environ 8,7 K), PTC et exemples d’utilisation d’outils
• Code Execution with MCP — Réduction de 98,7 % des tokens (150 K à 2 K tokens) grâce à l’orchestration d’outils par le code
• Writing Effective Tools for Agents — Ingénierie des descriptions d’outils ; les exemples d’entrées améliorent la précision ; enum response_format (72 contre 206 tokens)
• Building Effective Agents — L’ACI comme principe de conception fondamental

Spécifications de protocoles

• Google Cloud donates A2A to Linux Foundation — Annonce du 23 juin 2025 concernant le transfert du protocole, du SDK et des outils
• A2A and MCP: Detailed Comparison — Documentation du protocole A2A sur les responsabilités complémentaires agent-à-agent et agent-à-outil

Études de cas du secteur

• Vercel: We Removed 80% of Our Agent’s Tools — L’ancien exemple nomme 17 outils ; le nouveau expose ExecuteCommand et ExecuteSQL ; Vercel présente la refonte comme une suppression de 80 % ; réussite passée de 4/5 à 5/5 sur cinq requêtes représentatives, exécution 3,5 fois plus rapide, 37 % de tokens en moins
• Cloudflare: Code Mode — Appels API pilotés par TypeScript en remplacement des tool schemas
• Apideck: MCP Server Eating Your Context Window — 550 à 1 400 tokens par outil, 55 K tokens pour environ 40 outils MCP, 143 K/200 K du contexte consommés
• Scalekit: MCP vs CLI Token Benchmark — Surcharge en tokens 4 à 32 fois supérieure pour MCP par rapport à la CLI sur 75 exécutions de benchmark

Sécurité

• Vulnerable MCP Project — 50 vulnérabilités recensées, dont 13 Critical, signalées par 32 chercheurs
• AuthZed: Timeline of MCP Breaches — 9 incidents majeurs de sécurité MCP (avril–octobre 2025)
• Invariant Labs: MCP Tool Poisoning Attacks — Tool poisoning, rug pulls et escalade cross-origin
• Pivot Point Security: MCP Security Analysis — 43 % d’injection de commandes, 43 % de failles d’authentification OAuth

Conception de CLI

• Writing CLI Tools That AI Agents Actually Want to Use — Ugo Enyioha — Huit règles de conception pour des CLI adaptées aux agents

Projet de démonstration

• Market Analyst Agent — Implémentation complète avec consolidation des outils et patterns ACI

Le code complet du Market Analyst Agent, y compris les conceptions d’outils décrites dans cet article, est disponible sur GitHub.