MCP ou CLI : comment brancher un agent IA sur un outil (l'exemple Airtable)
Récemment, Airtable a publié un plugin pour les agents de développement type Claude Code ou Codex. En l’installant, on découvre qu’il contient en réalité deux outils qui font presque la même chose : un MCP et un CLI, tous deux capables de lire et d’écrire dans les bases, et même de modifier leur structure. Le plugin ajoute quelques skills pour guider l’agent.
Première réaction légitime : pourquoi proposer deux portes d’entrée vers les mêmes fonctionnalités ? Et laquelle choisir ?
La question dépasse largement Airtable. Elle rejoint un débat qui agite l’écosystème depuis quelques mois : après l’engouement pour les MCP, une bonne partie de la communauté est en train de revenir vers le bon vieux CLI. Dans cet article, je reviens sur ce qui distingue réellement ces deux approches, et je le mets à l’épreuve d’un cas d’usage vécu.
D’abord, deux définitions simples
Avant de comparer, posons les deux objets.
Un MCP (Model Context Protocol) est un standard de branchement entre un modèle d’IA et un outil externe. On peut le voir comme une prise normalisée : l’outil déclare à l’avance la liste des actions qu’il sait faire (« lister des enregistrements », « créer une table »…), avec pour chacune la forme exacte des paramètres attendus. L’agent lit ce catalogue et appelle les actions directement.
Un CLI (Command Line Interface) est un programme en ligne de commande, exactement comme git ou npm. On l’exécute dans un terminal en tapant des commandes, et il répond en texte. L’agent, lui, se sert du terminal comme le ferait un développeur.
La vraie différence : une prise typée contre un exécutable libre
On lit souvent que le MCP serait « distant » et le CLI « local ». C’est une simplification trompeuse : un serveur MCP peut très bien tourner sur votre machine. La distinction de fond est ailleurs.
Le MCP est un protocole cadré et typé. L’agent voit d’emblée toutes les actions disponibles, ce qui donne une bonne visibilité globale. En contrepartie, ce catalogue occupe de la place dans le « contexte » du modèle même quand on n’utilise qu’une fraction des outils. Autre atout : parce que c’est un standard, un MCP distant peut se brancher aussi bien dans un agent local (Claude Code) que dans une application hébergée sans terminal (Claude, ChatGPT, Mistral…).
Le CLI est un exécutable local, libre et composable. L’agent découvre les commandes à la demande (via --help, sous-commande par sous-commande), ce qui économise du contexte, d’où l’intérêt de l’accompagner d’un skill qui lui donne la vue d’ensemble. Surtout, il hérite de toute la puissance du terminal : rediriger une sortie vers un fichier, enchaîner des commandes, brancher un script Python au milieu. Et les modèles sont excellents pour composer des chaînes shell efficaces. Revers de la médaille : il faut un terminal (donc peu adapté aux interfaces en ligne), gérer l’authentification en local, et accepter d’exécuter des commandes, ce qui suppose un minimum de garde-fous.
Le nerf de la guerre : le contexte et les tokens
C’est ici que tout se joue. Avec le MCP, le résultat de chaque action atterrit directement dans le contexte du modèle. Demandez 100 enregistrements, et ce sont 100 enregistrements complets qui viennent gonfler la mémoire de travail, même si vous n’aviez besoin que d’un aperçu.
Avec le CLI, l’agent garde la main : il peut rediriger la réponse complète vers un fichier et n’en lire qu’un échantillon, ne récupérer que quelques colonnes, ou enchaîner des traitements. La donnée volumineuse ne passe pas forcément par le contexte.
Un cas concret : migrer une centaine d’enregistrements
Rien ne vaut un exemple vécu. J’avais une migration à faire : lire une centaine de lignes dans une table, les transformer vers un format différent, avec une dimension supplémentaire, ce qui gonflait le résultat à près de 1000 lignes à réécrire dans une autre table. Assez pour anticiper un problème de gestion du contexte. J’ai testé les deux approches.
En MCP
L’agent charge d’abord les données source. Puis, pour écrire le résultat, il n’a que deux options, toutes deux mauvaises :
- Écrire les enregistrements transformés directement dans sa réponse, sous forme de tool calls. Souvenez-vous : un tool call, c’est du texte généré. Réécrire 1000 lignes revient donc à les régénérer à la main, token par token. C’est long, coûteux, et exposé aux erreurs de recopie.
- Écrire un script pour transformer les données… mais il doit ensuite recopier le résultat du script dans ses tool calls MCP pour l’envoyer à la base. On retombe sur le même mur.
Dans les deux cas : énormément de tokens en sortie, et un risque d’erreur bien réel.
En CLI
Le déroulé devient limpide :
- Un appel CLI écrit les enregistrements source directement dans un fichier (contexte préservé).
- L’agent lit un échantillon de lignes pour comprendre la structure.
- Il écrit un script Python qui transforme le fichier vers le format cible.
- Il relit un échantillon du résultat pour vérifier.
- Un dernier appel CLI écrit les enregistrements depuis le fichier généré. La sortie du modèle se résume à la commande, pas aux 1000 lignes.
La donnée a circulé fichier → script → fichier → base sans jamais être régénérée par le modèle. Sur ce type d’opération, l’avantage du CLI est net.
Au fond, tout tient dans ce renversement : en MCP, le modèle doit écrire les données lui-même ; en CLI, il lui suffit d’écrire les commandes qui produisent les données. C’est là que se gagnent les tokens, la vitesse et la fiabilité.
Un mot sur les modifications de structure (ajouter une table, une colonne…), pour être juste : là, la différence est faible. Dans les deux cas, l’agent doit charger le contexte de la base puis appeler les commandes d’altération. Le volume est modeste, MCP et CLI se valent.
Alors, lequel choisir ?
Le bon choix dépend de l’environnement :
- Un chat en ligne, sans terminal (Claude, ChatGPT, Mistral) : le MCP est votre seule option viable. Il se branche partout, gère proprement l’authentification à distance, et reste parfait pour de la consultation ou des actions ponctuelles.
- Un agent de code, avec un terminal (Claude Code, Codex) : le CLI prend l’avantage dès qu’il y a du volume ou des traitements à chaîner. Plus sobre en tokens, donc moins cher et plus rapide, et bien plus flexible.
Cela explique pourquoi Airtable livre les deux : ce ne sont pas deux fois le même outil, mais deux réponses à deux contextes d’usage.
Et c’est aussi pourquoi la communauté « revient au CLI » sans pour autant enterrer le MCP : dans les agents de code, qui concentrent aujourd’hui les usages les plus intensifs, l’efficacité du terminal fait la différence. Le MCP, lui, garde son territoire : partout où il n’y a pas de shell.
Vous hésitez sur la bonne architecture pour brancher vos outils métier (Airtable ou autre) sur un agent IA ? C’est exactement le genre de sujet sur lequel j’accompagne mes clients.