Quand on conçoit des applications basées sur des modèles de langage, le choix de la méthode d’intégration avec le monde extérieur est crucial. Voici les grands axes de ma réflexion sur le sujet :
- Les Tools (ou Function Calling) s’intègrent directement au code de l’application. C’est l’approche idéale pour développer rapidement un prototype, faire du sans-serveur (serverless) ou exécuter des tâches simples à faible latence.
- Le Model Context Protocol (MCP) est un standard d’architecture ouvert qui sépare la logique de l’IA de ses sources de données. C’est le choix logique pour les projets d’agents à grande échelle, nécessitant de la réutilisabilité et une sécurité renforcée.
- L’approche hybride est souvent la plus efficace en production : utiliser des Tools locaux pour la logique interne ultra-rapide et l’architecture MCP pour l’accès aux données externes et aux outils communautaires.
Ma première confrontation au problème : les limites des Tools classiques
Au début, quand je voulais qu’un grand modèle de langage interagisse avec des outils externes, je n’avais pas d’autre choix que d’utiliser le Function Calling traditionnel. On définit une fonction en Python ou TypeScript, on la décrit dans un schéma JSON que l’on transmet au modèle, et l’application se charge de l’exécuter quand le modèle le demande.
Le fonctionnement est direct, mais pose un problème de taille à mesure que l’application grandit. Si je construis un outil de recherche pour Google Drive destiné à un chatbot spécifique, je ne peux pas simplement le copier-coller dans un autre assistant ou un autre client sans devoir réécrire une bonne partie du code d’intégration. La connexion est figée, codée en dur d’un point à un autre.
L’alternative : le Model Context Protocol (MCP)
Créé par Anthropic, le protocole MCP fonctionne un peu comme un port USB universel pour l’intelligence artificielle. Au lieu de développer des intégrations sur mesure pour chaque application, j’écris un serveur MCP dédié à une source de données spécifique, comme une base de données locale, Slack ou GitHub.
Toute application compatible avec le protocole — que ce soit Claude Desktop, Cursor, Zed ou un framework d’agent personnalisé — devient un client MCP capable de se connecter instantanément à ce serveur et d’exploiter ses ressources.
Comparatif technique : Tools vs MCP
| Caractéristique | Tools (Function Calling) | Model Context Protocol (MCP) |
|---|---|---|
| Nature | Fonctionnalité d’API propre à un modèle spécifique. | Standard architectural open source. |
| Architecture | Point à point (Application → Outil). | Client-Serveur (Application → Client MCP → Serveur MCP). |
| Réutilisabilité | Faible. Nécessite une réécriture pour chaque nouvelle application. | Élevée. Prêt à l’emploi sur n’importe quelle application compatible. |
| Capacités | Exécution d’actions ou de fonctions spécifiques. | Gestion d’outils, de prompts et de contextes complexes. |
| Sécurité | Gérée intégralement par l’application principale. | Gérée par des serveurs isolés et configurables. |
Pourquoi choisir l’un plutôt que l’autre ?
Mon choix dépend toujours de la nature du projet et de mes contraintes de déploiement.
Quand je privilégie les Tools classiques :
- Je développe une application d’IA simple et autonome qui n’a besoin de réaliser qu’une ou deux tâches très spécifiques.
- Je n’ai pas besoin de partager ces capacités d’outils avec d’autres assistants ou frameworks d’IA.
- Mon infrastructure de déploiement est strictement sans serveur (comme AWS Lambda ou Cloudflare Workers) et ne supporte pas l’exécution de processus d’arrière-plan persistants requis par l’architecture MCP.
Quand je me tourne vers l’architecture MCP :
- Je veux coder une intégration une seule fois et pouvoir l’utiliser indifféremment sur plusieurs clients IA.
- Je dois connecter l’IA à des environnements de données d’entreprise complexes et sécurisés.
- Je souhaite exploiter un écosystème de connecteurs existants créés et maintenus par la communauté sans tout réécrire à la main.
Le cas d’usage des Agents : pourquoi MCP s’impose pour la scalabilité
Les agents autonomes ont besoin d’une grande liberté d’action, d’un accès constant au contexte et de multiples intégrations. C’est dans ce scénario que l’architecture client-serveur de MCP montre toute sa pertinence face aux limites traditionnelles des agents.
Une architecture découplée
Avec MCP, je peux concevoir la logique de décision de mon agent (le cerveau) de manière isolée. Si je dois mettre à jour, ajouter ou supprimer des sources de données externes ou des outils (les mains), je le fais au niveau de mes serveurs MCP, sans toucher au code principal de l’agent.
La gestion du contexte
Un agent ne se contente pas d’agir, il doit aussi s’informer. MCP permet d’organiser proprement la fenêtre de contexte de l’agent en structurant l’accès aux bases de connaissances d’entreprise et aux fichiers locaux.
Un écosystème prêt à l’emploi
Au lieu de passer des jours à coder des wrappers d’API pour me connecter à Slack, GitHub ou Postgres, je peux connecter mon agent directement à des serveurs MCP existants.
Une sécurité renforcée par isolation
Laisser un agent exécuter des boucles d’actions de manière autonome comporte des risques (notamment en cas d’hallucination). Les serveurs MCP tournant dans des processus isolés, je peux restreindre leurs chemins d’accès aux fichiers locaux ou limiter finement leurs droits sans compromettre l’environnement d’exécution de l’application principale.
Schéma architectural d’un agent basé sur MCP
[ Logique de l'agent ] <-- (Le cerveau : gère la mémoire, la planification et la boucle)
|
[ SDK Client MCP ] <-- (Intégré à l'application pour dialoguer avec les serveurs)
|
========================= Couche de Protocole Standard =========================
|
[ Serveurs MCP ] <-- (Processus isolés : Base de données, Recherche Web, Fichiers)Pourquoi utiliser MCP plutôt que des tools classiques ?
La raison se résume en un mot : la scalabilité.
- Pas de verrouillage technologique (Vendor Lock-In) : Si j’écris un outil de base de données pour un agent avec LangChain sous forme de Tool classique, je dois réécrire le code d’intégration si je passe à CrewAI ou si je veux utiliser Cursor. Avec MCP, le même serveur de base de données fonctionne instantanément avec toutes ces plateformes.
- Allègement du package applicatif : Dans une application classique, chaque outil apporte ses dépendances et ses SDKs, ce qui peut alourdir l’application et provoquer des conflits de versions. Avec MCP, ces dépendances complexes vivent de manière isolée à l’intérieur de leurs serveurs respectifs.
- Partage natif des ressources et des prompts : Le protocole MCP gère trois notions clés : les Tools (les actions à exécuter), les Resources (les données en lecture seule comme des schémas de bases de données ou des fichiers de logs) et les Prompts (les modèles d’instructions stockés côté serveur qui guident le comportement du modèle). Le function calling classique ne gère que les outils.
Pourquoi utiliser des tools plutôt que MCP ?
L’approche MCP n’est pas toujours nécessaire et peut complexifier inutilement certains projets.
- Une complexité d’infrastructure réduite : Mettre en œuvre MCP exige de gérer une architecture client-serveur, des couches de transport persistantes (comme Stdio ou SSE) et le cycle de vie des connexions. Avec les Tools, il suffit de définir une fonction dans son code et de passer son schéma JSON directement lors de l’appel d’API de l’LLM.
- Pas de latence liée au réseau ou à l’IPC : L’utilisation d’un outil MCP implique une sérialisation des données à travers le protocole pour atteindre le serveur, puis une désérialisation au retour. Les Tools natifs s’exécutent directement dans le processus de l’application principale, ce qui est plus rapide.
- Intégration directe avec l’état de l’application : Un Tool classique a un accès immédiat aux variables en mémoire, à l’état de la session utilisateur et aux connexions de base de données de l’application. Pour obtenir le même résultat avec MCP, il faut sérialiser et transférer explicitement ces données à travers le protocole.
Peut-on utiliser les deux simultanément ?
C’est tout à fait possible, et c’est même l’architecture que je privilégie pour les systèmes d’agents complexes en production. Cette approche permet de séparer proprement les rôles.
La règle d’or consiste à attribuer les actions internes de l’application aux Tools natifs, et de déléguer l’accès au contexte externe et aux outils tiers au protocole MCP.
- Tools natifs (Actions internes) : Idéal pour modifier l’interface utilisateur de l’application, enregistrer l’activité de l’utilisateur ou la facturation en base de données, et pour toutes les tâches exigeant une exécution sous la milliseconde.
- Serveurs MCP (Actions et contextes externes) : Idéal pour récupérer des données sur GitHub, Slack ou Jira, faire tourner des scripts locaux dans des bacs à sable (sandboxes), ou utiliser des outils communautaires de navigation web.
Le fonctionnement concret de l’architecture hybride
L’application agit comme un routeur central. Au moment de préparer l’appel vers l’API du modèle, elle fusionne les deux sources de fonctions en une liste unique de schémas JSON :
[ Logique centrale de l'application ]
|
+-------------------+-------------------+
| |
[ Récupération des Tools natifs ] [ Connexion au Client MCP ]
- modifier_ui() - serveur_mcp_github
- facturer_client() - serveur_mcp_postgres
| |
+-------------------+-------------------+
|
v
[ Liste d'outils fusionnée ]
|
(Envoyée au LLM)Si le modèle choisit de déclencher modifier_ui, l’application exécute la fonction localement et immédiatement. S’il décide d’appeler une action liée à GitHub, l’application transmet la requête au client MCP, qui la relaie au serveur isolé pour exécution. C’est un compromis qui permet de garder le contrôle et la rapidité sur le code local tout en profitant de l’extensibilité de l’écosystème MCP.