Tool Calling vs MCP : différence et usages

Le Tool Calling est une fonctionnalité d’API de modèle de langage dans laquelle le modèle demande l’appel d’une fonction et votre application exécute le code. Model Context Protocol (MCP) est un standard JSON-RPC ouvert qui permet aux applications d’IA de découvrir et d’invoquer des outils exposés par des serveurs externes. MCP repose sur le Tool Calling sous-jacent au lieu de le remplacer.

Les développeurs qui créent des agents IA ou des backends fondés sur des LLM rencontrent souvent ces deux termes dans la documentation des fournisseurs. Pour comprendre Tool Calling et MCP, il faut distinguer la manière dont un modèle décide d’exécuter une fonction de celle dont une application se connecte au système qui l’héberge.

Qu’est-ce que le Tool Calling dans les API de LLM ?

Le Tool Calling (aussi appelé function calling) est une fonctionnalité d’API de modèle qui transforme un prompt en langage naturel en appel de fonction structuré. Vous transmettez des définitions de fonctions dans votre requête API avec un nom, une description et des paramètres JSON Schema. Le modèle décide ensuite de renvoyer ou non un appel structuré contenant le nom et les arguments de la fonction.

Le modèle n’exécute pas lui-même la fonction. Le Tool Calling fonctionne comme une conversation en plusieurs étapes entre votre application et le modèle :

Envoyer les déclarations d’outils : votre application interroge le modèle et inclut les définitions JSON Schema des outils qu’il peut appeler.
Recevoir un appel d’outil structuré : le modèle répond par un appel contenant le nom de la fonction choisie et des arguments JSON (par exemple, Anthropic renvoie un motif d’arrêt et un bloc tool_use).
Exécuter le code côté application : votre backend valide les arguments et exécute la fonction locale ou la requête API interne.
Renvoyer le résultat de l’outil : votre application adresse une deuxième requête au modèle avec le résultat (par exemple un bloc tool_result).
Recevoir la réponse finale : le modèle utilise le résultat pour répondre à l’utilisateur ou demande d’autres appels d’outils.

Une définition de fonction OpenAI utilise les parameters JSON Schema et prend en charge strict: true pour imposer le respect du schéma :

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a given location.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string"
      }
    },
    "required": ["location"],
    "additionalProperties": false
  }
}

Les principales API de modèles offrent un contrôle précis sur la sélection des fonctions. Dans les API OpenAI et Google Gemini, tool_choice permet de laisser la sélection sur auto (par défaut), de forcer un ou plusieurs appels (required chez OpenAI, any chez Gemini), de désactiver les outils (none), de limiter le modèle à un sous-ensemble avec allowed_tools ou d’utiliser le mode validated de Gemini pour garantir le respect du schéma de fonction. OpenAI et Gemini prennent tous deux en charge les appels de fonctions parallèles, permettant au modèle d’invoquer plusieurs fonctions dans un même tour. OpenAI permet de régler parallel_tool_calls sur false pour obtenir au plus un appel par tour. Gemini prend aussi en charge les appels compositionnels pour les exécutions séquentielles en plusieurs étapes.

Anthropic distingue l’utilisation des outils selon le lieu d’exécution du code. Les outils client (dont vos fonctions personnalisées et les outils au schéma Anthropic comme bash et text_editor) s’exécutent dans votre application. Les outils serveur (comme web_search, web_fetch, code_execution et tool_search) s’exécutent directement sur l’infrastructure d’Anthropic.

Qu’est-ce que le Model Context Protocol (MCP) ?

Le Model Context Protocol (MCP) est un standard open source qui relie les applications d’IA aux systèmes externes via JSON-RPC 2.0. Inspirée du Language Server Protocol, la spécification MCP (version 2026-07-28) joue le rôle d’un port USB-C pour les applications d’IA : une seule intégration serveur peut fonctionner avec ChatGPT, Claude, Visual Studio Code, Cursor et des agents personnalisés.

MCP répartit les responsabilités entre trois rôles :

Hôtes (Hosts) : les applications de LLM (comme un IDE ou une interface de chat) qui initient les connexions.
Clients (Clients) : les connecteurs de protocole exécutés dans l’application hôte.
Serveurs (Servers) : les services externes qui exposent des capacités et du contexte au client.

Dans la spécification du 2026-07-28, le protocole de base utilise des requêtes JSON-RPC 2.0 autonomes et sans état, avec une négociation des capacités à chaque requête. MCP définit deux transports standard : stdio, qui transmet des messages délimités par des sauts de ligne sur l’entrée et la sortie standard d’un sous-processus lancé par le client, et Streamable HTTP, où chaque message est un POST HTTP vers un point de terminaison MCP unique. Les développeurs peuvent aussi implémenter des transports personnalisés.

Alors que le Tool Calling des LLM ne gère que des fonctions, les serveurs MCP peuvent exposer trois fonctionnalités principales :

Tools : fonctions que le modèle d’IA peut exécuter.
Resources : contexte et données que l’application peut lire.
Prompts : modèles de messages et flux de travail pour les utilisateurs.

Côté client, MCP prend en charge Elicitation, qui permet à un serveur de demander des informations supplémentaires à l’utilisateur. La spécification du 2026-07-28 comprend aussi des extensions négociées et facultatives pour Tasks (opérations asynchrones de longue durée), Skills over MCP et MCP Apps (éléments d’interface interactifs affichés dans le fil).

Pour exécuter un outil, un client MCP découvre les outils disponibles en appelant tools/list, qui prend en charge la pagination et la mise en cache. Les serveurs qui déclarent la capacité listChanged peuvent avertir les clients lorsque les outils disponibles changent. Chaque définition d’outil MCP comprend un name sensible à la casse (de 1 à 128 caractères recommandés), un title facultatif, une description, des icons facultatives, un inputSchema (JSON Schema 2020-12 par défaut), un outputSchema facultatif et des annotations facultatives.

Lorsque le modèle décide d’utiliser un outil MCP, le client envoie une requête JSON-RPC tools/call au serveur :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "San Francisco, CA"
    }
  }
}

Si l’exécution d’un outil échoue sur le serveur, MCP renvoie l’erreur dans le résultat avec isError: true, afin que le modèle de langage puisse lire l’échec et se corriger.

Tool Calling vs MCP : comparaison

La comparaison directe du Tool Calling des LLM et de MCP montre qu’ils opèrent à différentes couches de la pile. En novembre 2026, voici les différences entre le Tool Calling natif et le Model Context Protocol selon sept dimensions d’architecture :

Dimension	Tool Calling (Function Calling)	Model Context Protocol (MCP)
Définition	Fonctionnalité d’API de modèle par laquelle un LLM produit des arguments de fonction structurés	Protocole JSON-RPC 2.0 ouvert reliant les hôtes et clients d’IA à des serveurs externes
Qui définit les outils	Le code de votre application (ou les outils serveur du fournisseur) dans la requête API du modèle	Un serveur MCP exposant des Tools, Resources et Prompts
Où le code s’exécute	Le backend de votre application (ou le cloud du fournisseur de LLM pour les outils serveur)	Un sous-processus local (`stdio`) ou un service distant (Streamable HTTP)
Découverte	Statique pour chaque requête API ; votre code fixe ou sélectionne les schémas avant d’appeler le modèle	Dynamique à l’exécution via `tools/list` et les notifications `listChanged`
Transport	API HTTPS du fournisseur (OpenAI, Anthropic, Google Gemini)	`stdio`, Streamable HTTP ou transports personnalisés
Portabilité entre clients	Liée à votre application et au format de schéma du fournisseur de LLM	Portable entre tous les hôtes compatibles MCP (Claude, ChatGPT, VS Code, Cursor, applications personnalisées)
Coût	Tokens d’entrée pour les définitions, tokens de sortie pour les appels et frais supplémentaires pour les outils serveur du fournisseur	Tokens d’entrée pour chaque schéma d’outil chargé et infrastructure d’hébergement ou d’exécution du serveur MCP

MCP remplace-t-il le Function Calling ?

MCP ne remplace pas le Function Calling, car le modèle de langage utilise toujours le Tool Calling pour sélectionner et invoquer chaque outil MCP. Tool Calling et MCP sont des couches complémentaires d’un même cycle de requête.

Lorsqu’une application d’IA se connecte à un serveur MCP, le flux associe les deux systèmes :

Découverte via MCP : le client MCP de l’application hôte envoie une requête tools/list au serveur MCP et reçoit les noms, descriptions et objets inputSchema JSON Schema de ses outils.
Formatage pour le LLM : l’hôte traduit ces définitions d’outils MCP dans le tableau tools natif du fournisseur de LLM et les envoie avec le prompt de l’utilisateur.
Sélection par Tool Calling : le modèle de langage évalue le prompt et produit un appel d’outil standard avec le nom et les arguments choisis.
Exécution via MCP : l’hôte intercepte l’appel du modèle, le convertit en requête MCP tools/call et l’envoie au serveur MCP via stdio ou Streamable HTTP.
Finalisation : le serveur MCP renvoie le résultat (avec isError: true en cas d’échec), l’hôte le transmet au modèle comme résultat d’outil et le modèle génère sa réponse finale.

Sans Tool Calling dans l’API du modèle, le LLM n’aurait aucun mécanisme pour déclencher un outil MCP. Sans MCP, votre application doit relier manuellement chaque schéma d’outil et gestionnaire d’exécution.

Comment OpenAI, Anthropic et Google prennent-ils directement en charge MCP ?

OpenAI, Anthropic et Google permettent désormais de transmettre directement des serveurs MCP distants à leurs API de modèles comme type d’outil intégré. Au lieu d’écrire votre propre boucle client MCP pour relier tools/list et tools/call, l’API du fournisseur de modèle se connecte au serveur MCP pour vous.

En novembre 2026, chaque fournisseur implémente les connexions directes aux serveurs MCP avec des capacités et des limites documentées propres :

OpenAI Responses API

Dans l’OpenAI Responses API, vous pouvez ajouter un serveur MCP en indiquant "type": "mcp" dans votre tableau d’outils avec server_label et server_url. OpenAI inclut deux contrôles essentiels pour la production :

allowed_tools : importe uniquement un sous-ensemble précis d’outils du serveur MCP pour éviter de surcharger le contexte du modèle.
require_approval : détermine si les appels d’outils s’exécutent automatiquement ou attendent une approbation humaine explicite.

Pour les services locaux ou privés, OpenAI fournit un Secure MCP Tunnel permettant de connecter des serveurs MCP internes sans les exposer sur Internet.

Anthropic MCP Connector

Anthropic propose un MCP connector en version bêta dans la Messages API (mcp_servers et mcp_toolset) qui se connecte aux serveurs MCP distants sans implémentation client distincte. Gardez à l’esprit quatre limites documentées :

Outils uniquement : seuls les appels d’outils de la spécification MCP sont pris en charge par le connecteur (pas les Resources ni les Prompts MCP).
HTTP public requis : le serveur MCP doit être exposé publiquement sur HTTP (avec prise en charge de Streamable HTTP et SSE).
Pas de stdio local direct : les serveurs stdio locaux ne peuvent pas se connecter directement à la Messages API, mais les SDK d’Anthropic fournissent des outils d’aide côté client pour les serveurs locaux.
Exclusions de conformité : le MCP connector bêta n’est pas admissible aux charges de travail Zero Data Retention (ZDR) ou HIPAA.

Google Gemini Interactions API

La Gemini Interactions API de Google accepte les serveurs MCP externes avec la déclaration "type": "mcp_server", configurée avec name, url, headers et allowed_tools. Google impose deux règles strictes à cette intégration :

Streamable HTTP uniquement : la Gemini Interactions API prend en charge les serveurs Streamable HTTP et non les transports SSE.
Syntaxe des noms : les noms de serveurs doivent utiliser snake_case et ne peuvent pas contenir de traits d’union.

Quand utiliser Tool Calling ou MCP ?

Le choix entre MCP et Tool Calling dépend des responsables des intégrations et du nombre d’applications qui doivent les partager. Examinez les contraintes de votre projet selon trois situations courantes.

Quand le Tool Calling simple suffit

Gardez le Tool Calling natif du LLM lorsque vos outils se trouvent dans un seul backend applicatif et qu’aucun client externe n’a besoin de les appeler. Si je construis une application web avec cinq requêtes internes à une base de données et une action de paiement Stripe, écrire un serveur MCP ajoute un saut réseau ou un sous-processus inutile.

Le Tool Calling simple convient mieux lorsque :

Vous n’avez qu’un petit nombre de fonctions qui interrogent votre propre base de données ou vos microservices internes.
Vous contrôlez toute la base de code et souhaitez une faible latence et une validation directe dans le processus.
Aucun autre assistant IA, IDE ou équipe n’a besoin de découvrir ou de réutiliser ces fonctions.

Quand un serveur MCP vaut l’investissement

Créez ou adoptez un serveur MCP lorsque les mêmes outils doivent fonctionner avec plusieurs clients d’IA ou lorsqu’une autre équipe gère le système sous-jacent. Si votre plateforme d’ingénierie expose le suivi des tickets et les journaux de déploiement via MCP, les développeurs peuvent connecter exactement le même serveur à Claude, ChatGPT, Visual Studio Code, Cursor et votre agent interne sans réécrire les schémas.

MCP vaut l’investissement lorsque :

Vous voulez écrire une fois et assurer la portabilité entre plusieurs hôtes d’IA et IDE de développement.
Un fournisseur tiers ou une autre équipe interne maintient l’intégration.
Votre agent dépend de la découverte dynamique des outils (tools/list et listChanged) lorsque les capacités changent à l’exécution.
Votre flux de travail nécessite des Resources MCP, des modèles de prompts destinés aux utilisateurs ou la collecte d’informations auprès d’eux, en plus de l’exécution de fonctions.

La configuration hybride

Une approche courante pour les équipes qui font passer des agents IA du pilote à la production consiste à combiner les deux méthodes. Une application type définit dans le code quelques outils de fonctions natifs sensibles à la latence, tout en connectant un ou deux serveurs MCP externes pour des intégrations SaaS tierces et en utilisant allowed_tools pour filtrer les points de terminaison inutiles.

Compromis de sécurité, de latence et de coût en tokens

Ajouter des outils à une application de LLM, par des déclarations natives ou des serveurs MCP, entraîne des coûts en tokens, des questions de mise en cache et des limites de confiance à gérer avec soin.

Coûts des tokens d’entrée et mise en cache des prompts

Chaque définition d’outil transmise à une API de modèle compte dans vos tokens d’entrée. Anthropic indique que les définitions d’outils dans le paramètre tools comptent comme tokens d’entrée. OpenAI précise que certains serveurs MCP exposent des dizaines d’outils à la fois et qu’en exposer beaucoup peut augmenter le coût et la latence.

Pour garder des coûts en tokens prévisibles :

Filtrez les outils importés : OpenAI et Google utilisent allowed_tools, tandis que le MCP connector d’Anthropic permet d’autoriser, d’interdire ou de configurer individuellement les outils dans mcp_toolset.
Gardez un ordre déterministe dans la liste d’outils. La spécification MCP indique qu’un ordre déterministe dans tools/list aide les clients à mettre la liste en cache et améliore le taux de succès de la mise en cache des prompts du LLM lorsque les définitions d’outils figurent dans le contexte du modèle.

Limites de confiance et approbation humaine

Les outils impliquent l’exécution de code arbitraire, un sujet encore plus sensible si vous déployez aussi des agents IA utilisant un ordinateur qui interagissent avec des systèmes d’exploitation complets. En connectant un serveur MCP tiers, vous franchissez une limite de confiance : des descriptions d’outils ou réponses de serveur non fiables peuvent servir de vecteur d’injection de prompt.

La spécification MCP avertit explicitement que les annotations d’outils doivent être considérées comme non fiables, sauf si elles proviennent d’un serveur de confiance. Puisque MCP ne peut pas imposer la sécurité au niveau du protocole de communication, la spécification indique que les applications hôtes doivent obtenir le consentement explicite de l’utilisateur avant chaque appel d’outil et devraient toujours garder un humain dans la boucle, capable de refuser les appels. Avec des intégrations API directes comme la Responses API d’OpenAI, activez require_approval sur les outils sensibles pour qu’un humain puisse examiner les arguments avant l’exécution.

FAQ

MCP est-il identique au Function Calling ?

Non. Le Function Calling (Tool Calling) est le mécanisme d’API de modèle par lequel un LLM produit une requête JSON structurée pour exécuter une fonction nommée. Le Model Context Protocol (MCP) est un standard de communication ouvert qui permet aux applications d’IA de découvrir et d’invoquer des Tools, Resources et Prompts hébergés sur des serveurs externes.

Peut-on utiliser MCP sans Tool Calling ?

Vous pouvez utiliser les Resources et les modèles de prompts MCP sans Tool Calling du modèle, car ces fonctionnalités sont lues ou déclenchées par l’application hôte ou l’utilisateur. Cependant, chaque fois qu’un modèle d’IA invoque de manière autonome un outil MCP via tools/call, il utilise sa capacité native de Tool Calling pour le sélectionner.

MCP coûte-t-il plus de tokens que le Tool Calling natif ?

Une définition d’outil individuelle coûte le même nombre de tokens d’entrée, que votre application la charge depuis du code local ou depuis un serveur MCP. En pratique, les configurations MCP consomment souvent plus de tokens, car un seul serveur MCP peut exposer des dizaines d’outils à la fois, sauf si vous filtrez la liste avec allowed_tools.

Quels fournisseurs de LLM prennent en charge les serveurs MCP dans leurs API ?

En novembre 2026, OpenAI, Anthropic et Google acceptent tous directement les serveurs MCP distants dans leurs API. OpenAI prend en charge "type": "mcp" dans la Responses API, Anthropic propose le MCP connector bêta (mcp_servers et mcp_toolset) dans la Messages API et Google prend en charge "type": "mcp_server" dans la Gemini Interactions API.

L’API d’Anthropic peut-elle se connecter directement à un serveur MCP stdio local ?

Non. Le MCP connector bêta d’Anthropic dans la Messages API ne se connecte qu’aux serveurs MCP distants exposés publiquement sur HTTP (Streamable HTTP et SSE). Pour utiliser un serveur MCP stdio local avec Claude, vous devez exécuter la connexion côté client à l’aide des outils du SDK d’Anthropic.

Tool Calling vs MCP : différence et quand les utiliser

Qu’est-ce que le Tool Calling dans les API de LLM ?

Qu’est-ce que le Model Context Protocol (MCP) ?

Tool Calling vs MCP : comparaison

MCP remplace-t-il le Function Calling ?