Appeler MyTools directement avec WebMCP

WebMCP est un standard web émergent qui permet à une page de donner à un agent IA une liste de fonctions appelables plutôt qu'un écran à interpréter. La page enregistre des outils sur document.modelContext — chacun avec un nom, une description et un schéma JSON — et un agent qui tourne dans ce navigateur peut les lister et les appeler.

MyTools enregistre trois outils globaux sur chaque page, et trois de plus sur chacune de ses 55 pages d'outils : lire l'état, lancer l'opération, sauvegarder le résultat. Le travail continue de se faire dans le navigateur, sur la machine de l'utilisateur. WebMCP change qui appuie sur le bouton, pas l'endroit où va le fichier.

Où cela fonctionne, et à quel point c'est stabilisé

Le navigateur de ChatGPT appelle déjà ces outils. OpenAI a ajouté la prise en charge de WebMCP au navigateur intégré à l'application de bureau ChatGPT : les outils ci-dessous y sont donc appelables sans flag, sans jeton d'essai et sans rien à configurer de votre côté. MyTools a déjà été piloté ainsi en conditions réelles : un plantage propre à ce navigateur a été signalé par quelqu'un dont l'agent utilisait déjà ces outils, puis corrigé en août 2026.

Dans Chrome, c'est un essai d'origine. L'essai court de Chrome 149 à Chrome 156, soit à peu près jusqu'à la fin 2026. MyTools embarque un jeton pour son origine de production : dans un Chrome compatible, les outils sont donc présents sans aucun flag à activer. Si l'essai se termine sans que l'API soit livrée, document.modelContext disparaîtra de Chrome, et ces outils avec lui — raison pour laquelle le point d'entrée par URL décrit plus bas, lui, ne bougera pas.

La spécification est un brouillon, pas un standard ratifié. WebMCP est un Draft Community Group Report du W3C Web Machine Learning Community Group, édité par des ingénieurs de Google et de Microsoft, et explicitement hors du processus de standardisation du W3C. Sa forme a déjà bougé une fois : les outils s'enregistraient sur navigator.modelContext avant que l'API ne passe à document.modelContext. Si vous partez d'une documentation plus ancienne, vérifiez ce point en premier.

Détectez la fonctionnalité, ne la présumez pas. Soit document.modelContext est là, soit il n'y est pas ; et avec plusieurs implémentations qui arrivent chacune à son rythme, c'est le seul test qui vaille. N'inspectez jamais le user agent pour cela. Là où il manque, rien ne casse sur le site : les outils n'existent tout simplement pas, et chaque page continue de fonctionner comme une page.

Il existe une solution de repli qui marche partout. Là où WebMCP n'est pas disponible, pilotez plutôt le site par son point d'entrée par URL : 50 des 55 outils s'ouvrent avec le fichier déjà chargé depuis une URL que vous construisez vous-même. Les deux mécanismes couvrent les mêmes opérations ; seule l'ergonomie change.

En local, dans un Chrome dépourvu du jeton d'essai, activez chrome://flags/#enable-webmcp-testing.

Pour aller plus loin — Le brouillon de spécification · La documentation WebMCP de Chrome

Trois outils sur chaque page

Ceux-là sont enregistrés sur tout le site, y compris sur les pages qui ne sont pas des outils : l'accueil, un article, cette page. C'est par eux qu'un agent trouve son chemin jusqu'au bon outil.

find_mytools_tools — Cherche dans le catalogue. Accepte query, category, inputType et limit, tous facultatifs, et renvoie les outils correspondants avec leur slug, le chemin de leur page et le fait qu'ils acceptent ou non une URL de fichier. En lecture seule. La sortie est plafonnée : affinez la recherche plutôt que de tout demander.

open_mytools_tool — Ouvre un outil, prêt à l'emploi. Prend slug — obligatoire, tel que renvoyé par find_mytools_tools — plus, en option, urls pour charger directement des fichiers distants, et carryResult, qui transmet à l'outil ouvert les fichiers que l'outil courant vient de produire, au lieu d'arriver sur un écran de sélection de fichiers vide.

suggest_mytools_pipeline — À partir du slug d'un outil et des noms des fichiers qu'il a produits, liste les outils vers lesquels ces fichiers peuvent aller ensuite. Seules les destinations compatibles remontent : un lot n'est jamais proposé à un outil mono-fichier, et aucun outil ne se voit proposer un format qu'il ne sait pas ouvrir.

Trois de plus sur chaque page d'outil

Les 55 outils portent tous le même triplet, nommé d'après le slug de l'outil, tirets remplacés par des tirets bas. Sur /pdf/rotate-pdf, ce sont get_rotate_pdf_state, run_rotate_pdf et download_rotate_pdf.

get_<tool>_state — Ce qui est chargé, la valeur des réglages, et une indication nommant l'appel à faire ensuite. Lisez-le avant de lancer quoi que ce soit : c'est de là que viennent le nombre de pages, les durées et les dimensions en pixels — et ce sont elles qui donnent du sens aux arguments.

run_<tool> — Fait le travail. Les arguments varient d'un outil à l'autre et sont décrits dans son schéma ; tout ce que vous omettez conserve la valeur affichée à l'écran. L'appel ne rend la main qu'une fois l'opération terminée : il n'y a donc rien à interroger en boucle — sur un long encodage vidéo, il dure simplement le temps de l'encodage.

download_<tool> — Sauvegarde le résultat sur l'appareil de l'utilisateur. Il n'est enregistré qu'une fois le résultat prêt : sa présence dans la liste des outils est donc le signal que le travail est terminé. Les outils qui produisent plusieurs fichiers acceptent index pour n'en sauvegarder qu'un, ou zip pour les sauvegarder tous dans une seule archive.

Trois outils aboutissent à une URL publiée plutôt qu'à un fichier — les deux outils de publication Facebook et celui d'envoi vers YouTube — et n'enregistrent donc aucun outil download. Ils refusent aussi d'agir si personne n'est connecté : la connexion ouvre une fenêtre que seul un vrai clic peut ouvrir.

Un exemple complet

Faire pivoter un PDF hébergé à une URL, de bout en bout. Chaque réponse ci-dessous est la vraie sortie de ces outils, pas une approximation.

find_mytools_tools({ query: "rotate pdf", inputType: "application/pdf", limit: 3 })

→ { "total": 55, "matched": 1, "tools": [
      { "slug": "rotate-pdf", "title": "Rotate PDF",
        "description": "Rotate PDF pages in one click",
        "multiple": true, "byUrl": true } ] }

open_mytools_tool({ slug: "rotate-pdf",
                    urls: ["https://example.com/rental-application.pdf"] })

→ "Opened Rotate PDF with 1 file(s) loading from URL. Everything is processed
   locally in the browser. The page-specific tools available to you have changed."

get_rotate_pdf_state({})

→ { "phase": "configure",
    "pdfs": [ { "name": "rental-application.pdf", "pages": 2, "rotations": [0, 0] } ],
    "saving": false, "result": null,
    "hint": "Call run_rotate_pdf with a rotation, optionally narrowed with pages,
             to turn the loaded PDFs." }

run_rotate_pdf({ rotation: 90 })

→ "Rotated 1 PDF(s) by 90°. Call download_rotate_pdf to save it."

download_rotate_pdf({})

→ "Saving rental-application-rotated.pdf to the user's device."

Rendre une décision à l'utilisateur

Tous les arguments n'ont pas à être choisis par vous. Quelle partie d'une photo garder, quelles pages d'un scan comptent vraiment, à quel volume c'est assez fort : ces choix-là demandent d'avoir le fichier sous les yeux. La surface est faite pour que vous puissiez vous arrêter, laisser l'utilisateur décider, puis reprendre. get_<tool>_state rapporte ce qui est à l'écran à l'instant même, y compris un réglage que l'utilisateur vient de changer à la souris, et tout argument que vous omettez dans run_<tool> conserve la valeur affichée à l'écran. Omettez-les tous, et l'exécution reprend exactement ce qu'il a réglé.

Le recadrage d'image, avec un vrai ajustement à la souris au milieu :

get_crop_image_state({})

→ … "source": { "width": 6240, "height": 4160 },
    "selection": { "x": 1459, "y": 420, "width": 3330, "height": 3328 }

    ← the user drags the box over what they want to keep

get_crop_image_state({})

→ … "selection": { "x": 2910, "y": 831, "width": 3330, "height": 3329 }

run_crop_image({})

→ "Cropped to 3330×3329 pixels out of 6240×4160 (5507 KB, image/jpeg).
   Call download_crop_image to save it."

Dites ce dont vous avez besoin dans le tour même où vous ouvrez l'outil — « faites glisser le cadre sur la partie que vous voulez garder, puis dites-moi que c'est bon » — et relisez l'état quand la réponse arrive. Rien n'est bloqué sur la page pendant que vous attendez : l'utilisateur travaille dans un onglet de navigateur ordinaire.

C'est là que passe la frontière entre une page d'outil et une API. Le travail que personne n'a besoin de regarder a sa place derrière un appel d'API, et mettre un navigateur devant ne serait que du surcoût. Une page ne se justifie que lorsqu'une personne doit voir le fichier pour trancher — et WebMCP est précisément ce qui garde un agent utile de part et d'autre de ce moment : c'est lui qui charge, mesure, convertit et enregistre autour d'un jugement qu'il n'a pas à rendre à la place de l'utilisateur.

Quatre principes qui régissent leur comportement

La sortie est plafonnée à environ 1500 caractères. Une réponse d'état est donc un résumé, pas un vidage complet. Les longues listes sont tronquées par la fin et signalées comme telles, et le contenu des fichiers n'y figure jamais. S'il vous faut le catalogue entier plutôt qu'un résultat de recherche, récupérez plutôt capabilities.json.

Aucun octet ne franchit la frontière. Vous ne pouvez pas passer un fichier à un outil, et vous n'en recevez jamais. Les fichiers entrent par une URL que le navigateur récupère, et sortent par download_<tool>, qui déclenche un téléchargement ordinaire du navigateur vers la machine de l'utilisateur. Tout ce que vous échangez avec ces outils est du texte.

Les appels peuvent être annulés. Chaque exécution reçoit un AbortSignal. Annuler un appel arrête réellement le travail au lieu de l'abandonner en arrière-plan — un encodage vidéo est interrompu, pas laissé en cours dans un worker — et l'appel revient comme une annulation, pas comme un échec.

La liste des outils change au fil de la navigation. Seuls les outils de la page courante sont enregistrés. Ouvrir un autre outil retire le triplet de la page précédente et enregistre le nouveau : relisez donc la liste des outils après chaque open_mytools_tool, au lieu de supposer que ce que vous avez vu avant est toujours là.

Les questions qui méritent une réponse

Retour à MyTools pour les agents IA