Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise
Pont navigateur WebMCP
Statut : Expérimental Portée : public, état actuel Dernière revue : 2026-10-10 Responsable : mainteneurs d’AX Code
Le pont WebMCP permet à l’agent d’ouvrir des pages dans une fenêtre Chrome isolée, de les lire et, facultativement, d’agir dessus. Il est expérimental, désactivé par défaut, et exige Chrome 150 ou plus récent.
WebMCP est une proposition de norme web. Une page peut enregistrer des outils structurés — un nom, une description et un schéma d’entrée — afin qu’un agent puisse appeler ces actions directement. AX Code consomme les outils qu’une page enregistre, et il peut aussi lire la page elle-même et agir dessus.
Codex et ChatGPT Work documentent la version de la même norme dans leur navigateur intégré sous le nom outils de site. Cette page montre comment leur application de bureau active WebMCP, comment un visiteur inspecte les outils qu’un site offre, et comment un auteur de site enregistre un outil. Les étapes ci-dessous sont celles d’AX Code.
L'activer avec Chrome
- Installez Google Chrome 150 ou plus récent. Chromium à la même version majeure fonctionne aussi. AX Code démarre sa propre fenêtre Chrome sur un profil neuf et laisse tranquille une fenêtre Chrome déjà ouverte.
- Démarrez l’interface de terminal avec
ax-code. - Cliquez sur la pastille WebMCP dans le pied de la barre latérale, ou sur la même pastille dans le pied de l’invite d’accueil, ou exécutez
/webmcp. Le clic ou la commande constitue le consentement. Aucun navigateur ne démarre avant cela. AX Code vérifie d’abord, sans démarrer de navigateur, si un Chrome 150 ou plus récent est installé aux emplacements habituels, et vous avertit sinon ; le contrôle est un conseil et ne bloque jamais la tentative. Votre choix est enregistré dans votre configuration utilisateur, donc le pont revient activé au prochain démarrage sans autre clic. - AX Code ouvre cette fenêtre isolée avec la fonctionnalité WebMCP activée (
--enable-features=WebMCP). La fenêtre ne contient aucune session tant que vous ne vous y connectez pas à la main. - Demandez à l’agent d’ouvrir une page. Avec le défaut du produit, la navigation n’est pas restreinte. Une liste d’origines configurée ou gérée la resserre.
- Cliquez de nouveau sur la pastille pour désactiver le pont. Cela met fin aux octrois temporaires de session ; les approbations enregistrées restent jusqu’à ce que vous les révoquiez dans les réglages MCP.
La pastille affiche [act] tant que le palier d’interaction est activé. Le défaut du produit inclut ce palier. Pour le désactiver, réglez interact sur faux dans le profil webmcp de l’entrée. Une entrée enregistrée plus tôt conserve les paliers qu’elle avait.
ax-code mcp webmcp affiche un extrait de configuration. Il n’installe pas de paquet, ne connecte pas de serveur et n’écrit pas de fichier. Ajoutez --interact pour afficher une entrée avec le palier d’interaction activé, ou --executable-path /absolute/path/to/chrome pour nommer un binaire Chrome 150+ précis. Lorsque ce chemin est défini, AX Code vérifie la version majeure du binaire avant le lancement.
Outils dans une fenêtre Chrome que vous avez ouverte vous-même
La fenêtre isolée ci-dessus a déjà WebMCP activé. Pour essayer les outils de page dans le profil Chrome que vous utilisez en construisant un site, suivez le guide WebMCP de Chrome :
- Ouvrez
chrome://flags/#enable-webmcp-testing. - Réglez le drapeau sur Activé.
- Relancez Chrome.
Ce drapeau s’applique au profil Chrome que vous avez ouvert. Le pont AX Code démarre encore depuis la pastille.
Indice d'invite
Tant que le pont est désactivé, une invite qui nomme une URL ou un serveur local (par exemple localhost:3000) montre un pointeur d’une ligne vers la pastille et /webmcp. Il apparaît au plus une fois par session et trois fois au total, et il ne change jamais ce qui est envoyé à l’agent.
Ce que l'agent peut faire
| Palier | Outils | Approbation |
|---|---|---|
| Pages | lister, ouvrir, naviguer, fermer des pages ; exécuter les outils qu’une page enregistre via WebMCP | chaque appel, sauf si une portée prise en charge a été enregistrée |
| Lecture | instantané de page, capture d’écran, console, métadonnées de requête | un octroi par origine et par session, ou une approbation de lecture enregistrée |
| Interaction | clic, survol, attente, remplissage, remplissage de formulaire, appui sur une touche, réponse aux boîtes de dialogue | voir plus bas |
Le contenu de page n’est pas fiable : une page peut tenter d’orienter l’agent. La sortie est étiquetée avec son origine et limitée en taille.
Enregistrer une approbation
Les invites éligibles proposent Ajouter à la liste d’autorisation WebMCP avec un fond rouge. Sélectionnez-la, revoyez la portée, puis choisissez Ajouter et autoriser. Les approbations enregistrées s’appliquent à ce projet sur cette machine et survivent aux reconnexions du navigateur et aux redémarrages d’AX Code.
- Le listage des pages approuve
list_pagespour le navigateur AX Code, y compris les titres et les URL de toutes les origines ouvertes. Il n’approuve pas le contenu des pages. - La navigation approuve l’ouverture ou la navigation vers une origine exacte.
- La lecture approuve les instantanés, les captures d’écran, la console et les métadonnées réseau sur une origine exacte. Les autres origines et ports ont besoin de leur propre approbation.
- La fermeture approuve la fermeture de toute page actuellement sur une origine exacte, y compris les pages avec du travail non enregistré. C’est un choix distinct : les approbations de navigation et de lecture ne l’accordent pas. L’origine cible est revérifiée avant la fermeture.
Après la première approbation de lecture, AX Code poursuit cette lecture dans le même appel après avoir revérifié la page. Un changement de page ou de pont arrête l’appel et exige une lecture neuve. Il ne rejoue pas une opération de navigateur échouée.
Les restrictions de navigation et la politique d’administrateur s’appliquent encore. Enregistrer une approbation ne modifie pas allowedOrigins. La saisie, les clics conséquents, les boîtes de dialogue et les outils enregistrés par la page conservent leurs approbations existantes. Autoriser une fois reste temporaire ; le compte à rebours n’enregistre jamais une approbation persistante.
Sélectionnez le lien liste d’autorisation WebMCP à côté de la pastille WebMCP (pied de la barre latérale de session et pied de l’invite d’accueil), exécutez /webmcp-allowlist, ou ouvrez /mcp, sélectionnez le pont et appuyez sur Ctrl+G. Double-cliquez une entrée (ou appuyez deux fois sur Enter) pour la révoquer ; la première activation marque la ligne et une seconde dans les quelques secondes confirme, donc un seul clic ne révoque jamais. La ligne d’effacement révoque de la même façon toutes les approbations enregistrées pour ce pont dans ce projet. Les longues listes défilent. Appuyez sur Échap ou cliquez hors du panneau pour le fermer.
La zone de recherche ajoute aussi des approbations. Saisissez une origine https:// exacte (ou http://localhost), puis sélectionnez la ligne de navigation, de lecture ou de fermeture pour l’enregistrer ; une ligne de listage de pages est proposée jusqu’à son enregistrement. Le pont doit être connecté : une approbation explicite se lie à l’identité du pont en cours et est vérifiée à chaque appel, exactement comme une approbation enregistrée depuis une invite, donc les listes d’origines gérées, le commutateur du palier de lecture et la politique d’administrateur s’appliquent encore. Désactiver la pastille WebMCP déconnecte le navigateur et conserve les choix enregistrés.
Le magasin local est ~/.local/share/ax-code/webmcp-approvals.json par défaut (les forçages de répertoire de données XDG s’appliquent). Les approbations sont liées à l’identité du pont ; changer son lancement ou son profil de navigateur exige une approbation neuve.
Échecs de navigation
Une erreur de navigation peut survenir après l’ouverture ou le changement d’une page. L’erreur signale une catégorie reconnue de délai, de réseau ou de page manquante lorsqu’elle est disponible, sans répéter le texte d’erreur brut du pont. Inspectez list_pages avant de décider de naviguer de nouveau. Les erreurs de navigation ne retirent pas les approbations enregistrées.
Palier d'interaction
Les survols et les clics ordinaires s’exécutent sous un octroi par origine, valable pour 20 actions, puis la même invite revient.
- La saisie, les appuis de touche, les boîtes de dialogue, les liens, les doubles clics et les clics dont le nom semble conséquent (soumettre, payer, supprimer, autoriser, …) demandent à chaque fois, en montrant la cible et la valeur complète.
- Les champs dont le nom ressemble à un identifiant sont étiquetés et masqués. Les valeurs qui ont la forme de clés d’API ou de clés privées sont refusées : saisissez les identifiants vous-même.
- Les actions exigent un instantané frais de la même page ; une page déplacée ou un élément inconnu est refusé. Trois refus dans un tour arrêtent les actions suivantes.
Les contrôles fondés sur le nom sont des heuristiques, pas une garantie. L’invite est le contrôle, donc lisez-la.
Travailler avec une page existante
Demandez à AX Code d’inspecter les capacités de la page, de développer ses outils natifs, ou de diagnostiquer un comportement précis. L’outil browser_workflow regroupe ces tâches sans vous obliger à démarrer un serveur de test pour des observations ordinaires. Activez d’abord le pont et identifiez la page visée ; aucune de ces actions n’ouvre une page, ne connecte une session, ne change le profil du navigateur ni ne planifie un travail futur.
Par exemple : « Inspecte les outils de mon application locale et montre à quelles fonctions d’application ils correspondent », ou « Capture cette page avant que je reproduise les résultats vides, puis compare les erreurs et indique-moi des fichiers source candidats. »
Inspecter les outils natifs et leur source
Appelez status avec server, pageId et le origin exact pour voir les outils réellement admis et la disponibilité native ou d’instantané. Une liste vide n’établit pas que des cadres inaccessibles n’ont pas d’outils. Les connecteurs existants peuvent mieux convenir aux tâches qui n’ont pas besoin du contexte de page.
{
"action": "inventory",
"server": "webmcp",
"pageId": 1,
"origin": "http://localhost:3000",
"sourceFiles": ["src/tools.ts", "public/search.html"]
}
Conservez le inventoryId renvoyé. Passez-le comme baselineId lors d’un appel d’inventaire ultérieur pour voir les outils ajoutés ou retirés et les champs de schéma modifiés. Les fichiers sont explicitement contrôlés en permission, contenus dans le dépôt et bornés. Les enregistrements impératifs statiques et les attributs de formulaire HTML entre guillemets produisent des candidats de source ; les noms calculés, les définitions en double et les modèles non pris en charge restent non résolus ou ambigus. Un nom et un schéma correspondants corroborent un candidat, mais ne prouvent pas que le navigateur a chargé cette révision de source.
Générer une intégration d'application
Utilisez author pour renvoyer du code d’intégration révisable :
{
"action": "author",
"name": "find_products",
"description": "Find products matching a query in the current catalog.",
"module": "./src/catalog.js",
"exportName": "findProducts",
"schema": {
"type": "object",
"properties": { "query": { "type": "string" } },
"required": ["query"]
},
"format": "imperative",
"effect": "read"
}
La fonction nommée doit être un export direct. L’enregistrement généré prend un AbortSignal pour le nettoyage de composant ou de route. Ne définissez acceptsSignal: true que lorsque la fonction d’application accepte un second argument {signal} et le respecte. format: "declarative" renvoie un formulaire plus une liaison de module pour une soumission humaine ; connectez son événement webmcp-result à l’interface de l’application. Les champs primitifs sont pris en charge ; les contraintes de schéma non prises en charge sont rejetées au lieu d’être écartées en silence. Revoyez la validation de l’application, l’autorisation et les effets réels avant d’appliquer l’un ou l’autre modèle. Les modifications de champs peuvent déclencher un enregistrement automatique même lorsqu’un formulaire exige une soumission humaine.
Vérifier séparément l'exécution et la sélection de modèle
Les étapes contract existantes vérifient des entrées fixes et des résultats attendus. Ajoutez {"action":"tool_presence","name":"admin_reset","present":false} après un changement de route ou de rôle pour vérifier qu’une opération indisponible a été désenregistrée. present: true peut aussi épingler descriptorHash. Ce sont des points de contrôle du cycle de vie, pas une trace d’événements. Les régressions exportées incluent les mêmes contrôles.
Utilisez une évaluation de sélection distincte pour découvrir si un modèle choisit le bon outil et les bons arguments :
{
"action": "selection_eval",
"inventoryId": "<returned inventory UUID>",
"cases": [
{ "task": "Find AX products", "expected": { "name": "find_products", "arguments": { "query": "AX" } } },
{ "task": "Delete every product", "expected": { "name": null, "arguments": {} } }
],
"repeats": 2
}
Le modèle d’API sélectionné ne reçoit que la tâche et le catalogue capturé, sans outils d’exécution ni réponses attendues. Les appels sont approuvés et bornés à 12 cas, trois répétitions et une échéance d’évaluation de deux minutes. Le rapport enregistre l’identité du modèle, un hachage de suite, des comptes distincts de choix exact et d’arguments, l’exactitude conjointe et les issues inconnues. Les échecs restent au dénominateur. Les modèles CLI sont indisponibles pour cette évaluation parce qu’ils peuvent exécuter leurs propres outils. Les scores de sélection ne prouvent pas l’exactitude des outils et ne qualifient pas Arena.
Diagnostiquer avant et après une action
Appelez observe avec la même cible de page, un sourceFiles facultatif, et un assertions explicite utilisant le schéma existant de rôle, de nom, de compte, de valeur, d’état coché et de désactivation. Effectuez l’action demandée une fois, par un outil approuvé ou à la main. Puis appelez {"action":"diagnose","observationId":"<returned UUID>"}. Le résultat compare les issues d’assertions, les hachages d’instantanés, les deltas bornés de console et de métadonnées de requête, les changements d’inventaire sémantique et les candidats de source. La corrélation est une preuve à examiner, pas une cause racine prouvée. Sans assertions, l’état est observed, pas pass.
Les lignes de base ne sont conservées que dans la session d’exécution courante, expirent après 30 minutes et sont limitées à 16 par session. Les changements de connexion ou d’emplacement de page invalident la réutilisation. Le pont épinglé ne peut pas identifier un rechargement de la même URL, donc ces comparaisons restent consultatives. Seuls les hachages des emplacements de page et des instantanés sont conservés ; le texte diagnostique borné et les descripteurs d’outils sont des preuves non fiables.
Pour un problème localhost reproductible, promote prend l’identifiant d’observation et un manifest normal explicite contenant la commande du serveur de test local et les étapes. Il fige un nouveau scénario contrôlé. Les résultats d’observation ne sont jamais copiés dans l’acceptation : exécutez un contrôle en échec avant de modifier, et qualifiez les exécutions corrigées par le flux existant.
Répéter une tâche d'observation quotidienne
Une recette à la demande vérifie une page existante sans navigation ni planification :
{
"action": "recipe",
"server": "webmcp",
"pageId": 1,
"definition": {
"version": 1,
"name": "Preview health",
"origin": "http://localhost:3000",
"assertions": [{ "locator": { "role": "status", "name": "Ready" }, "property": "count", "equals": 1 }]
}
}
Le défaut est l’instantané seul. Les queries facultatifs contiennent un outil exact name, descriptorHash, un objet input, resultPath et equals. Ils invoquent de véritables outils d’application sous l’approbation existante par appel ; les indications de lecture seule ne certifient pas les effets. Le résultat distingue explicitement l’observation d’instantané des appels d’application aux effets non vérifiés, et revérifie les instantanés après les requêtes. Enregistrez des définitions revues, pas des contenus capturés ni des identifiants. Les définitions ne portent aucune permission et ne deviennent jamais des reçus Arena. Un succès signifie seulement que les observations déclarées ont correspondu ; des données manquantes ne peuvent pas satisfaire un contrôle.
Enregistrer un outil manuellement
Demandez à l’agent d’ajouter un outil qui réutilise une logique déjà présente sur votre page, ou enregistrez-en un depuis le JavaScript de la page. Le guide de Chrome couvre l’API impérative et l’API de formulaire déclarative. Un outil minimal en lecture seule ressemble à ceci :
if (typeof document.modelContext?.registerTool === "function") {
await document.modelContext.registerTool({
name: "read_heading",
description: "Read the main heading of the current page.",
inputSchema: {
type: "object",
properties: {},
additionalProperties: false,
},
annotations: { readOnlyHint: true },
execute: async () => ({
heading: document.querySelector("h1")?.textContent ?? "",
}),
})
}
Un agent compatible peut alors découvrir read_heading sur cette page. La page outils de site d’OpenAI parcourt la même idée du côté de Codex et de ChatGPT Work, y compris la façon dont leur navigateur intégré liste les outils qu’un site fournit.
Limites
Pas de scripts, de téléversements, de téléchargements, de cookies, de corps de requête, de coordonnées ni de glisser-déposer. Les administrateurs peuvent désactiver le pont ou l’un ou l’autre palier avec l’exigence gérée webmcp (allow, allowRead, allowInteract, allowedOrigins) ; la configuration de projet et d’utilisateur ne peut pas l’assouplir.
Les serveurs que vous ajoutez avec ax-code mcp add sont un chemin de confiance différent. Voir Intégrations MCP.
Déboguer une page localhost en cinq étapes
Pour une page qui s’affiche mal, un contrôle qui ne fait rien, ou une requête qui échoue :
- Naviguez vers la page et prenez un instantané — l’arbre d’accessibilité est la ligne de base structurelle. La navigation et les lectures utilisent les approbations existantes.
- Effectuez une fois l’action en échec, sous les approbations d’interaction existantes.
- Lisez le delta : erreurs de console et métadonnées réseau (méthode, URL, statut, type — les corps de requête et de réponse restent hors de portée) autour de l’action. Pour un état asynchrone, attendez ; ne répétez jamais l’action déclencheuse.
- Verdict : PASS, FAIL ou BLOCKED, avec la capacité manquante nommée. Un accusé de réception d’outil n’est pas une preuve de succès de l’application.
- Si l’échec localhost peut s’exprimer comme une assertion structurée, figez-le comme un scénario
browser_workflow(ci-dessous), enregistrez le contrôle en échec, et exécutez deux fois le même hachage après le correctif.
Joindre des preuves à un rapport de bogue
Pour un échec localhost examiné à travers un scénario figé, un lot de preuves rend le rapport révisable : le nom et le hachage du scénario, le résultat d’assertion en échec (sans contenu de page capturé), les identifiants de reçus issus de browser_workflow inspect, les hachages d’instantanés, les deltas bornés d’erreurs de console et de métadonnées réseau, les liens de source avec leurs étiquettes explicit/local_map/unresolved, et l’origine. N’incluez qu’une sortie bornée et expurgée par le runtime — jamais les corps de requête ou de réponse, les en-têtes, les cookies, le stockage, le contenu de page, ni les valeurs en forme d’identifiants. Les identifiants de reçus et les données de reçus copiées ne sont que des références ; l’état faisant autorité des reçus reste possédé par le runtime.
Reproduire et vérifier un changement de développement
L’outil browser_workflow fige les étapes d’acceptation avant que vous modifiiez une application web, les exécute à travers le pont WebMCP connecté, et enregistre des assertions structurées. Activez d’abord le pont. Le premier environnement pris en charge est un serveur HTTP jetable sur 127.0.0.1 ; chaque exécution alloue un port différent et un répertoire de données temporaire, plus un contexte de navigateur isolé neuf. Les profils de navigateur persistants sont refusés. Les contextes vides sont conservés par le pont amont jusqu’à la déconnexion ; après 32 exécutions sur une connexion, reconnectez le pont avant de continuer. Le flux ne réutilise jamais leurs cookies ni leur stockage.
Demandez à l’agent de figer un scénario avec action: "freeze". Par exemple, un test/browser-server.mjs appartenant au projet qui accepte un argument de port peut utiliser :
{
"action": "freeze",
"manifest": {
"version": 1,
"name": "Search returns a matching result",
"server": "node test/browser-server.mjs {port}",
"path": "/",
"setup": [],
"reset": [],
"cleanup": [],
"steps": [
{ "action": "fill", "locator": { "role": "textbox", "name": "Search" }, "value": "example" },
{
"action": "assert",
"assertion": {
"locator": { "role": "status", "name": "One result" },
"property": "count",
"equals": 1
}
}
]
}
}
Conservez le hachage renvoyé. Exécutez avec {"action":"run","hash":"<hash>","server":"webmcp"} (utilisez le nom de votre pont connecté). Reproduisez l’échec, faites le changement, et exécutez deux fois le même hachage. Chaque exécution démarre le serveur déclaré, ouvre sa propre page, vérifie les étapes, ferme la page et arrête son serveur. Les commandes de cycle de vie s’exécutent à la racine du dépôt à travers les permissions shell normales. {port} se développe vers le port alloué ; {data} se développe vers un répertoire temporaire entre guillemets. Les commandes de préparation, de réinitialisation et de nettoyage doivent se terminer en 15 secondes ; la disponibilité a une échéance de 15 secondes et l’exécution du navigateur a une échéance de 120 secondes. Les actions du navigateur conservent leurs permissions et leurs budgets d’interaction existants.
Les étapes prises en charge sont le clic, le survol, le remplissage, l’assertion structurée et les contrôles de contrat d’outil de page. Les localisateurs utilisent un rôle exact et un nom accessible. Les actions avec zéro ou plusieurs correspondances s’arrêtent en unknown ; il n’y a pas d’UID deviné ni de repli CSS ou de script. Les assertions comparent le compte, la valeur, l’état coché ou désactivé. Une propriété d’état absente est inconnue. Pour un rendu asynchrone, ajoutez timeoutMs (0-10000, défaut 0) à une étape assert. L’exécuteur interroge de nouveaux instantanés structurés jusqu’à ce que l’assertion corresponde ou que l’échéance expire ; il ne répète jamais le clic ou le remplissage précédent. Le délai est figé avec le scénario et conservé dans son test exporté. Les scénarios sont bornés à 32 étapes et 32 KiB.
inspect renvoie le manifeste figé et les reçus d’exécution. Les reçus lient le scénario à la révision et au contenu du dépôt, aux issues d’opérations, aux hachages d’instantanés et aux métadonnées bornées de console et de réseau. Une source modifiée, des opérations refusées, des preuves manquantes, des délais et un nettoyage incomplet ne peuvent pas réussir. Ces résultats valident les assertions déclarées ; ils ne prouvent pas chaque comportement de l’application. L’état figé et les reçus faisant autorité vivent dans la session d’exécution courante. Après un redémarrage, figez et qualifiez de nouveau ; les reçus JSON copiés ne sont pas acceptés comme autorité d’exécution.
Exporter un test de régression
{"action":"export","hash":"<hash>"} renvoie un module Node autonome utilisant playwright-core. Enregistrez le code renvoyé comme test de projet et exécutez-le avec AX_TEST_WEBMCP_CHROME pointant vers Chrome. Il démarre le même jeu d’essai et utilise des contextes de navigateur neufs, des localisateurs stables de rôle et de nom, et les assertions figées. Exécutez réellement le test exporté avant de le dire validé. Les tests exportés sont un artefact de régression indépendant ; leur sortie n’est pas un reçu Arena. Les étapes de contrat d’outil de page utilisent le protocole WebMCP natif de Chrome avec des hachages de descripteur exacts et une sortie attendue, sans évaluer de scripts de page arbitraires. Chrome doit prendre en charge ce protocole expérimental pour les exports de contrat.
Développer un contrat d'outil de page et enquêter sur les échecs
Avec une page ouverte, {"action":"contracts","server":"webmcp","pageId":1} renvoie ses descripteurs enregistrés et les hachages exacts de descripteurs. Figez une étape contract contenant name, descriptorHash, input, resultPath et equals. Les changements de hachage font échouer le contrôle. Définissez expectError: true pour les entrées négatives : seule une erreur confirmée d’exécution d’outil de page la satisfait ; les appels annulés, le refus de permission et l’achèvement manquant sont inconnus. Ajoutez des assertions après les mutations pour vérifier aussi l’état de page résultant, en plus de la valeur de retour.
L’action template prend name, un module d’application relatif, un exportName explicite et schema. Elle vérifie que l’export local existe et renvoie un squelette d’enregistrement. Revoyez-le par rapport à la validation des entrées, à l’autorisation et à la logique métier de l’application avant de l’activer ; l’outil ne peut pas établir ces garanties à partir d’un nom de fonction exportée.
Une liste facultative sources nomme des fichiers locaux au dépôt avec des line à base un et des column à base zéro, et facultativement un fichier local map. Les exécutions échouées renvoient des diagnostics bornés et des liens de source étiquetés explicit, local_map ou unresolved. La correspondance est consultative, jamais la preuve d’une cause racine ou d’une assertion réussie. Les cartes distantes, les chemins hors du dépôt et les fichiers de plus de 1 MiB ne sont pas lus. Les preuves réseau du navigateur restent seulement des métadonnées.
Exiger des preuves navigateur dans l'Arena d'implémentation
Fournissez browserScenario: "<hash>" avec mode: "implement". Figez le scénario et enregistrez une véritable assertion en échec sur la base propre courante avant de démarrer l’Arena. Chaque candidat reçoit ce contrat figé dans son worktree isolé et doit l’exécuter deux fois avec succès à travers son pont isolé connecté. L’activation du navigateur et les permissions restent supervisées. Un accès au pont manquant, un contenu périmé, des résultats inconnus ou des reçus manquants empêchent la promotion, même si les contrôles du dépôt réussissent. La vérification de code normale et les contrôles de mutation s’exécutent encore, et aucun candidat ne fusionne automatiquement.
Choisir les preuves efficacement
Les outils WebMCP natifs décrivent les opérations de l’application ; DevTools MCP de Chrome fournit l’inspection et l’automatisation du navigateur. Préférez un outil enregistré par la page pour une opération d’application explicite, puis vérifiez son résultat et l’état de page résultant. Utilisez les instantanés d’accessibilité pour le texte et les localisateurs d’éléments stables. Pour la mise en page, le canevas ou un contenu seulement image, prenez une capture d’écran : rognez vers un instantané frais uid ou utilisez JPEG avec une qualité réduite pour rester dans les limites en ligne. Interpréter les pixels exige un modèle capable de vision. Ni WebMCP ni la liste documentée des outils DevTools MCP ne fournit un outil OCR dédié ; le texte d’image inféré est consultatif et ne peut pas satisfaire une assertion d’acceptation structurée.
Restreignez les lectures de console avec types et pageSize ; restreignez les métadonnées réseau avec resourceTypes et pageSize. Les reçus de flux conservent les lignes de base d’avant l’action et les deltas bornés, afin que les erreurs introduites par la reproduction soient plus faciles à trouver. Les corps réseau et l’évaluation arbitraire restent hors de la surface accordée au pont. Les traces de performance, l’émulation, Lighthouse, les captures vidéo, la mémoire et les outils d’extension dans DevTools MCP amont sont des capacités distinctes et ne sont pas exposées par ce profil.
Voir le guide de débogage WebMCP de Chrome et la référence des outils DevTools MCP amont. La branche principale amont peut différer du pont épinglé d’AX Code ; seuls les schémas d’outils locaux décrivent les arguments pris en charge.