Exposer les actions de votre site aux agents IA avec WebMCP

WebMCP inverse le sens du Model Context Protocol. Au lieu qu’un agent se connecte à un serveur que vous hébergez, votre page enregistre ses propres outils en JavaScript via document.modelContext.registerTool(), et un agent qui a déjà la page ouverte appelle directement ces actions déclarées, plutôt que de naviguer à tâtons dans votre interface et de deviner à quoi correspondent vos champs de formulaire.

Si vous avez déjà connecté un serveur MCP à un agent de codage, le modèle côté serveur vous est familier : un processus, un transport, une liste d’outils, un client qui se connecte. Le cas du navigateur est le plus délicat. Le trafic des agents arrive sur une page rendue avec une session authentifiée, et jusqu’à présent la seule voie possible était l’actionnement : lire le DOM, déduire ce que font les boutons, et espérer que l’étape de paiement ne se réaffiche pas au milieu d’un clic.

Cet article couvre les mécanismes qui comptent vraiment pour quiconque possède une application réelle : à quoi ressemble un enregistrement d’outil correct, ce que les trois indicateurs d’annotation changent réellement au comportement de l’agent, où les outils de site s’exécutent aujourd’hui, et les conséquences en matière de sécurité d’un outil qui s’exécute au sein de la session authentifiée de l’utilisateur.

L’inversion : qu’est-ce qui distingue WebMCP ?

Un serveur MCP côté serveur est une entité à laquelle un agent se connecte, configurée une fois et accessible indépendamment de toute page ouverte. WebMCP fonctionne dans l’autre sens. La documentation d’OpenAI sur les site tools place la frontière à l’endroit où résident les outils. MCP oriente une application d’IA vers un serveur, local ou distant, situé en dehors de la page et opérationnel qu’un navigateur soit ouvert ou non. Un site WebMCP livre ses propres capacités sous la forme d’un ensemble d’outils prêts à l’emploi qu’un agent découvre à son arrivée, sans rien à installer pour l’utilisateur.

Le gain, c’est la précision. La documentation WebMCP de Chrome formule la différence en termes de qui décide de la signification d’un contrôle : avec un outil, le site l’énonce explicitement, et l’agent n’a plus rien à déduire. L’actionnement lui impose une chaîne d’étapes et un jugement à chacune d’elles. Un agent appelant search_orders({ status: "open" }) contre un schéma que vous avez écrit ne peut pas se tromper de menu déroulant de filtrage, et ne peut pas casser parce que vous avez renommé une classe CSS.

Comment enregistrer un outil avec document.modelContext.registerTool() ?

L’enregistrement d’un outil prend un objet comportant un name, une description et un inputSchema ; la référence de l’API impérative de Chrome considère ces trois éléments comme des champs obligatoires, annotations et une fonction execute portant le comportement. Faites une détection de fonctionnalité avant l’appel, exactement comme dans l’exemple d’OpenAI, car l’API n’est pas encore présente dans la plupart des navigateurs.

async function registerAgentTools() {
  if (typeof document.modelContext?.registerTool !== "function") return;

  await document.modelContext.registerTool({
    name: "list_orders",
    description:
      "List the signed-in customer's orders, newest first, optionally filtered by fulfilment status. Returns order number, placed date, status and total.",
    inputSchema: {
      type: "object",
      properties: {
        status: {
          type: "string",
          enum: ["open", "shipped", "delivered", "cancelled"],
          description: "Fulfilment status to filter by. Omit for all orders.",
        },
        limit: {
          type: "integer",
          minimum: 1,
          maximum: 20,
          description: "Maximum orders to return. Defaults to 10.",
        },
      },
      required: [],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    // Same function the orders table calls. The API still checks the session.
    execute: async ({ status, limit = 10 }) => fetchOrders({ status, limit }),
  });
}

La description est la seule chose que le modèle lit pour décider si cet outil correspond à la requête : elle pèse donc autant que le code qui se trouve derrière. Nommez la forme du retour, nommez le filtre, et précisez ce que l’outil ne couvre pas.

Notez ce que fait execute ici : il délègue. L’outil appelle la même fonction de récupération de données que l’interface utilisateur, et le serveur en aval applique la même autorisation qu’il applique déjà. Les recommandations d’OpenAI orientent les développeurs vers leur authentification et leur autorisation existantes plutôt que vers un chemin parallèle, et la raison technique est évidente : deux chemins de code vers la même capacité finiront par diverger, et celui qui n’a pas d’interface devant lui est celui dont personne ne remarquera la dérive.

Que changent les trois indicateurs d’annotation ?

Les annotations sont des métadonnées qui indiquent à un agent comment traiter un outil avant de l’appeler. Chrome en documente trois, et les recommandations de sécurité des outils de Chrome reformulent chacune en fonction du risque qu’elle signale.

Définissez-les outil par outil, délibérément. Un outil cancel_subscription sans consequentialHint est un outil qu’un agent peut déclencher sans marquer de pause, et un outil de récupération d’avis sans untrustedContentHint transmet au modèle un bloc de texte rédigé par des inconnus sans aucun signalement.

Où WebMCP s’exécute-t-il aujourd’hui ?

La page d’OpenAI sur les site tools précise où ChatGPT honorera un outil enregistré : dans le navigateur intégré de l’application de bureau ChatGPT, maintenue à jour, où ChatGPT Work et Codex peuvent trouver et appeler ce que la page propose. Le modèle compte également : GPT-5.6 Sol et GPT-5.6 Terra sont pris en charge, et WebMCP est désactivé sur GPT-5.6 Luna. Les espaces de travail Enterprise et Edu sont exclus, et la disponibilité effective de la fonctionnalité dépend encore du déploiement progressif et de ce que la page ouverte enregistre. Une flèche dans la barre d’adresse liste les outils fournis par une page, et l’ensemble de la fonctionnalité peut être désactivé sous les autorisations du navigateur.

L’implémentation de Chrome en est encore au stade de prévisualisation. Chrome documente WebMCP derrière le drapeau chrome://flags/#enable-webmcp-testing pour le développement local, à passer sur Enabled avec un redémarrage, ainsi qu’un origin trial auquel vous pouvez participer à partir de Chrome 149. Ce n’est pas activé par défaut en version stable, et les déclarations de prise en charge des deux éditeurs évoluent : consultez donc les pages sources avant de livrer en vous appuyant dessus.

Ce que le navigateur de ChatGPT ne prend pas en charge

La documentation d’OpenAI indique clairement que le navigateur intégré ne couvre qu’une partie de WebMCP, et elle nomme deux lacunes. Les outils définis via les attributs de formulaire HTML ne deviennent pas des site tools, et les outils enregistrés à l’intérieur d’une iframe ne sont pas détectés, y compris les iframes de même origine. L’instruction pratique est brève : enregistrez de manière impérative, sur le document de premier niveau, et ne comptez sur rien d’exotique.

Cette restriction sur les iframes est propre à ChatGPT, pas au standard. Chrome place les deux API derrière la Permissions Policy tools, dont la valeur initiale est self. Avec cette valeur par défaut, le document de premier niveau et les frames de même origine peuvent enregistrer des outils, contrairement à une iframe cross-origin. Un widget intégré sur une autre origine peut enregistrer des outils si la policy tools est accordée au frame, si l’outil passe exposedTo en listant les origines autorisées, et si l’appelant passe fromOrigins à getTools(). Chrome restreint également WebMCP aux documents isolés par origine : une page utilisant document.domain n’obtient donc aucune API.

Votre outil s’exécute au nom de l’utilisateur connecté

Un outil enregistré s’exécute au sein de la page active sous la session authentifiée de l’utilisateur, ce qui signifie que chaque capacité que vous exposez est une capacité qu’un agent peut exercer avec les droits de cet utilisateur. La question du périmètre n’est pas de savoir ce qu’il serait pratique d’automatiser, mais ce que vous accepteriez de voir invoqué sans clic.

Les recommandations de sécurité de Chrome sont exceptionnellement directes sur ce point. Un modèle traite les instructions et les données comme une seule suite continue de tokens, sans démarcation entre les deux. La sécurité ne peut pas être garantie au sein d’un système probabiliste. L’injection de prompt a déjà fonctionné, de façon reproductible, contre des systèmes d’agents utilisant les meilleurs modèles disponibles, et le nombre de ces attaques sur le web ne cesse d’augmenter. OpenAI dit sensiblement la même chose à propos des outils eux-mêmes : dans sa documentation sur les site tools, les définitions d’outils d’un site web et les résultats qu’ils renvoient sont tous deux considérés comme du contenu non fiable.

Trois contrôles concrets en découlent. La visibilité des outils est fermée par défaut, puisque les autres sites et les iframes cross-origin ne peuvent pas voir vos outils tant que vous n’avez pas nommé leurs origines dans exposedTo ; appliquez aux outils en lecture seule qui exposent des données utilisateur la même vigilance qu’aux outils en écriture. Chrome signale également une voie d’accès que vous n’avez pas ouverte : les extensions peuvent interroger et exécuter vos outils depuis un content script, et une extension disposant de host_permission pour votre site peut de toute façon déjà exécuter son propre JavaScript sur la page. Enfin, restez concis. Chrome recommande 500 caractères pour une description d’outil, 150 par description de paramètre, 30 pour les noms d’outils et de paramètres, et 1,5 K par sortie d’outil, en décrivant ces quatre valeurs comme des recommandations susceptibles d’évoluer avec les retours de l’écosystème et d’être formalisées ultérieurement. Les travaux sur la gestion du consentement se poursuivent, notamment avec une requestUserInteraction() à l’état de brouillon de spécification pour interroger l’utilisateur en cours d’exécution, qui n’a pas encore été livrée.

WebMCP n’est pas un levier SEO

Enregistrer des site tools change ce qu’un agent peut faire une fois arrivé sur votre page. Cela ne fait rien pour le faire arriver. La liste des limitations de Chrome cite la découvrabilité des outils comme un problème ouvert : un client ou un navigateur ne découvre qu’un site dispose d’outils appelables qu’en s’y rendant. Il n’y a ni crawl, ni index, ni flux d’outils enregistrés. À la lumière de ce mécanisme, la conclusion est directe, même s’il s’agit de notre lecture et non d’une déclaration d’éditeur : WebMCP est une surface de parcours de conversion, pas un levier de classement ou de citation, et traiter une description d’outil comme un texte de meta-description revient à se tromper sur son lectorat.

Choisissez une action que vos utilisateurs réalisent déjà sur votre site, enregistrez-la d’abord en lecture seule, et consacrez le vrai travail à la description et au schéma. C’est là qu’un agent comprend ou ne comprend pas votre application, et c’est la partie qu’aucun déploiement de navigateur ne réglera à votre place.

FAQ

Comment désenregistrer un outil WebMCP lorsque l'utilisateur quitte la page ?

Il n'existe pas de méthode unregisterTool. Passez un AbortSignal dans l'objet d'options de document.modelContext.registerTool, puis déclenchez l'abandon de ce contrôleur lorsque l'outil ne s'applique plus, par exemple au démontage d'un composant ou lors d'un changement de route dans une SPA. Les bonnes pratiques de Chrome formulent cela en termes d'état de page : enregistrez un outil tant qu'il est utile, et désenregistrez-le dès qu'il ne l'est plus. Lier l'abandon à vos transitions de page est la manière pratique d'y parvenir, et cela évite qu'un outil obsolète persiste ou entre en conflit avec un nouvel enregistrement portant le même nom. Les agents observent le changement via l'événement toolchange sur document.modelContext.

Quelle est la différence entre les API WebMCP déclarative et impérative ?

L'API déclarative transforme un formulaire HTML existant en outil : ajoutez les attributs toolname et tooldescription à l'élément form, ainsi que toolparamdescription sur les champs individuels, et le navigateur en dérive une représentation structurée. Supprimer l'un ou l'autre de ces attributs désenregistre l'outil. L'API impérative, document.modelContext.registerTool, convient aux outils dynamiques et à la logique complexe. Le navigateur intégré de ChatGPT ne prend en charge que la voie impérative.

Existe-t-il une prise en charge React ou Angular pour enregistrer des outils WebMCP ?

Les deux existent et les deux sont expérimentales. Chrome Labs maintient le hook useWebMCP dans le paquet use-webmcp-tool, qui enregistre un outil au montage, le désenregistre au démontage, requiert React 18 ou une version ultérieure, et se réduit à une no-op là où l'API est absente. Angular expose provideExperimentalWebMcpTools depuis son paquet core, liant la durée de vie de l'outil à un injecteur, les providers de route ou d'application étant l'emplacement recommandé.

Le navigateur valide-t-il les arguments qu'un agent transmet par rapport à mon inputSchema ?

Ne partez pas de ce principe. Considérez les données qui parviennent à execute comme non validées et vérifiez-les dans votre code avant d'agir. Les recommandations WebMCP de Chrome invitent les développeurs à valider les contraintes et à renvoyer des erreurs descriptives afin que l'agent puisse réessayer, et Angular indique clairement qu'il ne vérifie pas les arguments fournis par l'agent par rapport au schéma JSON que vous avez déclaré. Les contrôles d'autorisation côté serveur restent applicables par-dessus.