En bref
Le tool calling et MCP adressent le même besoin de surface — connecter un LLM à des outils externes — mais à deux niveaux d’abstraction radicalement différents. Le tool calling est une primitive API : elle vit dans le payload de la requête, ne requiert aucune infrastructure, et disparaît avec la conversation. MCP est un protocole réseau à part entière : il impose un serveur dédié, des connexions persistantes, et en contrepartie ouvre des capacités que le tool calling pur ne peut pas offrir. Choisir entre les deux n’est pas une question de mode — c’est une question d’architecture.
Ce que chaque approche résout
Pense à un atelier de menuiserie. Le tool calling, c’est sortir du tablier les outils dont tu sais que tu vas avoir besoin pour cette commande précise — ils sont sur ta ceinture, accessibles en une seconde, mais tu dois les choisir d’avance. MCP, c’est l’établi mural standardisé : n’importe quel artisan qui passe (Claude, ChatGPT, VS Code) trouve la perceuse au même endroit, avec la même fiche d’utilisation. La perceuse coûte plus cher à installer, mais elle sert à tout le monde sans réinstallation.
Tool calling — la primitive directe
Le tool calling (« tool use » chez Anthropic, « function calling » chez OpenAI) est intégré directement dans l’API de messages. L’application envoie une liste de définitions d’outils au format JSON Schema dans le payload de la requête. Le modèle décide quand les invoquer, émet un bloc tool_use, l’application exécute localement, renvoie un tool_result, et le cycle reprend.
Tout l’état est dans la conversation. Il n’y a rien à déployer, rien à maintenir. La documentation Anthropic le décrit comme « one of the highest-leverage primitives you can give an agent ». L’option strict: true garantit la conformité au schéma en production.
Ce modèle est stateless côté protocole : chaque requête est autonome. La liste des outils est fixée à l’appel. La découverte est impossible en runtime.
MCP — le protocole de standardisation
MCP (Model Context Protocol) est un standard ouvert publié par Anthropic en novembre 2024, dont la spécification courante est versionnée 2025-11-25. L’analogie de la spec est celle de l’USB-C : une prise universelle pour connecter des systèmes hétérogènes à des clients IA. L’inspiration déclarée est le Language Server Protocol (LSP) de Microsoft.
L’architecture comporte trois rôles distincts :
- MCP Host : l’application IA (Claude Desktop, VS Code, Cursor…)
- MCP Client : composant interne du Host, maintient une connexion dédiée par serveur
- MCP Server : programme exposant des capacités via JSON-RPC 2.0
Deux transports sont disponibles : stdio (le Host lance le serveur en subprocess, communication via stdin/stdout, latence nulle, usage local) et Streamable HTTP (HTTP POST + Server-Sent Events optionnels, pour l’accès distant).
MCP est un protocole stateful : il gère un cycle de vie de connexion, négocie des capabilities au handshake, et peut envoyer des notifications push (notifications/tools/list_changed) quand la liste des outils change en cours de session.
En clair : tool calling vit dans la conversation et meurt avec elle. MCP vit dans un serveur dédié et survit aux conversations. La différence d’infrastructure n’est pas anodine — un serveur MCP, ça se déploie, ça se sécurise, ça se monitore. Tool calling, c’est juste du JSON dans la requête.
Tableau comparatif
| Dimension | Tool Calling | MCP |
|---|---|---|
| Niveau d’abstraction | Primitif API (dans la requête) | Protocole réseau (couche séparée) |
| Infrastructure requise | Aucune | Serveur MCP dédié |
| Stateful | Non (conversation) | Oui (connexions persistantes, sessions) |
| Primitives exposées | Tools uniquement | Tools + Resources + Prompts + Sampling |
| Interopérabilité | Spécifique au fournisseur | Cross-fournisseur (Claude, ChatGPT, VS Code…) |
| Transport | N/A (inline API) | stdio (local) ou Streamable HTTP (distant) |
| Découverte d’outils | Liste fixée dans le payload | tools/list dynamique en runtime |
| Notifications push | Non | Oui (notifications/tools/list_changed) |
| Problème résolu | Appel de fonction ad hoc | M×N intégrations → M+N |
Les trois primitives MCP sans équivalent dans le tool calling
Le tool calling ne connaît qu’un seul concept : l’outil exécutable. MCP en distingue trois, avec des modèles de contrôle différents :
| Primitive | Contrôle | Équivalent tool calling | Description |
|---|---|---|---|
| Tools | Modèle | Oui | Fonctions exécutables, actions sur le monde |
| Resources | Application | Non | Sources de données read-only avec URI unique (file:///path, calendar://events/…) |
| Prompts | Utilisateur | Non | Templates paramétrés, workflows réutilisables (slash commands, palettes) |
La primitive Sampling va dans l’autre sens : le serveur MCP peut demander une complétion LLM au client. C’est un pattern inverse sans équivalent dans le tool calling, aux implications architecturales non encore stabilisées dans la littérature.
Le problème M×N
La justification principale de MCP est économique au niveau de l’architecture. Sans standard, M applications qui consomment N systèmes externes génèrent M×N intégrations custom à maintenir. MCP transforme ce problème en M+N : chaque système expose un serveur MCP une seule fois, chaque client IA supporte le protocole une seule fois.
Pour une application isolée appelant deux APIs internes, cet argument ne s’applique pas. Pour une équipe qui déploie plusieurs agents consommant les mêmes systèmes (base de données, Slack, GitHub, Postgres), MCP élimine la duplication de code d’intégration. Les serveurs de référence officiels couvrent filesystem, GitHub, Slack, Postgres, Google Drive, SQLite, Puppeteer.
Sécurité : ce que MCP formalise que le tool calling ne formalise pas
La spec MCP 2025-11-25 introduit des mécanismes absents du tool calling pur :
- Annotations sur les outils (métadonnées comportementales) — la spec précise que les clients doivent les considérer non fiables sauf si elles proviennent d’un serveur de confiance
- outputSchema : validation du résultat structuré côté client
- Deux types d’erreur distincts : Protocol Errors (JSON-RPC) vs Tool Execution Errors (
isError: true), ce qui permet au modèle de s’auto-corriger sur les erreurs d’exécution - Principes de consentement : consentement explicite requis avant invocation, validation des inputs, rate limiting, sanitisation des outputs — au niveau SHOULD (recommandation), pas MUST (obligation)
Le transport Streamable HTTP introduit un risque spécifique : attaques DNS rebinding. La spec impose que le serveur valide l’en-tête Origin et rejette avec HTTP 403 si invalide. Les serveurs locaux doivent se lier uniquement sur localhost.
En clair : MCP formalise des concepts que tool calling laisse à la charge de chaque application — schéma de retour, types d’erreurs distincts, recommandations de consentement. Pour un agent unique, ces formalismes sont du sucre. Pour un parc de 50 agents partagés en entreprise, ils deviennent vitaux.
Quand utiliser l’un ou l’autre
Tool calling est le choix par défaut quand :
- Le périmètre est limité (quelques outils, une seule application)
- L’infrastructure doit rester minimale (prototypage, usage ponctuel)
- Les outils ne changent pas en cours de session
- Aucun partage entre applications n’est prévu
MCP devient pertinent quand :
- Plusieurs applications ou agents consomment les mêmes systèmes
- Les outils doivent être découverts dynamiquement en runtime
- Les primitives Resources ou Prompts sont nécessaires (données read-only exposées avec URI, templates utilisateur)
- Une standardisation d’équipe est requise (server unique réutilisable)
- Une orchestration multi-agents doit s’appuyer sur un écosystème composable
Simon Willison notait en novembre 2024 que la configuration MCP était « clunky » dans ses premières versions (édition JSON manuelle, disponibilité limitée à Claude Desktop). La complexité d’infrastructure est réelle : handshake de lifecycle, négociation de capabilities, gestion d’état persistant. Ce coût est justifié quand le gain de composabilité et de réutilisabilité dépasse cet overhead.
Les deux approches ne sont pas mutuellement exclusives : un agent peut utiliser le tool calling pour des outils locaux définis statiquement et s’appuyer sur MCP pour accéder à des serveurs partagés.
Support MCP dans l’écosystème
Anthropic a créé et maintient le protocole (Claude Desktop, Claude Code). Le support MCP est documenté chez OpenAI pour ChatGPT [NON VÉRIFIÉ — page inaccessible lors de la collecte]. Microsoft l’a intégré dans Visual Studio Code avec GitHub Copilot. Cursor, Windsurf, Replit, Codeium, Sourcegraph et Zed ont annoncé le support dans leurs plateformes de développement.
La gouvernance est open-source avec un processus SEP (Specification Enhancement Proposals), documenté sur modelcontextprotocol.io.
Ce qu’il faut retenir
Le tool calling et MCP ne sont pas en compétition directe : ils opèrent à des niveaux différents. Le tool calling est suffisant et optimal pour la grande majorité des usages applicatifs — une API, un agent, quelques outils. MCP apporte une valeur réelle dès que l’architecture implique plusieurs applications consommant les mêmes systèmes, ou que la découverte dynamique et la composabilité des outils deviennent des contraintes. Les primitives Resources et Prompts, sans équivalent dans le tool calling, ouvrent des possibilités d’interface modèle-contexte que le tool calling pur ne peut pas couvrir. La décision relève de l’architecture, pas de la tendance.