Une question revient systématiquement dans les projets qui ont déjà une intégration IA fonctionnelle depuis un moment : « notre système de function calling marche très bien, pourquoi migrer vers MCP ? ». La question est légitime, et la réponse n’est ni « il faut absolument migrer » ni « MCP ne change rien ». Elle se trouve entre les deux, et dépend surtout de ce que votre intégration doit faire évoluer dans les mois qui viennent.
Cet article ne traite pas le function calling en tant que tel, déjà couvert en détail ailleurs sur ce blog : il se concentre sur ce que MCP ajoute par-dessus, concrètement, pour un développeur qui a déjà une intégration LLM en production.
Ce que le function calling faisait déjà bien
Depuis l’arrivée du function calling côté API des grands fournisseurs, une intégration WordPress classique déclarait ses fonctions disponibles directement dans l’appel au modèle : un tableau de définitions avec nom, description et schéma de paramètres, envoyé à chaque requête. Le modèle décidait quelle fonction appeler, votre code PHP l’exécutait, et le résultat repartait dans la conversation.
Ce mécanisme fonctionne très bien pour une intégration simple, propre à une seule application, où le même code définit à la fois les fonctions et l’appel au modèle.
Ce que MCP standardise en plus
MCP ne remplace pas le function calling : il l’encapsule dans un protocole client-serveur qui sépare la définition des outils de l’application qui les consomme. Trois différences concrètes :
- Découverte dynamique : un client MCP interroge le serveur pour obtenir la liste des outils disponibles au moment de la connexion, plutôt que de les coder en dur dans chaque application qui veut s’y connecter.
- Réutilisation entre agents : un même serveur MCP exposant du contenu WordPress peut être utilisé par plusieurs agents différents (un assistant de rédaction, un outil de veille, un assistant support) sans dupliquer le code d’accès aux données.
- Transport normalisé : la communication suit un format défini (JSON-RPC sur stdio ou sur HTTP), ce qui permet à un client générique de parler à n’importe quel serveur conforme, sans adaptation au cas par cas.
Ce que ça change concrètement dans le code
Une fonction PHP qui exécutait déjà la logique métier d’un appel de function calling n’a généralement pas besoin d’être réécrite. Ce qui change, c’est la couche qui l’expose : au lieu de l’injecter directement dans le tableau de définitions envoyé au modèle, on l’enregistre comme un outil du serveur MCP, avec son propre schéma déclaré une seule fois, consultable par n’importe quel client compatible.
| Aspect | Function calling seul | Avec MCP |
|---|---|---|
| Définition des outils | Dans le code de l’application appelante | Dans le serveur, découverte à la connexion |
| Réutilisation | Copier-coller entre projets | Un serveur, plusieurs clients |
| Transport | Propre à chaque fournisseur d’API | Normalisé (JSON-RPC) |
| Exécution réelle de la fonction | Identique | Identique |
Quand la migration se justifie
Trois signaux indiquent qu’une migration vaut le coût du changement : plusieurs applications internes ont besoin d’accéder aux mêmes fonctions WordPress, l’équipe veut permettre à des agents tiers (pas seulement les vôtres) de se connecter au site, ou la duplication du code d’accès entre projets devient elle-même une source de bugs. À l’inverse, une intégration simple, à usage unique, sans perspective d’ouverture à d’autres clients, n’a souvent aucun bénéfice concret à migrer dans l’immédiat.
Migrer pour suivre une tendance coûte du temps sans bénéfice mesurable. Migrer parce que trois projets internes réimplémentent la même fonction d’accès au contenu, c’est un vrai retour sur investissement.
Une migration progressive, pas un big bang
Dans les projets où nous avons fait ce choix, la fonction métier existante a été conservée telle quelle, et seule la couche d’exposition a été réécrite : la fonction PHP qui récupérait un article WordPress est restée identique, elle a simplement été enregistrée comme outil d’un serveur MCP plutôt qu’injectée directement dans le tableau d’outils envoyé au modèle.
En résumé
MCP n’invalide pas le function calling, il en normalise l’exposition et la découverte au niveau du transport et du client, sans changer la mécanique de décision du modèle ni la logique métier qui exécute réellement l’action. La question à se poser n’est pas « function calling ou MCP », mais « ai-je besoin que plusieurs clients accèdent aux mêmes outils sans duplication de code ». Si la réponse est oui, la migration progressive, fonction par fonction, reste largement praticable.
