Manifest

Manifest lit une page à travers son arbre d'accessibilité, la même structure qu'utilisent les technologies d'assistance, puis recoupe avec le DOM les détails que cet arbre omet : marqueurs d'obligation, types de saisie, placeholders et états désactivés. Le résultat est une description des actions d'une page qui tient mieux que l'une ou l'autre source seule.

La sortie principale est un tableau JSON actions. Chaque entrée porte un id, un label, un type, une description et un champ requires. Ce champ est un ensemble de groupes reliés par AND, où chaque groupe interne est un ensemble d'alternatives reliées par OR. Ainsi, un sélecteur de taille apparaît comme un groupe avec plusieurs ids, et un bouton de connexion comme deux groupes d'un seul élément pour l'e-mail et le mot de passe.

Chaque action est livrée avec un localisateur : un sélecteur CSS, un rôle ARIA et un nom accessible. La documentation conseille de s'appuyer sur le rôle et le nom plutôt que sur le CSS dès que possible, car ils survivent aux redesigns qui ruineraient un sélecteur codé en dur.

Vous accédez à Manifest de deux façons. Ajoutez le serveur MCP io.omfang/manifest à la configuration de votre client et il expose un point de terminaison streamable-http, ou appelez l'API REST directement avec une clé dans l'en-tête x-api-key. Même forme de réponse dans les deux cas.

Les réponses en cache reviennent vite et comptent moins contre votre limite que les requêtes à froid. Comme les agents ont tendance à frapper le même petit nombre d'URL encore et encore, cela garde coût et latence prévisibles sur toute une exécution.

Un champ facultatif country définit l'en-tête Accept-Language de l'analyse et, sur certains sites, un cookie de langue. C'est du meilleur effort : Manifest ne contournera pas les redirections géographiques de façon universelle ni ne convertira les prix, et il renvoie un indicateur locale_mismatch pour que vous sachiez quand la page obtenue était propre à une langue.