error: unrecognized tool schema. Ce message, retourné par un second fournisseur de modèle alors que le premier acceptait le même appel sans broncher, résume à lui seul ce que le function calling n’a jamais résolu : chaque fournisseur décrivait ses outils à sa manière, avec ses propres conventions de nommage et de structure JSON.
Le function calling a rendu possible quelque chose d’essentiel : un modèle de langage peut décider, seul, qu’une tâche nécessite d’appeler une fonction précise plutôt que de répondre par du texte libre. Mais cette capacité, apparue chez les grands fournisseurs à partir de 2023, restait enfermée dans le format propriétaire de chacun. Le Model Context Protocol, normalisé à partir de novembre 2024, s’attaque à un problème différent : l’interopérabilité entre ces fournisseurs.
Ce que le function calling a réellement apporté
Avant le function calling, un développeur devait analyser le texte libre renvoyé par un modèle pour en extraire une intention d’action — une approche fragile, où une reformulation du modèle suffisait à casser le code d’extraction. Le function calling a inversé la logique : on décrit à l’avance les fonctions disponibles, avec leurs paramètres attendus, et le modèle renvoie directement un objet structuré indiquant quelle fonction appeler et avec quels arguments.
Sur un projet WordPress, cela s’est traduit par des définitions d’outils passées à chaque appel, où l’on décrit par exemple une fonction publier_article avec ses paramètres titre et categorie. Le modèle renvoie un appel structuré, et le code PHP se contente d’exécuter la fonction correspondante après validation.
Le problème que le function calling laissait entier
Chaque fournisseur exigeait sa propre structure de description d’outil : un nom de champ différent pour les paramètres, une convention distincte pour les types, une façon différente de signaler une erreur de validation. Un agent conçu pour fonctionner avec plusieurs modèles devait donc maintenir un adaptateur par fournisseur, avec le risque qu’une évolution de format côté fournisseur casse silencieusement l’intégration.
- Trois formats de description d’outil à maintenir en parallèle sur un projet multi-fournisseurs
- Aucune façon standard de découvrir dynamiquement les outils disponibles côté serveur
- Chaque changement de fournisseur imposait une réécriture des définitions de fonctions
- Aucun mécanisme commun d’authentification entre un agent et un serveur d’outils
Ce que le Model Context Protocol normalise
Le Model Context Protocol, publié par Anthropic en novembre 2024, ne remplace pas le function calling : il standardise la manière dont un serveur expose ses outils à un client, indépendamment du modèle utilisé derrière ce client. Un serveur MCP décrit ses outils une seule fois, dans un format commun, et n’importe quel client compatible peut les découvrir et les appeler.
{
"name": "publier_article",
"description": "Publie un article WordPress avec titre et categorie",
"inputSchema": {
"type": "object",
"properties": {
"titre": { "type": "string" },
"categorie": { "type": "string" }
},
"required": ["titre", "categorie"]
}
}Cette description ressemble à celle d’un outil de function calling classique, mais elle est portée par un protocole de communication standardisé plutôt que par une convention propre à un fournisseur. Un agent peut ainsi se connecter à plusieurs serveurs MCP différents sans réécrire d’adaptateur pour chacun.
Deux ans d’écart, pas un remplacement
Le function calling reste le mécanisme par lequel un modèle décide d’appeler une fonction ; le Model Context Protocol organise la façon dont cette fonction est décrite, découverte et exposée par un serveur. Les deux coexistent : un modèle utilise toujours sa capacité de function calling pour choisir un outil MCP parmi ceux qu’un serveur lui propose.
Sur nos projets, le passage à MCP n’a rien changé à la logique de décision du modèle : ce qui a changé, c’est le nombre de lignes d’adaptateur que nous n’avons plus besoin de maintenir.
Ce que cet écart de deux ans nous apprend
Un mécanisme de base — ici, la capacité d’appeler une fonction — précède presque toujours le protocole qui le standardise entre plusieurs acteurs. Attendre la normalisation avant d’expérimenter aurait retardé de deux ans des projets qui fonctionnaient déjà correctement avec le function calling seul.
En résumé
Le function calling a résolu la décision d’appeler une fonction ; le Model Context Protocol a résolu l’interopérabilité entre fournisseurs pour décrire et découvrir ces fonctions. Comprendre cette distinction évite de confondre les deux couches lors de la conception d’un agent multi-fournisseurs.
