Choisir entre CLI et MCP pour vos flux de travail d'agents IA

Je construis des flux de travail d'agents depuis environ un an, et une question revient sans cesse de la part des développeurs : dois-je utiliser un outil CLI ou construire un serveur MCP pour cette tâche ? Cela me semblait évident au début, mais plus je l'expliquais, plus je réalisais qu'il y avait une réelle confusion. Laissez-moi clarifier les choses.

Que comparons-nous ici ?

Quand je parle de CLI dans ce contexte, je ne parle pas d'exécuter des commandes dans votre terminal. Je parle de la manière dont les agents d'IA invoquent des outils externes. Il existe deux principaux modèles :

L'exécution de commandes shell fonctionne en exécutant directement des commandes shell. L'agent exécute essentiellement quelque chose comme npm run build ou python script.py et analyse la sortie.

MCP (Model Context Protocol) est un protocole ouvert développé par Anthropic qui utilise JSON-RPC 2.0 pour la communication entre les applications d'IA et les systèmes externes. Plutôt que d'exécuter des commandes shell, l'agent appelle des outils structurés exposés par un serveur MCP. Le serveur découvre les outils disponibles via la méthode tools/list, et l'agent les exécute en utilisant tools/call avec des paramètres typés.

La différence clé : les commandes shell donnent à l'agent une chaîne brute à exécuter, tandis que MCP donne à l'agent des définitions d'outils structurées et typées avec des schémas d'entrée clairs.

Quand les commandes shell sont pertinentes

Permettez-moi de vous donner un exemple concret. Sur mon site portfolio, j'ai des scripts qui génèrent des redirections de mes anciens articles de blog WordPress vers de nouvelles pages Next.js. Je n'ai pas construit de serveur MCP pour cela. Pourquoi ? Parce que c'est une opération simple, ponctuelle, qui existait déjà sous forme de script Node.

Les commandes shell sont avantageuses lorsque :

• Vous avez déjà un script ou une commande fonctionnel(le)
• La tâche est simple et ne nécessite pas de gestion d'état complexe
• Vous êtes en phase de prototypage et souhaitez avancer rapidement
• L'outil est bien établi et dispose d'une interface CLI stable

Autre scénario : j'utilise ffmpeg pour le traitement audio dans mes projets. Est-ce que je veux construire un serveur MCP pour ffmpeg ? Absolument pas. C'est un outil vieux de plusieurs décennies avec une interface CLI stable. L'agent a juste besoin de construire la bonne chaîne de commande.

L'agent n'a pas besoin de définitions d'outils de type sécurisé ici. Il a juste besoin de passer des arguments à un processus externe.

Quand MCP excelle

C'est là que MCP devient un investissement rentable. J'ai construit un serveur MCP pour mon outil de recherche de RFP. La fonctionnalité n'est pas simple du tout. Il s'agit d'une recherche en texte intégral à travers des milliers de documents de marchés publics, avec filtrage, classement et résumés générés par l'IA.

Si j'avais fait cela sous forme de commandes shell, l'agent construirait des chaînes de commandes complexes avec des dizaines d'arguments. Ce serait sujet aux erreurs et difficile à maintenir. Au lieu de cela, le serveur MCP expose des outils clairs avec des schémas d'entrée appropriés : search_rfps(query, filters) et get_rfp_details(id). L'agent les appelle avec des arguments typés, et le serveur MCP gère la complexité.

MCP est avantageux lorsque :

• Vous avez des flux de travail complexes et en plusieurs étapes qui nécessitent une structure appropriée
• Vous avez besoin d'interfaces type-safe avec JSON Schema pour les entrées
• Vous construisez quelque chose à partir de zéro qui sera utilisé de manière répétée
• Vous voulez que l'agent découvre dynamiquement les outils disponibles
• Vous avez besoin d'un contrôle granulaire sur ce que l'agent peut faire
• Vous voulez prendre en charge les déploiements locaux (transport STDIO) et distants (transport HTTP)

Le protocole prend également en charge la négociation des capacités lors de l'initialisation de la connexion, de sorte que les serveurs peuvent annoncer les fonctionnalités qu'ils prennent en charge et les clients peuvent s'adapter en conséquence.

Qu'en est-il de l'interaction avec les API ?

Cela revient souvent. Si l'agent doit appeler une API REST, doit-il utiliser curl ou construire un serveur MCP ?

L'approche CLI signifie que l'agent construit des chaînes de commandes comme curl -X GET https://api.example.com/data -H "Authorization: Bearer $TOKEN". Cela fonctionne, mais l'agent doit obtenir chaque en-tête, paramètre de requête et détail d'authentification correctement. Une seule erreur et l'appel échoue.

L'approche MCP expose des outils tels que get_data(filters) ou search_customers(query). Le serveur MCP gère les appels HTTP, l'authentification, la gestion des erreurs et les nouvelles tentatives en interne. L'agent se contente de passer des paramètres structurés.

Pour un appel rapide et ponctuel, la CLI convient. Pour tout ce que vous utilisez régulièrement, MCP est plus propre. Le serveur peut gérer le rafraîchissement des jetons OAuth, la limitation du débit et des messages d'erreur appropriés. Votre agent n'a pas besoin de connaître tout cela.

Le cadre de décision

Voici comment j'aborde la question maintenant :

Commencez par des commandes shell si : la tâche est un simple wrapper autour d'une commande existante, il s'agit d'une opération ponctuelle ou peu fréquente, ou vous avez juste besoin de quelque chose qui fonctionne rapidement.

Passez à MCP si : l'outil a des entrées complexes qui nécessitent une validation, sera utilisé fréquemment dans les flux de travail de l'agent, ou nécessite une découverte d'outils appropriée. La surcharge liée à la configuration d'un serveur MCP n'a de sens que lorsque la complexité de l'outil le justifie.

Il y a aussi une courbe d'apprentissage à considérer. Votre équipe doit comprendre comment MCP fonctionne : c'est un protocole ouvert avec des SDK pour plusieurs langages. Si vous êtes le seul à créer des outils pour agent et que vous avez juste besoin que quelque chose soit fait, les commandes shell suffisent. Si vous créez des outils pour une équipe ou si vous souhaitez une infrastructure réutilisable, MCP est rentable.

Et si on combinait les deux ?

Vous le pouvez, et vous devriez le faire lorsque c'est approprié. J'ai un serveur MCP pour mon blog qui gère des opérations complexes comme la génération de traductions ou la gestion des métadonnées de publication. Mais il appelle toujours des commandes shell en interne pour des tâches comme l'exécution de scripts Node ou l'accès à git. MCP est la couche d'orchestration, les commandes shell sont l'un des outils qu'il peut utiliser.

Ne pensez pas qu'il faille choisir l'un ou l'autre. Pensez à MCP comme un moyen de donner aux agents une interface plus propre vers vos outils existants, y compris les commandes shell. Le protocole utilise des messages JSON-RPC 2.0 quel que soit le transport, qu'il s'agisse de STDIO pour les processus locaux ou de HTTP Streamable pour les serveurs distants.

La prochaine fois que vous créerez quelque chose pour un agent, demandez-vous : s'agit-il d'un simple wrapper autour d'une commande existante, ou a-t-il besoin de sa propre interface structurée avec des définitions d'outils typées ? Cette réponse vous indiquera la voie à suivre.