2026-03-24 · Mis à jour 2026-07-14

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

AI Agent Tool Use en 2026 : MCP, CLI, compétences et exécution de code

Partie 3 de la série « Ingénierie de la pile Agentic »

Partie 1 boucles de raisonnement couvertes, et Partie 2 Mémoire couverte. Cet article introduit la couche d’action : la manière dont un agent expose, sélectionne et exécute des outils.

L’évolution des outils a connu un tournant entre 2025 et 2026. MCP a permis aux fournisseurs d’utiliser un protocole commun pour les services externes, tandis que les agents capables d’exécuter du code ont démontré qu’un modèle pouvait parfois composer un petit programme de manière plus efficace que de lancer une longue séquence d’appels JSON. Anthropic a signalé une réduction de 98,7 % des tokens dans un flux de travail d’analyse des dépenses, et la publication CodeAct a indiqué des gains allant jusqu’à 20 % au sein de son benchmark. Ces résultats concernent spécifiquement leurs tâches et leurs architectures, et ne représentent pas un avantage universel pour l’exécution de code.

Je compare l’appel de l’outil JSON, MCP, les compétences, les outils en ligne de commande ainsi que l’exécution de code, dans cet ordre précis. La dernière section applique les principes de conception de l’Interface Agent-Ordinateur (ACI) à Agent d’analyse de marché.

En résumé : Cinq modèles d’interface utiles couvrent la plupart des cas d’usage liés aux agents tool use. Les compétences permettent de transmettre des instructions, les outils en ligne de commande sont adaptés au développement local, MCP assure la communication avec des services partagés, tandis que l’exécution de code permet de structurer des tâches multiples au sein d’un sandbox. L’utilisation d’outils JSON reste le choix le plus simple pour des actions atomiques de petite taille. Quel que soit le protocole, l’Interface Agent-Ordinateur (ACI) doit garantir que les actions soient clairement définies, que les retours d’information soient concis et que les erreurs puissent être corrigées.

Cinq manières dont les agents AI utilisent des outils

In Partie 1, Le reasoning loop a sélectionné l’étape suivante. Partie 2 Il stocke l’état nécessaire pour le reprendre. La frontière de l’outil transforme cette décision en une action et renvoie une observation vers la boucle. Ces cinq motifs entraînent des compromis différents en termes de coût en tokens, de flexibilité et de contrainte d’application.

1. Appel de l’outil JSON : la référence de base

Le schéma de base consiste à définir tool schemas comme JSON, ce qui permet à LLM d’émettre des appels de fonctions structurés que votre code exécute ensuite. Cette approche est bien connue et fonctionne parfaitement pour de 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, c’est acceptable. Le problème réside dans l’échelle : la définition de chaque outil entraîne des coûts importants. 550 à 1 400 tokens. Avec 20 outils, vous dépensez déjà entre 15 000 et 25 000 tokens avant même que l’agent ne commence à raisonner.

2. MCP pour les intégrations partagées

Le Model Context Protocol constitue la norme autour de laquelle la plupart des fournisseurs se sont accordés. En décembre 2025, Anthropic l’a fait don à la Linux Foundation au sein de la fondation Agentic AI (AAIF), qu’elle a cofondée avec OpenAI et Block, avec le soutien de Google, Microsoft et AWS en tant que membres platinum. OpenAI a ajouté une prise en charge MCP dans ses Responses API. On compte aujourd’hui plus de 10 000 serveurs MCP actifs ainsi que plus de 97 millions de téléchargements mensuels SDK.

MCP convient aux intégrations SaaS跨 fournisseurs (Figma, Notion, Salesforce), aux services ne disposant pas d’équivalents en ligne de commande, ainsi qu’aux environnements nécessitant une orchestration OAuth. Son avantage réside dans sa capacité à fournir un layer commun de découverte et de transfert des données. La gouvernance reste cependant subordonnée aux mécanismes d’authentification, d’autorisation, d’journalisation et de déploiement du serveur.

L’histoire en environnement de production est plus complexe que ne le laissent supposer les chiffres présentés dans les titres.

La surface de sécurité constitue le premier problème à prendre en compte. Le Projet MCP vulnérable Surveille 50 vulnérabilités sur les serveurs MCP, dont 13 classées comme critiques, signalées par 32 chercheurs en sécurité. Les catégories d’attaques comprennent prompt injection, des erreurs de validation des entrées, des failles d’authentification ainsi que des vulnérabilités de sécurité réseau. Le premier serveur MCP malveillant dans le monde réel est apparu en septembre 2025: un paquet nommé postmark-mcp cela a réexpédié chaque e-mail envoyé vers l’adresse de l’attaquant par voie BCC, affectant une trentaine à cinq cents organisations avant que le problème ne soit découvert.

Le poisonage d’outil est le type d’attaque qui m’inquiète le plus. Invariant Labs a démontré Ces outils contaminés par MCP peuvent exfiltrer des données même lorsqu’ils ne sont jamais invoqués. Il suffit au modèle de lire les métadonnées de l’outil pour déclencher l’attaque. MCPTox benchmarks Les tests effectués sur 20 agents LLM contre 45 serveurs MCP du monde réel ont révélé des taux de réussite des attaques atteignant jusqu’à 72,8 %.

La surcharge liée aux tokens constitue le problème opérationnel majeur. Une équipe qui gère des serveurs MCP pour GitHub, Slack et Sentry (environ 40 outils au total) a constaté 55 000 tokens des définitions de schéma injectées avant même que l’utilisateur ne pose une question. Un autre cas a été signalé 143 000 sur 200 000 de tokens disponibles (72 %) Entièrement consommé uniquement par les définitions des outils.

Anthropic a indiqué une réduction de 85 % des schémas générés par son outil de recherche d’outils, ainsi qu’une réduction de 96 % lors du chargement de trois à cinq outils pertinents pour les tâches évaluées. Le chargement sélectif permet de conserver l’ensemble des fonctionnalités du protocole tout en supprimant les schémas qui ne sont pas nécessaires à la demande actuelle.

3. Expertise du package de compétences, et non son exécution

La fin de l’année 2025 a marqué la normalisation des agent skills sous forme de format ouvert (lancé en octobre 2025, publié en tant que norme ouverte en décembre 2025). Cette distinction est cruciale : les outils fournissent des capacités (ce que les agents peuvent faire), tandis que les skills apportent une expertise concrète (les connaissances nécessaires pour accomplir des tâches complexes).

La norme SKILL.md définit une compétence comme un fichier Markdown contenant du frontmatter YAML :

---
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 compétences emploient une révélation progressive. Environ 100 tokens de métadonnées sont chargés au démarrage ; les instructions complètes ne s’affichent que lorsque la compétence est active. En revanche, près de 40 outils MCP peuvent consommer environ 55 000 tokens Avant même que le processus de raisonnement ne débute. D’ici mars 2026, Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Goose, Windsurf et Roo Code avaient déjà adopté ce format. Victor Dibia décrit ce changement de paradigme. vers des actions d’agent pilotées par du code.

Utilisez ces compétences pour les connaissances sectorielles, les procédures en plusieurs étapes ainsi que les tâches récurrentes telles que les migrations de bases de données ou les intégrations de paiement. Elles conviennent aux missions où l’agent a besoin d’instructions sur la manière d’utiliser une capacité existante.

4. Outils CLI et shell

Les interfaces CLI peuvent être beaucoup moins coûteuses en contexte lorsque le modèle connaît déjà la commande. Scalekit a rapporté un 4-32x différence de tokens entre ses chemins CLI et MCP au cours de 75 exécutions. Cet étude de cas évalue ses outils et tâches ; elle ne remplace pas une comparaison basée sur vos propres fichiers de configuration et les résultats des commandes.

Des commandes largement documentées telles que git, docker, kubectl, gh, curl, et jq Il est fréquent que ces outils n’aient pas besoin de beaucoup de texte d’introduction décrivant leur schéma. Cependant, les CLI moins courants ou internes exigent néanmoins des aides facilement consultables, des exemples concrets, ainsi qu’une sortie lisible par la machine de manière stable.

Le guide d’Ugo Enyioha Élaboration d’outils en ligne de commande que les agents AI souhaitent réellement utiliser Huit règles de conception codifiées :

1. Structured output est obligatoire — prise en charge --json
2. Les codes de sortie constituent un flux de contrôle — il convient d’utiliser des codes distincts pour différents types d’erreurs.
3. Les commandes doivent être idempotentes.
4. Auto-déclaratives. --help avec des exemples concrets --quiet Pour les valeurs brutes, prise en charge de stdin
5. Fournir --dry-run et --yes flags
6. Prendre en charge l’introspection de la version
7. Gérer l’authentification à l’aide de variables d’environnement

Les compromis sont réels. La CLI ne dispose pas de la sécurité de type offerte par MCP, ni d’orchestration OAuth intégrée, de fonctionnalités de découverte d’outils, ni de journal d’audit. Le schéma auquel la plupart des équipes aboutissent est le suivant : utiliser la CLI en tant que solution par défaut pour le développement et les opérations locales, tandis que MCP est employé pour l’intégration avec des services externes et la gouvernance d’entreprise.

5. Exécution de code pour des tâches à plusieurs étapes

Il s’agit du changement apporté aux outils d’agent que je considère comme le plus significatif. Au lieu que LLM émette des JSON structurés pour appeler des fonctions prédéfinies une par une, l’agent génère un script Python ou Bash complet qui invoque plusieurs outils, traite les résultats à l’aide de boucles et de conditions logiques, et ne renvoie au contexte du modèle que des résumés finaux.

Anthropic a formalisé cela par Appel de outils programmatisés (APT), Désormais, le GA est disponible dans Claude API. Les fondements académiques en sont la Article CodeAct (Wang et al., ICML 2024), qui ont mené des tests sur 17 LLMs et ont constaté que les actions de codage permettaient d’atteindre des taux de réussite des tâches jusqu’à 20 % plus élevés, ainsi que 30 % moins d’étapes par rapport aux solutions basées sur JSON.

Trois études de cas réalisées par des clients montrent dans quels contextes ce schéma peut être utile. Considérez-les comme des preuves fournies par le fabricant et réexécutez la comparaison sur vos propres tâches.

• Vercel a reconstruit leur agent d0 de transformation texte en SQL en supprimant 80 % de ses outils (de 15 à 2 :) ExecuteCommand et ExecuteSQL). Le taux de réussite des tâches est passé de 80 % à 100 %, le temps d’exécution a été réduit de 3,5 fois, et l’utilisation de tokens a diminué de 40 %. Selon eux : « Les meilleurs agents sont probablement ceux qui disposent du moins grand nombre d’outils. »

• Cloudflare a développé le « Mode Code », en permettant aux agents d’écrire du TypeScript pour appeler leur API au lieu de définir des tool schemas, ce qui diminue la charge liée au contexte. Leur raisonnement : “LLMs disposent d’une quantité énorme de code TypeScript issu du monde réel dans leur ensemble d’entraînement, mais seulement un petit nombre d’exemples artificiels de tool calls.”

Voici le motif provenant de La documentation PTC d’Anthropic. Les outils traditionnels utilisés pour l’analyse des dépenses nécessitent plus de 20 passes d’inférence distinctes, une par membre de l’équipe, et tous les données intermédiaires doivent être transmises via le contexte. Un flux de travail consommant environ 150 000 tokens grâce à des appels directs à l’outil a été réimplémenté pour seulement environ 2 000 tokens, ce qui représente une réduction de 98,7 %. Avec l’exécution de code, l’agent écrit un seul script :

# Agent generates this code, executes in sandbox
import json
members = get_team_members("engineering")
over_budget = []
for m in members:
    expenses = get_expenses(m["id"], "Q3")
    total = sum(e["amount"] for e in expenses)
    if total > 5000:
        custom = get_custom_budget(m["id"])
        limit = custom["limit"] if custom else 5000
        if total > limit:
            over_budget.append({"name": m["name"], "spent": total, "limit": limit})
# Only this final summary returns to the LLM context
print(json.dumps(over_budget))

Le LLM ne prend en compte que le résumé final JSON, et non les milliers d’éléments de dépense traités au sein du sandbox. Efficacité en termes de tokens, composabilité native (les boucles et les conditions sont intégrées sans coût supplémentaire), gestion réelle des erreurs (try/except Au lieu de raisonnements en langage naturel concernant les erreurs, ainsi que la confidentialité (les données sensibles restent dans le sandbox), tous ces aspects s’améliorent simultanément.

Lorsque l’appel à la herramienta JSON reste pertinent : pour des opérations atomiques uniques, des environnements ne disposant pas d’infrastructures de sandboxing, de petits modèles présentant une capacité de génération de code limitée, ou encore en cas de exigences de contrôle qui nécessitent que chaque appel à une outil soit enregistré.

AI Table de comparaison des appels d’outils par agent

La composabilité, dans ce contexte, désigne la facilité avec laquelle plusieurs opérations peuvent être enchaînées pour former un flux de travail plus complexe. Une valeur faible indique que chaque tool call nécessite généralement un aller-retour supplémentaire vers le modèle ; une valeur élevée signifie que l’interface peut transmettre les résultats intermédiaires via des pipelines, des variables ou des étapes procédurales. Les cellules dédiées aux tokens et au succès des tâches résument les exemples cités, et non un seul benchmark géré de manière uniforme dans les cinq colonnes.

L’interface agent-ordinateur (ACI) pour les outils d’agent AI

Le terme « Agent-Computer Interface » (ACI) a été introduit par John Yang, Carlos E. Jimenez et leurs collègues de Princeton dans leur Article sur SWE-agent (NeurIPS 2024). L’idée est simple : tout comme les humains tirent parti d’interfaces bien conçues (HCI), les agents de langage modulaire constituent « une nouvelle catégorie d’utilisateurs finaux ayant leurs propres besoins et capacités, qui bénéficieraient d’interfaces spécialement développées pour eux ».

Le Résultats d’ablation J’ai effectué une sauvegarde de ces résultats. L’agent SWE-agent, doté de son ACI complet, a atteint 18,0 % sur le SWE-bench Lite, contre 7,3 % uniquement avec une shell Linux standard, ce qui représente une amélioration de 10,7 points de pourcentage grâce au seul design d’interface. Le mécanisme de contrôle de linting a lui seul contribué à 3 points de pourcentage : 51,7 % des modifications apportées par l’agent présentaient au moins une erreur détectée par le linter avant que celle-ci ne se propage.

Anthropic a adopté l’ACI comme concept fondamental dans ses Construire des agents efficaces Ce guide le présente comme l’un des trois principes fondamentaux : « Concevez avec soin votre interface agent-ordinateur grâce à une documentation et des tests approfondis des outils. » Leur conseil pratique est le suivant : « Une règle d’or consiste à évaluer l’effort requis pour développer des interfaces homme-machine, et à prévoir d’y consacrer autant d’efforts pour créer de bonnes interfaces agent-ordinateur. »

Quatre principes ACI en pratique

1. Les actions doivent être simples et faciles à comprendre. La erreur la plus fréquente consiste à associer de manière un‑à‑un les endpoints API. Au lieu de cela list_users, list_events, create_event, mettre en œuvre schedule_event qui détermine la disponibilité et planifie les tâches en une seule requête. Au lieu de read_logs, mettre en œuvre search_logs qui ne renvoie que les lignes pertinentes accompagnées de leur contexte.

2. Les actions doivent être compactes et efficaces. Consolidez les opérations importantes en un nombre aussi réduit que possible d’actions. Dans le Agent d’analyse de marché, J’intègre la récupération des prix aux métriques de base en une seule entité get_stock_snapshot un outil qui permet d’éviter de devoir effectuer des appels distincts pour obtenir les informations sur le prix, le volume, la capitalisation boursière et le ratio P/E.

3. Les retours d’environnement doivent être informatifs tout en restant concis. Évitez de renvoyer du HTML brut ou des en-têtes API complets. Remplacez les identifiants obscurs par des noms sémantiques. Les tests d’Anthropic a montré que l’ajout d’un response_format L’enum qui permet aux agents de demander des réponses concises (~72 tokens) ou détaillées (~206 tokens), avec une différence de coût en tokens équivalente à un facteur 3, a amélioré de manière significative les performances dans des environnements réels.

4. Les garde-fous doivent atténuer la propagation des erreurs. La détection automatique des erreurs permet aux agents de reconnaître et de corriger rapidement leurs fautes. Dans SWE-agent, Un éditeur de fichiers personnalisé intégrant un outil de linting rejette automatiquement les erreurs de syntaxe, permettant d’identifier 51,7 % des erreurs d’édition des agents avant qu’elles ne s’aggravent. J’applique le même principe dans l’Agent Market Analyst en validant les arguments des outils à l’aide de schémas Pydantic avant leur exécution :

from pydantic import BaseModel, Field, field_validator

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)")
    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 1y")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        v = v.upper().strip()
        if not v.isalpha() or len(v) > 5:
            raise ValueError(f"Invalid ticker format: {v}")
        return v

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

AI Patterns de conception d’outils d’agent fiables et efficaces

Anthropic’s Élaborer des outils efficaces pour les agents Les outils de framework guide sont présentés comme « un nouveau type de logiciel qui incarne un contrat entre des systèmes déterministes et des agents non déterministes ». Voici les schémas qui se sont dégagés de l’expérience en environnement de production.

Considérez les descriptions d’outils comme prompt engineering

Les descriptions doivent être détaillées. Il est nécessaire d’implémenter au moins 3 à 4+ instructions successives pour garantir une exécution cohérente du plan d’action. Cela permet de respecter les contraintes temporelles et logiques propres aux systèmes d’agents modernes. De plus, cette structure assure une meilleure gestion des dépendances entre différentes tâches à exécuter., abordant le moment où il convient d’utiliser l’outil, les paramètres obligatoires par rapport aux paramètres optionnels, le format de sortie, ainsi que les cas limites. Échappement des noms au moyen de préfixesasana_search, jira_searchCela entraîne des « effets non triviaux » sur la précision du choix des outils. Dans les expériences d’Anthropic, les descriptions d’outils optimisées pour Claude ont surpassé celles rédigées par des experts humains lors des évaluations benchmarks.

# 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": "stock_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 broad market news (not ticker-specific), use market_overview 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"]
    }
}]

Tests internes a montré que les exemples d’entrée (input_examples Ce champ a permis d’améliorer de manière significative la précision dans le traitement de paramètres complexes.

Retourner une sortie à fort signal, lisible par la machine

Évitez les identifiants de bas niveau (uuid, mime_type). Convertir les identifiants obscurs en noms sémantiques. Structurer la réponse de manière à permettre à l’agent de raisonner dessus sans avoir à analyser du texte générique :

# Bad: raw API response dumped to agent
def get_stock_price(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_price(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}%)"
    }

Retourner les erreurs sur lesquelles le boucle peut agir

Utilisez quatre mécanismes distincts, car chacun gère des catégories d’échec différentes :

1. Réessayer avec un backoff exponentiel en cas d’erreurs transitoires
2. Chaînes de fallback de modèles en cas de panne du fournisseur
3. Affectation par classification des erreurs : les erreurs transitoires sont réessayées, les LLM-erreurs récupérables sont renvoyées à l’agent accompagnées de contexte, tandis que les erreurs nécessitant une intervention humaine sont escaladées
4. Checkpoint pour assurer la survie en cas de plantage

Le guide d’Anthropic cité favorise la détection claire des erreurs des outils ainsi qu’une conception de ces derniers basée sur l’évaluation. Il ne définit pas de taux universel de réduction des pannes ; par conséquent, mesurez vous-même le taux de récupération, le nombre de tentatives et les procédures d’escalade pour votre ensemble de tâches.

from tenacity import retry, stop_after_attempt, wait_exponential

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

    Layer 1: Exponential backoff handles 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 modèles à l’agent Analyste de marché

Le Agent d’analyse de marché de Partie 1 rend visible l’effet de l’interface.

Consolidation des outils

L’article de la première partie présente la surface simplifiée à 5 outils issue de cette refonte. Avant cette opération de nettoyage, la conception initiale comptait plus de 10 outils : get_stock_price, get_company_metrics, get_market_cap, get_pe_ratio, get_volume, et ainsi de suite. Chacun d’eux n’était rien de plus qu’un enveloppe légère entourant une interface API. L’agent devait déterminer quelle combinaison appeler pour chaque requête.

J’ai regroupé ces éléments en 5 outils de haut niveau, en suivant le principe ACI d’actions compactes et efficaces :

Cela réduit considérablement la surcharge générée par tool schema et rend la sélection des outils par l’agent plus fiable, puisqu’il y a moins de choix ambigus à prendre en compte.

Structured outputs pour tool results

Chaque outil intégré à l’Agent Market Analyst renvoie une réponse validée par Pydantic. Cela met en œuvre le principe des garde-fous ACI au niveau de la frontière de l’outil :

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 NewsResult(BaseModel):
    """Each news item is 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

Le summary Le champ est celui qui revêt la plus grande importance. Il fournit à l’agent une chaîne prête à l’emploi qui peut être intégrée directement dans un rapport sans aucun traitement supplémentaire. key_points dans NewsResult Elles sont extraites du côté serveur, ce qui permet à l’agent d’éviter de consommer des tokens d’inférence pour parser le corps des articles.

Compromis et considérations

Outre les réserves spécifiques à chaque modalité mentionnées ci-dessus, plusieurs considérations transversales influencent ce choix :

• Le coût opérationnel varie en fonction de la dimension considérée. L’exécution de code permet d’économiser des tokens, mais augmente la latence de démarrage sandbox. MCP réduit le temps de développement nécessaire pour les intégrations SaaS, tout en ajoutant des coûts liés au déploiement des serveurs. La CLI est gratuite pour être lancée, mais plus difficile à gérer à grande échelle. Il convient d’optimiser en fonction du véritable goulot d’étranglement, qu’il s’agisse du coût en tokens, de la latence ou de la complexité opérationnelle.

• Les compétences de l’équipe sont essentielles. L’exécution de code suppose que vos agents (ainsi que les modèles qui les sous-tendent) sont capables de générer du Python ou du TypeScript fiables. L’interface ligne de commande exige une connaissance approfondie des conventions Unix. MCP nécessite une compréhension des protocoles de transport et des flux OAuth. Adaptez le mode d’interaction aux forces de votre équipe.

• La consolidation des outils peut aller trop loin. Lorsqu’un outil accumule des modes et des arguments non liés, l’agent se heurte à un problème de sélection différent au sein du schéma. Utilisez les évaluations de sélection d’outil et de réussite de tâche pour identifier l’interface adaptée à votre charge de travail.

• Les compétences sont basées sur prompt, mais ne sont pas imposées de manière stricte. Une compétence représente des instructions que l’agent doit suivre, et non des contraintes qu’il est tenu d’observer. Pour les workflows critiques, il convient de combiner ces compétences avec une validation déterministe.

• Les exigences en matière d’audit influencent le choix des solutions. Si vous avez besoin d’un registre complet de chaque appel à un outil ainsi que de son résultat, les outils MCP et JSON fournissent des traces d’audit structurées directement, sans configuration supplémentaire. L’exécution de code génère un script ainsi que ses sorties, ce qui est utile, mais il est plus difficile de décomposer ces éléments en actions individuelles pour la rédaction de rapports de conformité.

Sélection d’outils à grande échelle

Trois directions méritent d’être suivies.

Le premier est l’outil RAG destiné à l’échellement. Lorsque les ensembles d’outils atteignent des centaines ou des milliers d’éléments, la précision d’un choix d’outil naïf diminue jusqu’à 13,62 %. document relatif à RAG-MCP Il a été démontré que l’application de la génération augmentée par récupération à la sélection d’outils – c’est‑à‑dire l’indexation des descriptions d’outils dans une base de données vectorielle et la récupération uniquement des outils pertinents pour chaque requête – permet d’atteindre une précision de 43,13 %, ce qui représente une amélioration de 3,2 fois, tout en réduisant le nombre de tokens prompt d’environ 50 %.

Le deuxième cas concerne les agents qui créent leurs propres outils. LATM framework (LLMs En tant que concepteurs d’outils), on a établi un paradigme en deux phases dans lequel un LLM puissant génère des fonctions Python réutilisables, tandis qu’un LLM léger les utilise. ToolMaker (ACL 2025) transforme de manière autonome des dépôts GitHub en outils compatibles avec LLM, atteignant un taux de réussite de 80 %. Les recherches progressent actuellement du tool use vers la création d’outils, avant de se diriger vers la gestion de bibliothèques d’outils.

Le troisième est l’empileur à double protocole A2A + MCP. Le Protocol Agent2Agent de Google (A2A) permet de résoudre les problèmes que MCP ne peut pas gérer : la communication entre agents. MCP s’occupe de l’intégration agent-outil, tandis que A2A gère la découverte des agents, les négociations et la délégation de tâches. La formule combinée est la suivante : construire avec votre framework, équiper avec MCP, communiquer avec A2A.

Principaux enseignements

1. Choisissez l’interface en fonction de l’action : JSON pour les opérations à entrée structurée, MCP pour les services partagés, Skills pour les procédures, la CLI pour les commandes standardisées, et du code exécuté dans un environnement isolé pour la composition locale.
2. Conservez les conditions benchmark associées au résultat. Des solutions telles que CodeAct, Anthropic, Vercel, Cloudflare, Apideck et Scalekit ont été utilisées pour évaluer différents modèles, tâches, outils et plateformes d’intégration.
3. La qualité des ACI reste stable malgré les changements de protocole. Des actions claires, des retours d’information concis, des mécanismes de validation efficaces ainsi que des messages d’erreur utiles facilitent l’utilisation de chaque modalité.
4. Ne consolidez que les outils qui se chevauchent lorsque les évaluations montrent qu’une interface simplifiée améliore le choix des outils ou le succès des tâches.
5. La sécurité évolue avec les capacités d’exécution. Les interfaces shell et de code nécessitent un environnement isolé ; MCP requiert une gestion fine des identités et des politiques serveur ; quant à Skills, il s’agit toujours de directives plutôt que de mécanismes d’application stricte.

La couche suivante concerne les politiques

Partie 4, AI Sécurité des agents en 2026, On insère une vérification de politique entre la proposition de tool call et son exécution. La partie 5 place ensuite l’outil ainsi que son sandbox à l’intérieur d’un runtime permettant le redémarrage. La partie 6 revient à l’interface depuis le côté harness : on y montre comment les traces, les évaluateurs, les règles de tentative répétée et les contrôles d’acceptation transforment les retours de l’outil en un cycle d’amélioration mesurable.

Références

Articles de recherche

• Les actions de code exécutables permettent d’obtenir des agents LLM de meilleure qualité (CodeAct). — Wang et al., ICML 2024 — Les actions basées sur du code permettent d’atteindre un taux de réussite des tâches 20 % plus élevé que JSON
• SWE-agent : Les interfaces agent-ordinateur permettent l’ingénierie logicielle automatisée — Yang, Jimenez et al., NeurIPS 2024 — Principes de conception des ACI et évaluation via SWE-bench (18,0 % contre 7,3 %, soit une amélioration de 10,7 points en raison de la conception de l’interface)
• RAG-MCP : Atténuer la surcharge générée par Prompt dans le processus de sélection des outils LLM — Outil RAG permettant d’améliorer la précision de sélection de 13,62 % à 43,13 % LLMs En tant que concepteurs d’outils (LATM) — Cai et al., 2023 — Paradigme à deux phases pour la création d’outils d’agents ToolMaker : LLM Des agents qui créent des outils d’agents — Wolflein et al., ACL 2025 — Taux de réussite de 80 % pour transformer des dépôts en outils
• MCPTox : une évaluation exhaustive de la MCP toxicité Benchmark — Taux de réussite des attaques de 72,8 % sur 20 agents LLM et 45 serveurs MCP

Ingénierie Anthropic

• Appels avancés de Tool Use / Outils programmables — Recherche d’outils (réduction de l’schéma de 85 %), PTC, et exemples de tool use Exécution de code avec MCP — Réduction de 98,7 % des tokens (de 150 K à 2 K tokens) grâce à l’orchestration d’outils basés sur du code
• Rédiger des outils efficaces pour les agents — Conception de la description de l’outil ; les exemples d’entrée améliorent la précision ; énumération response_format (72 contre 206 tokens) Construire des agents efficaces — L’ACI en tant que principe fondamental de conception

Études de cas sectorielles

• Vercel : Nous avons supprimé 80 % des outils de notre agent — De 15 à 2 outils, taux de réussite de 80 % à 100 %, vitesse 3,5 fois supérieure, 40 % moins de tokens Cloudflare : Mode Code — Appels API pilotés par TypeScript remplaçant les tool schemas
• Apideck : MCP Un serveur qui épuise votre fenêtre de contexte — 550 à 1 400 tokens par outil, 55 K tokens pour environ 40 outils MCP, consommation de contexte de 143 K à 200 K Scalekit : MCP contre le token CLI Benchmark — Surpoids de 4-32 fois en tokens pour MCP par rapport à la CLI au cours de 75 exécutions benchmark

Sécurité

• Projet vulnérable MCP — 50 vulnérabilités identifiées, dont 13 sont de niveau Critique, signalées par 32 chercheurs AuthZed : Chronologie des fuites de données MCP — 9 incidents majeurs de sécurité MCP (avril-octobre 2025)
• Invariant Labs : attaques de contamination d’outil MCP — Empoisonnement des outils, retraits soudains de fonctionnalités et escalade entre origines différentes Sécurité des points pivots : Analyse de sécurité MCP — 43 % d’injections de commandes, 43 % de vulnérabilités dans l’authentification OAuth

Conception de l’interface ligne de commande

• Rédiger des outils en ligne de commande que les agents AI souhaitent réellement utiliser — Ugo Enyioha — Huit règles de conception pour des CLI adaptés aux agents

Projet de démonstration

• Agent d’analyse de marché — Implémentation complète incluant la consolidation des outils et les patterns ACI

Le code complet de l’agent Market Analyst, y compris les conceptions d’outils décrites dans cette publication, se trouve sur GitHub._

Série : Conception de la pile Agentic

• Partie 1 : AI Les boucles de raisonnement des agents en 2026 — ReAct, ReWOO, ainsi que le modèle Plan-and-Execute Partie 2 : AI L’architecture mémoire des agents en 2026 — checkpoints, les bases de données vectorielles et la mémoire de documents
• Partie 3 : AI L’agent Tool Use en 2026 (cet article) Partie 4 : AI La sécurité des agents en 2026 — garde-fous, permissions, sandboxes, HITL, ainsi que le cadrage MCP
• Partie 5 : Agents AI à exécution prolongée Runtime en 2026 — sessions, sandboxes, checkpoints, mécanismes d’orchestration et schémas de déploiement
• Partie 6 : Harness Engineering pour les agents AI (à paraître prochainement) — vérifications d’acceptation, traces, tentatives de réessai, transferts de responsabilités, ainsi que le cycle associé au modèle