Tutoriel WebMCP : créer des sites prêts pour les agents avec le nouveau standard de Chrome

Aujourd'hui, les agents d'IA naviguent sur le web comme un touriste devant un menu étranger : ils plissent les yeux devant des pixels, devinent à quoi servent les boutons et croisent les doigts pour que la page ne change pas de mise en page au moment du clic. Google et Microsoft ont décidé qu'il était temps d'y apporter une vraie solution.

En février 2026, Chrome 146 a livré une préversion de WebMCP, un projet de standard web qui permet aux sites d'indiquer aux agents exactement ce qu'ils peuvent faire et comment le faire. 

Finie la capture d'écran à la volée. 

Plus besoin de retro-ingénierie du DOM.

Dans ce tutoriel, je vous explique ce qu'est vraiment WebMCP, comment préparer votre environnement, puis comment réaliser des intégrations fonctionnelles en HTML et en JavaScript.

Je couvrirais également les bonnes pratiques de sécurité pour gérer les appels d'agents, ainsi que les tests avec les outils de débogage de Chrome.

Qu'est-ce que WebMCP ?

WebMCP (Web Model Context Protocol) est un nouveau standard de navigateur qui permet aux sites web de déclarer leurs capacités comme des outils structurés que les agents d'IA peuvent appeler directement. Au lieu de forcer une IA à « lire » et cliquer à travers une interface visuelle, WebMCP transforme la page elle-même en une API côté client, propre et explicite.

Imaginons un agent qui tente de réserver un vol sur un site de voyage aujourd'hui. Il doit identifier le champ de départ, deviner si la date est au format MM/JJ ou AAAA-MM-JJ, trouver le bouton Rechercher, et espérer que la page ne se recharge pas avec une mise en page inconnue. Si le site publiait plutôt un outil nommé searchFlights avec des paramètres typés pour l'origine, la destination, les dates et le nombre de passagers, toutes ces approximations disparaîtraient.

WebMCP rend cela possible. Un site enregistre des outils via une API de navigateur appelée navigator.modelContext, chaque outil étant défini par un nom, une description en langage naturel, et un schéma JSON pour ses entrées et sorties. L'agent découvre ces outils, envoie des paramètres conformes au schéma et reçoit en retour des données structurées.

Des ingénieurs de Google et Microsoft ont coécrit la spécification au sein du groupe communautaire W3C Web Machine Learning. L'architecture est entièrement côté client, ce qui la différencie des déploiements MCP classiques où un serveur backend exécute les outils. Alors que MCP standard connecte les agents à des serveurs via JSON-RPC, WebMCP maintient tout dans l'onglet du navigateur. 

Les outils s'exécutent dans le JavaScript de la page ; ils partagent la session utilisateur en cours, et le navigateur contrôle ce que l'agent est autorisé à faire. Si vous avez déjà travaillé avec des serveurs MCP (par exemple, dans notre tutoriel MCP Model Context Protocol), les concepts d'enregistrement d'outils vous seront familiers, mais le modèle de déploiement est très différent.

Fonctionnalités et capacités clés de WebMCP

Deux API sont disponibles et répondent à des besoins différents :

• L'API déclarative fonctionne via des annotations HTML. Vous ajoutez les attributs toolname et tooldescription à un élément <form>, avec éventuellement toolparamdescription sur des champs individuels, et le navigateur génère un schéma JSON à partir de la structure du formulaire. Les sites qui disposent déjà de bons formulaires ont très peu de changements à faire pour devenir accessibles aux agents.
• L'API impérative vous donne un contrôle total par code. Vous appelez navigator.modelContext.registerTool() et définissez le nom de l'outil, sa description, le schéma d'entrée et un callback execute. C'est la voie à suivre pour tout ce qui est trop dynamique pour un simple formulaire : workflows multi-étapes, appels d'API, résultats calculés et logique de validation personnalisée.

Les deux API permettent l'enregistrement dynamique, c'est-à-dire que les outils peuvent apparaître ou disparaître selon l'état de la page. Avant connexion, vous pourriez n'exposer qu'un outil login. Après authentification, les outils liés au compte sont enregistrés.

• Les schémas JSON de chaque outil précisent les types, énumérations, champs requis et descriptions des paramètres. Cette structure empêche les agents d'inventer des valeurs ou de placer des données dans les mauvais champs.
• Des pseudo-classes CSS apportent un retour visuel lors des interactions. Chrome applique :tool-form-active à tout formulaire en cours de remplissage par un agent, et :tool-submit-active au bouton d'envoi correspondant. L'humain qui regarde l'écran voit exactement sur quel formulaire l'agent travaille.

Il n'existe pas encore de mécanisme de découverte intégré. Un agent doit visiter votre page pour connaître les outils offerts. L'équipe Chrome a évoqué l'idée d'un manifeste .well-known/webmcp pour une découverte avant visite, mais rien n'est spécifié à ce stade.

Comme WebMCP est encore en préversion, attendez-vous à quelques aspérités et à des évolutions, d'autant que la spécification a déjà changé entre versions, y compris la suppression des méthodes provideContext et clearContext en mars 2026. 

La découvrabilité des outils se limite aux pages déjà consultées, et des enjeux de sécurité comme l'injection de consignes ou l'exfiltration de données via chaînage d'outils sont reconnus mais pas encore pleinement résolus. Consultez le changelog dans la documentation Chrome avant de commencer, car l'API a peut-être évolué depuis la rédaction de ce tutoriel.

Prérequis et mise en place de l'environnement WebMCP

Bien configurer l'environnement prend quelques minutes, mais la mauvaise version de Chrome vous en fera perdre bien davantage.

Chrome Canary version 146.0.7672.0 ou supérieure est requise. Les canaux Stable, Beta et Dev de Chrome n'intègrent pas le flag WebMCP. Plusieurs développeurs sur les forums Chrome ont témoigné avoir installé la mauvaise version et cherché en vain le flag. Téléchargez-la spécifiquement depuis la page Canary.

Page de téléchargement de Chrome Canary

Au-delà du navigateur, vous devez maîtriser les formulaires HTML et la gestion d'événements en JavaScript. Pour une remise à niveau, le cours Introduction to JavaScript de DataCamp couvre les fondamentaux. 

L'extension Model Context Tool Inspector n'est pas strictement indispensable, mais elle vaut la peine. Elle liste tous les outils enregistrés sur la page courante, permet de les exécuter manuellement avec vos paramètres, et intègre l'API Gemini pour tester les invocations en langage naturel.

Activer le flag expérimental WebMCP

Avec Chrome Canary installé :

1. Saisissez chrome://flags/#enable-webmcp-testing dans la barre d'adresse.
2. Passez le flag « WebMCP for testing » sur Enabled.
3. Cliquez sur Relaunch en bas de la page.

La page chrome://flags avec le flag WebMCP activé (Enabled).

Après le redémarrage, ouvrez DevTools (F12), allez dans l'onglet Console et exécutez :

console.log(navigator.modelContext);Propulsé par

Console DevTools montrant l'objet navigator.modelContext.

Obtenir un objet (plutôt que undefined) confirme que l'API est disponible. À partir de là, vous pouvez installer l'extension Model Context Tool Inspector et ouvrir la démo de voyage de Google pour voir l'enregistrement d'outils en situation. 

Là, lancez simplement l'extension : vous devriez voir quelque chose comme ceci :

Vérification de l'outil searchFlights avec l'extension Model Context Tool Inspector de Chrome avec le site démo Flight Search de Google. 

Comme vous le voyez, l'extension détecte l'outil searchFlights et expose son schéma d'entrée, ce qui donne au modèle une compréhension bien plus claire de la façon d'interagir avec la page.

Créer votre première intégration WebMCP

Vous pouvez démarrer de deux manières ; nous présentons les deux approches ci-dessous :

L'approche déclarative (HTML)

La façon la plus simple d'enregistrer un outil WebMCP est d'annoter un formulaire déjà présent sur votre page. Voici un formulaire de recherche produit standard, sans annotations WebMCP :

<form action="/search" method="GET">
  <label for="query">Search term</label>
  <input type="text" name="query" id="query" required>

  <label for="category">Category</label>
  <select name="category" id="category">
    <option value="all">All categories</option>
    <option value="electronics">Electronics</option>
    <option value="books">Books</option>
    <option value="clothing">Clothing</option>
  </select>

  <button type="submit">Search</button>
</form>Propulsé par

Quatre attributs transforment ce formulaire en outil appelable par un agent. toolname et tooldescription se mettent sur la balise <form>. Sur les champs, toolparamtitle et toolparamdescription supplantent des libellés trop vagues pour être exploitables par un agent :

<form toolname="search_products"
      tooldescription="Search the product catalog by keyword and optional category filter"
      action="/search" method="GET">

  <label for="query">Search term</label>
  <input type="text" name="query" id="query" required
         toolparamdescription="The keyword or phrase to search for in product titles and descriptions">

  <label for="category">Category</label>
  <select name="category" id="category"
          toolparamtitle="Product Category"
          toolparamdescription="Filter results to a specific product category. Use 'all' for no filter.">
    <option value="all">All categories</option>
    <option value="electronics">Electronics</option>
    <option value="books">Books</option>
    <option value="clothing">Clothing</option>
  </select>

  <button type="submit">Search</button>
</form>Propulsé par

Le navigateur génère alors en interne un schéma JSON. Le nom de l'outil, les types de paramètres, les valeurs d'énumération depuis les options <select> et les indicateurs required déduits du HTML sont repris sans configuration supplémentaire.

Pour tester, créez un fichier .html en local avec un éditeur de texte, collez le code ci-dessus et ouvrez-le dans Chrome via file:///{votre_document.html} ; pour faire fonctionner l'extension avec un fichier local, ouvrez ses paramètres, allez dans Détails et autorisez l'accès aux URL de fichiers, comme sur la capture ci-dessous.

Autoriser l'extension à accéder aux fichiers locaux.

Sinon, votre navigateur ne pourra pas interagir avec votre fichier HTML local. Une fois fait, ouvrez le fichier dans Chrome et consultez l'extension WebMCP : vous devriez voir un résultat semblable à la capture suivante. 

L'extension affiche le schéma généré pour l'outil search_products après ajout des annotations.

Que se passe-t-il concrètement quand un agent appelle cet outil ? 

Chrome focalise le formulaire, pré-remplit les champs avec les valeurs fournies par l'agent, et s'arrête là. L'utilisateur doit encore cliquer sur Envoyer. Ce comportement par défaut est volontaire : l'humain doit confirmer l'action avant son exécution.

L'attribut toolautosubmit sur la balise form supprime cette étape de confirmation. C'est pertinent pour des opérations en lecture seule comme une recherche. Pour toute action qui modifie des données, génère un achat ou change des réglages de compte, laissez-le de côté.

Il existe aussi un moyen d'intercepter l'envoi et de renvoyer un résultat structuré à l'agent. La méthode respondWith() sur l'événement submit accepte une promesse, et sa valeur résolue devient la sortie de l'outil :

<form toolname="search_products"
      tooldescription="Search the product catalog"
      toolautosubmit
      action="/search">
  <input type="text" name="query" required>
  <button type="submit">Search</button>
</form>

<script>
  document.querySelector("form").addEventListener("submit", (e) => {
    e.preventDefault();

    const query = new FormData(e.target).get("query");

    if (!query || query.trim().length === 0) {
      if (e.agentInvoked) {
        e.respondWith(Promise.resolve({
          error: "Search query cannot be empty. Please provide a keyword."
        }));
      }
      return;
    }

    const results = performSearch(query);

    if (e.agentInvoked) {
      e.respondWith(Promise.resolve({
        content: [{ type: "text", text: JSON.stringify(results) }]
      }));
    }
  });
</script>Propulsé par

Le booléen agentInvoked sur l'événement submit vaut true quand un agent a déclenché l'envoi, et false pour un clic humain classique. Vous pouvez l'utiliser pour différencier la réponse à renvoyer à l'agent de votre traitement habituel du formulaire.

S'il n'y a pas de toolparamdescription sur un champ, le navigateur reprend la description depuis l'élément <label> associé, ou à défaut depuis l'attribut aria-description. Un balisage accessible fournit donc déjà des descriptions de paramètres raisonnables sans effort supplémentaire.

Petite particularité actuelle : pour un groupe d'éléments <input type="radio">, toolparamdescription doit être placé sur le premier bouton radio, et s'applique à l'ensemble du paramètre.

L'approche impérative (JavaScript)

Les formulaires couvrent beaucoup de cas, mais certains outils doivent interagir avec l'état de l'application, appeler des API ou renvoyer des résultats calculés qui ne correspondent pas à un envoi de formulaire classique. Voici un outil basique qui ajoute des entrées à une to-do list :

window.navigator.modelContext.registerTool({
  name: "addTodo",
  description: "Add a new item to the user's to-do list. Use when the user asks to create, add, or remember a task.",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "The task description"
      },
      priority: {
        type: "string",
        enum: ["low", "medium", "high"],
        description: "Task priority level. Default to 'medium' if not specified by the user."
      }
    },
    required: ["text"]
  },
  execute: ({ text, priority = "medium" }) => {
    const newItem = { id: Date.now(), text, priority, done: false };
    todoApp.addItem(newItem);
    todoApp.renderList();

    return {
      content: [{
        type: "text",
        text: Added task: "${text}" with ${priority} priority. The to-do list now has ${todoApp.getCount()} items.
      }]
    };
  }
});Propulsé par

Le callback execute reçoit les paramètres envoyés par l'agent (ils doivent respecter l'inputSchema), exécute votre logique applicative et renvoie un tableau content. 

Un détail important : mettez l'UI à jour avant de renvoyer la réponse. 

Les agents vérifient parfois l'état visuel de la page après un appel d'outil pour confirmer la réussite ; si l'UI n'a pas encore changé, ils peuvent conclure à tort à un échec. Vous pouvez enregistrer et désenregistrer des outils au fil de l'évolution de l'état de la page :

function onUserLogin(user) {
  navigator.modelContext.registerTool({
    name: "viewOrderHistory",
    description: "Show the user's past orders with dates and totals",
    inputSchema: {
      type: "object",
      properties: {
        limit: {
          type: "number",
          description: "Maximum number of orders to return. Defaults to 10."
        }
      }
    },
    execute: async ({ limit = 10 }) => {
      const orders = await fetchOrders(user.id, limit);
      return {
        content: [{ type: "text", text: JSON.stringify(orders) }]
      };
    }
  });
}

function onUserLogout() {
  navigator.modelContext.unregisterTool("viewOrderHistory");
}Propulsé par

Un scénario plus réaliste : une page de réservation au restaurant qui vérifie la disponibilité des tables. Cet exemple montre aussi une validation côté code, recommandée par la documentation Chrome : les contraintes de schéma aident les agents mais ne sont pas toujours appliquées par tous.

navigator.modelContext.registerTool({
  name: "checkAvailability",
  description: "Check table availability for a given date and party size at this restaurant. Returns available time slots.",
  inputSchema: {
    type: "object",
    properties: {
      date: {
        type: "string",
        description: "The desired reservation date in YYYY-MM-DD format"
      },
      partySize: {
        type: "number",
        description: "Number of guests, between 1 and 12"
      }
    },
    required: ["date", "partySize"]
  },
  execute: async ({ date, partySize }) => {
    if (partySize < 1 || partySize > 12) {
      return {
        content: [{
          type: "text",
          text: "Party size must be between 1 and 12. For larger groups, please call the restaurant directly at (555) 123-4567."
        }]
      };
    }

    const parsedDate = new Date(date);
    if (isNaN(parsedDate.getTime()) || parsedDate < new Date()) {
      return {
        content: [{
          type: "text",
          text: "Please provide a valid future date in YYYY-MM-DD format."
        }]
      };
    }

    const slots = await api.getAvailableSlots(date, partySize);
    renderAvailabilityCalendar(date, slots);

    return {
      content: [{
        type: "text",
        text: JSON.stringify({
          date,
          partySize,
          availableSlots: slots.map(s => s.time),
          message: slots.length > 0
            ? Found ${slots.length} available time slots.
            : "No availability for this date. Try a different date or smaller party."
        })
      }]
    };
  }
});Propulsé par

Quelques points de la documentation Chrome méritent d'être soulignés : acceptez autant que possible les entrées brutes de l'utilisateur. Si quelqu'un dit « 11:00 à 15:00 », votre outil devrait accepter ces chaînes telles quelles, sans imposer une conversion en minutes depuis minuit ou un autre format interne. 

Validez dans le code, pas uniquement via le schéma, car l'application stricte du schéma varie selon les agents. Et ne renvoyez une réponse qu'une fois l'UI mise à jour, puisque les agents peuvent regarder la page pour confirmer l'opération.

Pour des outils MCP côté serveur complémentaires à une mise en oeuvre WebMCP côté client, notre guide sur la création de serveurs MCP avec FastMCP détaille toute la configuration.

Gérer l'invocation par agent et la sécurité dans WebMCP

La spécification WebMCP part du principe qu'un humain supervise. Les auteurs chez Google et Microsoft l'ont conçue pour des workflows coopératifs, pas pour une autonomie totale. Les mécanismes ci-dessous reflètent cette philosophie.

Distinguer utilisateur humain et agent d'IA

Une nouvelle propriété booléenne nommée agentInvoked apparaît sur l'interface SubmitEvent. Quand un agent déclenche l'envoi d'un formulaire, la propriété vaut true. Quand une personne clique sur Envoyer, elle vaut false.

document.querySelector("form").addEventListener("submit", (e) => {
  if (e.agentInvoked) {
    console.log("AI agent submitted the form");
    if (!isWithinAgentRateLimit()) {
      e.preventDefault();
      e.respondWith(Promise.resolve({
        error: "Too many requests. Please wait before trying again."
      }));
      return;
    }
  }
});Propulsé par

Au-delà des envois de formulaires, deux événements au niveau window suivent l'activité des agents. toolactivated se déclenche après l'invocation d'un outil par un agent, et Chrome pré-remplit les champs du formulaire associé. toolcancel se déclenche si l'utilisateur annule l'opération ou réinitialise le formulaire. 

Aucun des deux événements n'est annulable, mais tous deux portent une propriété toolName pour identifier l'outil concerné.

window.addEventListener("toolactivated", ({ toolName }) => {
  showAgentActivityBanner(toolName);
});

window.addEventListener("toolcancel", ({ toolName }) => {
  hideAgentActivityBanner();
});Propulsé par

Imposer des permissions avec humain dans la boucle

Avec les outils déclaratifs, le comportement par défaut exige que l'humain clique sur Envoyer après le pré-remplissage par l'agent. Conservez ce défaut pour toute action à conséquences réelles.

L'attribut toolautosubmit supprime cette étape. Réservez-le aux outils en lecture seule ou à faible risque : requêtes de recherche, vérifications de disponibilité, contrôles d'état. 

Toute action de création, modification ou suppression de données doit exiger un clic manuel.

Vous pouvez styliser l'état d'interaction de l'agent avec des pseudo-classes CSS :

form:tool-form-active {
  border: 2px solid #2563eb;
  background-color: #eff6ff;
  font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">1rem;
  border-radius: 8px;
}

form:tool-form-active::before {
  content: "AI agent is filling this form";
  display: block;
  font-size: 0.875rem;
  color: #2563eb;
  font-weight: 600;
  font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">0.5rem;
}Propulsé par

Formulaire avec le style :tool-form-active appliqué, bordure bleue et « AI agent is filling this form ».

Les outils impératifs posent un autre défi. Il n'y a ni formulaire ni bouton Envoyer : l'exécution démarre immédiatement quand l'agent appelle l'outil. 

Pour toute opération qui ne doit pas se faire sans approbation humaine, intégrez la confirmation au sein même de l'outil :

navigator.modelContext.registerTool({
  name: "deleteAccount",
  description: "Permanently delete the user's account and all associated data. Cannot be undone.",
  inputSchema: {
    type: "object",
    properties: {
      confirmPhrase: {
        type: "string",
        description: "The user must type 'DELETE MY ACCOUNT' to confirm."
      }
    },
    required: ["confirmPhrase"]
  },
  execute: ({ confirmPhrase }) => {
    if (confirmPhrase !== "DELETE MY ACCOUNT") {
      return {
        content: [{
          type: "text",
          text: "Confirmation phrase does not match. Ask the user to confirm explicitly."
        }]
      };
    }

    return new Promise((resolve) => {
      showConfirmationModal("Are you sure?", {
        onConfirm: async () => {
          await api.deleteAccount();
          resolve({ content: [{ type: "text", text: "Account deleted." }] });
        },
        onCancel: () => {
          resolve({ content: [{ type: "text", text: "Deletion cancelled by user." }] });
        }
      });
    });
  }
});Propulsé par

Le même schéma s'applique dans tout l'écosystème MCP : l'agent exprime une intention, l'humain confirme l'exécution. Pour une vue d'ensemble des mises en oeuvre, consultez notre panorama des meilleurs serveurs et clients MCP.

Tester votre implémentation WebMCP

Une fois votre première intégration WebMCP en place, il est temps de la tester. 

Utiliser le simulateur d'agent de Chrome DevTools

Après avoir installé l'extension Model Context Tool Inspector, un petit badge sur son icône indique le nombre d'outils enregistrés sur la page. Le panneau affiche pour chacun son nom, sa description et son schéma d'entrée. Si un outil n'apparaît pas, son enregistrement a échoué.

Panneau de l'extension listant plusieurs outils enregistrés, schémas dépliés.

Pour tester le simulateur d'agent, revenons au site démo Flight Search de Google. Nous pouvons désormais tester l'exécution manuelle ou en langage naturel. 

Exécution manuelle

L'exécution manuelle supprime l'aléa dans les tests d'agent. Sélectionnez un outil dans la liste déroulante du panneau, saisissez un objet JSON dans « Input Arguments », puis cliquez sur « Execute Tool ». L'extension appelle directement l'outil avec vos paramètres.

Extension avec l'outil searchFlights sélectionné, paramètres JSON remplis, bouton Execute Tool visible.

C'est idéal pour isoler un problème. Si un outil fonctionne avec des paramètres saisis à la main mais échoue quand l'agent l'appelle, c'est probablement la description ou le schéma qui posent souci, pas la fonction execute. Par exemple, sur la démo voyage de Google :

{
  "origin": "LON",
  "destination": "NYC",
  "tripType": "round-trip",
  "outboundDate": "2026-06-10",
  "inboundDate": "2026-06-17",
  "passengers": 2
}Propulsé par

La page de démo présente les résultats après exécution manuelle de l'outil.

Tests en langage naturel

Les tests en langage naturel utilisent l'API Gemini. Collez une clé depuis AI Studio dans les paramètres de l'extension, puis saisissez une consigne du type 

Search for round-trip flights from London to New York leaving June 10th, returning June 17th, for 2 passengers.Propulsé par

L'extension envoie cette requête à Gemini 2.5 Flash accompagnée de vos définitions d'outils, et le modèle choisit l'outil à invoquer et les bons paramètres.

Champ de saisie en langage naturel avec une consigne et réponse d'invocation d'outil par l'agent.

Si l'agent choisit le mauvais outil ou mappe mal les paramètres, vos descriptions d'outils doivent sans doute être plus précises. Privilégiez des descriptions positives et explicites (« utilisez-le pour vérifier la disponibilité des vols »), plutôt que de décrire ce qu'il ne faut pas faire.

Séquence de test pratique :

1. Vérifiez que les outils apparaissent dans l'extension après le chargement de la page.
2. Exécutez chaque outil manuellement avec des paramètres corrects. Confirmez que la logique execute fonctionne et que l'UI se met à jour comme prévu.
3. Testez avec de mauvais paramètres. Vérifiez que votre validation intercepte les erreurs et que les messages sont assez clairs pour que l'agent se corrige.
4. Testez en langage naturel. Voyez si l'agent choisit le bon outil et traduit correctement les mots de l'utilisateur en paramètres du schéma.
5. Couvrez les cas limites : utilisateurs non authentifiés, formulaires désactivés, indisponibilité d'API, appels répétés rapidement.

Pour le contexte des outils MCP dans l'écosystème Google, notre tutoriel Google MCP Servers couvre plusieurs modèles pertinents. Et pour une vue plus large au-delà de Chrome, consultez Top Remote MCP Servers.

Conclusion

WebMCP offre aux sites un canal de communication direct avec les agents d'IA. Plutôt que de deviner l'interface, l'agent appelle des outils structurés publiés par la page avec des paramètres typés. L'API déclarative transforme des formulaires existants en outils appelables par agent avec quelques attributs HTML. L'API impérative couvre tout le reste. Le modèle de sécurité maintient l'humain aux commandes pour les actions sensibles.

La spécification est encore jeune, uniquement disponible dans Chrome Canary derrière un flag, et inadaptée à la production. Mais le fait que Google et Microsoft la coécrivent, sous gouvernance W3C, suggère une vraie trajectoire vers un standard stable. Investir du temps maintenant vous permettra de maîtriser les patterns et mécanismes de sécurité quand la version stable arrivera.

Pour vous préparer, auditez les formulaires de vos sites et identifiez ceux qui profiteraient le plus d'un accès par agent. Les formulaires de recherche et vérifications de disponibilité sont des points de départ peu risqués. Une fois l'API déclarative apprivoisée, passez aux outils impératifs pour les workflows à logique personnalisée. 

Pour aller plus loin :

• Tutoriel MCP Model Context Protocol pour les concepts fondamentaux derrière WebMCP.
• Créer des serveurs MCP avec FastMCP pour des outils MCP côté serveur complémentaires à WebMCP côté client.
• Tutoriel Google MCP Servers pour les modèles d'intégration spécifiques à Google.
• Top Remote MCP Servers et Top MCP Servers and Clients pour une vision d'ensemble de l'écosystème.