Deux approches pour le même problème
Le function calling et le MCP existent tous deux parce que les modèles d'IA ont besoin d'un moyen d'interagir avec le monde au-delà de la génération de texte. Tous deux permettent aux modèles d'invoquer des opérations externes, de recevoir des résultats et d'utiliser ces résultats dans leurs réponses. Mais ils abordent le problème sous des angles différents, et comprendre ces angles vous aide à choisir le bon pour votre situation.
Comment fonctionne le function calling
Le function calling est une fonctionnalité au niveau de l'API offerte par les fournisseurs de modèles. Quand vous envoyez une requête à Claude ou GPT-4, vous pouvez inclure une liste de définitions d'outils. Chaque définition a un nom, une description et un schéma de paramètres. Le modèle décide d'appeler ou non l'un des outils définis, génère les paramètres appropriés, et c'est le code de votre application qui gère l'exécution réelle.
La caractéristique clé du function calling, c'est qu'il est contrôlé par l'application. Vous définissez quels outils sont disponibles par requête. Vous gérez l'exécution. Vous repassez les résultats au modèle. Le flux entier est géré par la logique de votre application.
Cela vous donne un contrôle précis. Vous savez exactement quels outils sont disponibles dans tout contexte donné. Vous pouvez implémenter vos propres contrôles de sécurité, votre rate limiting et votre gestion d'erreurs. Le modèle n'interagit jamais directement avec les systèmes externes ; votre code médie chaque interaction.
Comment fonctionne le MCP
Le MCP est un standard au niveau du protocole. Au lieu de définir les outils dans chaque requête API, les outils sont exposés par des serveurs MCP autonomes auxquels tout client compatible peut se connecter. Le client découvre les outils disponibles en interrogeant le serveur, et l'exécution d'outil passe par le protocole plutôt que par le code de l'application.
La caractéristique clé du MCP, c'est qu'il est contrôlé par le serveur. Le serveur MCP définit quels outils sont disponibles. Le client (généralement un assistant IA comme Claude Desktop ou Cursor) gère la connexion et présente les appels d'outil à l'utilisateur pour confirmation.
Cela vous donne de la portabilité. Construisez un outil une fois comme serveur MCP, et il fonctionne avec tout client qui prend en charge le protocole. Les utilisateurs peuvent panacher des serveurs de différents fournisseurs sans aucun code d'intégration sur mesure.
Quand le function calling a du sens
Le function calling est le bon choix quand vous construisez une application spécifique avec des besoins d'outils bien définis. Si vous créez un chatbot de support client qui doit consulter les statuts de commande et traiter les retours, vous savez exactement quels outils sont nécessaires. Les définir comme appels de fonctions vous donne un contrôle complet sur l'interaction.
C'est aussi pertinent quand vous devez intégrer étroitement l'usage des outils à la logique de votre application. Peut-être que le résultat d'un appel d'outil déclenche un effet de bord dans votre système, ou que vous devez appliquer des règles métier avant d'exécuter un outil. Le function calling garde tout cela dans le code de votre application où c'est facile à raisonner.
Les scénarios à fort débit favorisent aussi le function calling. Quand vous traitez des milliers de requêtes par minute et que chaque requête a besoin du même ensemble d'outils, la surcharge d'établir des connexions MCP n'a pas de sens. Le function calling vous laisse définir les outils une fois et réutiliser les définitions entre requêtes.
Quand le MCP a du sens
Le MCP est le bon choix quand vous voulez que les utilisateurs finaux puissent connecter et configurer leurs propres outils. Si vous construisez un assistant IA que différents utilisateurs personnaliseront avec différentes intégrations, le MCP permet à chacun de connecter les serveurs dont il a besoin sans que vous ayez à anticiper chaque outil possible.
C'est aussi le bon choix pour les concepteurs d'outils qui veulent une portée maximale. Si vous avez construit un outil utile et voulez qu'il soit utilisable à travers Claude Desktop, Cursor, Windsurf et d'autres clients IA, le publier comme serveur MCP vous donne une compatibilité avec tous via une seule implémentation.
Et le MCP brille dans les usages exploratoires et interactifs où la séquence exacte d'appels d'outils ne peut pas être prédite. Quand un utilisateur demande à une IA de l'aider sur une tâche de recherche, la combinaison d'outils nécessaire peut changer à chaque conversation. Avoir un ensemble de serveurs MCP connectés et disponibles, dans lequel le modèle puise au besoin, est plus pratique que de prédéfinir des ensembles d'outils pour chaque scénario possible.
Utiliser les deux ensemble
Ces approches ne sont pas mutuellement exclusives. Une application peut utiliser le function calling pour ses fonctionnalités cœur tout en prenant en charge les connexions MCP pour l'extensibilité. Un environnement de développement peut définir certains outils directement et laisser les utilisateurs en ajouter d'autres via des serveurs MCP.
La bonne approche dépend de vos contraintes. Contrôle contre flexibilité. Spécificité contre portabilité. Logique applicative contre personnalisation utilisateur. La plupart des systèmes du monde réel finiront par utiliser une combinaison des deux à mesure que l'écosystème mûrit.
Lectures complémentaires
- Ce que fait réellement le Model Context Protocol
- En quoi les serveurs MCP diffèrent des API traditionnelles
- Pourquoi les serveurs MCP open source dominent l'écosystème
- Pourquoi la qualité des serveurs MCP varie autant (et comment l'évaluer)
Parcourez les serveurs MCP sur Skillful.sh. Cherchez plus de 137 000 outils IA sur Skillful.sh.