MCP vs CLI vs extension navigateur pour piloter un agent

Utilisez MCP lorsqu'un hôte d'agent a besoin d'outils typés et détectables avec un emplacement au niveau du protocole pour les capacités et le consentement. Utilisez un CLI lorsque la tâche contient déjà des commandes, des fichiers, des canaux, des codes de sortie et un shell contrôlé. Une extension de navigateur n'est généralement pas une option tierce : elle peut accorder ou attacher un accès au navigateur sous un outil auquel l'agent accède via MCP ou CLI.

Un agent IA doit-il utiliser MCP ou CLI ?

Commencez par la limite opérationnelle, pas par un gagnant. Si un hôte doit énumérer les outils, valider les arguments JSON, présenter les approbations des utilisateurs et basculer entre les serveurs, MCP propose un contrat partagé. Si un agent de codage dispose déjà d'un shell restreint et que l'opération est naturellement représentée par une commande avec stdout stable et un code de sortie, CLI est généralement le chemin le plus simple.

MCP, CLI et les extensions sont-ils comparables ?

Pas à un seul niveau. MCP et CLI sont des surfaces d'invocation : elles indiquent à un hôte agent comment demander du travail. Une extension de navigateur est un composant d'exécution ou d'accès à l'intérieur du navigateur. Il peut s'attacher à l'onglet d'un utilisateur, demander des autorisations d'hôte, injecter un script de contenu ou relier l'état du navigateur à un autre processus.

Cette distinction évite les fausses comparaisons. « MCP prend en charge les schémas tandis qu'une extension peut cliquer sur la page » compare une propriété de protocole avec une capacité d'implémentation. Une question de conception juste est la suivante : quelle route d'appel doit exposer quelle implémentation de navigateur, sous quelles autorisations et limites de contrôle utilisateur ?

En quoi MCP et CLI diffèrent-ils ?

Un client MCP initialise une session, négocie les fonctionnalités, répertorie les outils et envoie des appels structurés à un serveur. La spécification actuelle des outils permet aux serveurs de publier des noms, des descriptions, des schémas d'entrée JSON, des schémas de sortie facultatifs et des annotations. L'hôte reste responsable de la présentation du consentement approprié et doit traiter les annotations des outils comme non fiables, à moins que le serveur ne soit fiable.

Un processus CLI reçoit des chaînes et l'état de l'environnement du système d'exploitation. Son contrat peut être documenté par --help, une page de manuel, des exemples, des codes de sortie et éventuellement une sortie JSON. Le shell ajoute une composition mature via des redirections, des canaux, des scripts, l'isolation des processus et la journalisation standard, mais crée également des risques de citation, de chemin, d'environnement et d'injection que l'hôte doit limiter.

Les deux peuvent envelopper la même implémentation. Dans notre expérience, Playwright alimentait les deux routes. La tâche du navigateur n'est pas devenue plus ou moins performante car une commande traversait JSON-RPC et l'autre traversait un shell ; la surface de découverte, de sortie, de session et de politique a changé.

En quoi les coûts de découverte et de contexte diffèrent-ils ?

MCP rend la découverte lisible par machine. Cela aide un hôte à décider de ce qui peut être appelé et donne des descriptions de modèles et des formes d'arguments. Le coût est qu'un catalogue volumineux ou des résultats d'outils détaillés peuvent occuper un contexte significatif si un client les charge avec impatience. Les clients peuvent atténuer ce problème grâce à la sélection de serveur, à la recherche, aux groupes d'outils, aux fichiers de résultats, aux instantanés limités et aux sorties concises.

Un CLI n'élimine pas le contexte. L'agent a toujours besoin de noms de commandes, d'indicateurs, d'exemples et de résultats renvoyés. Une compétence bien conçue peut charger uniquement la recette de commande appropriée et demander au CLI un JSON compact ou un fichier de résultats. Un CLI mal conçu peut vider des mégaoctets ou forcer des appels d'aide répétés. Comparez les octets et le contenu visible par le modèle de l'itinéraire réel, et non des slogans tels que « zéro jeton CLI ».

Quelle interface est la plus sûre ?

Aucune des deux interfaces n'est intrinsèquement sûre. MCP peut décrire un outil comme étant en lecture seule ou destructeur, mais la spécification avertit les clients de ne pas faire confiance aux annotations d'un serveur non fiable. L'hôte a toujours besoin de la confiance du serveur, du consentement de l'utilisateur, de l'authentification, des restrictions de cible, des délais d'attente, de la journalisation et d'un moyen de révoquer les informations d'identification.

Un CLI peut être fortement confiné avec une liste blanche d'exécutables étroite, un répertoire de travail fixe, un environnement nettoyé, un utilisateur non-administrateur, un bac à sable du système de fichiers et une validation des arguments. Cela peut également devenir dangereux si un agent reçoit un shell général contenant des secrets, une substitution de commandes, un accès étendu aux fichiers ou des informations d'identification de production. Évitez de placer des secrets directement dans des invites ou des arguments de commande où les journaux de processus et de transcription peuvent les conserver.

Les extensions de navigateur ajoutent leur propre limite. Examinez les autorisations demandées, les modèles d'hôte, la portée du script de contenu, la provenance des mises à jour, les ponts de messagerie natifs et si l'utilisateur peut voir et interrompre les actions. « S'exécute dans mon navigateur » ne constitue ni une preuve de sécurité ni une preuve de risque ; le graphique d’autorisation et de flux de données décide.

Dans quelle mesure chaque approche est-elle portable ?

MCP peut conserver un contrat client stable pendant que le serveur s'exécute en tant que processus ou service local, mais l'authentification, les transports, les chemins du système de fichiers et l'installation du serveur varient toujours selon l'hôte. Les outils CLI fonctionnent bien là où les systèmes d'exploitation, les environnements d'exécution, les binaires et les shells cibles sont compatibles. Les scripts doivent tenir compte des guillemets, des séparateurs de chemin, de la disponibilité du navigateur et de l'épinglage de version.

Les extensions sont liées à l'extension API d'un navigateur, au modèle d'autorisation, à la distribution de magasin ou d'entreprise et au profil utilisateur. Ils sont utiles précisément parce qu'ils vivent à proximité d'un vrai navigateur, mais cela les rend moins portables vers des serveurs sans tête ou des tâches sans navigateur.

Que s'est-il passé lors de notre test de même tâche ?

Les deux routes ont ouvert une page détenue, rempli un champ, attendu des produits en retard, trouvé des contrôles en double, survécu à un remplacement de DOM, observé un HTTP 503 intentionnel et une requête réussie, et fermé le navigateur. Chaque itinéraire utilisait neuf appels ou commandes de tâches, répétés trois fois.

Le résultat de l'heure du mur pointe dans la direction opposée au résultat de l'octet, car le faisceau CLI a intentionnellement lancé neuf processus npx distincts et s'est rattaché à une session nommée. Un wrapper persistant ou une commande par lots peut modifier ce résultat. La conclusion défendable est plus étroite : dans cette configuration, MCP a exposé une découverte plus riche et a renvoyé plus de texte ; CLI a renvoyé une sortie concise mais a déplacé la découverte en dehors des appels de tâche.

Quand devez-vous utiliser MCP, CLI ou les deux ?

Préférez MCP pour une fonctionnalité côté hôte qui doit être détectable, saisie, consentie et échangeable entre les clients. Préférez CLI pour les opérations locales déterministes, les outils d'ingénierie existants, les étapes de construction, le travail sur le référentiel ou les commandes dont les contrats de fichier et de code de sortie sont déjà solides.

Utilisez les deux lorsque la limite le mérite. Un serveur MCP gouverné peut exposer une action commerciale précise tandis que l'agent de codage utilise les commandes CLI pour la validation locale. Un CLI peut gérer l'installation et les diagnostics du serveur tandis que la tâche active utilise les outils MCP. Évitez d’exposer la même action à haut risque via plusieurs voies non contrôlées, à moins que les comportements d’autorisation et d’audit ne soient véritablement équivalents.

Ajoutez une extension de navigateur uniquement lorsque la tâche nécessite un onglet existant, un état visible par l'utilisateur ou des API réservés au navigateur. Préférez un profil d’automatisation propre ou un protocole direct lorsqu’un profil personnel n’est pas nécessaire.

Que sont ego (lite) et le Skill ego-browser ?

Il faut distinguer le produit de son interface de contrôle. ego (lite) est un navigateur Chromium local et complet destiné aux personnes et aux agents IA ; sa catégorie de produit est celle des navigateurs pour agents IA. Ce n’est ni un agent IA, ni une extension de navigateur, ni un serveur MCP, ni un navigateur cloud. Un agent compatible utilise ego-browser — le Skill et l’interface de contrôle — pour travailler dans un Space dédié, visible par l’utilisateur et doté de ses propres onglets. L’utilisateur peut suivre le travail, le mettre en pause ou reprendre la main. Même si le Skill est lancé depuis un point d’entrée du shell et exécute du JavaScript, il ne s’agit pas d’un flux CLI exécutant les commandes une par une.

L’agent écrit un programme JavaScript, puis démarre l’environnement d’exécution du Skill depuis son point d’entrée shell. Le programme s’exécute dans Node.js, tandis que les opérations du navigateur passent par le contrôleur local et la connexion CDP intégrée d’ego (lite). Le workflow peut naviguer, attendre, inspecter, cliquer et extraire en une seule exécution, puis ne renvoyer au modèle que le résultat sélectionné.

ego-browser nodejs <<'EOF'
const task = await taskSpace("review dashboard");
const page = task.page("p1");
await page.goto("https://app.example.com/reports");
const title = await page.title();
console.log({ title });
await task.finish({ keep: [] });
EOF

Il s’agit d’une troisième voie valide, car la comparaison utile porte sur le modèle d’exécution et non sur le nom de l’exécutable. MCP expose des outils structurés et découvrables et renvoie généralement un résultat après chaque appel. Une CLI commande par commande expose des opérations shell individuelles. Le Skill ego-browser exécute plutôt, hors du contexte du modèle, un workflow JavaScript en plusieurs étapes dans un Space dédié et visible. Le shell lance le Skill ; il ne le transforme pas en CLI.

Pour comprendre plus en détail pourquoi le regroupement des actions JavaScript modifie le coût du contexte et les allers-retours du modèle, consultez notre analyse technique de la voie hors contexte.

Lors de notre exécution contrôlée du 11 septembre 2026, ego-browser 0.5.0.31 a repris un Space ego (lite), attendu des données de test retardées, identifié deux contrôles Beta en double et ouvert un onglet de résultat vérifié séparément.

Choisissez cette voie lorsqu’un agent a besoin d’un Space de navigateur visible et autorisé par l’utilisateur, qu’un JavaScript en plusieurs étapes doit s’exécuter hors de la boucle du modèle et que la reprise en main humaine compte. Choisissez MCP si l’hôte requiert une découverte standardisée des outils et des appels gouvernés ; choisissez CLI si le travail correspond déjà à des commandes, fichiers, pipes et codes de sortie stables. Préférez une API, une requête HTTP ordinaire, un navigateur de test jetable ou une suite Playwright déterministe s’ils résolvent la tâche avec une surface de confiance plus réduite.

Comment valider le choix ?

1. Gelez une tâche représentative, des versions, un hôte, des informations d'identification et des conditions d'arrêt.
2. Compter le schéma visible par le modèle et le contenu du résultat avec un dénominateur déclaré ; n'estimez pas les jetons à partir du nombre de personnages.
3. Enregistrez les échecs d'appel, les mauvais choix d'outils, les demandes d'autorisation, les chemins d'exposition secrets et les travaux de récupération.
4. Répétez dans un ordre alterné et conservez les échecs au lieu d'en faire la moyenne.
5. Testez la limite de déploiement réelle : local, distant, conteneur, extension de navigateur ou profil existant.
6. Choisissez l'itinéraire le plus simple qui répond aux exigences de découverte, de sécurité, de portabilité, d'observabilité et de maintenance.

Quelles sources officielles définissent les couches ?

Utiliser le MCP actuelspécification d'architectureetspécification des outilspour les revendications de protocole. Les implémentations testées sont documentées dans le document officielPlaywright MCPetPlaywright CLI Dépôts.

Traitez l'accès au navigateur comme une surface d'autorisation distincte ; Chrome documente son modèle dansDéclarer les autorisations. L'exemple ego-browser a été comparé à l'exemple actuelDémarrage rapide ego (lite)le 11 septembre 2026.

FAQ

MCP utilise-t-il plus de jetons que CLI ?

C'est possible lorsqu'un client charge des schémas d'outils volumineux ou des résultats détaillés, mais il n'y a pas de pourcentage universel. L'aide et la sortie CLI consomment également du contexte. Mesurez le client, le serveur, les compétences et la tâche réels avec une télémétrie réelle.

Un CLI peut-il être un serveur MCP ?

Oui. Un serveur MCP peut valider un appel structuré et appeler un CLI existant en dessous. Le wrapper doit préserver la sémantique des erreurs, restreindre les arguments et éviter de dupliquer un shell général dangereux.

Une extension de navigateur est-elle plus sûre que MCP ?

Pas par catégorie. Comparez les autorisations exactes des extensions, la politique de l'hôte, les informations d'identification, le chemin de mise à jour, la visibilité des utilisateurs et la révocation. MCP décrit l'appel ; une extension décrit l'accès côté navigateur.