MCP vs Function Calling : quelles différences pour l'appel d'outils des AI Agent ? JSON Schema, API et Tool Calling comparés

La spécification MCP distingue trois primitives — prompts, ressources et outils — et définit deux transports standards, stdio et Streamable HTTP, selon sa spécification officielle du serveur MCP et sa documentation officielle des transports.

Conclusion opérationnelle : MCP vs Function Calling ne constitue généralement pas un choix exclusif. Function Calling permet au modèle d’exprimer « quel outil appeler et avec quels paramètres » ; MCP permet à une application de découvrir et de connecter des outils selon un protocole standardisé. Pour une seule application avec peu d’outils, restez sur Function Calling. Ajoutez une couche d’adaptation interne si plusieurs modèles doivent partager le même catalogue, puis introduisez MCP lorsque plusieurs agents, IDE ou clients doivent découvrir et réutiliser les mêmes outils.

Cette analyse s’adresse à trois profils précis :

• aux développeurs d’une application unique qui veulent éviter une couche MCP prématurée ;
• aux équipes qui construisent une plateforme multi-modèles et doivent unifier les événements d’appel et les schémas ;
• aux responsables d’une migration vers MCP qui doivent définir ce qui reste dans l’application, ce qui passe par le serveur et ce qui demeure sous le contrôle de l’API métier.

Le vrai point de séparation entre MCP et Function Calling

La confusion vient du fait que les deux mécanismes manipulent des outils et des données structurées. Pourtant, ils ne répondent pas à la même question.

Function Calling intervient principalement dans la boucle modèle-application :

• l’application décrit les fonctions disponibles au modèle ;
• le modèle sélectionne éventuellement une fonction ;
• il renvoie un nom d’outil et des arguments conformes à un schéma ;
• l’application valide ces arguments et exécute le code ;
• le résultat est renvoyé au modèle pour poursuivre la réponse.

La documentation officielle d’OpenAI présente Function Calling comme un moyen de connecter un modèle à des outils et systèmes externes, tandis que la fonction est exécutée par l’application et non directement par le modèle. Cette distinction est détaillée dans la documentation OpenAI sur Function Calling et dans l’article officiel consacré aux appels de fonction et aux mises à jour de l’API.

La documentation de Google décrit une boucle comparable : l’application transmet les déclarations de fonction, le modèle renvoie un appel structuré, l’application exécute la fonction, puis renvoie le résultat au modèle. La documentation officielle de Google sur Function Calling précise notamment que l’exécution de la fonction relève de la responsabilité de l’application.

MCP se situe davantage entre le client hôte et le fournisseur d’outils. Son architecture distingue un host, des clients MCP et des serveurs MCP. Le host gère les connexions et les autorisations ; chaque client maintient une connexion vers un serveur ; le serveur expose des outils, des ressources ou des prompts. Cette séparation permet à plusieurs applications de réutiliser une même intégration sans recopier toute la logique de connexion.

MCP et Tool Calling se trouvent-ils au même niveau ? Non. Tool Calling décrit le message ou l’intention par lequel le modèle demande une opération. MCP décrit un protocole de connexion et de découverte entre un client et un serveur d’outils. Un client MCP peut alimenter le catalogue transmis au modèle, mais MCP ne remplace pas la décision du modèle et ne devient pas, par lui-même, une capacité de raisonnement.

Le JSON Schema fait le lien entre les deux mondes, sans les confondre. Il documente les paramètres attendus, les types, les propriétés obligatoires et parfois les valeurs autorisées. Il ne décide ni de l’identité de l’utilisateur, ni de son droit à effectuer l’opération, ni de la façon dont l’API doit gérer une erreur métier.

Rappel d’architecture : un schéma valide décrit la forme d’une requête ; il ne prouve jamais que cette requête est légitime.

Dans l’écosystème Claude, la documentation officielle d’Anthropic sur l’utilisation des outils suit la même séparation générale : le modèle produit un bloc d’appel d’outil, puis le programme client exécute l’opération et retourne un résultat. Les noms de champs et les formats ne sont cependant pas identiques d’un fournisseur à l’autre, ce qui justifie une normalisation interne lorsque plusieurs modèles sont utilisés.

Trois architectures qui répondent à trois situations

Le choix devient plus clair lorsqu’il est formulé à partir du déploiement prévu, plutôt qu’à partir d’un classement abstrait des fonctionnalités.

Les scores sont des critères éditoriaux de décision, pas des mesures de performance. Ils évaluent la pertinence de chaque route dans le scénario indiqué.

Une seule application et peu d’outils : ne rajoutez pas MCP par principe

Pour un agent de montage vidéo qui appelle une API de transcodage, un assistant de design qui récupère des fichiers ou un outil de génération audio qui déclenche un rendu, Function Calling suffit souvent. L’application possède déjà le contexte de l’utilisateur, la liste des fonctions et le code d’exécution. Ajouter un serveur MCP créerait une frontière supplémentaire à maintenir sans résoudre un problème présent.

Cette route réduit plusieurs coûts cachés :

• une connexion supplémentaire à initialiser et surveiller ;
• une couche de journaux et de diagnostic entre l’agent et l’API ;
• une gestion de versions du serveur et du client ;
• une surface d’authentification qui n’apporte rien si tout reste dans le même processus ;
• des erreurs plus difficiles à attribuer, car l’équipe doit distinguer l’échec du modèle, du client MCP et de l’API.

Un seul AI Agent a-t-il besoin de MCP ? Pas nécessairement. Si un agent unique utilise des outils internes, la priorité est de stabiliser le contrat d’appel : nom de fonction, JSON Schema versionné, validation côté serveur, identifiant de requête, délai maximal et stratégie de reprise. Même sans MCP, il faut éviter de coder les fonctions directement dans les prompts ou dans des branches spécifiques à un fournisseur.

Le minimum recommandé consiste à conserver une interface interne indépendante du format reçu du modèle :

{
  "event": "tool.requested",
  "tool": "render_video",
  "schema_version": "1",
  "arguments": {
    "project_id": "p_123",
    "preset": "social_vertical"
  },
  "request_id": "req_456"
}

Ce format n’est pas un message MCP. C’est un événement de domaine qui permet de modifier le fournisseur de modèle sans réécrire la logique d’autorisation et d’exécution.

Plusieurs modèles : l’adaptateur interne devient prioritaire

Les fournisseurs ne présentent pas tous les appels de la même manière. Les noms de champs, les identifiants d’appel, le traitement des appels parallèles, les modes de sélection d’outils et les limitations de schéma peuvent varier. La documentation de Gemini signale par exemple que l’application doit conserver l’identifiant exact d’un appel lorsqu’elle renvoie le résultat correspondant dans le tour suivant.

L’erreur classique consiste à faire remonter directement dans le cœur métier le format natif d’un fournisseur. Le code finit alors par mélanger :

• la réponse du modèle ;
• la traduction vers une fonction locale ;
• la vérification des droits ;
• l’appel HTTP ou local ;
• la conversion de l’erreur ;
• le résultat destiné au tour suivant.

L’adaptateur interne doit donc normaliser au moins cinq éléments :

• tool_name, le nom canonique de l’outil ;
• arguments, toujours convertis en objet validé ;
• call_id, conservé pour rattacher le résultat au bon tour ;
• status, avec des états distincts pour refus, erreur de validation, délai dépassé et échec métier ;
• result, séparé des messages affichés à l’utilisateur.

Cette couche n’est pas un doublon inutile de MCP. Elle répond à une autre contrainte : rendre interchangeables les modèles et leurs API. MCP peut ensuite devenir la source de découverte des outils, mais il ne supprimera pas les différences entre les interfaces de génération ou de Tool Calling des modèles.

Le rôle du JSON Schema doit aussi être limité avec précision. OpenAI indique que Structured Outputs peut contraindre les arguments d’un appel de fonction lorsqu’un mode strict est activé, mais rappelle que les schémas pris en charge correspondent à un sous-ensemble de JSON Schema et que les refus ou interruptions prématurées restent des cas à traiter. La présentation officielle d’OpenAI sur Structured Outputs constitue une référence utile pour cette limite.

Le partage entre plusieurs clients justifie réellement MCP

MCP prend une valeur nette lorsque le même outil doit être découvert depuis plusieurs environnements : agent conversationnel, IDE, application de bureau, flux d’automatisation ou interface interne. Sans protocole commun, chaque client doit intégrer l’authentification, la description des outils, les conversions de schéma, les délais et les chemins d’erreur.

Le serveur MCP peut exposer un outil de recherche de fichiers, un accès à un dépôt, un moteur de rendu audio ou une commande de génération vidéo. La spécification distingue aussi les outils des ressources et des prompts, ce qui permet de ne pas transformer chaque donnée contextuelle en fonction exécutable. Cette répartition est décrite dans l’aperçu officiel des primitives MCP.

La spécification MCP définit stdio et Streamable HTTP comme transports standards. Avec stdio, le client lance le serveur comme sous-processus ; avec HTTP, le serveur fonctionne comme un service indépendant pouvant accepter plusieurs connexions. Le transport ne détermine toutefois pas les permissions métier ni la sécurité complète de l’API.

MCP peut-il exécuter directement une API métier ? Un serveur MCP peut appeler une API métier derrière un outil, mais il ne doit pas être considéré comme l’autorité finale. Il reçoit une demande, vérifie le contexte et transmet éventuellement une opération ; l’API métier doit encore appliquer l’identité, la portée, l’état de la ressource, les limites et les règles de validation.

Pour une équipe qui construit des outils audio ou vidéo, cette séparation est importante. Un serveur peut exposer create_preview ou export_master, mais l’API doit encore vérifier que le projet appartient au bon compte, que le format est autorisé et que l’opération ne dépasse pas les ressources disponibles. Le serveur MCP facilite l’accès ; il ne remplace pas le contrôle métier.

Les outils distants déplacent le problème vers l’exploitation

Un MCP local peut être relativement simple à tester. Un MCP distant devient un service à exploiter. L’équipe doit alors traiter l’authentification, les secrets, la disponibilité, les délais, la journalisation, la rotation des versions et le filtrage réseau.

Pour HTTP, la spécification officielle d’autorisation MCP prévoit un cadre reposant sur des mécanismes OAuth et impose notamment la validation des jetons destinés au serveur concerné. Elle indique aussi qu’un serveur MCP ne doit pas accepter ou retransmettre aveuglément un jeton prévu pour une autre ressource.

Les limites les plus souvent sous-estimées sont les suivantes :

• Disponibilité : un agent peut perdre l’accès à plusieurs outils si le serveur distant ou le réseau tombe ;
• Latence : la découverte, l’authentification et l’appel ajoutent des étapes avant l’exécution de l’API ;
• Permissions : le serveur doit savoir quelle identité et quelle portée transmettre, sans réutiliser aveuglément un jeton reçu ;
• Observabilité : les traces doivent relier le prompt, l’appel du modèle, la requête MCP et l’opération métier ;
• Compatibilité : le client et le serveur doivent négocier une version et des capacités compatibles.

Une ressource dépendante de macOS — par exemple un logiciel de création, un environnement de compilation Apple ou un flux audio spécifique — peut être placée sur un Mac distant contrôlé. Cela relève du choix d’infrastructure, pas d’une exigence du protocole. L’équipe doit encore décider si elle veut un Mac permanent, une machine isolée par équipe ou un environnement temporaire. La location d’un Mac cloud devient pertinente lorsque le besoin porte sur un environnement macOS accessible à distance, sans transformer chaque poste local en serveur permanent.

Expérience de déploiement : avant de rendre un MCP distant accessible à plusieurs clients, il faut tester séparément l’expiration du jeton, l’arrêt du serveur, le refus de permission et la perte de connexion. Un agent qui fonctionne seulement sur le chemin nominal n’est pas encore prêt pour une équipe.

Les opérations sensibles nécessitent deux barrières et une autorité métier

Ni Function Calling ni MCP ne doit être traité comme un système complet d’autorisation.

Dans une opération à risque — suppression d’un fichier, publication d’une vidéo, envoi d’un message, remboursement ou modification d’un compte — trois niveaux sont nécessaires :

• Contrôle du modèle : limiter les outils proposés et rendre la description suffisamment précise pour réduire les appels incohérents ;
• Contrôle de l’exécution : vérifier l’identité, la portée, les paramètres, l’environnement et la nécessité d’une confirmation humaine ;
• Contrôle de l’API métier : appliquer la décision définitive, même si l’appel arrive sans passer par l’agent.

La spécification MCP rappelle que les utilisateurs doivent conserver le contrôle des données partagées et des opérations réalisées, tandis que les applications doivent construire des flux explicites de consentement et d’autorisation. Ces exigences sont exposées dans la section officielle MCP consacrée au consentement et à la sécurité.

La documentation d’OpenAI sur Function Calling distingue également la demande du modèle et l’exécution produite par l’application. Le modèle propose l’appel, mais le programme doit générer le résultat de l’outil et décider si l’opération est autorisée.

MCP remplacera-t-il Function Calling ? Il est peu probable qu’une telle substitution soit le bon modèle mental. MCP peut standardiser la connexion, les capacités exposées et la découverte d’outils, tandis que le modèle continue de produire une intention d’appel selon l’interface prise en charge par l’application. Dans une architecture robuste, MCP et Function Calling peuvent donc être superposés.

La confirmation utilisateur ne doit pas être remplacée par la conformité au JSON Schema. Un schéma peut imposer que amount soit un nombre et que currency soit une valeur autorisée ; il ne peut pas déterminer si l’utilisateur voulait réellement effectuer le paiement.

Une migration en cinq étapes évite de transformer MCP en refonte générale

Une équipe qui possède déjà du Function Calling peut introduire MCP progressivement.

Inventorier les outils réellement réutilisés

Classez les fonctions selon quatre critères : nombre de clients, fréquence d’évolution, sensibilité des données et dépendance à un environnement particulier. Une fonction appelée par une seule application n’est pas automatiquement candidate à MCP.

Stabiliser le contrat interne

Définissez un nom canonique, une version de schéma, des erreurs typées, un identifiant de corrélation et une politique de délai. Les paramètres doivent être validés avant l’appel réseau ou l’accès au système de fichiers.

Séparer l’adaptation du fournisseur

Chaque modèle doit être converti vers l’événement interne de l’équipe. Cette étape permet de changer de fournisseur sans modifier l’API métier, et de tester les différences de Tool Calling sur des cas contrôlés.

Exposer un premier serveur MCP à faible risque

Commencez par une ressource en lecture seule ou une opération réversible : recherche de fichiers, lecture d’un statut de rendu ou récupération de métadonnées. N’exposez pas immédiatement les opérations d’écriture, d’effacement ou de publication.

Tester les chemins d’erreur et les permissions

Le test minimal doit comparer une exécution directe et une exécution via MCP pour le même outil. Vérifiez les journaux, simulez un délai dépassé, un schéma invalide, un jeton expiré et un refus utilisateur. La procédure doit être rejouée après toute évolution du protocole ou de l’API du modèle.

Le support Mac de Zilmac peut s’inscrire dans cette phase lorsque le serveur dépend de logiciels macOS, de permissions locales ou d’un flux créatif qui ne se reproduit pas correctement dans un environnement générique.

La décision finale dépend du nombre de frontières à maintenir

La bonne question n’est pas « MCP est-il plus moderne que Function Calling ? ». Il faut compter les frontières d’intégration que l’équipe devra maintenir pendant la période de planification du projet :

• combien de modèles doivent appeler les mêmes outils ;
• combien de clients doivent les découvrir ;
• combien d’environnements doivent être isolés ;
• quelles opérations exigent une confirmation ;
• qui est responsable du serveur, de ses versions et de ses journaux ;
• quelle API reste l’autorité finale.

Pour un agent unique avec quelques fonctions, Function Calling seul conserve une chaîne courte et lisible. Pour une plateforme multi-modèles, Function Calling avec adaptateur interne réduit le couplage aux formats fournisseurs. Pour plusieurs clients partageant des outils, Function Calling avec MCP devient cohérent, à condition de traiter le serveur comme un composant de production et non comme un simple fichier de configuration.

Le schéma, la découverte et l’exécution doivent rester distincts. Le JSON Schema formalise les données ; Function Calling transporte l’intention du modèle ; MCP organise la connexion et la réutilisation ; l’API métier autorise réellement l’opération.

Si l’architecture actuelle repose sur des appels directs, elle conserve toutefois trois limites lorsqu’elle s’étend : chaque nouveau client doit recoder les connexions, les permissions restent dispersées et les outils dépendant de macOS sont difficiles à isoler proprement. Dans ce cas précis, louer un environnement Mac contrôlé chez Zilmac peut être plus souple qu’acheter une machine dédiée ou maintenir un poste toujours allumé, surtout pour tester un serveur MCP distant, un flux audio-vidéo ou une intégration nécessitant macOS pendant une période limitée. La présentation des environnements Mac disponibles permet ensuite de vérifier si ce mode d’exploitation correspond réellement au niveau de partage, d’isolement et de récupération attendu.