Étude de cas · Automatisation du support client
L'agent de support consacrait plus de contexte aux définitions d'outils qu'au ticket lui-même.
L'agent IA d'une équipe de support était connecté à une douzaine de serveurs MCP et noyait chaque prompt sous les schémas d'outils. Le passage au Code Mode d'onemcp a rendu le contexte au problème du client — et réduit le coût et la latence de chaque réponse.
- Secteur
- Support client SaaS
- Équipe
- Organisation de support d'~15 personnes
- Stack technique
- Zendesk · Stripe · Postgres · API de commandes interne · Slack
# Synthèse
- Surcharge d'outils par requête réduite d'environ 90 %
- Schéma d'outils par appel ramené d'~15 000 à ~500 jetons
- Coût et latence en baisse à chaque réponse
Scénario illustratif inspiré de déploiements onemcp courants. L'équipe décrite est une composition et non un client nommé ; les chiffres sont représentatifs et non mesurés.
Contexte
Une équipe de support SaaS avait bâti un agent IA pour trier et traiter les tickets. Pour travailler réellement, il lui fallait une large portée : Zendesk pour le ticket, Stripe pour le paiement, Postgres et une API de commandes interne pour l'état du compte, et Slack pour l'escalade. Chacun de ces éléments était un serveur MCP, câblé directement dans l'agent.
L'agent fut utile dès le premier jour. Il était aussi lent et coûteux d'une manière que l'équipe ne parvenait pas tout à fait à expliquer — jusqu'à ce qu'elle examine ce que contenait réellement chaque prompt.
Le défi
Chaque serveur MCP auquel l'agent se connectait injectait, à chaque requête, l'intégralité de son schéma d'outils dans le contexte. Avec une douzaine de serveurs connectés, cela représentait des centaines de définitions d'outils et de paramètres accompagnant chaque ticket — que le ticket courant en ait besoin ou non.
Le coût se manifestait de trois façons :
- Un contexte gaspillé. Environ 15 000 jetons de formules d'outils précédaient la vraie question du client dans chaque prompt. Sur les longs fils, les définitions évinçaient la conversation elle-même.
- Des factures et une latence plus élevées. Ces jetons d'entrée étaient payés et traités à chaque tour, multipliés par des milliers de tickets par semaine.
- Davantage de marge d'erreur. Un prompt plus vaste et plus bruité offrait au modèle plus d'occasions de choisir le mauvais outil ou de perdre le fil d'un ticket en plusieurs étapes.
L'approche
L'équipe a placé l'ensemble des serveurs de l'agent derrière un unique portail onemcp et a fait dialoguer l'agent avec lui via le Code Mode.
Au lieu de précharger chaque définition, le portail expose trois méta-outils :
search— trouver les outils pertinents pour le ticket en cours.describe— obtenir à la demande la signature exacte de ces seuls outils.execute— exécuter un court script qui les appelle, en un seul aller-retour.
Ainsi, un ticket de remboursement charge les outils Stripe et de commandes dont il a besoin, et rien d'autre. Le catalogue complet reste disponible — il n'est simplement plus entraîné dans chaque prompt.
Les résultats
- Environ 90 % de surcharge d'outils en moins par requête. Le schéma d'outils par appel est passé d'environ 15 000 jetons vers ~500. L'économie se répète à chaque tour de chaque ticket.
- Des réponses moins chères et plus rapides. Moins de jetons d'entrée par appel se traduisait par une facture plus basse et une première réponse plus rapide, sans retirer aucun outil de la portée de l'agent.
- Un traitement multi-étapes plus stable. Le contexte tourné vers le ticket plutôt que vers la boîte à outils, l'agent gardait le fil tout au long des remboursements, recherches de compte et escalades.
L'agent est devenu plus rapide et moins cher le jour même du basculement, et nous n'avons retiré aucun outil. Il a simplement cessé de tous les transporter dans chaque message.