MCP, Function Calling, Tool Use : le guide complet
Les grands modèles de langage (LLM) sont puissants, mais ils ont une limite fondamentale : ils ne peuvent que générer du texte. Pour qu'un agent IA puisse réellement agir — chercher sur le web, interroger une base de données, envoyer un email — il faut un mécanisme qui lui permette d'appeler des outils externes. C'est exactement ce que proposent MCP (Model Context Protocol), Function Calling (OpenAI) et Tool Use (Anthropic).
Dans ce guide, on décortique chaque approche, on compare leurs architectures, et on vous donne des exemples de code prêts à l'emploi pour intégrer des outils dans vos agents IA.
L'essentiel
- Function Calling (OpenAI) : mécanisme propriétaire intégré à l'API GPT, où vous déclarez des fonctions en JSON Schema et le modèle décide de les appeler. Simple et rapide à mettre en place.
- Tool Use (Anthropic) : approche similaire pour Claude, avec une gestion native des erreurs (
is_error) et la possibilité pour le modèle de "réfléchir" visiblement avant d'appeler un outil. - MCP (Model Context Protocol) : protocole ouvert lancé fin 2024 par Anthropic, qui standardise la connexion des LLM à des outils et données, à la manière de l'USB pour les périphériques.
- En 2025, la tendance est à l'interopérabilité : définir ses outils une fois et les rendre utilisables quel que soit le LLM.
🧠 Pourquoi les LLM ont besoin d'outils
Un LLM seul ne peut pas :
- Accéder à des données en temps réel (météo, cours de bourse, actualités)
- Effectuer des calculs précis (arithmétique complexe, conversions)
- Interagir avec des systèmes externes (API, bases de données, fichiers)
- Exécuter du code ou des commandes système
Sans mécanisme d'appel d'outils, un LLM est condamné à halluciner les réponses à ces questions. Les protocoles d'appel d'outils résolvent ce problème en permettant au modèle de déclarer qu'il souhaite utiliser un outil, puis de recevoir le résultat pour formuler sa réponse finale.
Le flux général est toujours le même :
- L'utilisateur pose une question
- Le modèle identifie qu'un outil est nécessaire
- Le modèle produit un appel structuré (nom de l'outil + paramètres)
- Le système hôte exécute l'outil
- Le résultat est renvoyé au modèle
- Le modèle formule sa réponse finale
Ce qui change entre les approches, c'est comment les étapes 3 à 5 sont implémentées.
🔧 Function Calling (OpenAI)
Principe
Function Calling est l'approche introduite par OpenAI en juin 2023. L'idée est simple : vous décrivez des fonctions disponibles dans votre prompt système sous forme de schémas JSON, et le modèle peut décider d'en appeler une au lieu de répondre directement.
Architecture
Le flux d'exécution suit une logique en cascade : la requête utilisateur est envoyée à l'API OpenAI accompagnée de la définition des fonctions. Le modèle analyse la requête, choisit d'appeler une fonction et retourne un appel structuré en JSON. C'est ensuite votre code qui intercepte ce JSON, exécute la fonction locale correspondante, puis renvoie le résultat au modèle pour qu'il formule sa réponse finale.
Définition des fonctions
Chaque fonction est décrite via un schéma JSON Schema comprenant un nom, une description textuelle détaillée, et un objet parameters définissant les propriétés attendues (type, énumérations, champs obligatoires). L'outil décrit ici prend une ville et une unité de température, puis retourne les conditions météo.
Exemple complet en Python
L'implémentation en Python passe par le SDK OpenAI : on déclare les outils disponibles, on envoie la conversation au modèle avec tool_choice="auto", puis on intercepte les tool_calls dans la réponse. Pour chaque appel, on exécute la fonction locale, on renvoie le résultat via un message de rôle tool avec le tool_call_id, et on relance un appel pour obtenir la réponse finale formatée.
Modes d'appel
OpenAI propose trois modes via le paramètre tool_choice :
| Mode | Comportement |
|---|---|
"auto" |
Le modèle décide seul s'il doit appeler une fonction |
"none" |
Le modèle ne peut pas appeler de fonction |
"required" |
Le modèle doit appeler au moins une fonction |
{"type": "function", "function": {"name": "X"}} |
Force l'appel d'une fonction spécifique |
Appels parallèles
Depuis fin 2023, GPT-4 et GPT-3.5-turbo peuvent déclencher plusieurs appels de fonctions en parallèle dans une seule réponse. Par exemple, si l'utilisateur demande "la météo à Paris et à Lyon", le modèle produira deux tool_calls simultanés que votre code pourra traiter indépendamment dans une boucle. Vous pouvez désactiver ce comportement avec parallel_tool_calls: false.
Forces et limites
Avantages :
- Syntaxe simple et bien documentée
- Support natif des appels parallèles
- Large écosystème d'exemples
- Compatible avec tous les modèles GPT récents
Limites :
- Propriétaire à OpenAI (bien que le format soit repris par d'autres)
- Les définitions de fonctions consomment des tokens
- Pas de standard ouvert officiel
🛠️ Tool Use (Anthropic)
Principe
Anthropic a introduit Tool Use pour Claude en avril 2024. Le concept est similaire au Function Calling d'OpenAI, mais avec quelques différences architecturales notables, notamment le format des messages et la gestion des résultats.
Architecture
Le flux d'Anthropic est proche de celui d'OpenAI, mais le format des messages diffère : la requête utilisateur est envoyée à l'API Anthropic avec les définitions d'outils. Claude choisit un outil et retourne un bloc tool_use intégré dans son contenu. Votre code exécute l'outil, puis renvoie le résultat via un message de type tool_result. Le modèle reçoit ce résultat et produit la réponse finale.
Définition des outils
Anthropic utilise aussi JSON Schema mais avec une structure légèrement différente : la clé input_schema remplace parameters. L'outil prend les mêmes paramètres (ville et unité), avec des descriptions détaillées pour guider le modèle dans son choix.
Exemple complet en Python
L'implémentation avec le SDK Anthropic suit le même schéma : déclaration des outils, appel initial, puis détection du stop_reason == "tool_use". On extrait ensuite le bloc tool_use depuis response.content, on exécute la fonction, et on renvoie le résultat dans un message utilisateur contenant un bloc de type tool_result avec le tool_use_id correspondant. Un second appel au modèle produit la réponse finale.
Contrôle de l'utilisation des outils
Anthropic propose un paramètre tool_choice similaire :
| Mode | Comportement |
|---|---|
{"type": "auto"} |
Claude décide seul |
{"type": "any"} |
Claude doit utiliser un outil (n'importe lequel) |
{"type": "tool", "name": "X"} |
Force l'utilisation d'un outil spécifique |
Particularités d'Anthropic
Le "thinking" avant l'outil : Claude peut inclure du texte (réflexion) avant l'appel d'outil dans le même message. Cela donne de la transparence sur son raisonnement.
Résultats d'erreur : Vous pouvez signaler qu'un outil a échoué en utilisant le champ is_error à true dans le bloc tool_result, accompagné d'un message décrivant l'erreur. Claude adaptera sa réponse en conséquence, potentiellement en reformulant sa requête ou en informant l'utilisateur.
Forces et limites
Avantages :
- Réflexion visible avant l'appel d'outil
- Gestion native des erreurs avec is_error
- Descriptions d'outils très détaillées pour un meilleur choix
- Support du streaming avec les blocs tool_use
Limites :
- Format légèrement plus verbeux
- Écosystème d'exemples moins fourni (mais en croissance rapide)
- Le résultat de l'outil doit être dans un message user (architecture particulière)
🌐 MCP (Model Context Protocol)
Principe
MCP est un protocole ouvert créé par Anthropic et publié fin 2024. Contrairement au Function Calling et au Tool Use qui sont des mécanismes d'API propres à chaque fournisseur, MCP vise à être un standard universel pour connecter les LLM à des sources de données et des outils.
L'analogie souvent utilisée : MCP est au LLM ce que USB est aux périphériques. Un protocole unique pour tout connecter.
Architecture
MCP introduit une architecture client-serveur structurée autour de trois composants. L'application hôte (Claude Desktop, un IDE, ou votre agent) encapsule un ou plusieurs clients MCP. Chaque client maintient une connexion 1:1 avec un serveur MCP distinct — par exemple, un serveur pour l'accès aux fichiers locaux, un autre pour l'API GitHub. Les serveurs exposent outils, ressources et prompts de manière standardisée, permettant à l'hôte de les consommer sans se soucier de leur implémentation interne.
Les trois primitives MCP
MCP ne se limite pas aux outils. Il expose trois types de capacités :
| Primitive | Description | Exemple |
|---|---|---|
| Tools | Fonctions appelables par le LLM | Chercher sur le web, exécuter du SQL |
| Resources | Données consultables (lecture seule) | Contenu d'un fichier, résultat d'une requête |
| Prompts | Templates de prompts réutilisables | Template de résumé, template d'analyse |
Exemple de serveur MCP en Python
Avec le SDK officiel Python, on crée un serveur via FastMCP("weather-server"). L'outil get_weather est déclaré avec le décorateur @mcp.tool(), une ressource en lecture seule via @mcp.resource() avec un URI de type weather://current/{city}, et un prompt réutilisable via @mcp.prompt(). Le serveur se lance ensuite avec mcp.run() sur le transport stdio.
Exemple de serveur MCP en TypeScript
En TypeScript, le SDK fournit la classe McpServer à laquelle on attache des outils via server.tool(). Chaque outil reçoit un nom, une description et un schéma Zod pour la validation des paramètres. Le résultat est renvoyé sous forme de contenu textuel JSON. Le serveur écoute ensuite sur le transport StdioServerTransport.
Transports
MCP supporte deux modes de transport :
| Transport | Usage | Communication |
|---|---|---|
| stdio | Serveurs locaux | Le client lance le serveur comme un processus enfant |
| SSE (Server-Sent Events) | Serveurs distants | Communication HTTP, idéal pour les services cloud |
Configuration dans Claude Desktop
La configuration se fait dans le fichier JSON de Claude Desktop, sous la clé mcpServers. Chaque serveur est défini par une commande (python, npx, etc.), des arguments, et éventuellement des variables d'environnement comme les tokens d'API. Par exemple, on peut lancer un serveur météo en Python et le serveur GitHub via npx avec un GITHUB_TOKEN.
Écosystème de serveurs MCP
L'un des grands avantages de MCP est son écosystème croissant de serveurs prêts à l'emploi :
- Fichiers : Lecture/écriture de fichiers locaux
- GitHub : Repos, issues, pull requests
- Bases de données : PostgreSQL, SQLite, MongoDB
- Web : Brave Search, Fetch
- Productivité : Google Drive, Slack, Notion
- Développement : Docker, Kubernetes
Forces et limites
Avantages :
- Standard ouvert et interopérable
- Trois primitives (tools, resources, prompts)
- Écosystème de serveurs réutilisables
- Séparation claire client/serveur
- Fonctionne avec n'importe quel LLM (pas lié à un fournisseur)
Limites :
- Plus complexe à mettre en place qu'un simple function calling
- Encore jeune (spec en évolution)
- Nécessite un runtime pour les serveurs
- Overhead pour des cas d'usage simples
📊 Tableau comparatif complet
| Critère | Function Calling (OpenAI) | Tool Use (Anthropic) | MCP |
|---|---|---|---|
| Type | API propriétaire | API propriétaire | Protocole ouvert |
| Créateur | OpenAI | Anthropic | Anthropic (open source) |
| Format de définition | JSON Schema (parameters) |
JSON Schema (input_schema) |
Décorateurs / SDK |
| Appels parallèles | ✅ Natif | ✅ Possible | ✅ Via le client |
| Gestion d'erreurs | Via le contenu du message | is_error natif |
Via le protocole |
| Streaming | ✅ | ✅ | ✅ |
| Multi-fournisseur | ❌ (format repris par d'autres) | ❌ | ✅ |
| Ressources (données) | ❌ | ❌ | ✅ |
| Prompts réutilisables | ❌ | ❌ | ✅ |
| Complexité setup | ⭐ Faible | ⭐ Faible | ⭐⭐⭐ Moyenne |
| Maturité | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| Documentation | Excellente | Très bonne | Bonne (en croissance) |
🔀 Quand utiliser quoi ?
Utilisez Function Calling (OpenAI) si :
- Vous utilisez déjà les modèles GPT
- Votre cas d'usage est simple (quelques fonctions)
- Vous voulez le setup le plus rapide possible
- Vous n'avez pas besoin de partager vos outils entre projets
Utilisez Tool Use (Anthropic) si :
- Vous utilisez Claude comme modèle principal
- Vous avez besoin de la réflexion visible du modèle
- La gestion fine des erreurs est importante
- Vous voulez un modèle qui excelle dans le choix d'outils complexes
Utilisez MCP si :
- Vous construisez un agent qui doit fonctionner avec plusieurs LLM
- Vous voulez un écosystème d'outils réutilisables entre projets
- Vous avez besoin de plus que des outils (ressources, prompts)
- Vous construisez une plateforme ou un framework d'agents
- La standardisation et l'interopérabilité sont prioritaires
Combiner les approches
En pratique, beaucoup de développeurs combinent ces approches. Par exemple :
- Utiliser MCP pour définir et partager les outils
- Traduire les outils MCP en Function Calling ou Tool Use selon le LLM utilisé
- Des frameworks comme LangChain et OpenClaw font cette traduction automatiquement
Un agent universel typique instancie un client MCP connecté aux serveurs d'outils, puis convertit dynamiquement la liste des outils MCP au format Function Calling ou Tool Use selon le fournisseur LLM sélectionné. Lorsqu'un appel d'outil est détecté dans la réponse du LLM, l'agent l'exécute via le client MCP et renvoie le résultat au modèle.
🚀 Bonnes pratiques communes
Quelle que soit l'approche choisie, certaines bonnes pratiques s'appliquent toujours :
1. Des descriptions claires et précises
Le modèle choisit ses outils en se basant sur les descriptions. Soyez explicite : une description vague comme "Cherche des trucs" donnera de mauvais résultats. Privilégiez une description détaillée qui précise la source, le format de retour et les limites, par exemple "Recherche des articles dans la base de données par mot-clé. Retourne les 10 résultats les plus récents avec titre, date et résumé."
2. Validez les paramètres
Ne faites jamais confiance aux paramètres générés par le modèle sans validation. Pour chaque outil, vérifiez systématiquement les types, les plages de valeurs, et la sécurité des chemins (par exemple, bloquer les chemins contenant .. ou commençant par / pour les opérations sur les fichiers).
3. Gérez les erreurs gracieusement
Renvoyez des messages d'erreur clairs pour que le modèle puisse s'adapter : structurez vos retours d'erreur avec un indicateur success, le message d'erreur, et idéalement une suggestion de correction. Cela permet au LLM de reformuler sa requête ou d'informer l'utilisateur utilement.
4. Limitez le nombre d'outils
Plus vous exposez d'outils, plus le modèle risque de se tromper. Gardez un set focalisé et pertinent pour la tâche.
| Nombre d'outils | Recommandation |
|---|---|
| 1-5 | ✅ Idéal |
| 6-15 | ⚠️ Acceptable avec de bonnes descriptions |
| 15-30 | ⚠️ Regroupez en catégories |
| 30+ | ❌ Trop — utilisez un routeur ou un sélecteur d'outils |
5. Testez avec des cas limites
Les modèles peuvent halluciner des paramètres ou appeler le mauvais outil. Testez systématiquement :
- Requêtes ambiguës ("cherche ça" → quel outil ?)
- Paramètres manquants
- Résultats vides ou erreurs
- Chaînes d'appels (outil A → outil B)
🔮 L'avenir des interactions LLM-outils
L'écosystème évolue rapidement :
- MCP gagne en adoption et pourrait devenir le standard de facto
- OpenAI et Google travaillent sur leurs propres protocoles d'outils
- Les frameworks (LangChain, CrewAI, OpenClaw) abstraient ces différences
- La tendance est à l'interopérabilité : un outil défini une fois, utilisable partout
L'important n'est pas de choisir "le meilleur" protocole, mais de comprendre les principes sous-jacents. Le mécanisme fondamental — le modèle déclare vouloir utiliser un outil, votre code l'exécute, le résultat revient au modèle — reste le même partout.
Maîtrisez ce pattern, et vous pourrez construire des agents IA capables d'interagir avec n'importe quel système.
Erreurs courantes
- Descriptions trop vagues : le modèle ne sait pas quand utiliser l'outil et finit par halluciner ou ignorer l'outil. Toujours préciser le contexte d'usage, les paramètres attendus et le format de retour.
- Oublier la validation des paramètres : un LLM peut générer des valeurs inattendues (chemin de fichier avec
../, entier négatif pour un ID, etc.). Validez systématiquement côté serveur avant l'exécution. - Ne pas gérer les erreurs : si un outil échoue silencieusement ou renvoie une erreur brute, le modèle ne peut pas s'adapter. Utilisez
is_errorchez Anthropic ou un format structuré chez OpenAI. - Trop d'outils disponibles : au-delà d'une quinzaine d'outils, les performances de sélection chutent. Ajoutez un routeur ou un sélecteur d'outils en amont.
- Confondre MCP et Function Calling : MCP est un protocole de transport et de définition, pas un mécanisme d'appel direct par le LLM. Il faut un adaptateur entre les deux.
Outils recommandés
- ruflo : la plateforme d'orchestration multi-agent qui explose sur GitHub : pour orchestrer plusieurs agents utilisant différents protocoles d'outils.
- RAG pour les nuls : donner de la mémoire à son IA : pour combiner appel d'outils et récupération de contexte dans vos agents.
- Automatiser un pipeline complet avec un agent : pour mettre en pratique l'appel d'outils dans un workflow agent autonome.
- DeerFlow de ByteDance : l'agent open-source qui recherche, code et cree sur le long terme : exemple concret d'agent open-source combinant outils de recherche et de code.
- Dexter : un agent IA autonome qui fait de la recherche financière profonde : exemple concret d'agent utilisant des outils complexes en production.
FAQ
MCP remplace-t-il le Function Calling d'OpenAI ?
Non, MCP est un protocole de définition et de transport. Vous pouvez utiliser MCP pour définir vos outils, puis les traduire en Function Calling pour l'API OpenAI. Les deux sont complémentaires.
Peut-on utiliser plusieurs outils en même temps avec Anthropic ?
Oui, Claude peut appeler plusieurs outils dans une seule réponse, mais ce n'est pas le comportement par défaut contrairement à OpenAI. Il faut le gérer dans votre logique d'orchestration.
Combien d'outils peut-on déclarer au maximum ?
Il n'y a pas de limite stricte côté API, mais les performances de sélection dégradent au-delà de 15-20 outils. Privilégiez un routeur ou un sélecteur pour les cas complexes.
MCP fonctionne-t-il avec des LLM autres que Claude ?
Oui, c'est tout l'intérêt du protocole. Des serveurs MCP peuvent être consommés par n'importe quel client, y compris avec GPT, Gemini ou des modèles open source via des adaptateurs.
Quelle est la différence entre une ressource et un outil en MCP ?
Un outil est une fonction exécutable (avec effets de bord possibles), tandis qu'une ressource est une donnée consultable en lecture seule, comme le contenu d'un fichier ou le résultat d'une requête.
Conclusion
MCP, Function Calling et Tool Use partagent un même principe fondamental : permettre à un LLM de dépasser le texte pour interagir avec le monde réel. Le Function Calling d'OpenAI reste le plus simple pour démarrer avec GPT. Le Tool Use d'Anthropic apporte une réflexion visible et une gestion d'erreurs plus fine. MCP, lui, trace la voie de l'interopérabilité — un outil défini une fois, utilisable partout. En 2025, la bonne stratégie est souvent de combiner ces approches : MCP pour la définition et le partage, Function Calling ou Tool Use pour l'exécution selon le modèle choisi. Maîtrisez ce pattern, et vous construirez des agents IA qui ne se contentent pas de parler, mais qui agissent.