Agent Azure AI Foundry et MCP : pourquoi c’est plus rapide qu’un LibreChat

Le symptôme : un agent qui réfléchit bien, mais qui vous fait attendre

Vous avez branché votre agent sur Microsoft 365, sur votre CRM, sur Odoo. Il sait tout faire. Mais dès qu’une question demande trois outils (« prépare mon rendez-vous de 14 h »), la réponse met longtemps à arriver, et l’équipe retourne chercher à la main.

Le plus souvent, le modèle n’y est pour rien. C’est le chemin que prend chaque appel d’outil qui coûte cher. Et ce chemin dépend de l’endroit où vous faites tourner l’agent.

Comment une interface de chat appelle un outil MCP

Dans LibreChat, Open WebUI ou une interface faite maison, le serveur de chat est le client MCP. Le modèle (OpenAI, Azure OpenAI, Mistral…) ne parle pas directement à vos outils : il répond « appelle tel outil avec tels paramètres », et c’est le serveur de chat qui s’en charge, puis qui relance le modèle avec le résultat.

Pour une question qui demande deux outils, cela donne :

Sur nos propres agents, la différence saute aux yeux dès qu’ils utilisent des outils MCP : avec Foundry, la réponse arrive beaucoup plus vite. Rien de dramatique sur un seul outil, en revanche. Mais un agent utile en enchaîne souvent trois ou quatre : chercher le client, lire le dernier e-mail, regarder l’agenda, préparer une note. Chaque étape repasse par votre serveur, et chaque requête au modèle renvoie tout le contexte.

Comment Azure AI Foundry appelle le même outil

Avec le service d’agents d’Azure AI Foundry, l’outil MCP fait partie de la définition de l’agent : une adresse de serveur, un nom, et une connexion d’authentification. Quand le modèle a besoin de l’outil, c’est Foundry lui-même qui l’appelle, puis qui reprend le raisonnement avec le résultat. Le navigateur ne voit passer que la réponse, diffusée au fil de l’eau, et les étapes de travail si vous voulez les afficher.

Trois conséquences concrètes :

• Moins d’allers-retours. Le contexte de la conversation reste dans Foundry. Votre application n’a pas à le renvoyer à chaque outil.
• Rien à héberger entre l’utilisateur et le modèle. Pas de serveur de chat, pas de base de données de conversations, pas de mises à jour de LibreChat à suivre.
• Le raisonnement reste continu. Le modèle enchaîne ses outils sans repasser par l’extérieur ; vous pouvez même afficher en direct le résumé de ce qu’il fait.

Un réglage compte beaucoup pour la vitesse : l’approbation des outils. Par défaut, Foundry peut demander une validation avant chaque appel MCP, ce qui renvoie la main à l’application. Pour un serveur de confiance, en lecture ou limité à des brouillons, on la désactive (require_approval: "never") et l’agent enchaîne sans attendre.

Un exemple réel : « Prépare mon rendez-vous de 14 h avec Maison Ferrand »

Un commercial pose la question dans un onglet Teams. L’agent a deux serveurs MCP : celui du CRM, et un serveur Microsoft 365.

1. CRM : l’agent lit l’opportunité « Agencement du showroom », 42 000 € HT, étape Négociation.
2. Microsoft 365 : il cherche les derniers e-mails échangés avec le client, et trouve une demande d’étalement du paiement.
3. Microsoft 365 : il retrouve le compte rendu de la dernière réunion Teams, qui signale un changement de décideur.
4. CRM : il ajoute une note de préparation à l’opportunité.

Quatre outils, une seule question. Avec un serveur de chat au milieu, ce sont quatre relances complètes du modèle depuis votre serveur. Avec Foundry, c’est une seule requête depuis Teams, et le commercial voit défiler les étapes pendant que l’agent travaille.

Et les droits ? L’OAuth délégué, expliqué simplement

La vitesse ne vaut rien si l’agent voit tout. Foundry gère pour cela l’OAuth identity passthrough : chaque utilisateur se connecte une fois au serveur MCP avec son propre compte.

1. Vous déclarez dans votre projet Foundry une connexion OAuth vers le serveur MCP : l’application Microsoft Entra à utiliser et les droits demandés.
2. La première fois qu’un utilisateur sollicite l’outil, Foundry renvoie un lien de connexion. L’utilisateur accepte, une seule fois.
3. Foundry conserve son jeton et le transmet au serveur MCP à chaque appel.
4. Le serveur MCP interroge Microsoft 365 (ou votre logiciel) au nom de cet utilisateur, par exemple avec le flux « on-behalf-of » de Microsoft Entra.

Résultat : un assistant RH ne lit que les dossiers que la personne peut ouvrir, et un commercial ne voit que ses propres comptes. Pas de compte technique tout-puissant, pas de clé partagée.

Gratuit et open source : Foundry Agents affiche vos agents Foundry dans SharePoint et Teams, gère la connexion de chaque utilisateur à vos serveurs MCP et montre les outils appelés en direct. Voir Foundry Agents · Le code sur GitHub

Ce qu’il faut savoir avant de se lancer

Quelques points vérifiés en conditions réelles, qui évitent des journées de recherche :

Point	Ce qui se passe	Ce qu’on fait
Liste des outils	Foundry demande la liste des outils de chaque serveur MCP avant chaque réponse	Héberger le serveur sur une offre qui ne s’endort pas (Azure Functions Flex avec instances toujours prêtes, Container Apps avec une instance minimum)
Démarrage à froid	Un serveur endormi ajoute plusieurs secondes à la première réponse	Instance toujours prête, ou un simple appel périodique
Trop d’outils	Un serveur Microsoft 365 complet expose des centaines d’outils, au-delà de ce qu’un modèle accepte	Ne garder que les outils utiles (préréglages, liste d’outils autorisés), ou un serveur à recherche d’outils
Lien de connexion	Le lien de consentement expire après quelques minutes	L’interface doit l’afficher au bon moment et proposer de recommencer
Locataire	L’OAuth délégué de Foundry exige que l’utilisateur appartienne au même locataire Microsoft Entra que le projet	Prévoir des comptes invités pour les partenaires, ou un projet par locataire
Droits	Le serveur MCP peut faire tout ce que ses permissions autorisent	Lecture seule ou brouillons d’abord, et des droits Microsoft Graph limités au strict nécessaire

Où ça s’affiche : SharePoint et Teams, sans rien installer de plus

Un agent Foundry n’a pas d’interface. Plutôt que d’héberger un portail de chat, Foundry Agents l’affiche là où vos équipes travaillent déjà : une page SharePoint, un onglet Teams, l’application Teams. Le composant est gratuit et open source (licence MIT) :

• chaque utilisateur se connecte avec son compte Microsoft 365, sans clé d’API ;
• la connexion à vos serveurs MCP se fait dans la conversation, une fois ;
• les étapes de l’agent (outils appelés, durée, résultat) s’affichent en direct ;
• plusieurs agents par page, chacun visible seulement par son équipe.

Vous pouvez l’installer et l’utiliser tel quel pour vos propres cas d’usage : les idées n’ont pas de limite. Et si vous voulez aller plus loin, un serveur MCP pour votre logiciel métier, des agents sur vos données, un déploiement propre dans tout le tenant, on peut en parler.