Chaque intégration que vous enregistrez à la main est de la dette

Chaque outil que vous enregistrez à la main dans votre agent est de la dette à échéance : quelqu'un doit le mettre à jour, le ré-enregistrer et le versionner, et ce quelqu'un, en général, c'est vous. MCP (Model Context Protocol) attaque le problème par le côté opposé : au lieu de porter le catalogue dans l'agent, il le met sur un serveur que l'agent interroge quand il en a besoin. Le module Microsoft Learn « Integrate MCP tools with Azure AI Agents » le parcourt complètement. Ce post fait pareil : ce que résout le catalogue actif, comment se construisent le serveur et le client, ce que simplifie le chemin administré du Foundry Agent Service et comment entre l'approbation humaine au milieu.

Le coût d'enregistrer à la main

Le calcul est simple et défavorable : enregistrer, mettre à jour et versionner chaque API grandit plus vite que l'agent lui-même. Chaque nouvel outil ajoute une intégration à maintenir ; chaque changement côté fournisseur devient votre tâche ; chaque version non testée, une possibilité de casser en production. Et le coût se répète sur chaque agent que vous montez : la même intégration, écrite une fois par équipe, une fois par projet.

MCP change l'équation avec un principe : « intégration une fois ». La connexion s'écrit une fois, sur un serveur centralisé ; celui qui la consomme est l'agent, à l'exécution, en demandant au catalogue quels outils sont disponibles aujourd'hui. Avec plusieurs intégrations en jeu, la maintenance se multiplie par le nombre d'agents : le même correctif d'authentification réappliqué dans chaque projet.

Ce qu'est MCP

MCP est un standard ouvert qui standardise la façon dont les intégrations d'outils se connectent aux agents d'IA, via la détection dynamique et les catalogues actifs. La détection dynamique est le mécanisme central : l'agent interroge un serveur MCP à l'exécution et obtient le catalogue à jour des outils avec leurs descriptions, sans avoir les intégrations en dur.

Les conséquences pratiques se voient au quotidien. Les outils s'ajoutent, se mettent à jour ou se retirent sur le serveur sans modifier l'agent. Et comme le catalogue voyage avec des descriptions, l'agent sait ce que fait chaque outil et à quoi il sert avant de décider s'il l'appelle.

Les trois avantages

Ce que MCP apporte face à une intégration sur mesure se regroupe en trois :

Interopérabilité entre LLM : vous changez ou évaluez des modèles sans refaire les intégrations ; la connexion vit sur le serveur, pas dans du code lié au fournisseur.
Sécurité standardisée : une méthode d'authentification cohérente entre serveurs, sans clés indépendantes par API que l'agent va toucher.
Maintenance réduite : le principe « intégration une fois » concentre la maintenance sur le catalogue et non sur chaque agent séparément.

Le serveur : FastMCP et @mcp.tool

Le serveur MCP est le registre d'outils de l'agent, et avec FastMCP il se construit court : FastMCP("server-name") crée le serveur, et chaque fonction que vous voulez publier porte le décorateur @mcp.tool. FastMCP utilise les annotations de type et les docstrings de votre fonction pour générer la définition de l'outil et sert tout par HTTP. C'est-à-dire : vous écrivez une fonction Python normale, avec ses types et sa description, et cette fonction devient un outil du catalogue.

Deux détails définissent son rôle. Il peut se mettre à jour sans redéployer l'agent : vous changez la fonction sur le serveur et l'agent voit le changement à sa prochaine requête. Et ce qu'il ne fait pas compte aussi : le serveur héberge les définitions d'outils et les met à disposition du client ; il n'invoque pas d'outils ni n'administre l'état de la conversation. Cette séparation permet de changer de serveur sans toucher à l'agent, et de changer d'agent sans toucher au serveur. Et comme le serveur vit à un seul endroit, les identifiants et les endpoints se configurent là, une fois.

Le client : découvrir, encapsuler, enregistrer

Le client MCP est le pont entre le serveur et le service d'agent, et il parcourt un flux séquentiel en trois étapes :

Découvrir. Il initialise la session et détecte les outils disponibles avec session.list_tools(), qui renvoie le catalogue actuel avec ses descriptions.
Encapsuler. Chaque outil est enveloppé dans une fonction asynchrone qui invoque session.call_tool(tool_name, tool_args). L'invocation passe par call_tool, pas par list_tools : list_tools découvre ; call_tool exécute.
Enregistrer. Les fonctions auxiliaires se regroupent dans un FunctionTool qui s'enregistre dans l'agent Azure AI, prêt pour l'invocation en langage naturel.

L'étape 2 a une raison qu'il vaut comprendre : l'encapsulation asynchrone permet d'appeler les outils du catalogue comme s'ils étaient des fonctions natives, sans bloquer l'exécution. Pendant que l'outil répond, l'agent reste utilisable.

Le flux complet

flowchart LR
    A[Agent Azure AI] -->|"1 · list_tools()"| C[Client MCP]
    C -->|"2 · demande le catalogue"| S[Serveur MCP<br/>fonctions @mcp.tool]
    S -->|"3 · descriptions"| C
    C -->|"4 · FunctionTool enregistré"| A
    A -->|"5 · call_tool(tool, args)"| C
    C -->|"6 · invocation HTTP"| S
    S -->|"7 · résultat"| C
    C -->|"8 · résultat asynchrone"| A

Les étapes 1 à 4 sont la découverte : c'est le catalogue entrant dans l'agent, avec ses descriptions, et de là sort la décision de quoi appeler et pourquoi. Les étapes 5 à 8 sont l'invocation d'un outil déjà découvert, c'est-à-dire là où l'agent travaille. Au quotidien de l'agent, ce qui existe c'est le FunctionTool ; le serveur reste de l'autre côté du client, faisant son travail.

Le chemin administré : MCPTool

Il y a un raccourci pour tout ce qui précède : l'objet MCPTool du Foundry Agent Service connecte l'agent à des serveurs MCP distants sans créer le client à la main. Les paramètres, tous déclaratifs :

server_label : le nom avec lequel l'agent identifie le serveur.
server_url : le point de terminaison du serveur distant.
En-têtes personnalisés : clés d'API ou tokens OAuth, appliqués avec update_headers.
allowed_tools (optionnel) : quels outils du serveur l'agent peut utiliser.
require_approval : always par défaut ; never pour le laisser passer sans frein.

L'exemple utilise « GitHub » comme server_label et https://api.githubcopilot.com/mcp/ comme server_url, avec les en-têtes appliqués par update_headers. Avec ça, les outils s'invoquent automatiquement pendant l'exécution et le client MCP à la main cesse d'être votre travail.

Approbation humaine

require_approval gouverne l'étape sensible. Sur always, la valeur par défaut, chaque invocation passe par une approbation humaine avant de s'exécuter ; sur never, l'outil tourne sans frein. Le message a une forme fixe : la réponse de l'agent inclut un mcp_approval_request, et on répond avec un mcp_approval_response qui porte le approval_request_id de la requête et la décision (approve).

sequenceDiagram
    participant A as Agent
    participant H as Approbateur
    A->>A: invocation avec require_approval: always
    Note over A: la réponse inclut mcp_approval_request
    A->>H: mcp_approval_request (approval_request_id)
    H->>A: mcp_approval_response (approve)
    A->>A: l'outil s'exécute

La paire approval_request_id et approve est ce qui permet d'auditer le flux de bout en bout : chaque réponse se raccroche à la requête qui l'a déclenchée. La valeur se choisit à la création du MCPTool et s'applique aux outils que cet objet apporte : always laisse le frein en place jusqu'à ce que vous décidiez de le bouger, never le retire.

L'exemple : inventory de cosmétiques

Un détaillant de cosmétiques expose via un serveur MCP les outils qui évaluent les niveaux de stock et les tendances de ventes. L'assistant IA interroge le catalogue et répond à l'équipe d'inventaire sans qu'aucune de ces API soit intégrée à la main dans l'agent. « Est-ce qu'on reste en stock de la crème de nuit ? » se répond avec des données qui vivent sur le serveur. Si la semaine prochaine ils ajoutent un outil de retours, il s'ajoute sur le serveur et l'assistant commence à l'utiliser sans que personne ne touche à son code.

De la lecture à l'exécution

Ce qui n'a pas tourné, c'est la pratique de créer sa propre solution d'outils MCP avec le Foundry Agent Service : ça exige un abonnement Azure. Et un cas concret est resté sans essai : comment se comporte allowed_tools quand un même agent pointe vers plusieurs serveurs MCP. Le post a couvert le protocole, le serveur, le client, le chemin administré et le flux d'approbation ; il reste à lancer la pratique et à pointer un agent vers deux catalogues réels pour voir ce qu'il fait avec les outils des deux.

Mon avis

La question n'est plus si vous connectez votre agent à trois APIs aujourd'hui, mais combien il vous coûte de maintenir ces trois quand elles changent. Chaque intégration à la main est de la dette qui se paie à chaque mise à jour ; le catalogue à un seul endroit est la façon d'arrêter de la payer par agent. Si vous allez connecter votre agent à plusieurs serveurs, le travail qu'il vaut de planifier est celui du catalogue : bien décrire les outils une fois et laisser l'agent demander. L'agent ne devrait pas apprendre où vit l'outil ; il devrait apprendre ce qu'il peut faire.

---

*Source : le module « Integrate MCP tools with Azure AI Agents » de Microsoft Learn.*