WebMCP vs MCP : quelle est la différence ?

MCP est un protocole qui permet d’exécuter un serveur exposant vos outils à des agents IA, où qu’ils se trouvent. WebMCP est un standard web proposé qui permet à une page web de déclarer ce qu’un agent peut y faire pendant que l’utilisateur la consulte.

Si vous avez déjà développé un serveur MCP, le nom « WebMCP » laisse penser qu’il s’agit du même protocole, simplement transposé dans le navigateur. Ce n’est pas le cas. Cette différence détermine où se trouve le code destiné aux agents, sous quelle identité il s’exécute et si vous pouvez déjà vous appuyer dessus.

Cet article compare les deux approches selon l’environnement d’exécution, l’identité, le cycle de vie et la découverte des outils. Il associe ensuite chacune à un type de produit et fait un point sans détour sur l’état d’avancement de WebMCP.

Quelle est la différence entre WebMCP et MCP, en une phrase ?

MCP est un serveur que vous exploitez pour qu’un agent puisse appeler vos outils. WebMCP, c’est votre page qui déclare ce qu’un agent peut faire sur la page où il se trouve déjà. Le Model Context Protocol est un standard ouvert permettant de connecter des applications d’IA à des données, des outils et des workflows externes, indépendamment du fait que l’agent s’exécute ou non dans un navigateur. Le guide de Chrome sur quand utiliser WebMCP et MCP présente WebMCP comme un standard de navigateur proposé, composé de deux API. Ces API ne sont accessibles qu’à l’agent intégré au navigateur, et c’est le navigateur qui relaie les messages entre cet agent et votre site. Pour en savoir plus sur les navigateurs dotés de leur propre agent, consultez notre introduction aux navigateurs agentiques. Chrome qualifie WebMCP d’« inspiré de MCP ». Il s’agit d’une API de navigateur calquée sur MCP, et non de MCP réécrit en JavaScript.

Qui exécute quoi avec MCP et WebMCP ?

Un serveur MCP est un processus distinct, avec son propre déploiement, sa propre authentification et sa propre disponibilité. WebMCP n’ajoute aucun processus : il s’exécute dans l’onglet ouvert.

Avec MCP, vous exploitez un service auquel des agents sur des clients desktop, mobiles, cloud ou web peuvent se connecter à tout moment. Cette portée a un coût. Vous hébergez le serveur, vous le versionnez, vous le supervisez et vous décidez de la manière d’authentifier chaque appelant. Le guide du développeur sur l’écosystème MCP explique comment clients, serveurs et protocole s’articulent.

Avec WebMCP, les définitions des outils sont livrées avec votre frontend. Il n’y a rien de plus à déployer, mais les outils sont liés à l’onglet. Chaque outil WebMCP disparaît avec l’onglet qui l’a enregistré. Si l’utilisateur quitte la page ou ferme l’onglet, l’agent perd l’accès à cet outil.

Identité : l’agent agit en tant qu’utilisateur connecté

Comme les outils WebMCP s’exécutent dans la page que l’utilisateur a déjà ouverte, un agent qui les utilise opère dans la session, avec les cookies et les autorisations existants de cet utilisateur. Il ne détient pas d’identifiants distincts pour votre site. Chrome souligne que WebMCP peut exploiter les données de session actives, les cookies et le DOM de la page, qui n’existent pas en dehors d’un onglet ouvert. Il en découle que les requêtes réseau d’un outil partent avec la session dont dispose déjà la page.

Un serveur MCP est confronté à un problème différent. En tant que service autonome, il doit déterminer lui-même qui l’appelle et ce que cet appelant est autorisé à faire. Cela implique généralement d’émettre et de vérifier une forme d’identifiant pour l’agent ou pour l’utilisateur qu’il représente. WebMCP fait l’économie de cette étape, car il ne quitte jamais la session de l’utilisateur. Vous n’avez ni clés d’API à provisionner, ni comptes de service à configurer, ni couche d’autorisation distincte à construire pour l’agent.

Cette identité fondée sur la session a toutefois un revers. Du point de vue de la page, un appel d’outil WebMCP est une action effectuée par l’utilisateur connecté. Sauf si vous prévoyez explicitement une distinction, votre code ne peut pas différencier un appel d’agent d’un clic. Trois bonnes pratiques en découlent :

• Limitez la portée de chaque outil à ce que l’utilisateur pourrait déjà faire via l’interface.
• Exigez une confirmation pour les actions sensibles. La présentation de WebMCP indique qu’un outil réalisant une opération sensible, comme un achat, peut afficher une boîte de dialogue de confirmation à l’utilisateur avant de poursuivre.
• Appuyez-vous sur les contrôles de la plateforme. WebMCP ne fonctionne que dans des documents isolés par origine et est contrôlé par la Permissions Policy tools. Sa valeur par défaut étant self, un iframe cross-origin doit se voir accorder l’accès explicitement.

<iframe src="https://widget.example.com/" allow="tools"></iframe>

Si l’iframe ne comporte pas cet attribut, la valeur par défaut self bloque l’enregistrement d’outils dans ce frame cross-origin. La documentation de Chrome précise également que les API WebMCP sont désactivées dans tout document qui active document.domain, par exemple via l’en-tête Origin-Agent-Cluster: ?0.

WebMCP et MCP comparés

La distinction fondamentale entre MCP et WebMCP oppose, d’un côté, la persistance et la portée, et de l’autre, le contexte de la page et la session utilisateur.

Les cinq premières lignes s’appuient sur la comparaison entre WebMCP et MCP publiée par Chrome.

Quand utiliser MCP ou WebMCP ?

Utilisez MCP pour les traitements réalisés côté serveur sans interface, et WebMCP pour les actions effectuées sur une page en présence d’un utilisateur.

• Service backend, tâches d’arrière-plan ou accès aux données sans interface : MCP. WebMCP nécessite une page ouverte, et la présentation de Chrome précise qu’il est conçu avant tout pour une personne travaillant dans un navigateur local, et non pour des exécutions headless. Commencez par créer un serveur MCP.
• Application web avec un utilisateur connecté : WebMCP. Utilisez-le pour les actions sur la page en cours, comme remplir un formulaire complexe ou sélectionner des dates dans un widget de réservation, lorsque la session de l’utilisateur et l’état de la page comptent.
• Les deux. De nombreux produits auront besoin des deux. MCP prend en charge la logique métier et les données, tandis que WebMCP couvre les actions dans l’onglet. Si vous disposez déjà d’une API HTTP, exposer cette API aux LLM avec MCP en constitue le pendant naturel côté serveur. Pour le côté navigateur, consultez notre article complémentaire, Exposer les actions de votre site aux agents IA avec WebMCP.

WebMCP remplace-t-il MCP ?

Non. Chrome l’affirme clairement : WebMCP n’étend ni ne remplace MCP. Il est conçu pour le navigateur et laisse de côté les concepts propres au serveur, comme les ressources. Il dépend en outre d’une page : ses outils ne peuvent être découverts qu’en visitant le site, et ils disparaissent à la fermeture de l’onglet. De nombreuses tâches d’agents ne passent jamais par une page web : tâches planifiées, assistants intégrés à l’IDE, pipelines de données ou agents exécutés dans le cloud. Ces tâches nécessitent toujours un serveur MCP.

Quel est le niveau de maturité de WebMCP ?

WebMCP est expérimental. Il est disponible via une origin trial dans Chrome à partir de Chrome 149 et, en local, via le flag chrome://flags/#enable-webmcp-testing. Chrome avertit que l’API est encore en discussion et susceptible d’évoluer. Les origin trials durent une période déterminée, peuvent être assorties de limites d’utilisation et visent à recueillir des retours qui façonneront l’API définitive. La spécification WebMCP est un rapport préliminaire (draft report) du W3C Web Machine Learning Community Group. Ce n’est ni un standard du W3C, ni un document inscrit sur la voie de standardisation du W3C (Standards Track). La documentation de Chrome ne couvre que l’implémentation de Chrome : ne présumez donc pas de la prise en charge par d’autres navigateurs ou hôtes d’agents tant que leur propre documentation ne la confirme pas. Suivez WebMCP sur Chrome Status pour connaître l’évolution des jalons. Chrome indique également que WebMCP peut être ajouté sous forme d’amélioration progressive (progressive enhancement). Adoptez cette approche, afin que votre interface fonctionne de la même manière, qu’un agent puisse ou non voir les outils.

Faire son choix

MCP et WebMCP répondent à des questions différentes. MCP rend vos fonctionnalités accessibles à n’importe quel agent, à tout moment. WebMCP rend la page consultée par un utilisateur exploitable par l’agent de son navigateur, dans le cadre de sa propre session. Prochaine étape : dressez la liste des actions qu’expose votre produit et classez-les. Les opérations headless relèvent d’un serveur MCP, tandis que les actions de page liées à la session sont des candidates à WebMCP, derrière l’origin trial. Gardez la couche WebMCP aussi légère que possible, car l’API peut encore évoluer.

FAQ

Comment activer WebMCP pour les vrais visiteurs, et pas seulement dans mon propre navigateur ?

Enregistrez votre origine dans la console Chrome Origin Trials et générez un jeton WebMCP. Servez-le sur chaque page qui enregistre des outils, soit dans une balise meta d'origin trial, soit dans un en-tête de réponse HTTP Origin-Trial. Les jetons sont propres à chaque origine. Sans jeton, les visiteurs utilisant une version standard de Chrome ne verront jamais vos outils, car le flag de test local n'affecte que le navigateur dans lequel vous l'activez. La phase d'évaluation a débuté avec Chrome 149 et devait initialement durer jusqu'à Chrome 156. Google a demandé à la prolonger jusqu'à Chrome 162 : vérifiez donc la date d'expiration de votre jeton dans la console Origin Trials.

Comment tester des outils WebMCP sans développer d'agent ?

Utilisez Model Context Tool Inspector, une extension Chrome référencée dans la documentation WebMCP de Chrome. Elle liste les outils enregistrés par une page et vous permet de les exécuter vous-même. Elle vérifie également que le navigateur parvient à analyser votre JSON Schema et affiche le résultat ou l'erreur renvoyé par chaque outil. WebMCP doit tout de même être activé sur votre page, soit via le flag de test WebMCP dans chrome://flags, soit via un jeton d'origin trial.

Puis-je réutiliser les définitions de mes outils MCP pour WebMCP ?

Vous pouvez souvent réutiliser les définitions des entrées, mais pas les handlers. Les outils MCP comme les outils WebMCP décrivent leurs entrées avec JSON Schema : le nom, la description et la structure des arguments d'un outil sont donc généralement transposables. Le handler, lui, diffère. Un handler MCP s'exécute sur votre serveur, avec le mécanisme d'authentification que vous avez implémenté. Un handler WebMCP est du code JavaScript qui s'exécute dans la page, avec la session de l'utilisateur et l'état actuel du DOM.

Angular prend-il en charge WebMCP ?

Oui, mais uniquement à titre expérimental. La prise en charge expérimentale d'Angular permet d'enregistrer des outils WebMCP qui suivent le cycle de vie de l'injection de dépendances d'Angular, et peut transformer des Signal Forms en outils sans que vous ayez à écrire de JSON Schema à la main. La documentation d'Angular avertit que la spécification WebMCP évolue fréquemment et que ces API peuvent changer, y compris en dehors des versions majeures. Figez votre version d'Angular et attendez-vous à devoir mettre à jour votre code.