WebMCP — MCP dans le browser, enfin

Les agents IA interagissent avec les sites Web comme des utilisateurs maladroits. Ils cliquent sur des boutons en devinant les sélecteurs CSS, scrapent du texte en espérant que la structure HTML ne change pas, et prient pour que la prochaine refonte de design ne pète pas tout. C’est lent, fragile, et ça demande une maintenance constante.

WebMCP propose l’inverse : au lieu de laisser l’agent tâtonner dans le DOM, tu lui donnes une API structurée. Ton site expose des outils, des templates de prompts, des ressources de données — exactement comme un serveur MCP classique, mais directement dans le browser. Pas de backend dédié, pas d’infra à déployer.

Le Web agentique, mais par le DOM. Vraiment ?

Aujourd’hui, pour qu’un agent réserve un vol sur ton site, il doit trouver le champ de recherche, remplir les dates en devinant le format, cliquer sur “Rechercher” en espérant que le bouton soit bien celui-là, puis parser les résultats en scrapant le HTML. Chaque étape est une inférence. Chaque refonte CSS casse tout.

WebMCP change le paradigme : au lieu de deviner, l’agent appelle searchFlights({ origin: "CDG", destination: "JFK", dates: [...] }) et reçoit du JSON structuré. Le site décide de l’interface qu’il expose. L’agent consomme une API claire, pas une soupe de balises.

C’est la même philosophie que MCP (Model Context Protocol), mais portée dans le browser. MCP permet aux LLM d’appeler des outils externes — typiquement des serveurs qui exposent des APIs (bases de données, APIs REST, filesystems). WebMCP applique ce modèle aux sites Web : ton app frontend devient elle-même un serveur MCP, et l’agent qui tourne dans Claude Desktop (ou tout autre client MCP) peut interagir avec elle via des outils déclarés en JavaScript.

Deux API pour deux niveaux d’interaction

WebMCP distingue deux modes d’interaction, selon la complexité du workflow.

API déclarative : pour les actions standards qui peuvent être définies directement dans les formulaires HTML. Recherches, soumissions de formulaires, navigation — tout ce qui se mappe naturellement à des éléments DOM existants. Tu annotes tes formulaires, et webMCP génère automatiquement les outils correspondants.

API impérative : pour les interactions complexes qui nécessitent de la logique métier custom. Réservations multi-étapes avec validation côté serveur, workflows conditionnels, appels API tiers. Là, tu enregistres des callbacks JavaScript qui encapsulent la logique.

Une recherche de vol, c’est de l’API déclarative. Une réservation complète avec choix de siège, ajout de bagages, paiement en plusieurs étapes — c’est de l’API impérative.

sequenceDiagram
    participant Agent as Agent (Claude Desktop)
    participant Widget as WebMCP Widget
    participant Site as Site Web
    participant Callback as Callback JS

    Agent->>Widget: appelle tool "searchFlights"
    Widget->>Site: transmet les paramètres
    Site->>Callback: exécute la logique métier
    Callback->>Site: retourne les résultats
    Site->>Widget: résultats structurés (JSON)
    Widget->>Agent: réponse MCP

L’agent n’a jamais accès direct au DOM. Il passe par le widget webMCP, qui sert de proxy entre le client MCP et les callbacks JavaScript que tu as déclarés.

Quatre primitives : tools, prompts, resources, sampling

WebMCP supporte l’ensemble des primitives MCP.

Tools : des fonctions que l’agent peut appeler. Tu enregistres un outil searchFlights avec une description et un schéma de paramètres. L’agent voit cet outil dans sa liste, l’appelle avec les bons arguments, ton callback s’exécute et retourne les résultats. Pas de scraping, pas de devinette.

Prompts : des templates prédéfinis que le client MCP peut utiliser pour standardiser des requêtes courantes. Exemple : un prompt pour générer un commit message Git qui prend un diff en argument et structure la requête pour que le LLM produise un message cohérent.

Resources : des données exposées par le site pour que l’agent les utilise en contexte. Contrairement aux tools (qui effectuent des actions), les resources sont en lecture seule. Tu peux exposer le contenu de la page courante via page://current, ou des resources dynamiques via des URI templates (element://{elementId}).

Sampling : l’inversion de contrôle. Au lieu que l’agent appelle des outils sur le site, c’est le site qui demande à l’agent de générer du contenu. Cas d’usage : un éditeur SQL visuel où l’utilisateur décrit ce qu’il veut en langage naturel, et le site demande à l’agent de générer la requête SQL correspondante. Quand le site envoie une requête de sampling, webMCP affiche une modal à l’utilisateur pour obtenir son consentement. Pas de génération en arrière-plan sans validation humaine.

Le widget : une session MCP dans le browser

Le carré bleu en bas à droite de la page, c’est le widget webMCP. C’est le point d’entrée pour connecter un client MCP au site.

Le workflow : tu installes un client MCP (Claude Desktop, ou autre), tu génères un token webMCP, tu le colles dans le widget. Le widget établit une connexion WebSocket avec le client MCP qui tourne en local (sur localhost). Une fois connecté, tous les tools, prompts et resources déclarés par le site deviennent immédiatement disponibles dans le client. L’agent peut les appeler comme n’importe quel outil MCP.

Différence clé avec MCP classique : ici, le serveur MCP tourne dans le browser (via JavaScript), pas sur un serveur distant. Le client MCP se connecte en local au widget via WebSocket. Le site expose ses capacités directement depuis le frontend, sans passer par un backend dédié.

C’est ce modèle client-side qui rend webMCP léger à adopter : pas besoin de déployer un serveur MCP, pas besoin de gérer des endpoints HTTP exposés. Tout se passe entre le browser et le client MCP local.

Cas d’usage : e-commerce, support, voyages

Chrome met en avant trois cas d’usage dans l’annonce de webMCP. Ce ne sont pas des démos pour la forme — ce sont les workflows où l’ambiguïté du DOM coûte cher en erreurs et en friction utilisateur.

E-commerce : un agent qui aide l’utilisateur à acheter un produit doit naviguer dans des filtres complexes (taille, couleur, options), ajouter au panier, gérer les quantités. En scraping DOM, chaque étape est fragile. Avec webMCP, tu exposes un outil addToCart({ productId, quantity, options }). L’agent appelle l’API, le site contrôle la logique.

Support client : créer un ticket support implique souvent de remplir un formulaire avec des infos techniques (navigateur, version, logs, config). L’utilisateur moyen ne sait pas où trouver ces infos. Un agent peut les collecter automatiquement et pré-remplir le ticket via un outil createSupportTicket qui récupère navigator.userAgent, la résolution écran, etc.

Voyages : chercher un vol, c’est un workflow complexe avec origine, destination, dates, filtres (prix, escales, compagnie), tri des résultats. En DOM scraping, l’agent doit deviner où sont les filtres, comment les appliquer, comment parser les résultats. Avec webMCP, le site expose searchFlights qui retourne du JSON structuré. L’agent reçoit les résultats exploitables, les filtre, les compare, et appelle bookFlight({ flightId }) pour finaliser la réservation.

Ces trois cas ont un point commun : le workflow est complexe mais prévisible. Ce ne sont pas des sites statiques — ce sont des apps Web riches avec de la logique métier. WebMCP permet d’exposer cette logique de manière structurée, sans que l’agent ait à deviner.

Limites et questions ouvertes

WebMCP est en early preview. Certaines limites sont évidentes, d’autres sont des questions ouvertes qui détermineront si ça devient un standard ou une curiosité technique.

Sécurité : aujourd’hui, n’importe quel script JavaScript sur la page peut appeler mcp.registerTool. Si un script tiers malveillant s’exécute sur ton site (extension browser compromise, CDN piraté, injection XSS), il peut enregistrer des outils qui exfiltrent des données ou effectuent des actions non autorisées. Pas de mécanisme d’isolation ou de validation visible dans la spec actuelle. Le modèle de sécurité repose sur la confiance du code JavaScript qui tourne sur la page.

Découvrabilité : le workflow actuel requiert que l’utilisateur colle manuellement un token dans le widget. Aucun mécanisme de découverte automatique. Une piste possible : un meta tag dans le <head>, ou une entrée dans un manifest JSON, qui signale “ce site expose des outils webMCP”. Mais ça pose des questions de privacy : un site peut-il déclarer qu’il expose des outils sans consentement explicite de l’utilisateur ?

Standardisation : WebMCP est développé sous l’égide du W3C Web Machine Learning Community Group, avec la participation de Microsoft, Google et d’autres acteurs. La spec est en cours de rédaction, mais rien ne garantit que tous les navigateurs l’implémenteront. Historiquement, les API proposées par un group W3C mettent du temps à devenir des standards cross-browser implémentés par tous les vendors.

Adoption : implémenter webMCP, ça veut dire maintenir deux interfaces : l’UI pour les humains, et l’API pour les agents. Développement supplémentaire, documentation, tests, maintenance. Quelle est l’incitation économique pour un site e-commerce ou une plateforme SaaS ? Si l’agent aide l’utilisateur à acheter plus facilement, ça peut augmenter les conversions. Mais si l’agent permet de comparer des prix ou de trouver des alternatives plus rapidement, ça peut aussi cannibaliser les ventes. Les sites qui vont adopter webMCP en premier seront probablement ceux qui ont un intérêt direct à faciliter les interactions agentiques : plateformes de support, outils dev, SaaS complexes.

WebMCP est disponible en early preview pour les participants au programme d’aperçu anticipé de Chrome. La spec est en cours de rédaction sur le repo W3C, et le site de démo montre les quatre primitives MCP en action.

C’est une bonne direction pour sortir du DOM scraping. Reste à voir si ça deviendra un standard cross-browser largement adopté.