WebMCP, c’est quoi ? Le guide d’un site qui l’utilise

WebMCP met en jeu trois parties. La page déclare des outils. Le navigateur tient la liste et transmet les appels dans les deux sens. L’agent, intégré au navigateur, installé en extension ou logé dans le navigateur d’une application de bureau, lit la liste et décide quoi appeler. Aucun serveur au milieu : comme l’a dit un ingénieur à BlinkOn 21, le navigateur joue le rôle d’un serveur MCP, sans qu’aucun serveur n’existe.

1. La page

   Déclare ses outils depuis son propre JavaScript et les exécute quand on les appelle : mêmes fonctions que ses boutons, mêmes cookies, mêmes droits.

2. Le navigateur

   Garde les outils de chaque onglet, les présente à l’agent, achemine les appels vers la page et garde l’humain dans la boucle.

3. L’agent

   Lit les noms, descriptions et schémas, choisit un outil, envoie les arguments et lit le texte qui revient.

• Il agit en tant qu’utilisateur

  Les outils s’exécutent dans l’onglet ouvert, avec la session que la personne a déjà. Ni clé d’API, ni OAuth, ni nouvel identifiant : l’onglet fermé, l’accès disparaît avec lui.

• Il vit et meurt avec la page

  Les outils n’existent que tant que la page qui les a déclarés est ouverte. On change de page, ils disparaissent ; la suivante déclare les siens. Kasper Kulikowski (Chrome) les dit liés à l’onglet et éphémères.

• Il garde l’humain dans la boucle

  La cible, c’est la navigation à deux : la personne voit la page changer pendant que l’agent travaille et garde les étapes qui engagent. Un outil de formulaire remplit les champs ; par défaut, c’est l’humain qui valide.

• Il ne montre que ce que l’utilisateur peut faire

  Les outils sont déclarés par le code de la page, pour la personne qui la regarde. L’agent d’un visiteur déconnecté ne voit jamais « payer », parce que la page ne le déclare pas.

• Il se dégrade sans casser

  Pas d’outil pour la tâche ? L’agent revient à l’interface, comme avant. WebMCP est un chemin plus rapide et plus sûr pour les agents, pas une barrière.

Il existe deux variantes. L’API impérative, en JavaScript, peut tout faire. L’API déclarative tient en quelques attributs HTML posés sur un formulaire existant. Pour l’agent, aucune différence : comme le dit Dominic Farolino, éditeur de la spécification, à BlinkOn, il n’y a au fond que des outils.

if ("modelContext" in document) {
  const registration = new AbortController();

  await document.modelContext.registerTool(
    {
      name: "search_flights",
      description:
        "Search flights between two airports on one date. " +
        "Returns up to 10 offers with price, duration and stops.",
      inputSchema: {
        type: "object",
        properties: {
          from: { type: "string", description: "Departure airport, IATA code" },
          to: { type: "string", description: "Arrival airport, IATA code" },
          date: { type: "string", format: "date" },
        },
        required: ["from", "to", "date"],
      },
      annotations: { readOnlyHint: true },
      async execute({ from, to, date }, { signal }) {
        // The same function the search button calls.
        const offers = await searchFlights({ from, to, date, signal });
        // The person sees what the agent asked for.
        showResults(offers);
        return offers.slice(0, 10);
      },
    },
    { signal: registration.signal },
  );
}

// Later: registration.abort() removes the tool.

<form
  toolname="book_table"
  tooldescription="Book a table for a date, a time and a party size."
  action="/reservations"
  method="post"
>
  <input name="date" type="date" required>
  <select name="time" required>
    <option>19:00</option>
    <option>20:30</option>
  </select>
  <input name="guests" type="number" min="1" max="12" required
    toolparamdescription="Number of people, 1 to 12">
  <button>Book</button>
</form>

Beaucoup d’équipes feront les deux. Shopify propose Checkout MCP pour les agents sur serveur et Checkout WebMCP pour les agents dans le navigateur de l’acheteur, sur le même objet de commande, et conseille la version serveur dès que l’agent peut tourner sur un serveur. Les MCP Apps vont dans l’autre sens : elles font entrer l’interface d’un site dans la conversation de l’agent, quand WebMCP fait entrer l’agent dans le site.

1. Mars 2025

   Le nom apparaît

   Le développeur Jason McGhee publie un projet appelé WebMCP, première apparition du nom, pour que des sites proposent des outils à des clients IA locaux.

2. Juin–juil. 2025

   Un serveur MCP dans une page web

   Chez Amazon, Alex Nahas veut que ses collègues utilisent des agents sur les outils internes. Le MCP distant reposait sur OAuth, Amazon sur une authentification unique SAML, et le serveur MCP interne avait grossi jusqu’à des milliers d’outils. Sa réponse : faire tourner le serveur dans le JavaScript d’une page où l’utilisateur est déjà connecté. Il l’appelle MCP-B (le B pour browser, « Browser MCP » étant déjà pris), et le présente sur Hacker News le 9 juillet.

3. Juil. 2025

   Deux navigateurs, la même idée

   Le 9 juillet, Chrome annonce son intention de prototyper une « Script Tools API ». Le 16 juillet, Microsoft Edge publie son explainer « Web Model Context », signé Andrew Nolan et Brandon Walderman.

4. Août 2025

   Une seule proposition

   Les deux propositions fusionnent au sein du Web Machine Learning Community Group du W3C entre le 7 et le 18 août, le travail de Nahas étant reconnu comme expérience d’implémentation. Le 29 août, Patrick Brosset montre un prototype d’Edge piloté depuis VS Code.

5. 25 sept. 2025

   Officiellement au W3C

   La charte révisée du groupe entre en vigueur avec WebMCP parmi ses livrables. Éditeurs : Khushal Sagar et Dominic Farolino (Google), Brandon Walderman (Microsoft). En novembre, le groupe se réunit au TPAC de Kobe, et Sagar présente WebMCP au Web AI Summit de Google.

6. 10 févr. 2026

   L’essai développeurs de Chrome

   Chrome 146 livre WebMCP derrière une option, avec une extension d’inspection pour appeler les outils à la main. L’équipe relations développeurs de Chrome reconnaît ne pas avoir encore testé avec de vrais agents.

7. Mars–juin 2026

   L’API est reconstruite

   provideContext et unregisterTool disparaissent, modelContext passe sur document, le mécanisme de consentement est retiré pour l’instant. Le 11 juin, l’équipe WebKit d’Apple s’oppose formellement à la proposition.

8. Mai–juin 2026

   De Google I/O à la phase d’essai

   À Google I/O, le 19 mai, Chrome annonce une phase d’essai, un panneau WebMCP dans les DevTools et une catégorie « navigation agentique » dans Lighthouse. L’essai ouvre le 9 juin, de Chrome 149 à 156.

9. Août 2026

   Les sites et les agents arrivent

   Les boutiques Shopify déclarent des outils à partir du 5 août, le jour où Mozilla passe sa position à « neutre ». Le 25 août, le navigateur de ChatGPT sur ordinateur commence à les appeler. Le WebMCP Challenge de Google réunit environ 5 000 participations.

10. Sept. 2026

    Sans interface et sans date de sortie

    consequentialHint arrive et les agents sans interface entrent dans le périmètre. Le checkout de Shopify suit le 28 septembre. Le 29, Chrome demande à prolonger son essai jusqu’à la version 162 et espère livrer dans cette fenêtre. Le 1er octobre, la charte d’un nouvel Agentic Web Working Group entre en relecture.

WebMCP est un brouillon de Community Group, pas un standard du W3C. Un standard suppose plusieurs moteurs, et aujourd’hui seul Chromium l’implémente. Au sein même du W3C, les groupes accessibilité et vie privée sont critiques.

• Implémente

  Google Chrome

  Deux des trois éditeurs. Essai développeurs dès Chrome 146, phase d’essai de 149 à 156, prolongation jusqu’à 162 demandée, pas encore d’intention de livrer.

• Implémente

  Microsoft Edge

  Un éditeur et le premier prototype. Edge participe aussi à la phase d’essai.

• Appelle les outils

  OpenAI

  Le navigateur de ChatGPT sur ordinateur appelle les outils WebMCP depuis le 25 août 2026 : outils JavaScript, sur la page principale seulement.

• Neutre

  Mozilla Firefox

  Un prototype derrière un réglage désactivé par défaut. De l’intérêt pour l’API JavaScript, des réserves sur un nom qui promet MCP.

• Opposé

  Apple Safari

  Veut combler les manques dans HTML et ARIA, et a prévenu qu’il ferait une objection formelle si WebMCP passait tel quel en Working Group.

• Pas en l’état

  Groupe accessibilité du W3C

  Ne soutient pas la spécification dans sa forme actuelle, et voit dans toolautosubmit une porte ouverte à des interfaces trompeuses, proches du détournement de clic.

WebMCP rend le travail d’un agent explicite, ce qui réduit ce qu’il doit toucher. Il ne rend pas les agents sûrs. La spécification le dit elle-même : rien ne garantit que l’intention déclarée d’un outil corresponde à son comportement réel.

1. 01

   Les mots deviennent une surface d’attaque

   Noms, descriptions et résultats atterrissent tous dans le contexte du modèle. Une page malveillante peut y cacher des instructions, et une page honnête peut les relayer en renvoyant des avis ou des messages de forum. Marquez ces résultats avec untrustedContentHint et dites-le aussi en toutes lettres, comme le fait le site de documentation d’OpenAI.

2. 02

   Le premier script à déclarer gagne

   Un nom d’outil est unique par page : un script d’analyse ou de publicité compromis qui déclare checkout en premier en prend le contrôle. Dans une étude de laboratoire de 2026 (arXiv 2606.06387), cette course a détourné GPT-5.4, Claude Opus 4.6 et Gemini 2.5 Flash à chaque essai.

3. 03

   Des capacités blanchies en langage naturel

   Earlence Fernandes (UC San Diego) a glissé une instruction dormante dans la description d’un outil d’un site ; plus tard, sur un autre site, un mot déclencheur a poussé l’agent à appeler l’outil de ce second site. L’isolation entre origines ne vaut que ce que vaut la défense de l’agent contre l’injection de prompt.

4. 04

   Votre bouton « Approuver » n’est pas un garde-fou

   Les outils agissent avec les cookies de l’utilisateur, et un agent qui appelle des outils sait souvent aussi cliquer. Le 2 septembre 2026, un développeur a vu le navigateur de ChatGPT appeler un outil qui ne faisait que proposer, puis cliquer sur le bouton « Approuver » de la page ; la page a enregistré « approuvé par vous » (ticket #288). La règle de Shopify : l’agent montre la commande et le total, demande à l’acheteur, et redemande si le total change.

5. 05

   Les outils disparaissent en plein vol

   Les résultats meurent avec le document. Si un appel fait changer de page, la réponse peut ne jamais arriver (Shopify note qu’executeTool() renvoie alors null), et les agents ne retrouvent pas toujours les outils redéclarés après le trajet.

6. 06

   Personne ne voit encore le trafic des agents

   Les sites peuvent compter les appels, pas savoir s’ils ont servi ce que voulait l’utilisateur. Yoav Weiss (Shopify) a ouvert un ticket sur la mesure en conditions réelles ; un des premiers sites marchands équipés dit ne pas encore pouvoir observer de vrai trafic d’agents.

1. Penser en tâches, pas en éléments

   Un outil par tâche qu’un utilisateur vient accomplir, pas un par bouton. Nommer ce qu’il fait : create_event exécute, start_event_creation ouvre le formulaire.

2. Garder la liste courte

   Des dizaines d’outils dégradent les agents et peuvent pousser les navigateurs à en écarter. Ne déclarer sur chaque page que ce que cette page sait faire.

3. Respecter les budgets

   Les limites de Chrome : 30 caractères par nom, 500 par description, 150 par description de paramètre, environ 1 500 par résultat. Mettre la réserve importante en premier : ce qui dépasse est coupé sans prévenir.

4. Accepter l’entrée brute

   Prendre « de 11 h à 15 h » tel que l’utilisateur l’a dit ; ne pas demander au modèle des minutes depuis minuit. Des valeurs d’énumération lisibles : « express », pas 1.

5. Valider dans le code, souplement dans le schéma

   Rien ne garantit que les contraintes du schéma soient appliquées. Vérifier dans execute et renvoyer des erreurs qui disent comment corriger l’appel.

6. Montrer ce qui s’est passé

   Mettre l’interface visible à jour à chaque appel : la personne partage l’onglet avec l’agent.

7. Signaler ce que vous ne contrôlez pas

   untrustedContentHint sur les résultats qui contiennent du contenu d’utilisateurs, et le même avertissement dans la description.

8. Laisser la décision à l’humain

   consequentialHint pour les paiements, envois et suppressions, une étape de confirmation dans le parcours, et les prix et stocks revérifiés à l’exécution.

9. Survivre aux changements de page

   Faire le travail dans la page et renvoyer des données, faire de la navigation un outil à part, et déclarer les mêmes noms sur chaque page.

10. Détecter, charger tard, nettoyer

    Tester document.modelContext (anciennes versions de Chrome : navigator.modelContext), ne charger le code des outils qu’à ce moment, et passer un AbortSignal.

11. Surveiller vos scripts tiers

    Déclarer tôt les outils critiques, et auditer les balises qui partagent votre page.

12. Tester comme un agent

    L’extension Model Context Tool Inspector de Chrome, le panneau WebMCP des DevTools, l’audit « navigation agentique » de Lighthouse, et un test navigateur qui appelle les vrais outils.