Cette année, nous avons vu le Model Context Protocol (MCP) gagner en adoption en tant que protocole ouvert pour connecter des outils à l’IA, permettant aux utilisateurs de lire des données et de passer à l’action. Si MCP a ouvert la voie à la connectivité, le faire fonctionner réellement en entreprise reste un défi pour la plupart des équipes. MCP seul ne peut pas fournir un contexte efficace, mettre à l’échelle les outils en toute sécurité et observer comment ces outils sont utilisés.
Aujourd’hui, Glean aide les entreprises à combler le fossé de mise en œuvre en introduisant le MCP Gateway, qui offre :
- Du contexte pour l’IA au travail : la qualité des outils n’est pas la même partout. Glean fournit des index et des graphes de connaissances afin que les entreprises disposent d’un contexte cohérent et fiable, utilisable partout.
- Un accès sécurisé aux données et aux outils : connectez-vous de manière sécurisée à des données et des outils avec permissions appliquées, avec des contrôles d’accès granulaires et des protections contre l’injection de prompts et le code malveillant, qui contribuent à protéger votre entreprise sur l’ensemble des surfaces.
- Déploiement, administration et visibilité centralisés : administration centralisée avec des serveurs MCP distants, possibilité de déployer auprès de tous les employés via MDM, et tableaux de bord pour rester informé de l’utilisation.
De meilleurs outils commencent par un meilleur contexte
MCP est un protocole, pas une couche de contexte. Lorsque vous interrogez via MCP, vous dépendez de la qualité des outils fournis par la communauté. La plupart des outils MCP prêts à l’emploi interrogent séparément les API Jira, Confluence, GitHub et Slack, chacun avec des approches de recherche différentes, une indexation incohérente et aucun classement centralisé.
Une approche MCP fédérée peut orienter un modèle vers la bonne API, mais l’agrégation des résultats entre sources se fait toujours par le modèle à l’exécution, ce qui oblige le modèle lui-même à lever les ambiguïtés, réconcilier et cartographier les relations entre systèmes. Cela consomme davantage de tokens, car les fondations de contexte adéquates ne sont pas en place.
À la place, le serveur MCP de Glean utilise un index pré-calculé et un graphe de connaissances pour effectuer ce travail en amont. Voyez cela comme une jointure pré-calculée sur l’ensemble des données de votre entreprise, plutôt que de résoudre cette jointure à l’exécution.
Cette approche fait une différence considérable en efficacité de tokens et en qualité de réponse. Plus tôt ce mois-ci, nous avons comparé Glean à des outils MCP prêts à l’emploi dans Claude Cowork sur ~175 requêtes d’entreprise, en gardant le harness et le modèle constants et en ne changeant que la couche de contexte. Le contexte d’entreprise de Glean a été préféré ~2,5x plus souvent, et les outils prêts à l’emploi ont utilisé en moyenne 30 % de tokens en plus.
Nous avons également observé comment cette même différence d’architecture se manifeste pour les workloads d’ingénierie au sein d’un AI-IDE. Voici un exemple, légèrement modifié pour retirer des données sensibles :
Owner : the agent-builder team owns the code path, and the library-revamp feature flag has a single named feature owner you can ping directly.
What's actually going on : the old two-tab layout (All / Active) only renders when the revamp flag is off. So if a customer still sees two tabs, the revamp flag is evaluating to false for that tenant.
What to check first, in order :
- Flag state for the tenant. The revamp flag went GA earlier this year, so most tenants should be on by default. Confirm the customer is on a recent enough release, and check whether a tenant-specific override is pinning the flag to false for their cohort.
- Customer-managed toggle. Admins on the customer side can flip this themselves. Worth asking whether they (or a previous admin) turned it off.
- Trigger gates. Even with the revamp on, the tabs only show under certain trigger entitlements and not on a narrow viewport, so rule those out.
- Cache. A correctly served flag with a stale browser bundle is a common false alarm. Have them hard-reload.
Who to ping : the feature owner first for "is this tenant supposed to be on the revamp ?", then the agent-builder team for code-side questions.
I don't have prior context on the agent library UI ownership in this repo, let me not guess.
A few concrete first checks :
- Find the component : grep for the tab layout to locate the file, then check the history for the most recent owner and any in-flight redesign.
- Check for a flag : this is usually flag-gated, so the customer may be on the off variant. Worth confirming before chasing a code bug.
- Customer and deployment : which customer, which deployment ? A stale deploy can also explain old UI.
Want me to dig in, find the component and current owner, or check whether this is a feature-flag rollout issue first ?
Glean MCP a répondu à la question. Il a nommé le responsable, identifié le flag exact derrière l’ancienne mise en page, expliqué pourquoi le client la voyait, et fourni une liste priorisée de vérifications à faire en premier, incluant l’override au niveau du tenant et le toggle côté client. La stack prête à l’emploi a reconnu la nature du problème mais s’est arrêtée là : elle a refusé de nommer un responsable, listé des prochaines étapes génériques, et demandé la permission de commencer à investiguer. Pour un ingénieur support en plein triage, une réponse clôt le ticket et l’autre relance le chronomètre.
Voilà la différence d’architecture : des index pré-calculés et des graphes de connaissances fournissent un contexte précis, inter-applications, que les outils MCP prêts à l’emploi ne peuvent pas reproduire à l’exécution.
Ici, « contexte » signifie aussi bien plus que la recherche. Le MCP Gateway expose l’ensemble de la surface d’outils de Glean. Cela inclut la recherche, les outils de lecture et d’écriture, les outils personnalisés, ainsi que tous les serveurs MCP tiers que vous apportez, tous accessibles via le Gateway. Cela permet à Glean de se connecter à plus de 2 000 outils, pour que tout votre contexte vive au même endroit.
Gouverné par défaut, sécurisé dès la conception
L’adoption de MCP en entreprise s’accélère, avec des serveurs qui s’exécutent sur de nombreux hôtes. Encadrer cette activité par une gouvernance centralisée permet aux équipes sécurité et IT d’appliquer les mêmes protections que celles qu’elles utilisent déjà partout ailleurs.
Glean MCP Gateway standardise l’utilisation de MCP dans toute l’organisation en fournissant un annuaire centralisé des serveurs distants que vos équipes peuvent utiliser, avec les mêmes protections que Glean applique déjà à tous les autres outils. Ainsi, l’ensemble de votre contexte est rendu disponible et sécurisé en un seul endroit.
Chaque appel MCP via le Gateway passe par les quatre contrôles suivants :
- Connecteurs avec application des autorisations. Les autorisations du système source sont héritées. Si un utilisateur ne peut pas voir un ticket Jira, il ne peut pas le lire via le Gateway. S’il ne peut pas écrire dans un enregistrement en aval, il ne peut pas non plus y écrire via le Gateway.
- Autorisation via votre IdP. OAuth passe par le serveur d’autorisation de Glean, l’authentification des utilisateurs étant déléguée à votre fournisseur d’identité existant. L’hôte ne détient qu’un token MCP provenant de Glean. Les tokens OAuth en aval restent côté serveur, de sorte qu’une session d’hôte compromise n’expose aucune information d’identification en aval. L’OAuth par source de données s’effectue lors du premier usage via un lien de connexion que le Gateway remet à l’hôte.
- Contrôles d’accès granulaires. Les administrateurs décident quelles équipes ont accès à quels outils et lesquels nécessitent une validation humaine, de sorte qu’une équipe puisse accéder aux outils d’écriture tandis qu’une autre ne le peut pas.
- Modèles de sécurité IA appliqués aux appels d’outils. Les outils invoqués via le Gateway sont vérifiés contre l’injection de prompt, le code malveillant et le contenu toxique, afin de garantir un fonctionnement sûr sur différentes surfaces.
Déploiement centralisé de MCP via MDM
Installer Glean MCP sur l’appareil d’un employé a toujours été simple. Le déployer sur un parc géré de milliers d’appareils, c’est là que les projets s’enlisent. Glean MCP Gateway rationalise cela en traitant MCP comme n’importe quelle autre application d’entreprise, le rendant déployable via votre Mobile Device Management (MDM) existant. Cela signifie :
- Glean MCP est automatiquement poussé sur chaque appareil géré, sans configuration par utilisateur.
- Les employés sont intégrés sans configuration manuelle.
- Les politiques de sécurité et d’appareil sont appliquées de manière centralisée, de la même façon que l’IT les applique pour toute autre application gérée.
- Les mises à jour automatiques sont activées par défaut, afin que les nouveaux hôtes pris en charge et les changements de configuration soient déployés sans que personne n’ait à réinstaller.
Ce qui arrive sur chaque appareil n’est que de la configuration. Le serveur MCP s’exécute côté Glean, et l’authentification se fait par utilisateur lors du premier appel via votre fournisseur d’identité.
Une adoption que vous pouvez voir
Bien que nous ayons toujours eu des journaux d’audit, nous les intégrons désormais dans un tableau de bord centralisé d’insights afin que vous puissiez analyser l’usage de MCP selon :
- Utilisateurs actifs, appels au serveur MCP, outils utilisés et moyenne d’appels par utilisateur, chacun avec des écarts période sur période.
- Utilisateurs actifs dans le temps (quotidien, hebdomadaire et mensuel) avec l’adoption comparée à l’usage global de Glean.
- Principales applications hôtes par utilisateurs actifs, pour voir où le trafic MCP est concentré.
- Un tableau Usage Breakdown qui pivote par utilisateur, application, outil MCP ou serveur MCP, avec des filtres multi-sélection et des ventilations au niveau des départements, faisant remonter les principaux outils par usage et leur attribution au serveur MCP.
Chaque métrique est également accessible via l’API Glean Insights. Les administrateurs peuvent voir l’usage de MCP dans un tableau de bord centralisé d’insights aux côtés du reste de leurs données d’adoption de Glean. C’est de la télémétrie d’adoption.
Disponible dès maintenant
Glean MCP Gateway vous permet d’accéder à un contexte d’entreprise complet, performant et économe en tokens sur les principaux hôtes MCP. Il facilite et sécurise le déploiement de MCP dans toute votre entreprise, et vous permet de le gérer via MDM comme n’importe quelle autre application, avec une sécurité intégrée et une observabilité centralisée via les tableaux de bord Insights.
Pour en savoir plus, demandez une démo de Glean dès aujourd’hui.
Auteurs : Aditya Kumar, David Hamilton, Harshi Murthy, Mohit Gupta, Roshan Dheram, Daniel Martinho
