WebMCP est une API de navigateur proposée qui découvre, décrit et exécute des outils structurés pour un agent IA pour le compte d'un utilisateur. Le site web déclare ce que fait une action et quelles entrées elle accepte ; l'agent appelle cet outil au lieu de deviner quel bouton ou quel champ cliquer. Cela peut rendre un formulaire, un parcours de réservation ou une tâche de diagnostic plus rapides et plus fiables, mais ce n'est pas un remplacement universel de l'automatisation du navigateur. la documentation WebMCP de Chrome
Le choix pratique est architectural. WebMCP est une coopération côté serveur : l'éditeur du site publie un contrat destiné aux agents. L'automatisation du navigateur est une observation côté client : un agent pilote l'interface qui existe déjà, y compris une session connectée et autorisée. Utilisez le premier lorsque vous maîtrisez le site et pouvez définir des outils sûrs ; utilisez le second lorsque vous devez composer avec le web d'aujourd'hui. les recommandations sur les outils sûrs
Qu'est-ce que WebMCP ?
WebMCP (Web Model Context Protocol) est une proposition d'API côté navigateur, portée par l'équipe Chrome et la communauté WebMCP. La documentation de Chrome le présente comme un moyen de construire et d'exposer des outils structurés pour les agents, tout en préservant l'application web visible et le contrôle de l'utilisateur. Un site peut publier un outil de recherche, de paiement, de sélection de dates, de support ou de diagnostic en amélioration progressive ; un humain peut continuer à utiliser la même page quand aucun agent n'est présent. l'annonce de l'origin trial de Chrome
Comment fonctionne WebMCP ?
Une page WebMCP enregistre des outils auprès du navigateur. Chaque outil possède un nom, une description, un schéma d'entrée et une implémentation qui s'exécute dans la page. L'API impérative utilise JavaScript pour des actions personnalisées ; l'API déclarative annote des formulaires HTML ordinaires. La documentation de Chrome souligne trois éléments qui comptent pour un agent : la découverte, les schémas JSON des entrées et des sorties, et l'état décrivant ce que la page courante sait faire.
Le résultat peut être un chemin d'action plus court. Au lieu de lire un DOM volumineux, de déduire qu'un bouton signifie submit_application et d'espérer qu'un sélecteur survive à une refonte, un agent peut appeler l'outil nommé avec des champs décrits par le schéma. L'action s'exécute toujours visiblement dans le site, ce qui permet à la page d'afficher sa progression et de demander une confirmation avant un achat ou toute autre opération qui modifie l'état.
Notre test de WebMCP en conditions réelles, étape par étape
Le 11 septembre 2026, nous avons mené un test guidé sur la démo officielle Hotel Chain de Chrome Labs, avec Google Chrome 152.0.7977.76 sous macOS et le WebMCP Model Context Tool Inspector 1.9.15. L'opérateur a utilisé des données client synthétiques, aucune clé d'API Gemini et aucun identifiant réel d'hôtel, de paiement ou de compte. Il s'agissait d'un parcours de comportement, pas d'un benchmark de vitesse ou de fiabilité.
- L'Inspector a découvert les outils et les schémas de la page. Nous avons appelé search_location pour Paris, le 18 septembre, trois nuits et un adulte ; la page a affiché deux établissements.
- Nous avons appelé filter_search_results avec breakfast. Le nombre de résultats visibles est passé de deux à un, ne laissant que Montmartre Suites.
- Nous avons ouvert cet hôtel, lancé le parcours de réservation et fourni l'identité synthétique Alex Chen. L'outil a préparé le formulaire mais n'a pas finalisé la réservation.
- La page s'est arrêtée sur Confirm Reservation. Ce n'est qu'après le clic de l'opérateur humain que la démo a affiché Reservation Confirmed.
Une limitation de l'outillage a également compté : l'action Copy trace de l'Inspector a renvoyé un tableau JSON vide après notre parcours manuel Execute Tool. Nous utilisons donc des captures d'écran et un relevé d'étapes structuré comme preuves de cette exécution, et nous ne généralisons pas ce résultat de trace aux autres modes de l'Inspector.
Ce que WebMCP apporte face à l'automatisation du navigateur
WebMCP et l'automatisation du navigateur répondent à des modes de défaillance différents. WebMCP lève l'ambiguïté lorsque le site publie un bon contrat. L'automatisation classique, qu'il s'agisse de Playwright, Selenium, browser-use ou d'un agent pilotant un vrai navigateur, traite les sites qui ne publient aucun contrat en lisant la page rendue et en interagissant avec elle. WebMCP complète donc l'automatisation : un client peut appeler un outil de page lorsqu'il existe et revenir à une navigation ordinaire lorsqu'il n'existe pas.
La distinction s'audite plus facilement comme une frontière de capacités. Lisez la colonne positive comme la colonne négative avant de choisir une voie.
| Approche | Ce qu'elle peut faire | Ce qu'elle ne peut pas faire |
|---|---|---|
| WebMCP | Appeler des outils nommés et décrits par un schéma, exposés par une page | Atteindre des pages qui n'enregistrent pas d'outils ni n'importent une connexion distincte du navigateur |
| Automatisation fondée sur le DOM | Piloter presque toute page rendue avec des sélecteurs, des captures d'écran ou l'état d'accessibilité | Connaître l'action prévue du site sans interpréter l'interface |
| Réutilisation d'une session de navigateur réel | Utiliser un état de navigateur connecté, autorisé et explicitement provisionné | Garantir l'accès, contourner un CAPTCHA ou s'affranchir des règles du site |
Un déploiement concret commence par un outil en lecture seule, un navigateur pris en charge et une étape de confirmation visible. N'élargissez qu'une fois la voie de repli fonctionnelle.
La frontière de session compte tout autant. WebMCP s'exécute dans la page visitée par le client ; il ne transfère pas les cookies Chrome d'un utilisateur vers une nouvelle session cloud. Sur un site dépourvu de WebMCP, ego (lite) est le navigateur Chromium local pour agents IA : vous fournissez explicitement son état de navigation, puis un agent compatible utilise le site via ego-browser dans un Space dédié et visible. Le Space sépare les onglets et le contrôle de la tâche de votre travail en cours, mais ce n'est ni une VM distante ni une frontière d'isolation entre locataires. Cette voie modifie le modèle d'exécution du navigateur, pas le contrat d'interface du site. les notes de version d'OpenClaw 2.0
Utilisez ce tableau d'évaluation pour expliciter la décision au lieu de traiter WebMCP comme une mise à niveau universelle.
| Question d'évaluation | Choisissez WebMCP lorsque... | Choisissez l'automatisation du navigateur lorsque... |
|---|---|---|
| Maîtrisez-vous le site ? | Oui ; vous pouvez livrer et sécuriser des outils de page | Non ; vous devez composer avec un site tiers |
| La tâche exige-t-elle une connexion existante ? | La session authentifiée de la page suffit | L'agent doit réutiliser une session locale provisionnée à part |
| Quel est l'objectif du déploiement ? | Un contrat stable et typé pour les clients pris en charge | Un flux immédiat sur plusieurs pages, sans travail d'adoption |
Quand WebMCP est-il le bon choix ?
Choisissez WebMCP lorsque vous possédez l'application, que vous pouvez définir des frontières de tâche stables et que vous voulez que les agents accomplissent un travail structuré : formulaires de support, recherche de voyage, paiement ou diagnostic interne. C'est particulièrement utile pour les interfaces complexes où un humain connaît l'action prévue mais où un agent aurait sinon besoin de nombreux clics interprétés. Gardez l'outil petit, typé et observable.
Choisissez l'automatisation avec un navigateur réel lorsque vous ne maîtrisez pas le site, qu'il vous faut une connexion déjà autorisée, que vous devez travailler sur de nombreux sites sans lien entre eux ou qu'il vous faut un flux aujourd'hui plutôt qu'après l'adoption du site. Pour des scripts de CI engagés, l'automatisation déterministe reste appropriée ; pour un travail interactif connecté, un navigateur local visible donne à l'agent le même compte et le même état de page qu'un humain peut vérifier.
Les limites de sécurité de WebMCP
WebMCP ne confère pas d'autorité par lui-même. Chrome encadre les API par l'isolation d'origine et la règle d'autorisation tools ; les iframes cross-origin sont désactivées par défaut. Un site ne peut exposer des outils qu'aux origines auxquelles il fait confiance, et les recommandations de sécurité de Chrome préconisent readOnlyHint pour les outils qui ne modifient rien et untrustedContentHint lorsque la sortie contient du texte externe ou généré par des utilisateurs.
L'injection de prompt reste possible, car un agent traite ensemble les instructions et le contenu web. Gardez des descriptions et des sorties concises, validez les entrées côté serveur, exigez la confirmation de l'utilisateur pour les actions décisives et n'exposez que le plus petit ensemble d'origines et d'outils nécessaire. WebMCP est une interface plus claire, pas une raison de faire l'impasse sur l'authentification, l'autorisation, les journaux d'audit ou la relecture humaine.
Les défis et limites de WebMCP
La principale limite de WebMCP est son adoption : un client doit visiter une page compatible, et le navigateur doit implémenter l'API expérimentale. Chrome note aussi que les scénarios headless ne sont pas la cible principale de conception, que les applications complexes peuvent nécessiter une refonte de leur état et que la proposition évolue encore.
Cela crée une pile mixte pour longtemps encore. Un site peut exposer un excellent outil de paiement tout en laissant les réglages du compte en contrôles DOM ordinaires ; un navigateur peut prendre en charge WebMCP en test mais pas dans votre parc de production. Conservez une voie de repli d'automatisation classique et mesurez les erreurs d'outil, les taux de confirmation et les passages à l'humain sur des exécutions répétées.
Comment essayer WebMCP dès aujourd'hui
Pour des expérimentations locales, activez chrome://flags/#enable-webmcp-testing dans Chrome et redémarrez. Pour des tests réels, la documentation de Chrome renvoie les développeurs vers l'origin trial de Chrome 149. Utilisez les démos officielles et l'extension Model Context Tool Inspector pour voir les outils enregistrés, les appeler manuellement et tester des entrées valides comme invalides. La proposition étant en discussion active, figez la version du navigateur et attendez-vous à des changements d'API. le WebMCP Challenge d'OpenAI
Si vous utilisez des agents plutôt que de gérer un site, vous n'avez pas à attendre l'adoption de WebMCP. Lancez /ego-browser dans votre agent de code pris en charge, décrivez la tâche délimitée et gardez explicites la session du navigateur et les autorisations. Les deux approches coexisteront : WebMCP rend les sites coopératifs plus faciles à piloter ; l'automatisation avec un vrai navigateur atteint tout le reste.
Questions fréquentes
WebMCP est-il identique à un serveur MCP ?
Non. Un serveur MCP classique est un processus ou un service externe qui expose des outils à un client. WebMCP expose des outils depuis la page web elle-même à un agent dans le navigateur, avec les frontières de l'origine du navigateur et de la règle d'autorisation.
WebMCP peut-il automatiser un site sans prise en charge de WebMCP ?
Non. Le client doit visiter une page qui enregistre des outils. Utilisez l'automatisation de navigateur ordinaire pour un site qui n'a pas adopté WebMCP, et arrêtez-vous pour solliciter un humain lorsque l'authentification ou un défi l'exige.
Qui doit implémenter WebMCP ?
C'est l'éditeur du site web qui implémente les outils WebMCP ; un client agent et un navigateur doivent pouvoir les consommer. Un visiteur ne peut pas ajouter d'outils à un site qui ne lui appartient pas.
Quels sont les principaux avantages de WebMCP ?
WebMCP donne aux agents des actions nommées, des entrées décrites par un schéma et l'état de la page, ce qui réduit la devinette de sélecteurs et les clics interprétés sur les sites coopératifs. L'application doit toujours valider chaque charge utile.
Quelles sont les principales limites de WebMCP ?
WebMCP exige l'adoption par les pages et la prise en charge par les navigateurs, reste expérimental dans Chrome et ne résout ni la parité headless, ni la politique d'authentification, ni l'injection de prompt.
Les outils WebMCP peuvent-ils fonctionner sans humain ?
Certains outils à faible risque peuvent s'exécuter automatiquement, mais les actions sensibles devraient demander une interaction et une confirmation de l'utilisateur. La conception de Chrome vise des parcours locaux dans le navigateur, avec un humain dans la boucle.
WebMCP expose-t-il des outils à toutes les iframes ?
Non. L'isolation d'origine et la règle d'autorisation tools encadrent l'enregistrement ; les iframes cross-origin nécessitent une autorisation explicite et une exposition de confiance.
Combien de temps l'API WebMCP restera-t-elle stable ?
Il n'existe encore aucune garantie de stabilité. Chrome qualifie WebMCP de standard proposé en discussion active : figez donc les versions et suivez l'explainer et les notes de l'origin trial.
Puis-je utiliser WebMCP avec un compte déjà connecté ?
Une page peut exposer des outils au sein de sa propre session authentifiée, mais WebMCP ne transfère pas les cookies vers un autre navigateur. Gardez l'autorisation et la confirmation dans le modèle de sécurité du site.
Que dois-je utiliser tant qu'un site n'a pas WebMCP ?
Utilisez l'automatisation de navigateur ordinaire. Pour une session locale autorisée, ego (lite) permet à un agent pris en charge de piloter un navigateur réel provisionné à part via /ego-browser.
Où puis-je lire les recommandations d'implémentation ?
Commencez par la documentation WebMCP de Chrome, les recommandations sur les outils sûrs, la page de l'origin trial et l'explainer WebMCP sur GitHub ; les liens figurent dans les notes de sources ci-dessous.