Un agent de navigateur voit un bouton et estime sa position. Cela peut fonctionner. Mais une application web peut aussi communiquer sa signification de manière plus explicite : cette action recherche des rendez-vous disponibles, attend une date et renvoie une liste. C’est précisément ce passage de la position de clic à l’outil décrit qui rend WebMCP intéressant.
Selon l’état documenté, WebMCP est une proposition expérimentale. L’explainer actuel couvre l’enregistrement impératif via JavaScript et document.modelContext. Les outils de formulaire HTML déclaratifs sont explorés séparément et ne font pas actuellement partie de cette spécification. La page de présentation de Chrome datée du 18 mai 2026 ne justifie donc pas d’annoncer en octobre une nouvelle fonctionnalité universelle des navigateurs.
Un outil commence par une action limitée
Notre propre exemple s’appelle « trouver des rendez-vous disponibles ». Sa tâche s’arrête à l’information. Il ne crée pas de réservation. La description elle-même devrait déjà l’indiquer clairement, afin qu’un agent ne transforme pas un résultat de recherche en rendez-vous confirmé.
L’entrée contient une date et une prestation proposée. Le résultat indique la même référence ainsi que les créneaux disponibles. Une valeur isolée telle que « 10:30 » serait moins solide : elle pourrait appartenir à un autre jour ou à une autre prestation. Un résultat structuré est particulièrement utile lorsque ses entrées peuvent être interprétées sans ambiguïté.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Il s’agit de notre schéma pédagogique, et non d’un enregistrement WebMCP prêt à être copié. La date future et la prestation sont inventées. Il montre le contrat qu’une implémentation réelle devrait spécifier. Pour la syntaxe concrète de l’API, c’est la documentation expérimentale actuelle qui fait foi.
Les erreurs ont elles aussi besoin d’une signification compréhensible
Une date invalide, l’absence de rendez-vous disponibles et une prestation inaccessible pour des raisons techniques sont trois résultats différents. Si tous produisaient simplement une liste vide, l’agent devrait deviner la cause. La réponse de l’outil devrait donc transmettre un état compréhensible et les informations nécessaires à la décision suivante.
Il en va de même pour les informations partielles. La recherche est-elle complète, ou manque-t-il encore des données ? La réponse correspond-elle à la dernière demande ? La personne a-t-elle modifié la date entre-temps ? Ces questions se posent, que l’interface soit sollicitée au moyen d’une capture d’écran ou d’un outil.
Une description n’est pas une autorisation
Un schéma d’entrée correct indique quelle forme une requête doit prendre. Il ne décide pas si l’appelant a le droit de lire ces informations. L’application doit toujours appliquer ses propres règles. Un nom d’outil qui sonne bien n’est ni une connexion ni un contrôle d’accès.
Le passage à la réservation a lui aussi besoin d’une signification propre. « Rechercher des créneaux disponibles » et « réserver ce créneau pour moi » ont des conséquences différentes. Ces actions ne devraient pas se fondre discrètement en une seule fonction. Une réservation réelle devrait tenir compte de l’élément confirmé et de l’instruction voulue.
Pour un premier exercice de conception sans risque, des données d’exemple fixes suffisent donc. Décrivez trois états de réponse et déterminez quelle action suivante serait raisonnable dans chaque cas. Vous pouvez ainsi tester la clarté du contrat sans simuler une vraie réservation ni un environnement d’exécution WebMCP existant.
WebMCP n’est pas automatiquement un serveur MCP distant existant
Le mot MCP apparaît dans divers contextes techniques. Une action décrite côté navigateur n’est pas, pour cette seule raison, le même type de connexion qu’un serveur d’outils distant accessible via HTTP. Pour une connexion donnée, ce qui compte, ce sont le client, le transport, la connexion et les outils réellement proposés.
Un accès MCP distant existant ne prouve donc pas qu’un site web prend en charge WebMCP. De même, une proposition expérimentale de navigateur ne garantit pas que chaque agent puisse déjà l’utiliser. Cette distinction est pratique : elle évite qu’un nom similaire conduise à un mauvais plan d’intégration.
La question transposable reste claire. Une application peut-elle exprimer quelle action, avec quelles entrées, a quel résultat et quel effet ? Plus cette réponse est précise, moins un agent doit deviner à partir d’une position à l’écran. De bons contrats d’outil rendent la marge de manœuvre plus facile à comprendre ; les règles de l’application restent néanmoins sous sa propre responsabilité.
Sources et état
Recherches et documentation à la date du 25 octobre 2026. WebMCP · Explainer WebMCP.
