Je réfléchis beaucoup à la façon dont les agents de code interagissent avec les services externes. Chez Arcade.dev, on construit des outils agentiques, donc je passe la plupart de mes journées à regarder des agents IA tenter de faire des choses concrètes dans le monde réel. Et un schéma me revient sans cesse.
Nous construisons des intégrations de plus en plus complexes pour connecter les agents de code aux serveurs MCP. SDKs personnalisés, connexions persistantes, configurations client élaborées. Mais voilà le truc : ces agents savent déjà utiliser le CLI. Ils ont été entraînés sur des millions de sessions shell. curl, git, docker, npm. Ils connaissent les patterns. Flags, stdin, stdout, pipes, codes de sortie : tout ça est gravé en eux.
Alors pourquoi leur apprendre une nouvelle interface ?
Pourquoi pas simplement utiliser des APIs ?
Je sais ce que certains d’entre vous pensent. « Pourquoi ne pas ignorer MCP complètement et donner à l’agent un accès API brut ? »
J’ai regardé des agents essayer. Ça casse de façon prévisible.
Les APIs sont conçues pour des développeurs qui lisent la documentation, comprennent les flux d’authentification et savent quels endpoints appeler dans quel ordre. Un agent face à une API REST brute doit résoudre : parmi ces 200 endpoints, lesquels me faut-il vraiment ? Quel est le schéma d’auth ? Quels headers sont obligatoires ? Comment paginer ? Que signifie le code d’erreur 422 dans le contexte de cette API précise ?
C’est énormément de travail d’inférence avant qu’une seule action utile se produise, et chaque étape brûle des tokens et introduit des points de défaillance.
MCP règle ça au niveau protocolaire. Il offre une façon standard d’annoncer des capacités, décrire des schémas, gérer l’authentification et piloter le cycle de vie des appels d’outils. Un outil MCP n’expose pas « voici 200 endpoints, bonne chance ». Il expose « voici les 12 choses que vous pouvez faire, voici exactement ce que chacune attend, et voici comment s’authentifier ». L’agent dépense ses tokens sur la tâche, pas sur la plomberie.
Personne n’a écrit de posts pour déclarer « REST est mort, utilisez juste curl. » curl, c’est comment on parle à REST depuis un terminal. mcpx, c’est comment on parle à MCP depuis un terminal. Même relation. Le protocole compte toujours. C’est l’interface qui a changé.
Le meilleur des deux mondes
Et si l’interface de l’agent vers MCP était simplement… le CLI ?
C’est l’idée derrière mcpx. C’est un outil en ligne de commande qui parle MCP sous le capot, mais présente une interface shell en surface. Pensez à curl : vous n’avez pas besoin de comprendre HTTP/2 ou les handshakes TLS pour faire un appel API. Vous tapez une commande et vous obtenez une réponse.
Le workflow pour un agent ressemble à ceci :
bash
# 1. Search for relevant tools across all configured MCP servers
mcpx search "create issue"
# 2. Inspect a specific tool's schema
mcpx info linear create_issue
# 3. Execute it
mcpx exec linear create_issue '{"title": "Fix the login bug", "priority": "high"}'Pas de connexions persistantes à gérer. Pas de schémas d’outils qui gonflent le prompt système. L’agent découvre ce dont il a besoin à la demande, valide les entrées localement avant d’envoyer, et reçoit une sortie structurée qu’il peut parser.
Quand utiliser le CLI, quand utiliser le remote
Je veux être honnête sur là où mcpx s’inscrit et là où ce n’est pas sa place. C’est important, et je ne pense pas que le débat actuel soit assez précis sur ce point.
Le CLI (mcpx) est conçu pour les agents de code mono-utilisateur, mono-machine.
Vous êtes développeur. Vous utilisez Claude Code, Cursor, Windsurf ou Cline. Vous voulez que votre agent de code interagisse avec GitHub, Linear, Slack, votre base de données, sans configurer un client MCP personnalisé pour chaque outil. La moitié des clients MCP n’ont pas encore construit d’intégrations solides, ou rattrapent encore leur retard sur les flux d’auth, ou leur support MCP est « techniquement fonctionnel » mais pas production-ready. mcpx contourne tout ça. Un seul CLI, une seule installation, tous les serveurs MCP dont votre agent a besoin.
C’est le sweet spot : un développeur, son agent, sa machine.
Le MCP remote (HTTP) est conçu pour les applications agentiques multi-utilisateurs.
Si vous construisez quelque chose avec LangChain, CrewAI ou n’importe quel framework où plusieurs utilisateurs déclenchent des agents qui agissent en leur nom, vous avez besoin du flux MCP remote complet. Isolation multi-utilisateurs, délégation OAuth par utilisateur, permissions scopées par tenant, pistes d’audit centralisées. Le CLI n’est pas la bonne interface pour ça. Une connexion MCP HTTP via une gateway, si.
Ce ne sont pas des approches concurrentes. Ce sont des interfaces différentes vers la même infrastructure :
Même gateway. Mêmes outils. Même auth. Même piste d’audit. Seule la façon de se connecter change. mcpx, c’est la colonne de gauche. Si vous avez besoin de la colonne de droite, il vous faut un MCP remote, et c’est le bon choix.
Je construis mcpx parce que la colonne de gauche manquait d’outillage sérieux. Pas parce que la colonne de droite ne compte pas.
Pourquoi ça compte pour l’efficacité des tokens
Il y a une raison pratique pour laquelle cette approche fonctionne bien pour les agents de code en particulier : les tokens coûtent cher, et les fenêtres de contexte sont finies.
L’intégration MCP classique charge le schéma de chaque outil disponible dans le prompt système de l’agent. Avec 50 outils répartis sur 5 serveurs, une bonne partie de la fenêtre de contexte est engloutie par des schémas que l’agent n’utilisera peut-être jamais. Avec mcpx, l’agent démarre avec zéro outil en contexte et découvre progressivement ce dont il a besoin. D’abord chercher, ensuite inspecter, enfin exécuter. Vous ne payez que ce que vous utilisez vraiment.
Et comme chaque appel est éphémère (on spawne le processus, on récupère le résultat, c’est fini), il n’y a aucun état de connexion à gérer entre les tours. Le contexte de l’agent reste propre.
Un bon outillage, ça change tout
Si on demande aux agents d’utiliser le CLI pour MCP, l’outillage doit être bon. Pas « techniquement fonctionnel » bon, vraiment bon. Comme curl l’est pour HTTP, ou jq pour JSON.
Concrètement :
Sortie intelligente - tableaux lisibles dans un terminal, JSON quand vous le pipez vers un autre outil. Détection automatique, aucun flag nécessaire.
Débogage réel - mcpx -v affiche les en-têtes HTTP, les messages JSON-RPC et les temps aller-retour. Quand quelque chose casse, vous voyez exactement ce qui s’est passé. Voici à quoi ça ressemble face à une gateway de production comme celle d’Arcade :
mcpx -v exec arcade Gmail_WhoAmI
> POST https://api.arcade.dev/mcp/evan-coding
> authorization: Bearer eyJhbGci...
> content-type: application/json
< 200 OK (142ms)
< x-request-id: abc123Cet en-tête d’autorisation n’est pas une clé API partagée qui traîne dans un fichier .env. C’est un token OAuth à portée limitée - la Gateway a géré le flux d’auth, appliqué les permissions et journalisé l’appel. J’ai juste tapé une commande.
Une recherche qui fonctionne - la correspondance par mots-clés convient quand vous savez ce que vous cherchez. Mais les agents, souvent, ne le savent pas. mcpx intègre une recherche sémantique avec un modèle d’embeddings local (sans clé API, sans appel réseau) pour que les agents trouvent des outils en décrivant ce qu’ils veulent accomplir.
Support complet du protocole - OAuth pour les serveurs distants, tâches asynchrones pour les opérations longues, saisie demandée par le serveur (elicitation), journalisation structurée. La spec MCP évolue vite, et votre client CLI doit suivre.
Les clients à jour comptent aussi
C’est le point qui ne reçoit pas assez d’attention. MCP est un protocole jeune, et la spec évolue rapidement. Les tâches, l’elicitation, la journalisation structurée - tout cela est relativement récent, et ça compte vraiment en production.
mcpx suit le dernier SDK MCP et implémente la spec complète : transports stdio et HTTP (avec fallback automatique Streamable HTTP → SSE), découverte OAuth et renouvellement de token, validation JSON Schema, gestion des tâches avec annulation, et flux de saisie demandée par le serveur. Quand la spec ajoute quelque chose, le CLI doit le supporter - sinon les agents n’ont qu’une vue partielle de ce que MCP peut faire.
Essayez-le
mcpx est open source (MIT) et disponible en binaire unique ou via npm :
bash
# Install
bun install -g @evantahler/mcpx
# or
curl -fsSL https://raw.githubusercontent.com/evantahler/mcpx/main/install.sh | bash
# Configure a server
mcpx add github --url https://mcp.github.com
# Start exploring
mcpx search "pull request"Si vous utilisez Claude Code ou Cursor, mcpx embarque des compétences d’agent intégrées :
bash
mcpx skill install --claude # Claude Code
mcpx skill install --cursor # CursorUne seule commande, et votre agent de code sait comment découvrir et utiliser les outils MCP à la demande, sans gonflement de schéma, sans connexions persistantes.
J’utilise mcpx avec la gateway d’Arcade au quotidien - c’est comme ça que j’accède aux outils GitHub, Slack, Google Workspace, Linear et tout un tas d’autres services sans configurer chacun individuellement. La gateway gère OAuth et la journalisation d’audit, je n’ai pas à y penser.
bash
mcpx add arcade --url https://api.arcade.dev/mcp/engineering-tools
mcpx search "send email"Si vous construisez avec des serveurs MCP ou que vous en construisez, tentez le coup. Le gain de vitesse d’itération a été significatif pour moi.
Obtenir mcpx sur GitHub → Licence MIT. Ouvrez une issue si quelque chose casse, une PR si vous voulez corriger.
Evan Tahler est Responsable de l’ingénierie chez Arcade, le seul runtime pour MCP. Il a construit mcpx parce que quelque chose devait exister et n’existait pas.
