Votre app LLM a-t-elle vraiment besoin de MCP ? MCP vs CLI vs function calling

La même question revient souvent chez les développeurs : mon app LLM doit interroger une base de données ou lancer une commande de déploiement, dois-je créer un serveur MCP ? Parfois oui. Mais le plus souvent, la réponse honnête est : pas encore.

MCP, le Model Context Protocol, est utile parce qu'il donne aux applications IA une façon standard de découvrir des outils, ressources et prompts. Mais un standard ne doit pas devenir l'abstraction par défaut pour tous les cas.

Commencez par la surface d'intégration

Function calling, CLI et MCP résolvent le même problème : le modèle a besoin de capacités sûres et structurées. La différence est l'endroit où vit le contrat.

Avec le function calling natif, le contrat vit dans votre application. Vous définissez les schémas, recevez les appels d'outils, exécutez le code côté serveur et retournez les résultats. C'est direct, observable et souvent le chemin le plus rapide vers la production.

Avec une couche CLI, le contrat est une commande exécutable. Tests, type checks, migrations, plans d'infrastructure et recherche dans le dépôt sont déjà des commandes. La bonne architecture n'est pas un shell ouvert, mais un broker strict avec allowlist, timeouts, validation, limites de sortie et logs.

Avec MCP, le contrat devient un protocole entre client et serveur. Il est pertinent quand la même capacité doit dépasser un SDK, une application hôte ou une équipe.

Quand le function calling suffit

Pour une première version de fonctionnalité produit, le function calling est souvent le meilleur départ. Authentification, logs, rate limits, multi-tenant et réponse aux incidents restent dans la frontière applicative que vous opérez déjà.

Si les outils sont spécifiques au produit — consulter des commandes, préparer des remboursements, résumer un compte — MCP peut ajouter une frontière sans améliorer l'expérience.

Le problème apparaît plus tard, lorsque plusieurs équipes réimplémentent les mêmes outils dans plusieurs hôtes. C'est là que MCP devient intéressant.

Quand une CLI est meilleure

Pour les agents de code et les workflows d'infrastructure, la CLI est souvent l'interface la plus honnête. Elle est reproductible localement, hérite des conventions du projet, produit des logs lisibles et échoue avec des codes de sortie.

Si le workflow est déjà orienté commande, encapsulez d'abord la CLI. Donnez au modèle des résumés structurés et gardez les logs bruts pour les humains.

Quand MCP mérite sa complexité

MCP vaut le coût quand la même capacité doit être disponible dans plusieurs environnements IA : recherche documentaire, contexte de repository, design system, métadonnées de base de données ou journaux d'audit. Une équipe peut posséder le serveur et plusieurs apps le consommer.

Voir aussi nos patterns MCP en production et notre stratégie MCP pour SaaS.

MCP ne supprime pas les sujets d'exploitation : authentification, autorisation, secrets, rate limits, télémétrie, versioning de schéma et erreurs sûres restent nécessaires.

La règle pratique

Un seul client et une logique produit : function calling. Un workflow humain déjà basé sur des commandes : broker CLI. Plusieurs clients IA, ownership distribué et outils stables : MCP.

La meilleure architecture n'est pas la plus récente. C'est celle qui ajoute le moins de frontières tout en gardant sécurité, observabilité et réutilisation.