La semaine dernière, Charles Chen a publié « MCP is Dead; Long Live MCP! », où il soutient qu'une grande partie des critiques contre le Model Context Protocol (MCP) vise la mauvaise cible et brouille souvent la frontière entre les cas où MCP est démesuré et ceux où il résout de véritables problèmes.
Pour de nombreux workflows locaux et mono-utilisateur, l'argument est juste. Si vous développez sur votre propre machine, avec un petit ensemble d'outils, et que vous maîtrisez entièrement l'environnement, MCP peut ajouter une structure dont vous n'avez pas besoin.
Mais le problème est différent à l'échelle de l'entreprise. Vous ne cherchez pas seulement à aider un modèle à appeler un outil sur un ordinateur portable. Vous cherchez à déployer l'IA de manière sûre et cohérente dans toute une organisation. Lorsque vous prenez du recul sur ce qu'il faut pour exploiter l'IA comme un service gouverné et observable pour des milliers de personnes, c'est là que MCP commence à compter.
La vraie question n'est pas de savoir si MCP est mort ou non. C'est : quand MCP ajoute-t-il une complexité inutile, et quand accomplit-il un véritable travail pour vous ?
Ce que l'article a raison de souligner
Le billet de Charles a raison sur plusieurs points, en particulier pour les développeurs individuels :
Pour les développeurs en solo, les CLI sont souvent le meilleur outil. Si le modèle « connaît » déjà des outils comme curl, jq, git, psql ou aws grâce au préentraînement, vous n'avez pas besoin de schémas ou de documentation supplémentaires pour en tirer de la valeur. Dans de nombreux cas, le modèle peut utiliser ces outils directement, ce qui est moins coûteux en tokens et plus simple à configurer.
Encapsuler chaque endpoint REST dans MCP est démesuré. Si vous ne faites qu'appeler quelques API sur mesure depuis votre propre agent, des wrappers faits maison ou de petits CLI peuvent très bien convenir. MCP ne rend pas automatiquement ces appels meilleurs.
MCP via stdio est généralement la mauvaise abstraction pour les outils locaux. Pour un agent local et un outil local, un MCP basé sur stdio ne fait qu'ajouter de la structure sans apporter beaucoup de valeur. Un CLI léger peut être l'option la plus directe.
Le battage autour du « MCP pour tout » était bien réel. Pendant un temps, MCP a été traité comme la réponse à tous les problèmes d'intégration, sans qu'on sache clairement quand il est réellement pertinent par rapport aux cas où il ne fait qu'ajouter une complexité inutile.
Si tout ce que vous faites se limite à exécuter un seul agent sur votre propre machine, en dialoguant avec quelques API que vous contrôlez, il est difficile de contredire ces critiques.
Mais ce n'est pas ce que la plupart des entreprises cherchent à faire.
La distinction qui compte vraiment
L'article d'origine met en lumière deux distinctions qui comptent beaucoup, surtout du point de vue de l'entreprise :
- Le stdio local vs. le MCP HTTP distant
- L'ordinateur portable d'un seul utilisateur vs. l'ensemble du parc IA d'une entreprise
Sur votre ordinateur portable, vous contrôlez tout :
- Vous détenez les clés d'API.
- Vous êtes le seul utilisateur.
- Vous êtes à l'aise pour déboguer directement les problèmes afin de comprendre ce qui a mal tourné.
- Vous n'avez pas besoin d'un modèle de permissions ni d'un journal d'audit pour savoir qui a exécuté quoi.
À l'échelle de l'entreprise, les questions changent :
- Qui est autorisé à appeler quel outil, pour le compte de qui, et sous quelle identité ?
- Comment rendre les mêmes capacités disponibles sur plusieurs surfaces d'IA, comme les IDE, les chatbots, les agents, sans reconstruire les intégrations à chaque fois ?
- Comment voir quels outils sont réellement utilisés, lesquels échouent, et où les agents se retrouvent bloqués ?
- Comment maintenir à jour les prompts, les skills et la documentation sur toutes ces surfaces ?
Ce ne sont pas des questions de conception de CLI. Ce sont des questions de plateforme.
C'est là que les serveurs MCP distants cessent de ressembler à de simples « wrappers d'API » et commencent à ressembler à une infrastructure partagée : une couche commune pour les outils, l'identité, les politiques et la distribution à l'échelle de l'entreprise.
Si vous souhaitez un aperçu plus approfondi de la façon dont nous avons mis en œuvre cette infrastructure dans la pratique, nous entrons davantage dans les détails dans notre billet « Les serveurs MCP de Glean apportent le contexte complet de l'entreprise là où votre IA s'exécute ».
Ce dont les entreprises ont réellement besoin de cette couche
Si l'on met de côté les détails de protocole pour se concentrer sur les résultats, la plupart des entreprises attendent les quatre mêmes choses de leur couche « IA vers outils » :
1. Authentification et gestion des secrets centralisées, par utilisateur
Dans une entreprise de 10 000 personnes utilisant cinq outils d'IA, « il suffit de donner une clé d'API à l'agent » ne passe pas à l'échelle. Vous ne voulez pas que chaque développeur (ou chaque hôte d'agent) détienne des clés d'API à longue durée de vie pour Jira, Salesforce, Slack et les services internes. Vous voulez :
- Une seule connexion (OAuth ou SSO) à la « passerelle d'outils » de l'entreprise.
- Des tokens à courte durée de vie émis par utilisateur.
- La capacité de révoquer l'accès de manière centralisée lorsqu'une personne part ou change de rôle.
Un serveur MCP distant s'inscrit naturellement dans ce rôle : le serveur détient les secrets ; les utilisateurs et les hôtes s'authentifient auprès du serveur ; le serveur répartit les appels vers les API sous-jacentes.
Du point de vue de Glean, c'est précisément pour cela que nous avons associé les serveurs MCP distants à une authentification OAuth centralisée et à Glean Protect, afin que les clients puissent activer et désactiver les outils en un seul endroit et faire appliquer les permissions de bout en bout.
2. Télémétrie et observabilité à l'échelle de l'organisation
Lorsque vous avez de nombreuses équipes, hôtes et outils, vous devez répondre à des questions comme :
- Quels outils font réellement bouger les lignes ?
- Quels outils échouent ou expirent ?
- Quelles équipes sur- ou sous-utilisent certaines actions ?
Avec un serveur centralisé, vous pouvez émettre des traces et des métriques standard, comme OpenTelemetry, et obtenir une vue unique et cohérente de la façon dont les outils sont utilisés dans toute l'organisation. Cette vue devient encore plus importante à mesure que les agents commencent à entreprendre des actions autonomes au-dessus de votre index et de votre graphe de connaissances, et pas seulement à répondre à des questions.
3. Prompts/skills et documentation standardisés sur toutes les surfaces
L'article d'origine fait une observation importante : les prompts MCP sont essentiellement des skills délivrés par le serveur, et les ressources MCP sont des documents délivrés par le serveur. Cela vous donne un moyen de :
- Publier un seul skill de « revue de code » ou de « triage d'incidents » et le faire apparaître de manière cohérente dans de nombreux outils.
- Garder la documentation synchronisée entre les équipes et les dépôts, sans copier du Markdown dans chaque projet.
- Injecter un contexte dynamique, comme le dernier statut, les tarifs ou les mises à jour de politiques, dans les prompts et les documents au moment de la requête.
C'est la même idée qui sous-tend les skills Glean. C'est une façon de conditionner l'expertise en skills réutilisables que les agents peuvent invoquer partout où ils s'exécutent. MCP vous offre une couche de transport neutre pour ces skills et ces documents, afin qu'ils ne restent pas enfermés dans une seule application.
4. Une seule surface d'intégration pour de nombreux hôtes
Les entreprises modernes ne vivent pas dans une seule interface. Elles disposent de :
- IDE comme Cursor, VS Code, Windsurf
- Applications de chat IA comme Claude, ChatGPT
- Les assistants internes et les créateurs d'agents
- Les outils verticaux avec agents intégrés
Sans protocole, chaque association devient une intégration sur mesure. Avec MCP, vous vous rapprochez du principe « intégrer une fois, utiliser partout » : définissez vos outils à un seul endroit, connectez-les à de nombreux hôtes et gardez votre Graphe d'entreprise et votre logique de politique derrière une seule surface.
Il ne s'agit pas d'économiser quelques tokens dans votre fenêtre de contexte. Il s'agit d'exploiter l'IA comme une plateforme gouvernée et observable.
Quand vous n'avez probablement pas besoin de MCP
Il vaut la peine d'être explicite sur les cas où nous ne privilégierions pas MCP en premier :
- Vous construisez un seul workflow personnel entre un LLM et une ou deux API que vous possédez.
- Toute la logique réside sur votre ordinateur portable ou dans un seul service que vous contrôlez de bout en bout.
- Vous n'avez pas besoin d'authentification partagée, de télémétrie ni de séparation multi-tenant.
- Vous êtes satisfait de documenter l'usage dans un README ou un AGENTS.md et d'en rester là.
Dans ces situations, un CLI ou un wrapper SDK minimal est souvent exactement ce qu'il faut. Vous obtenez une itération plus rapide avec moins de surcharge, et vous pouvez toujours « monter » vers MCP plus tard si vos workflows le nécessitent.
Quand MCP apporte une réelle valeur
À l'inverse, MCP commence à faire ses preuves dans des schémas comme ceux-ci :
N'importe quel hôte, les mêmes outils.
Vous voulez que Cursor, Claude, ChatGPT et votre assistant interne puissent tous :
- Rechercher dans le même graphe d'entreprise.
- Utiliser les mêmes outils pour créer un ticket ou mettre à jour un enregistrement.
- Respecter les mêmes autorisations et règles d'audit.
Un serveur MCP partagé vous offre un seul endroit pour définir ces outils et un seul endroit pour appliquer les politiques, tandis que chaque hôte parle simplement le même protocole.
Des outils approuvés par l'administration et conviviaux.
La sécurité et l'IT veulent :
- Approuver quels serveurs et outils MCP sont visibles.
- Configurer OAuth, les URI de redirection et les listes d'autorisation d'hôtes.
- Visualiser l'usage et les erreurs sans avoir à tracer les problèmes à travers des systèmes déconnectés et des scripts personnalisés.
C'est beaucoup plus simple lorsque vous disposez d'un concept de première classe de serveurs et outils MCP dans une console d'administration, soutenu par une couche serveur centrale, plutôt qu'une multitude de CLI et de scripts ponctuels.
Des compétences et une documentation à l'échelle de l'entreprise.
Vous voulez :
- Que les SRE, les PM et les ingénieurs voient les mêmes runbooks d'incidents et invites de triage, quelle que soit la surface d'agent qu'ils utilisent.
- Que ces invites et documents restent à jour, y compris le contexte dynamique comme le statut actuel ou les informations de version).
- Une visibilité sur les compétences et documents réellement utilisés.
Les invites et ressources MCP, livrées depuis un serveur central, sont conçues pour faire exactement cela.
Des agents qui survivent à un seul environnement.
Dès que vous voulez des agents qui :
- S'exécutent dans CI/CD ou GitHub Actions
- Se déclenchent à partir de systèmes de ticketing ou d'alertes
- Apparaissent dans des applications SaaS que vous ne contrôlez pas
…vous êtes par définition en territoire distant, multi-tenant, audité et à permissions. C'est là que MCP sur HTTP, avec l'authentification et la journalisation appropriées, commence à ressembler beaucoup moins à une surcharge et beaucoup plus à la bonne approche.
Nous avons observé un schéma similaire avec l'indexation face à la recherche fédérée : des protocoles comme MCP et les connecteurs fédérés sont parfaits pour l'interopérabilité, mais le véritable levier se produit lorsqu'ils reposent sur un index et un graphe de connaissances solides, capables de réellement fournir un contexte pertinent et tenant compte des permissions à ces agents.
Dépasser le cycle du battage médiatique
Charles a raison de pointer du doigt le cycle de battage médiatique autour de MCP, porté par les influenceurs. Il y a six mois, on avait l'impression que tout le monde voulait se positionner comme « compatible MCP ». Aujourd'hui, le pendule est reparti dans l'autre sens, et la conversation se concentre souvent sur la raison pour laquelle un CLI est plus simple.
Sous ce changement, l'histoire architecturale est assez simple. Sur une seule machine, les CLI directs et les wrappers ad hoc sont souvent l'outil le plus pragmatique.
À l'échelle de l'entreprise, les équipes finissent par avoir besoin :
- D'un contrat standard entre les hôtes IA et les outils
- D'un endroit central pour gérer l'authentification, la télémétrie et les politiques
- D'un moyen partagé de fournir des compétences et une documentation sur de nombreuses surfaces
MCP n'est pas le seul moyen d'y parvenir. Une entreprise pourrait construire son propre protocole, mettre en place une passerelle personnalisée et y connecter chaque hôte. Mais si l'écosystème converge déjà vers une norme ouverte qui fournit une grande partie de ces fondations clés en main, il est légitime de se demander s'il s'agit d'une infrastructure que vous souhaitez construire et maintenir vous-même.
Chez Glean, nous pensons que les protocoles ouverts et une indexation solide sont complémentaires, et non concurrents :
- Notre Graphe d'entreprise et notre pile d'indexation font le gros du travail d'unification, de structuration et de classement des données d'entreprise.
- Les normes ouvertes comme MCP, les compétences et les frameworks d'agents aident ce contexte à atteindre les agents et les hôtes que nos clients utilisent réellement.
Alors non, nous ne pensons pas que MCP soit « mort ».
MCP sur un seul ordinateur portable a probablement été survendu. Mais MCP en tant que couche centrale pour l'IA d'entreprise ne fait que commencer.
