MCP vs API vs function calling : comparatif technique
MCP, API REST et function calling : quelles différences concrètes pour connecter un LLM à vos systèmes ? Tableau comparatif et guide pratique pour architectes et développeurs.
Frédéric Le Bris
CEO & Co-fondateur
Avant le Model Context Protocol (MCP), connecter un assistant IA à une source de données d'entreprise demandait soit d'écrire un plugin sur mesure, soit de passer par le function calling du modèle, soit de construire une couche d'API dédiée. Trois approches, trois niveaux de complexité, trois façons différentes d'exposer des données à un LLM. Cet article compare ces trois mécanismes de façon technique et concrète, à destination des développeurs et architectes qui doivent choisir.
Le contexte : pourquoi connecter un LLM à des données externes ?
Un modèle de langage, par défaut, ne connaît que son contexte de conversation et ses données d'entraînement. Pour qu'il puisse raisonner sur vos données — votre cartographie SI, votre base de connaissances, votre CRM — il faut lui fournir un mécanisme pour accéder à ces sources en temps réel.
Trois approches techniques coexistent aujourd'hui :
- L'appel d'API direct : le développeur expose une API REST/GraphQL, l'intègre dans l'orchestration du LLM, et gère lui-même la sérialisation des requêtes et des réponses.
- Le function calling : le modèle déclare des fonctions disponibles dans son prompt système ; à l'exécution, il décide d'appeler telle ou telle fonction et l'orchestrateur l'exécute.
- MCP (Model Context Protocol) : un protocole standardisé, porté par Anthropic, qui définit un contrat d'interface universel entre un hôte LLM et n'importe quelle source de contexte externe.
Tableau comparatif : MCP vs API vs function calling
| Critère | API directe | Function calling | MCP |
|---|---|---|---|
| Standardisation | Aucune (chaque API est différente) | Partielle (propre à chaque fournisseur de modèle) | Universelle (protocole ouvert) |
| Effort d'intégration | Élevé (couche d'orchestration à construire) | Moyen (déclaration de schéma JSON) | Faible (connecteur MCP prêt à l'emploi) |
| Portabilité entre modèles | Non | Non (lié au fournisseur) | Oui (tout client MCP compatible) |
| Gestion du contexte | Manuelle | Manuelle | Native (le protocole gère le flux de contexte) |
| Sécurité / contrôle d'accès | À implémenter côté API | À implémenter côté orchestrateur | Géré par le serveur MCP |
| Traçabilité des appels | À implémenter | À implémenter | Intégrée (journalisation côté serveur MCP) |
| Lecture seule possible | Oui (si l'API le prévoit) | Oui (si la fonction le prévoit) | Oui (par conception dans UrbaHive) |
| Multi-tenant | À implémenter | À implémenter | Géré par le serveur MCP (token = tenant) |
| Compatibilité | Dépend du client LLM | Dépend du fournisseur | Claude Desktop, claude.ai, Claude Code, tout client MCP |
L'API directe : puissante mais coûteuse à intégrer
Appeler une API REST depuis un LLM, c'est techniquement possible. Le développeur récupère la réponse JSON, la formate, l'injecte dans le contexte du modèle. Mais cette approche a plusieurs limites :
- Chaque API est différente. Authentification, schéma de réponse, pagination, gestion des erreurs : tout est à réimplémenter pour chaque source de données.
- L'orchestration est à la charge du développeur. Décider *quand* appeler l'API, *quelles* données extraire, *comment* les présenter au modèle — tout cela nécessite une couche de code spécifique.
- La maintenabilité est faible. Changer d'API ou de modèle oblige souvent à refactorer l'intégration complète.
Pour un usage en production sur plusieurs sources de données, l'API directe sans couche d'abstraction devient rapidement un dette technique. C'est précisément le problème que MCP résout.
Le function calling : un progrès, mais lié au fournisseur
Le function calling (ou tool use) est une avancée significative. Le développeur déclare dans le prompt système une liste de fonctions disponibles avec leur schéma JSON. Le modèle, lors de l'inférence, décide d'appeler une fonction si la question l'exige, retourne un appel structuré, et l'orchestrateur exécute la fonction avant de renvoyer le résultat au modèle.
Avantages :
- L'IA décide elle-même *quand* appeler quel outil.
- La déclaration en JSON Schema est relativement standard.
Limites :
- Dépendance au fournisseur. La syntaxe de function calling d'OpenAI n'est pas identique à celle d'Anthropic ou de Google. Un connecteur écrit pour GPT-4 n'est pas directement portable vers Claude.
- Gestion du contexte manuelle. Le développeur doit toujours décider quelles fonctions exposer, gérer les erreurs, formater les résultats.
- Pas de standardisation de la découverte. Chaque intégration redéfinit son propre catalogue d'outils.
MCP : le standard universel pour la connexion LLM-SI
MCP introduit une couche d'abstraction supérieure. Au lieu de décrire des fonctions spécifiques à un modèle, on crée un serveur MCP — un service qui expose des ressources, des outils et des prompts selon un protocole JSON-RPC standardisé. N'importe quel client MCP (Claude Desktop, claude.ai, Claude Code, ou un client tiers compatible) peut se connecter à ce serveur sans code d'intégration supplémentaire.
Ce que MCP standardise concrètement :
- La découverte des capacités : le client demande au serveur MCP ce qu'il sait faire (
tools/list,resources/list). - L'appel structuré : les requêtes et réponses suivent un schéma JSON-RPC 2.0 identique quelle que soit la source de données.
- Le transport : stdio pour les processus locaux, HTTP/SSE pour les serveurs distants.
- La gestion du contexte : le protocole gère nativement le flux d'information entre le modèle et la source.
Pour un architecte d'entreprise, l'analogie est celle de l'USB : avant l'USB, chaque périphérique avait son propre connecteur. MCP est l'USB des connecteurs IA.
Pourquoi UrbaHive a choisi MCP
UrbaHive expose sa cartographie SI via un serveur MCP plutôt que via une API dédiée ou du function calling, pour trois raisons :
- Portabilité immédiate. Le même serveur MCP fonctionne avec Claude Desktop, claude.ai et Claude Code sans modification.
- Sécurité by design. Le serveur MCP peut être conçu en lecture seule dès le protocole — pas besoin de mettre en place des garde-fous au niveau de l'orchestrateur.
- Expérience développeur simplifiée. Générer un token, coller une configuration JSON, poser des questions : aucune ligne de code à écrire côté client.
Pour comprendre la mise en pratique, consultez notre article Connecter Claude à sa cartographie SI via MCP et notre guide complet MCP.
Quand utiliser quelle approche ?
| Cas d'usage | Approche recommandée |
|---|---|
| Intégration ponctuelle, source unique, équipe technique disponible | API directe |
| Chatbot avec outils métier, modèle unique, périmètre limité | Function calling |
| Connexion de plusieurs sources de données à plusieurs modèles IA | MCP |
| Accès IA à la cartographie SI avec conformité RGPD | MCP (serveur souverain) |
| Prototype rapide sans infrastructure | Function calling |
Conclusion
MCP, API directe et function calling ne sont pas en compétition : ils répondent à des niveaux de maturité et de complexité différents. Pour les équipes qui veulent connecter un assistant IA à leurs données d'entreprise de façon durable, portable et sécurisée, MCP représente aujourd'hui l'approche la plus robuste.
Pour les architectes et développeurs qui souhaitent expérimenter concrètement, UrbaHive propose un serveur MCP prêt à l'emploi, connecté à votre cartographie SI, en lecture seule et hébergé en Europe.
Créez votre compte UrbaHive et testez le connecteur MCP dès aujourd'hui. Consultez aussi la page Connecteurs pour le détail technique.
FAQ
MCP remplace-t-il complètement le function calling ?
Non. Le function calling reste pertinent pour des intégrations simples, mono-modèle, avec un périmètre d'outils limité. MCP apporte une valeur supplémentaire quand on veut de la portabilité entre modèles, plusieurs sources de données, ou une infrastructure partagée entre équipes.
Un serveur MCP peut-il exposer des opérations d'écriture ?
Oui, le protocole MCP le permet. Mais ce n'est pas une obligation. UrbaHive a fait le choix de n'exposer que des opérations de lecture pour garantir la sécurité du connecteur. Chaque implémenteur choisit ce qu'il expose.
MCP est-il compatible avec les modèles OpenAI ou Gemini ?
Le protocole MCP est ouvert et des clients tiers commencent à l'implémenter. Nativement, MCP est supporté par la gamme Claude (Anthropic). La compatibilité avec d'autres modèles dépend du client utilisé.
Quelle est la différence entre un outil MCP et une ressource MCP ?
Un outil MCP est une action que l'IA peut déclencher (ex. : rechercher une application par nom). Une ressource MCP est un document ou un flux de données que l'IA peut lire directement (ex. : la fiche d'un serveur). Les deux sont exposés par le serveur MCP.
Combien de temps faut-il pour développer un serveur MCP ?
Un serveur MCP minimaliste (quelques outils, une source de données) se développe en quelques heures avec les SDK disponibles (Python, TypeScript). La complexité augmente avec le nombre de sources et les exigences de sécurité.
Liens internes :