Actions disponibles

Autonomy MCP propose 23 outils, un pour chaque opération de l'API HTTP, avec les mêmes arguments, résultats et règles. Le nom d'un outil est autonomy_ suivi du nom de l'opération, les points étant remplacés par des underscores : run.get devient autonomy_run_get.

Projets

Cas de test

Chaque étape est un résultat attendu en langage courant (text), avec un id stable et des pièces jointes attachments facultatives : account, inbox, phone, file, screenshot ou data. Les pièces jointes sont des données de test, sauf si exact vaut true. Une pièce jointe data peut porter une valeur value (y compris {{env.NAME}}), ou une intention intent comme « A strong password » pour que l'agent en choisisse une. Avec secret: true, la valeur est en écriture seule. Voir Étapes sous forme de résultats attendus pour tous les champs et toutes les limites.

Plans de test

Exécutions

Environnements

Problèmes

Un problème ne modifie jamais le résultat d'une exécution ou d'une étape.

Paramètres supplémentaires sur MCP

Chaque outil accepte aussi :

• response_format : "markdown" (par défaut) ou "json". Les deux s'accompagnent du même résultat structuré ; seul change le texte que lit l'assistant. Un texte très long est coupé à 24 000 caractères : utilisez des filtres plus précis ou un limit plus petit.
• idempotencyKey (outils qui modifient quelque chose) : facultative sur MCP. Si le client l'omet, Autonomy en crée une nouvelle à chaque appel : un appel retenté n'est alors pas reconnu comme une répétition et peut faire le travail deux fois. Transmettez votre propre clé lorsqu'une nouvelle tentative ne doit pas répéter la modification, par exemple avec autonomy_run_trigger.

Les erreurs reviennent sous forme d'erreur d'outil avec le texte <CODE>: <message>, avec les mêmes codes d'erreur que l'API HTTP.

Confirmer les remplacements

Autonomy ne pose pas de seconde question dans MCP. Les outils qui remplaceraient quelque chose nécessitent confirm: true :

• autonomy_test_case_update_steps toujours, car il remplace toute la liste d'étapes.
• autonomy_test_plan_set_members lorsque des cas de test seraient retirés.
• autonomy_environment_upsert lorsque le slug existe et que des champs ou des cibles sont fournis.

Sans confirmation, rien n'est écrit. L'outil renvoie INVALID_ARGUMENT avec confirmRequired: true et un résumé wouldChange. Lisez le résumé, montrez-le à la personne si c'est important, et seulement ensuite rappelez l'outil avec confirm: true. N'ajoutez pas la confirmation par réflexe.

Suivre une exécution

1. Lancez-la. Appelez autonomy_run_trigger avec un testCaseId (ou un testPlanId) et un environmentSlug ou des targets. Conservez les runIds.
2. Attendez-la. Appelez autonomy_run_get avec le runId. Conservez le cursor. Tant que next vaut wait, rappelez l'outil avec ce cursor et waitMs: 25000. timedOut: true signifie seulement que rien n'a changé pendant l'attente : rappelez l'outil.
3. Voyez ce qu'a fait l'agent. Appelez autonomy_run_step_actions, avec stepIndex pour vous concentrer sur une étape. Tant que l'exécution est en cours, relisez depuis le début chaque fois que runCursor change.
4. Lisez les preuves. Quand l'exécution se termine, et surtout lorsque next vaut evidence, appelez autonomy_run_evidence. Chaque étape comporte son résultat attendu, son résultat, l'explication, la Final check et des liens vers les médias. Les liens expirent au bout de 15 minutes ; rappelez l'outil pour en obtenir de nouveaux.
5. Consultez les problèmes. Appelez autonomy_issue_list avec le runId pour voir les problèmes que l'exécution a trouvés ou montrés. Ils sont tenus à l'écart du résultat.

next est un conseil, pas une décision. Décidez à partir de status et des étapes. Une exécution se termine en passed, failed, couldnt_start ou cancelled. L'explication d'une étape échouée indique si le résultat attendu n'a pas été atteint ou si l'agent n'a pas pu montrer qu'il l'a été ; lisez-la avant de traiter l'échec comme un bug. Une étape avec failureCategory: "runner" a échoué à cause d'Autonomy, pas de l'application. Voir Exécutions et preuves pour tous les champs.

Cibles de déclenchement

autonomy_run_trigger accepte des platforms parmi web, api, ios et android. Utilisez environmentSlug lorsque la cible est enregistrée, ou targets pour un nouveau déploiement ou un nouveau build, mais pas les deux.

Ajoutez branch, pr et deployment.commitSha pour relier les exécutions à une pull request ou à un commit.

Portées OAuth

Voir Accès à l'organisation pour la façon dont chaque portée apparaît sur l'écran de consentement.

Recettes pour agents

Vérifier la couverture existante

Avec Autonomy MCP, trouvez le projet qui correspond à ce dépôt, puis listez ses cas de test, ses plans de test et ses exécutions récentes pertinents.
Si une exécution existe déjà pour cette branche ou cette PR, résumez son statut avant de lancer quoi que ce soit de nouveau.

Exécuter sur une prévisualisation de PR

Avec Autonomy MCP, exécutez le cas de test pertinent sur cette URL de prévisualisation.
Transmettez la branche, le numéro de PR, le SHA du commit et votre propre idempotencyKey. Attendez la fin de l'exécution, puis résumez le résultat et l'explication de chaque étape.

Diagnostiquer une exécution qui n'a pas réussi

Récupérez l'exécution Autonomy, ses Step Actions et ses preuves avant de proposer une correction.
Citez l'étape, son explication, la Final check et un lien vers un média qui appuient votre conclusion.
Listez les problèmes trouvés par l'exécution.