AWS publie 6 approches pour optimiser les outils MCP et économiser du contexte

Le 12 juillet 2026, AWS a publié un guide technique sur les problèmes de conception des outils MCP et proposé 6 approches pratiques pour les résoudre, de l'optimisation des descriptions à l'analyse des paramètres côté serveur par IA. L'étude repose sur des tests réels d'une API de recherche de contenus éducatifs (K-12).

Pourquoi les outils MCP dégradent la qualité des modèles

Le Model Context Protocol aide les LLM à utiliser des outils externes, mais la conception des définitions est souvent mauvaise. AWS a identifié deux problèmes principaux :

Bloat (gonflement) : chaque serveur MCP charge les définitions de ses outils dans la fenêtre de contexte, même s'ils ne servent pas. Avec plusieurs serveurs actifs, la fenêtre se remplit de définitions avant que l'utilisateur ne pose sa première question.

Confusion : un contexte surchargé dégrade le raisonnement du modèle. Le LLM confond des outils similaires, se trompe de paramètres et interprète mal les contraintes. La proximité sémantique entre les outils et des noms de paramètres peu clairs aggravent le problème.

6 approches : tout l'éventail des solutions

AWS a testé six implémentations sur des requêtes réelles comme « Trouve un test sur les fractions pour la 7e année » et « J'ai besoin de contenu aligné sur le TEKS » :

• V1 (Raw Passthrough) : expose l'API du backend telle quelle, avec beaucoup d'erreurs de paramètres
• V2 (Rich Descriptions) : des docstrings détaillées avec exemples, qui améliorent la précision mais alourdissent la taille
• V3 (Schema & Defaults) : paramètres renommés (`discipline` → `subject`), enums `Literal`, valeurs par défaut raisonnables ; un bon compromis
• V4 (Lazy Loading) : les détails (taxonomie) sont placés derrière un outil distinct ; la base est minimale, mais il faut des requêtes supplémentaires
• V5 (Server-side Introspection) : Amazon Nova 2 Lite analyse les paramètres côté serveur ; le comportement est stable, mais des appels d'inférence s'ajoutent
• V6 (Agent-as-Tool) : un seul paramètre `question: str`, toute la logique à l'intérieur ; un contrôle maximal, mais il faut une infrastructure

Les recommandations clés d'AWS

L'AWS Prescriptive Guidance recommande de limiter les paramètres d'un outil à « environ huit ou moins ». L'étude d'Anthropic a montré qu'une sortie détaillée à la demande réduit les tokens de réponse d'environ deux tiers.

Par ailleurs : rédiger des messages d'erreur précis et exploitables (pas un simple « no results », mais une description exacte de ce qu'il faut essayer). Utiliser des noms de paramètres propres au domaine plutôt que des noms de colonnes de base de données réduit nettement la confusion du modèle.

Comment choisir l'approche adaptée à votre cas

Il n'existe pas de solution universelle. Le choix dépend du nombre de paramètres (peu → V3, beaucoup → V4-V5), de la stabilité du vocabulaire, des exigences de latence et du besoin d'uniformité entre différents modèles. Pour la plupart des tâches de recherche et de filtrage, V3 suffit. Les applications spécialisées (taxonomies complexes, raisonnement en plusieurs étapes) tirent profit de V4-V5.

Ce que cela change

Les outils MCP ralentissent aujourd'hui souvent les agents LLM, mais AWS a montré que le problème peut se résoudre par l'ingénierie de contexte. Les ingénieurs disposent désormais d'un playbook pratique pour équilibrer contexte et précision, plutôt que d'ajouter des descriptions à l'aveugle.