bugAgent

Connectez l’Agent bug à n’importe quel client IA compatible avec MCP.

Signalez, classez et gérez des bugs, des demandes de fonctionnalités et bien plus directement depuis votre assistant de programmation IA. Sans changer de contexte ni copier-coller : décrivez simplement le problème et l’Agent bug s’occupe du reste.

Les clients MCP externes sont distincts de l’assistant IA du tableau de bord de l’Agent bug. L’assistant du tableau de bord est désactivé par défaut pour tous les forfaits et nécessite une activation explicite dans l’espace de travail ; son ai_assistant ne désactive ni MCP ni les intégrations. L’authentification MCP, les portées, les autorisations de l’espace de travail et du projet, ainsi que les droits propres aux outils restent applicables.

Premiers pas

L’Agent bug exécute le serveur MCP hébergé afin que les clients IA puissent créer, consulter et gérer des rapports de bugs, des demandes de fonctionnalités, des améliorations et bien plus via le Model Context Protocol. Les clients se connectent directement au point de terminaison HTTP Streamable hébergé.

Obtenir votre clé API

Créez un compte gratuit ; les nouveaux propriétaires d’espace de travail sont directement dirigés vers la configuration de la clé API. Les utilisateurs existants peuvent générer une clé depuis Settings → Developers → API Keys.

Configurer votre client IA

Ajoutez l’Agent bug comme serveur MCP dans la configuration de votre client (voir la procédure ci-dessous).

Commencer à signaler des bugs

Décrivez un bug en langage naturel et l’Agent bug le classe automatiquement, l’enrichit et l’enregistre.

# Create a bug report
"File a bug: Login button is unresponsive on iOS Safari.
Steps: tap login, nothing happens. Expected: navigate to
dashboard. Severity: high."

# bugAgent auto-classifies as UI bug, severity high

# File a feature request
"Feature request: Add dark mode toggle to the
settings page. Users have asked for this in surveys."

# Auto-classified as feature-request, severity medium

Configuration

Plugin dédié à la capture de bugs

Consultez le code source public du plugin et la liste de vérification de configuration. Il s’agit d’un aperçu du code source ; la vérification OAuth pour l’hébergement et la publication dans le répertoire OpenAI sont en attente.

Le point de terminaison dédié https://mcp.bugagent.com/mcp/capture ne propose que capture_get_profile, capture_list_projects, capture_search_reports, capture_get_report et capture_create_report. Il ne donne pas accès à l’administration, à la suppression, aux commentaires ni à l’exécution de tests. La disponibilité dans le répertoire OpenAI est soumise à un examen et à une publication distincts.

Connectez-vous avec OAuth. Les autorisations de capture sont liées à ce point de terminaison et ne peuvent pas être utilisées sur le point de terminaison complet /mcp. Les lectures nécessitent bugs:read ; la création nécessite bugs:write. Les clés API d’espace de travail restent prises en charge avec reports:read et reports:write, et sont limitées à leur espace de travail.

Sélectionnez d’abord un espace de travail et un projet autorisés. Les recherches et la consultation des rapports nécessitent explicitement workspace_id et project_id ; les résultats sont limités et paginés. Les résultats de recherche sont des correspondances possibles et ne garantissent pas l’absence de doublons.

Avant la création, vérifiez la destination, le titre, la description, le type et la gravité. Envoyez approved: true et un UUID stable request_id avec la charge utile approuvée. Réutilisez le même identifiant de requête uniquement pour une nouvelle tentative identique ; toute charge utile modifiée sera rejetée. Les limites du forfait existantes et le transfert Jira configuré restent applicables.

L’interprétation des images peut aider à rédiger un brouillon, mais ce point de terminaison ne permet pas de téléverser des pièces jointes. Ouvrez le ticket créé pour joindre des éléments privés. Ne collez jamais de mots de passe, de jetons ni d’autres secrets dans la conversation.

Recommandé : HTTP Streamable hébergé

Connectez-vous directement à https://mcp.bugagent.com/mcp. Rien à installer ni à maintenir en fonctionnement localement. Ajoutez votre clé API d’espace de travail comme jeton Bearer :

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

💡

Remplacez ba_live_YOUR_KEY_HERE par votre véritable clé API depuis Settings → Developers.

Pont stdio facultatif

Utilisez le pont publié uniquement si un client exige stdio et ne peut pas se connecter à un serveur HTTP distant. Lancez-le à la demande avec npx -y bugagent-mcp :

{
  "mcpServers": {
    "bugagent": {
      "command": "npx",
      "args": ["-y", "bugagent-mcp"],
      "env": {
        "BUGAGENT_API_KEY": "ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Se connecter au serveur

Dans le tableau de bord sur les appareils tactiles, touchez une fois un libellé de la barre latérale pour naviguer. Les options et la restauration sont des commandes distinctes, également accessibles au clavier. La visibilité de la barre latérale n’accorde ni ne révoque les autorisations MCP.

Le serveur MCP de l’Agent bug est disponible à l’adresse https://mcp.bugagent.com/mcp via le transport HTTP Streamable. Connectez-vous depuis l’un des huit clients ci-dessous : choisissez celui qui convient à votre flux de travail.

Pour obtenir une configuration compacte prête à copier, des conseils sur les clés à portée limitée et des invites de démarrage sûres, consultez le guide de démarrage rapide MCP public.

🔑

Obtenez d’abord votre clé API. Connectez-vous à Settings → Developers, cliquez sur Create API Key, sélectionnez les portées nécessaires à votre client et copiez la valeur (elle commence par ba_live_). Vous ne pourrez la voir qu’une seule fois ; collez-la donc dans un endroit sûr. Les clients MCP n’affichent que les outils autorisés par ces portées. Les exemples de connexion ci-dessous utilisent cette clé ; les invites nécessitant une session OAuth interactive ou un droit associé à un forfait payant sont indiquées séparément.

Option 1 — MCP Inspector (interface Web, recommandé pour les premiers tests)

L’outil officiel d’Anthropic. Il lance une interface Web locale qui permet de parcourir chaque outil, de renseigner les paramètres et de consulter les réponses. Aucune configuration ni IDE requis.

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell ou CMD)

npx @modelcontextprotocol/inspector

Dans l’interface du navigateur qui s’ouvre :

1. Transport Type : sélectionnez Streamable HTTP
2. URL : https://mcp.bugagent.com/mcp
3. Connection Type : sélectionnez Proxy (valeur par défaut — Inspector utilise un processus Node local comme proxy pour contourner CORS dans le navigateur)
4. Ouvrez Server Settings → Custom Headers et ajoutez :
   • Header Name : X-Api-Key
     • Value : ba_live_YOUR_KEY_HERE (sans le préfixe Bearer)
5. Cliquez sur Connect. Le panneau de gauche affiche les outils de l’Agent bug autorisés par les portées de la clé API sélectionnées.
6. Cliquez sur un outil (par exemple list_bug_reports), renseignez les paramètres, puis cliquez sur Run Tool. La réponse s’affiche à droite.

Prérequis : MCP Inspector v2 nécessite Node.js 22.19 ou une version ultérieure. Installez une version actuelle de Node.js depuis nodejs.org si ce n’est pas déjà fait.

Si Inspector renvoie invalid_client, il tente d’utiliser une connexion OAuth enregistrée au lieu de l’authentification par clé API. Supprimez le serveur enregistré (ou effacez son état OAuth stocké), ajoutez-le à nouveau et utilisez l’en-tête personnalisé X-Api-Key ci-dessus. Ne placez pas une clé ba_live_ dans un champ OAuth client_id.

Option 2 — Claude Desktop (Mac et Windows)

Si vous utilisez l’application Claude Desktop, vous pouvez ajouter l’Agent bug comme serveur MCP permanent. Avec une clé API d’espace de travail, Claude ne reçoit que les outils autorisés par les portées de cette clé. OAuth délégué donne accès au catalogue interactif complet.

macOS

1. Ouvrez Claude Desktop → barre de menus Claude → Settings → Developer → Edit Config. Le fichier ~/Library/Application Support/Claude/claude_desktop_config.json s’ouvre.
2. Ajoutez l’entrée de l’Agent bug sous mcpServers :

   {
     "mcpServers": {
       "bugagent": {
         "type": "http",
         "url": "https://mcp.bugagent.com/mcp",
         "headers": {
           "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
         }
       }
     }
   }
   

3. Enregistrez le fichier et quittez complètement Claude Desktop (Cmd+Q, ne vous contentez pas de fermer la fenêtre).
4. Relancez Claude Desktop. L’icône marteau des outils en bas de la zone de saisie du chat doit maintenant afficher les outils de l’Agent bug.
5. Essayez : saisissez « Liste mes 5 rapports de bugs les plus récents » — Claude appellera automatiquement list_bug_reports.

Windows

1. Ouvrez Claude Desktop → File → Settings → Developer → Edit Config. Le fichier %APPDATA%\Claude\claude_desktop_config.json s’ouvre (généralement C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
2. Ajoutez le même bloc JSON que dans la section macOS.
3. Enregistrez le fichier et quittez complètement Claude Desktop depuis la zone de notification (clic droit sur l’icône Claude → Quit), puis relancez l’application.
4. L’icône marteau des outils affichera les outils de l’Agent bug.

Option 3 — Claude Code (CLI)

Si vous utilisez Claude Code depuis votre terminal (la version CLI de Claude), enregistrez le serveur de l’Agent bug avec une seule commande. La procédure est identique sur macOS, Linux et Windows.

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp \
  --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

Redémarrez ensuite votre session Claude Code. Vérifiez la connexion :

claude mcp list

Vous devriez voir bugagent dans la liste avec un point vert. Commencez par une invite compatible avec une clé API : « Liste mes 5 rapports de bugs ouverts les plus récents. »

Connecté, mais certains outils sont absents ?

Vérifiez le nombre d’outils du serveur dans /mcp, et pas seulement les outils déjà chargés dans la conversation. Claude Code peut découvrir des outils à la demande grâce à la recherche d’outils. Demandez-lui de rechercher dans bugAgent list_test_cases, list_test_suites ou get_test_run_plan. Consultez la documentation de recherche d’outils de Claude Code.

Le catalogue est filtré selon les portées de la clé API. La lecture des cas de test nécessite test_cases:read ; la lecture des suites et des exécutions nécessite test_runs:read. Ne demandez que les portées d’écriture dont vous avez réellement besoin. Comparez le tools/list authentifié avec le même point de terminaison et la même clé que votre client ; une découverte anonyme ou effectuée avec une autre clé ne constitue pas une comparaison valable. Vérifiez qu’une configuration au niveau du projet ne remplace pas votre connexion au niveau utilisateur, puis reconnectez-vous ou redémarrez après toute modification des identifiants.

Si le catalogue du serveur authentifié inclut un outil, mais que le client ne parvient toujours pas à le découvrir, consignez la version du client, la version du serveur, les noms et le nombre d’outils, ainsi que les éventuelles erreurs de schéma, en supprimant les identifiants et les données client. Une session démarrée avec ENABLE_TOOL_SEARCH=false claude permet de distinguer une découverte différée des problèmes de chargement, mais charge toutes les définitions d’outils et utilise davantage de contexte ; utilisez-la uniquement comme diagnostic temporaire. N’élargissez pas les autorisations et ne séparez pas les points de terminaison dans le seul but d’augmenter le nombre d’outils.

Pour le supprimer ultérieurement :

claude mcp remove bugagent

Option 4 — OpenAI Codex CLI

Si vous utilisez OpenAI Codex CLI, exportez votre clé API et ajoutez l’Agent bug à ~/.codex/config.toml.

Enregistrement permanent (ajouter à la configuration)

[mcp_servers.bugagent]
url = "https://mcp.bugagent.com/mcp"
bearer_token_env_var = "BUGAGENT_API_KEY"

Définir la clé API

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

Démarrez ou redémarrez Codex depuis cet environnement. Codex résout automatiquement les appels d’outils à partir de votre invite en langage naturel. Essayez : « Liste mes bugs ouverts, triés par gravité. »

Option 5 — Cursor (Mac et Windows)

Cursor intègre la prise en charge de MCP. Avec une clé API d’espace de travail dont les portées sont correctement définies, l’assistant IA de Cursor peut signaler des bugs, lister des rapports et exécuter des flux d’automatisation pris en charge sans quitter votre éditeur. Les analyses de sécurité, de performances et exploratoires nécessitent OAuth délégué et l’accès au forfait applicable.

1. Ouvrez Cursor → Settings (Cmd+, sur Mac / Ctrl+, sur Windows) → MCP dans la barre latérale gauche.
2. Cliquez sur + Add new MCP server.
3. Sélectionnez le type de transport HTTP.
4. Renseignez :
   • Name : bugagent
     • URL : https://mcp.bugagent.com/mcp
     • Header name : Authorization
     • Header value : Bearer ba_live_YOUR_KEY_HERE
5. Cliquez sur Save. Cursor affiche un indicateur vert lorsque la connexion est établie.
6. Ouvrez le chat de Cursor (Cmd+L / Ctrl+L) et saisissez « Crée un rapport de bug intitulé “Connexion cassée” avec une gravité élevée. » Cursor appellera create_bug_report.

Autre méthode : Cursor lit également ~/.cursor/mcp.json (Mac) ou %USERPROFILE%\.cursor\mcp.json (Windows). Ajoutez le même format JSON que celui présenté dans la section Claude Desktop.

Option 6 — VS Code avec l’extension Continue (Mac et Windows)

Si vous préférez VS Code, l’extension Continue prend en charge les serveurs MCP de manière native.

1. Installez l’extension Continue depuis la marketplace VS Code.
2. Ouvrez la configuration de Continue : palette de commandes (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Open config.json. Le fichier se trouve ici :
   • macOS : ~/.continue/config.json
     • Windows : %USERPROFILE%\.continue\config.json
3. Ajoutez une entrée mcpServers :

   {
     "mcpServers": [
       {
         "name": "bugagent",
         "type": "streamable-http",
         "url": "https://mcp.bugagent.com/mcp",
         "requestOptions": {
           "headers": {
             "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
           }
         }
       }
     ]
   }
   

4. Enregistrez. Continue se rechargera automatiquement et affichera les outils de l’Agent bug dans la barre latérale.
5. Ouvrez le panneau de chat Continue et essayez : « Liste mes 5 rapports de bugs ouverts les plus récents. »

Autres extensions VS Code compatibles avec MCP : Cline, Roo Code et Windsurf (fork) suivent toutes des modèles de configuration JSON similaires, avec une clé mcpServers et le transport HTTP.

Option 7 — Hôtes compatibles avec OAuth (Claude.ai Web comme exemple)

Certains hôtes MCP s’authentifient via OAuth 2.0 et demandent à l’avance un client_id et un client_secret statiques, au lieu d’accepter une clé API Bearer. Générez une paire d’identifiants de connecteur depuis le tableau de bord de l’Agent bug et collez-la dans le formulaire de connexion de l’hôte. Cette paire identifie le client MCP ; après consentement, l’exécution des outils utilise l’utilisateur connecté et son espace de travail actif dans l’Agent bug. La procédure ci-dessous prend l’application Web Claude.ai comme exemple, car c’est le cas le plus courant.

i

OAuth lié à une ressource. L’identifiant de la ressource protégée est https://mcp.bugagent.com/mcp. Les hôtes compatibles avec les normes le découvrent via /.well-known/oauth-protected-resource/mcp et l’envoient comme paramètre RFC 8707 resource. L’Agent bug émet des jetons opaques liés à cette ressource, au client OAuth, à l’utilisateur connecté et aux portées accordées ; un jeton ne peut pas être réutilisé auprès d’un autre service ni échangé par un autre client.

1. Dans bug Agent : ouvrez Settings → Developers → MCP Connectors. Cliquez sur Generate connector, donnez-lui un nom décrivant l’hôte (par ex. « Claude.ai (work) »), collez l’URI de redirection requise par votre hôte MCP (pour l’application web Claude.ai, il s’agit de https://claude.ai/api/mcp/auth_callback — consultez la documentation des connecteurs de votre hôte pour les autres), puis choisissez Confidential comme méthode d’authentification. Copiez le client_id et le client_secret affichés une seule fois sur l’écran de confirmation.
2. Dans les paramètres de connecteur / OAuth de votre hôte MCP, collez :
   • URL du serveur : https://mcp.bugagent.com/mcp
     • Client ID + Client Secret : ceux de l’étape 1
     • URL d’autorisation : https://mcp.bugagent.com/authorize
     • URL du jeton : https://mcp.bugagent.com/token
     • Ressource protégée / audience, si demandé : https://mcp.bugagent.com/mcp Pour Claude.ai en particulier : accédez à claude.ai/customize/connectors et cliquez sur Add MCP connector.
3. Enregistrez. L’hôte vous redirige vers bug Agent pour vous connecter (avec Google ou par e-mail/mot de passe — selon la méthode utilisée pour le tableau de bord) et approuver le consentement, puis termine la négociation OAuth.
4. Gérez les connecteurs générés depuis la même page Settings. Seul le créateur peut révoquer un connecteur du tenant ; les administrateurs de l’espace de travail ne peuvent pas révoquer l’enregistrement d’un autre membre. Une révocation confirmée supprime cet enregistrement de la liste active. Les enregistrements distincts portant le même nom restent séparés : comparez leurs Client IDs. Si la révocation ne peut pas être confirmée, la page affiche une erreur au lieu d’un message de réussite. La révocation bloque toute nouvelle authentification du connecteur. Les jetons d’accès déjà émis peuvent rester valides jusqu’à leur expiration.

Remarque : Claude Code, Cursor, VS Code et MCP Inspector n’ont pas besoin de cette procédure : ils gèrent automatiquement l’enregistrement dynamique des clients (RFC 7591) et s’authentifient par clé API, comme indiqué ci-dessus. Le formulaire MCP Connectors est réservé aux hôtes qui exigent des identifiants OAuth statiques.

Les valeurs d’accès et de renouvellement OAuth ne sont affichées qu’à l’hôte. Elles sont opaques, renouvelées lors de leur actualisation et stockées par bug Agent uniquement sous forme de hachages à sens unique ; l’identifiant d’actualisation de l’identité en amont est chiffré au repos. Ne copiez jamais un jeton OAuth dans une requête d’API REST ou vers un autre serveur MCP.

Option 8 — HTTP direct avec curl (Terminal)

Pour tester directement le serveur sans client ou l’intégrer à un script, vous pouvez appeler le point de terminaison HTTP avec curl. Le protocole MCP est du JSON-RPC 2.0 sur Streamable HTTP.

macOS / Linux

# Set your API key as a variable
export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

# 1. Initialize the MCP connection
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl-example","version":"1.0.0"}}}'

# 2. List tools visible to this key
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

# 3. Call a tool — list 5 reports from a specific project
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc":"2.0",
    "id":3,
    "method":"tools/call",
    "params":{
      "name":"list_bug_reports",
      "arguments":{"project":"bugagent","limit":5}
    }
  }'

Windows (PowerShell)

# Set your API key
$env:BUGAGENT_API_KEY = "ba_live_YOUR_KEY_HERE"

# Use Invoke-RestMethod (PowerShell's curl equivalent)
$headers = @{
  "Authorization" = "Bearer $env:BUGAGENT_API_KEY"
  "Content-Type" = "application/json"
  "Accept" = "application/json, text/event-stream"
}

# 1. Initialize
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"powershell-example","version":"1.0.0"}}}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 2. List tools visible to this key
$body = '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 3. Call list_bug_reports for a specific project
$body = @{
  jsonrpc = "2.0"
  id = 3
  method = "tools/call"
  params = @{
    name = "list_bug_reports"
    arguments = @{ project = "bugagent"; limit = 5 }
  }
} | ConvertTo-Json -Depth 5

Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

Les réponses peuvent être au format JSON ou Server-Sent Events. Chaque fragment SSE est une ligne préfixée par data:, suivie d’un objet JSON. Les clients conformes aux normes doivent envoyer Accept: application/json, text/event-stream ; bug Agent normalise actuellement les valeurs Accept manquantes ou incomplètes pour assurer la compatibilité.

ℹ️

Dépannage — 401 Unauthorized : vérifiez que votre clé API n’a pas été révoquée dans Settings → Developers. Les clés commencent par ba_live_. Si le problème persiste, générez une nouvelle clé et réessayez.

Modèle d’accès et portées de moindre privilège

Le catalogue OAuth complet contient 141 outils. Une clé API d’espace de travail ne voit que les outils associés à l’une de ses portées sélectionnées. La découverte sans authentification peut afficher les métadonnées des outils, mais tools/call exige toujours une clé API ou un jeton OAuth.

Lire les rapports de bogues et résoudre les projets reports:read

Créer et mettre à jour des rapports de bogues reports:read, reports:write

Moniteur d’utilisation usage:read

Vérifier l’état de synchronisation Jira jira:read

Synchroniser ou fusionner des rapports Jira jira:write

Créer des automatisations Web automations:write

Exécuter des automatisations Web et lire les exécutions automations:run

Observer les ressources et exécutions mobiles mobile:read

Gérer les ressources mobiles mobile:read, mobile:write

Exécuter l’automatisation mobile mobile:read, mobile:run

Gérer le catalogue de tests reports:read, test_cases:read, test_cases:write

Worker d’exécution de tests externe test_runs:read, test_runs:write

Les clés API sont liées à l’espace de travail dans lequel elles sont créées. Les paramètres d’un outil peuvent limiter un appel à un projet autorisé, mais ne peuvent pas faire basculer la clé vers un autre espace de travail. Résolvez les UUID de projet avec list_projects et rejetez les noms ambigus.

Titres et annotations des outils

Chaque outil renvoyé par tools/list comprend un titre lisible et des indications de lecture/écriture. Les indications de lecture manquantes proviennent d’une liste explicitement vérifiée, et non de préfixes de noms d’outils ou de portées de clés API. Les annotations explicites, notamment false, sont conservées.

• readOnlyHint: true décrit un outil qui ne modifie pas son environnement.
• readOnlyHint: false avec destructiveHint: false décrit des écritures additives, et non une opération en lecture seule.
• readOnlyHint: false avec destructiveHint: true décrit des écritures potentiellement destructrices. Les outils non classés utilisent ces valeurs par défaut prudentes. L’indication de caractère destructeur n’a de sens que pour les écritures.

login n’est pas en lecture seule : en mode stdio, il enregistre les identifiants. analyze_fix_area et check_config_drift sont des écritures potentiellement destructrices, car elles remplacent des résultats d’analyse ou des références de configuration persistés.

Les annotations n’accordent pas d’accès et ne remplacent ni l’authentification, ni l’autorisation au niveau de l’espace de travail/du projet, ni les portées des clés API, ni les vérifications de droits. Les demandes de confirmation dépendent de la politique d’autorisations du client et des paramètres utilisateur ; les indications ne garantissent pas qu’un appel déclenchera une demande.

Pour la découverte et l’audit programmatiques, téléchargez le mcp-tool-index.json généré. Il répertorie les 141 outils d’exécution, l’accès par portée de clé API ou réservé à OAuth, la famille de droits, les noms des entrées, le mode du schéma de sortie et les annotations MCP explicitement déclarées. Une annotation null signifie qu’elle n’est pas déclarée au point d’appel ; utilisez la réponse tools/list du serveur connecté pour obtenir les annotations effectives après application des valeurs par défaut.

!

Outils réservés à OAuth : la gestion du compte, des clés API et de l’équipe, la gestion des connexions Jira, les autres intégrations, les commandes de test premium, les notes, le suivi du temps et les autres opérations interactives ne sont pas déverrouillés par l’ajout de portées de clé API. Les outils de vérification, de synchronisation et de fusion des rapports Jira constituent l’exception limitée via jira:read et jira:write.

À essayer — Prompts en langage courant

Une fois la connexion établie, vous n’avez pas besoin de connaître les noms des outils ni leurs paramètres. Décrivez ce que vous voulez en langage courant et votre assistant IA appellera automatiquement l’outil bug Agent approprié.

Les prompts concernant les rapports de bogues, la gestion des tests avec portée limitée, l’automatisation Playwright, l’automatisation mobile et l’utilisation sont accessibles aux clés API disposant des portées correspondantes. Les entrées liées à la sécurité, aux performances, à l’exploration, au compte, à l’équipe, aux notes, au suivi du temps et aux autres domaines sans portée de clé API nommée exigent une délégation OAuth et tout droit de forfait applicable.

Rapports de bogues

List my 5 most recent bug reports
Show all open critical bugs in the Auth project
Create a bug titled "Login broken on Safari" with severity s2
Update TEST-451 status to in-progress and assign it to me
Add a comment to TEST-451: "root cause confirmed — null check missing in auth middleware"
Show me everything filed this week, grouped by severity

Gestion des tests

Create a test suite called "Smoke Tests" with cases for login, checkout, and account settings
Run the Regression suite and list all failures
Use Hermes to execute the curated "Checkout smoke" suite and report every result to bugAgent
Show failing test cases from the last 7 days
Which test cases have never been run in the past 90 days?
Get a pass-rate trend for this month vs last month

Sécurité et performances

Run a security scan on https://app.example.com
Get this month's security scan results — show only high and critical findings
Create a performance test for the landing page and check Lighthouse scores
What are the Core Web Vitals for our checkout flow?

Automatisation Playwright

Create a Playwright script that logs in and verifies the dashboard loads
Run the checkout automation on iPhone 15 Pro on a real device
Optimize the login automation script
Show runs for the checkout automation — any failures?
Schedule the smoke test suite to run every weekday at 6 AM UTC

IA exploratoire

Run an exploratory AI session on https://app.example.com with 5 parallel agents
Get the latest exploration run results — list any bugs that were filed
What testing strategies did the agents use and which found the most issues?

Utilisation et statistiques

Check my plan usage for this month
Show team bug stats for this week broken down by severity and type
List all team members and their roles
How many security scans do I have left this month?

Référence rapide

Références de configuration pour les huit options de connexion. Les clients à clé API se connectent à https://mcp.bugagent.com/mcp avec l’en-tête Authorization: Bearer ba_live_YOUR_KEY_HERE sur Streamable HTTP ; les hôtes compatibles OAuth utilisent les identifiants de connecteur générés dans le tableau de bord.

Claude Desktop — macOS ~/Library/Application Support/Claude/claude_desktop_config.json

Claude Desktop — Windows %APPDATA%\Claude\claude_desktop_config.json

Claude Code (CLI) claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_..."

Codex CLI ~/.codex/config.toml

Cursor — macOS Settings → MCP UI, ou ~/.cursor/mcp.json

Cursor — Windows %USERPROFILE%\.cursor\mcp.json

VS Code + Continue ~/.continue/config.json (macOS) / %USERPROFILE%\.continue\config.json (Windows)

Hôte compatible OAuth Settings → Developers → MCP Connectors — générez le client_id et le client_secret de l’hôte

HTTP direct (curl) curl / Invoke-RestMethod — incluez Accept: application/json, text/event-stream

Dépannage

401 Unauthorized La clé est incorrecte, expirée ou révoquée. Vérifiez Settings → Developers — les clés commencent par ba_live_. Générez-en une nouvelle si nécessaire.

Les outils n’apparaissent pas dans le client Les clients à clé API ne répertorient que les outils autorisés par les portées sélectionnées pour la clé. Vérifiez la clé dans Settings → Developers, puis quittez complètement le client et relancez-le après avoir modifié sa configuration. Dans Claude Desktop, utilisez Cmd+Q (ne vous contentez pas de fermer la fenêtre). Dans Cursor, vérifiez la présence d’un point vert dans Settings → MCP.

Champ manquant dans le client Comparez le schéma du client au tools/list brut du même point de terminaison. S’ils diffèrent, actualisez ou reconnectez le catalogue d’outils, puis démarrez une nouvelle conversation. Si le problème persiste, recueillez le point de terminaison, la version du client et la réponse brute tools/list ; un cache obsolète n’est qu’une cause possible.

Accept header required Envoyez Accept: application/json, text/event-stream pour Streamable HTTP conforme aux normes. bug Agent normalise actuellement les valeurs manquantes ou incomplètes, mais les intégrations ne doivent pas dépendre de ce comportement de compatibilité.

Données d’un mauvais espace de travail Chaque clé API est limitée à un seul espace de travail. Générez une nouvelle clé depuis l’espace de travail que vous souhaitez interroger dans Settings → Developers.

Les outils apparaissent, mais les appels échouent sans message Examinez la réponse pour repérer isError: true et le contenu renvoyé. Un outil visible peut tout de même être refusé en raison du forfait, du rôle, des droits de fonctionnalité, de l’appartenance au projet, de la propriété ou d’une entrée invalide. Ne vérifiez l’état du serveur qu’après avoir lu l’erreur de l’outil.

Erreur CORS de MCP Inspector Dans l’interface d’Inspector, sélectionnez Proxy (et non Direct) comme type de connexion. Inspector utilise un processus Node local comme proxy pour contourner les restrictions CORS du navigateur.

MCP Inspector v2 se ferme avec le code 5 Inspector v2 renvoie un code de sortie non nul lorsqu’une réponse d’outil contient isError: true. Lisez le message de réponse pour repérer une erreur de forfait, d’autorisation, d’entrée ou d’exécution ; Inspector v1 pouvait renvoyer le code de sortie 0 pour la même réponse d’outil en échec.

Codex CLI — outils non reconnus Vérifiez que ~/.codex/config.toml utilise [mcp_servers.bugagent], définissez bearer_token_env_var = "BUGAGENT_API_KEY" et exportez cette variable avant de démarrer Codex. Vérifiez codex --version si les outils n’apparaissent toujours pas.

Fonctionnalités MCP

Les sessions conversationnelles restent un projet pilote soumis aux restrictions de l’espace de travail. L’enregistrement d’un script généré par une session nécessite l’approbation explicite de son propriétaire dans Workbench via le point de terminaison d’enregistrement réservé aux sessions. Il n’existe aucun outil d’approbation MCP : demander à un agent de rédiger un script ne crée ni ne planifie une automatisation.

La conservation d’une capture d’écran du navigateur cloud crée uniquement un brouillon de constat via le point de terminaison de conservation réservé à la session du propriétaire. L’actualisation en direct ne remplace pas la capture d’écran sélectionnée ; l’enregistrement nécessite toujours un accès actuel du propriétaire, la génération de navigateur autorisée d’origine et une source disponible. Le propriétaire doit l’examiner et l’approuver dans Workbench avant qu’un bogue et ses éléments de preuve privés soient déposés. Aucun outil MCP ne permet de conserver des images ou de contourner cette approbation.

Le consentement au lancement du navigateur est également réservé au propriétaire du tableau de bord. Les clés API, les outils MCP et les réponses génériques du chat ne peuvent pas l’accorder. L’approbation couvre un navigateur en lecture seule et la capture privée de captures d’écran, mais pas la connexion, les actions sur les formulaires ni l’enregistrement de réunions. L’hôte de navigateur cloud de production n’est pas activé par ces contrôles de consentement.

Le catalogue interactif/OAuth complet contient 141 outils. Les clés API d’espace de travail ne découvrent que le sous-ensemble de moindre privilège autorisé par leurs portées sélectionnées ; les outils de compte, d’administration des clés API, d’administration de l’équipe, de tests premium, de notes et de suivi du temps sont réservés aux sessions interactives, sauf si une entrée indique explicitement une portée de clé API.

🐛

Gestion des rapports de bogues

Les mises à jour des rapports enregistrent atomiquement les valeurs réelles Avant/Après, y compris les champs de reproduction, les notes internes et les étiquettes. Les valeurs inchangées et les écritures échouées ne créent pas d’entrées dans l’historique des champs. Le journal des modifications du tableau de bord développe les différences textuelles et permet de parcourir les entrées plus anciennes. L’historique des pièces jointes conserve des métadonnées descriptives, et non des URL signées ou des fichiers supprimés. Les valeurs historiques manquantes ne sont pas complétées rétroactivement. Aucun outil MCP d’historique ni protocole de conflit de modification en direct n’est ajouté ; les clients autorisés peuvent utiliser le point de terminaison REST de l’historique des rapports. update_bug_report accepte également les champs de chaîne steps_to_reproduce, expected_result et actual_result. Les champs omis sont conservés ; une chaîne vide efface le texte. Les mises à jour conservent les autorisations existantes de l’espace de travail/du projet et les exigences de portée reports:write.

Les imports de captures d’écran Google Sheets reprenables utilisent le point de terminaison REST distinct POST /api/reports/import-attachment avec reports:write, et GET pour consulter l’état avec reports:read. Aucun outil MCP d’import de captures d’écran n’est ajouté. Cette API réservée aux fichiers JPEG/PNG vérifie le stockage privé et le ticket Jira exact associé avant de signaler la fin de l’opération ; l’import de rapports hérité reste limité à la session.

Les liens privés vers les pièces jointes des rapports et des exécutions de tests revérifient l’appartenance active à l’espace de travail et les autorisations actuelles du projet à leur ouverture. Le téléchargement des exécutions de tests nécessite une session du tableau de bord, et non une clé API MCP. Les liens de stockage émis précédemment peuvent rester valides jusqu’à 60 secondes et ne doivent pas être partagés.

• create_bug_report — Déposer un nouveau rapport avec classification automatique parmi 19 types — bugs, demandes de fonctionnalités, améliorations, dette technique et plus encore (titre : 3 à 500 caractères). Le tableau facultatif attachments accepte des fichiers encodés en base64 jusqu’à 400 MB chacun : toute image, vidéo, fichier audio, PDF ou texte/JSON. Définissez format_description: true pour reformater automatiquement la description en un modèle structuré à l’aide de l’IA. Transmettez time_spent_seconds pour suivre l’effort d’assurance qualité. Transmettez priority (urgent / high / normal / low) pour définir l’urgence de correction indépendamment de la gravité. Transmettez is_epic: true pour créer une Epic, ou parent_epic_id (UUID/ID court) pour créer un enfant dans le même projet autorisé. La réponse inclut les champs de hiérarchie ainsi que project_id, project, short_id, legacy_short_id et project_short_id.
• list_bug_reports — Lister et filtrer les rapports (100 maximum par page). Les filtres de projet sont appliqués côté serveur avant la pagination. Filtrez par project (UUID, slug, nom exact ou préfixe de ticket), project_id, project_slug, project_prefix, workspace (UUID, nom exact ou préfixe de ticket de l’espace de travail), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause ou reporter_user_id. Le filtre search recherche dans le texte des rapports ; une entrée composée uniquement de chiffres, telle que 366, effectue une recherche exacte dans les numéros de ticket hérités et ceux des projets, excluant ainsi les textes sans rapport contenant ces chiffres. Chaque résultat inclut des identifiants de personnes/projets limités au tenant, ainsi que is_epic, parent_epic_id, parent_epic et epic_progress avec une taille limitée. Les outils de lecture des rapports n’exposent pas les adresses e-mail des membres.
• pick_next_bug — Renvoie le ou les prochains bugs sur lesquels la boucle de l’agent doit travailler, par ordre de priorité (S1 → S2 → S3, du plus ancien au plus récent dans chaque catégorie). Portée automatiquement à votre espace de travail — renvoie les tickets de tous les projets de votre équipe avec status new, awaiting-triage ou confirmed et une gravité S1-S3. Lecture seule — ne réserve pas les tickets de manière atomique. severity facultatif (un seul niveau), limit (1-50, 1 par défaut). Renvoie un objet contenant count et bugs ; chaque bug est une ligne de file d’attente réduite, et non un objet complet de forme list_bug_reports. À associer à claim_bug pour le modèle lecture puis réservation.
• claim_bug — Fait passer atomiquement un bug de status new, awaiting-triage ou confirmed à status='in-progress', définit assigned_to sur l’utilisateur appelant et horodate claimed_at=NOW(). Sans risque de concurrence entre appels simultanés grâce au modèle UPDATE-WHERE-RETURNING de Postgres : si deux agents appellent claim_bug sur le même identifiant à peu d’intervalle, un seul reçoit claimed:true avec le corps du bug, tandis que l’autre reçoit claimed:false avec une chaîne indiquant la raison. Les réponses réussies incluent reporter_user_id, reporter_name, assigned_to et assignee_name. Un processus pg_cron libère automatiquement les réservations obsolètes (status= in-progress + claimed_at > 30 minutes) et les remet à new, afin que les tickets d’un agent ayant planté réintègrent la file sans intervention manuelle. Entrées : id (UUID ou ID court).
• get_bug_report — Obtenir les détails complets d’un rapport par UUID ou ID court d’espace de travail/projet. Renvoie les champs standard relatifs aux personnes, au projet et à la qualité, ainsi que is_epic, l’identité du parent, la progression agrégée et une première page limitée des enfants pour les Epics.
• Tags natifs des rapports : create_bug_report et update_bug_report acceptent tags sous forme de tableau de chaînes, par exemple {"tags":["login","regression"]}. Au maximum 20 éléments bruts sont acceptés avant déduplication. Les chaînes sont supprimées de leurs espaces de début et de fin, doivent être non vides et ne pas dépasser 50 points de code Unicode, et ne peuvent contenir de caractères de contrôle ASCII (U+0000 à U+001F ou U+007F). Les doublons exacts sont supprimés après suppression des espaces ; la casse est préservée et Login diffère de login. Lors d’une mise à jour, le tableau remplace tous les tags, [] les efface et l’omission les conserve. Lors de la création, l’omission signifie qu’il n’y a aucun tag. null et les éléments non valides sont rejetés. Les résultats de création, de lecture, de liste et de mise à jour exposent les tags natifs.
• Filtrage par tags : appelez list_bug_reports avec {"project":"bugagent","tags":["login","regression"]} pour rechercher TOUS les tags demandés, en respectant la casse, avant la pagination. Les mêmes limites de tags s’appliquent ; l’omission ou [] n’applique aucun filtre par tag. Les portées existantes reports:read / reports:write et les autorisations de l’espace de travail/du projet restent inchangées. Cela n’ajoute aucune interface visuelle pour les tags ni import, synchronisation ou remplissage rétroactif automatique des libellés Jira.
• get_epic — Lire directement une Epic avec id obligatoire (UUID ou ID court d’espace de travail/projet). Renvoie uniquement l’enregistrement de l’Epic, sans charger implicitement les rapports enfants. Nécessite l’accès à son espace de travail et à son projet ; les appelants utilisant une clé API doivent disposer de reports:read. Utilisez séparément list_epic_children pour lire les enfants.
• list_epic_children — Parcourir les rapports enfants d’une Epic avec id, limit (1–100) et offset. Renvoie children, total, has_more et epic_progress agrégé par SQL, sans charger tous les rapports enfants.
• update_bug_report — Mettre à jour les champs standard d’un rapport ainsi que is_epic et parent_epic_id. Transmettez parent_epic_id: null pour détacher ; le changement de parent ou le détachement est atomique et nécessite une autorisation pour le même espace de travail et le même projet. La promotion en Epic détache un parent existant, tandis qu’une Epic ayant des enfants ne peut pas être rétrogradée. Les règles existantes concernant le statut, la résolution, la cause racine et les notifications d’affectation restent applicables. Une modification de status sur un rapport lié à Jira est répercutée sur le ticket Jira via ses transitions de workflow lorsqu’une seule transition légale correspond au statut associé ; sinon, le ticket reste inchangé.
• add_comment — Ajouter un commentaire à un rapport de bug (UUID ou ID court, corps de 1 à 10 000 caractères). Si le rapport est synchronisé avec Jira, le commentaire est automatiquement envoyé au ticket Jira associé. Le Markdown de pièce jointe privée, tel que ![proof](/api/attachments/ATTACHMENT_UUID), devient un lien intelligent absolu et authentifié vers bugAgent dans Jira. Les personnes qui le consultent doivent se connecter à bugAgent et avoir accès à l’espace de travail et au projet du rapport ; l’affichage natif des aperçus intégrés de Jira n’est pas garanti.
• list_comments — Lister le fil de commentaires enregistré d’un rapport, du plus ancien au plus récent — chaque commentaire avec le nom de l’auteur, parentId (réponses en fil), createdAt et updatedAt. Les commentaires ne font pas partie de get_bug_report ; c’est donc ainsi que vous pouvez lire la discussion d’un ticket. Accepte un UUID ou un ID court. Cette lecture ne rafraîchit pas Jira. Les intégrations planifiées qui ont besoin de commentaires Jira à jour peuvent d’abord appeler POST /api/jira/comments-refresh avec une clé API autorisée appartenant à un gestionnaire. Utilisez les ID de commentaires et les révisions de contenu pour distinguer les nouveaux commentaires des modifications, et ne prétendez pas fournir un rapport d’activité complet si le rafraîchissement échoue.
• link_bug_reports — Créer un lien sémantique directionnel entre deux rapports du même projet autorisé. Pour parent-of, le rapport source doit être une Epic et le rapport cible un enfant standard. Privilégiez parent_epic_id lors de la création ou de la mise à jour pour affecter une Epic.
• unlink_bug_reports — Supprimer un lien de rapport de bug créé précédemment à l’aide de son UUID (link_id, renvoyé par link_bug_reports ou list_bug_report_links).
• list_bug_report_links — Lister tous les liens créés par les utilisateurs qui touchent un rapport de bug. Renvoie chaque lien tel qu’il apparaît depuis le point de vue du rapport fourni — par exemple, une ligne duplicate-of enregistrée où ce rapport est la cible est affichée comme duplicated-by ; parent-of où ce rapport est la cible est affiché comme subtask-of ; depends-on où ce rapport est la cible est affiché comme blocks ; testing-blocked-by où ce rapport est la cible est affiché comme blocks-testing. related-to est symétrique. Complète le champ similar_reports détecté automatiquement et renvoyé par get_bug_report.
• classify_bug — Classer une description dans l’un des 19 types de rapports (bugs, fonctionnalités, améliorations, etc.) avec un score de confiance
• flush_reports — Supprimer en masse les anciens rapports (administrateurs uniquement)

📊

Utilisation et analyses

• get_usage — Vérifier l’utilisation par rapport aux limites du forfait. Les appelants utilisant une clé API doivent disposer de usage:read.
• get_stats — Comptages quotidiens, répartitions par type, gravité et statut

📁

Gestion des projets

• list_projects — Lister les projets accessibles avec id, name, slug, ticket_prefix, la description et le statut par défaut. Utilisez ces valeurs avec les outils de rapports de bugs et de catalogue de tests pour cibler le bon projet.
• create_project — Créer un projet (il devient automatiquement le projet par défaut s’il s’agit du premier)
• delete_project — Supprimer définitivement un projet et toutes les données associées (rapports de bugs, automatisations, cas de test, applications mobiles, planifications, captures géographiques, notes, entrées de temps). Réservé au propriétaire ou au gestionnaire. Impossible de supprimer le dernier projet. L’espace de stockage est libéré automatiquement.
• export_okf_bundle — Exporter les connaissances d’assurance qualité d’un projet — rapports de bugs, cas de test, automatisations et tests de performance, de sécurité et exploratoires — sous forme de lot Markdown OKF/OQA (le format Open Query Agent utilisé par oqa.ai). Le projet actif est utilisé par défaut ; transmettez le paramètre facultatif project (slug ou nom) pour en exporter un autre. Renvoie la liste des fichiers du lot ainsi que le lot lui-même sous forme de fichier zip encodé en base64.

🔐

Authentification et compte

• register_account — Créer un compte (mot de passe : 8 à 128 caractères, limité à 5 requêtes par 15 min)
• login — Se connecter et recevoir des jetons d’accès (limité à 5 requêtes par 15 min)
• update_profile — Mettre à jour le nom d’affichage
• change_password — Modifier le mot de passe du compte
• get_settings — Lire le profil et les préférences de notification.
• update_settings — Mettre à jour les préférences de profil et de notification prises en charge. Modification réservée à OAuth.

🔑

Gestion des clés API

• generate_api_key — Créer une clé API nommée
• list_api_keys — Lister les clés actives (préfixe uniquement)
• regenerate_api_key — Révoquer et remplacer une clé
• delete_api_key — Révoquer définitivement une clé

👥

Gestion de l’équipe

• list_workspaces — Lister les espaces de travail auxquels vous appartenez, votre rôle dans chacun et celui utilisé par défaut par la session. Les hôtes multi-espaces de travail peuvent épingler une requête avec l’en-tête X-BugAgent-Workspace (membres actifs uniquement)
• list_team_members — Lister tous les membres de votre espace de travail avec leurs rôles, leur statut et leurs indicateurs de booster
• invite_team_member — Inviter un utilisateur par e-mail (les gestionnaires peuvent inviter des contributeurs et des gestionnaires ; seuls les propriétaires peuvent inviter des administrateurs). Lien valable 5 jours

🎯

Intégrations

La synchronisation des rapports Jira Cloud est incluse dans les forfaits Free et Enterprise. Un gestionnaire de l’espace de travail doit d’abord connecter Jira dans le tableau de bord. Les clés API de l’espace de travail peuvent ensuite utiliser jira:read pour la comparaison et jira:write pour la synchronisation/fusion ; les limites de forfait et d’API d’Atlassian restent applicables.

• sync_to_jira — Envoyer un rapport à Jira à l’aide de la connexion partagée de l’équipe. Le rapport est dirigé vers le projet Jira associé au projet bugAgent du rapport (avec le projet par défaut de l’espace de travail comme solution de repli), en utilisant sa correspondance de champs : la v2 sépare la priorité et la sévérité personnalisée, tandis que les correspondances sans version conservent la traduction historique de la sévérité en priorité. Le paramètre facultatif projectKey peut sélectionner uniquement cette correspondance configurée ou le projet par défaut de l’espace de travail ; les projets Jira arbitraires sont refusés. En général, vous n’en avez pas besoin : lorsque le mode de synchronisation du projet est auto_new ou auto_all, les rapports que vous créez sont envoyés automatiquement — utilisez cet outil pour un envoi manuel en mode manual.
• check_jira_sync — Comparaison en lecture seule du titre et du statut, de la priorité et de la sévérité associés pour un rapport lié autorisé. Utilise le projet enregistré du rapport et la connexion Jira. La version 2 associe séparément la priorité Jira et un champ de sévérité personnalisé pris en charge ; les correspondances sans version conservent le comportement historique de conversion de la priorité en sévérité. Cet outil ne compare pas les commentaires, les pièces jointes, le type ni tous les champs Jira.
• merge_jira_sync — Fusionner ces champs associés en utilisant prefer: jira pour récupérer les valeurs Jira ou prefer: bugagent pour envoyer les valeurs locales. Les mises à jour du statut utilisent les transitions de workflow Jira autorisées. Les conflits sortants non associés, les échecs d’écriture à distance et les modifications locales concurrentes renvoient des erreurs au lieu de prétendre que tout est synchronisé. Les commentaires et les pièces jointes restent des workflows de synchronisation distincts du tableau de bord. Les écritures entre systèmes ne sont pas atomiques.
• push_to_claude — Générer (ou régénérer) les Notes du développeur d’un rapport de bogue — cause racine, correctif suggéré, étapes de vérification et évaluation des risques. Accepte un UUID ou un identifiant court (WRKID-545). Utilise les clés de la plateforme — aucune connexion Claude par équipe n’est nécessaire. Exécute une chaîne adaptative : trois étapes pour les bogues s3 / medium ou s4 / low (brouillon Sonnet → critique OpenAI gpt-5 → synthèse Sonnet), cinq étapes pour les deux catégories de sévérité les plus élevées — s1 / critical ou s2 / high — (brouillon → critique → réfutation Sonnet → arbitre Claude Opus qui lit la transcription complète et rédige les notes finales en exerçant son propre jugement). La réponse expose chaque étape : analysis, draft, critique, rebuttal, challenger_model, adjudicator_model et un indicateur debated. En cas d’échec d’une étape, le processus passe à la meilleure réponse suivante. Déclenché automatiquement à la création d’un bogue ; généralement appelé uniquement pour une régénération manuelle.
• analyze_fix_area — Générer (ou régénérer) le sous-bloc « Likely Fix Area » des Notes du développeur — une réponse Sonnet ciblée qui indique où, dans la base de code, le correctif a le plus de chances de se trouver. Accepte un UUID ou un identifiant court. Utilise la clé Anthropic de la plateforme. Si l’équipe dispose d’une ligne github_connections et que le projet a un github_repo associé, la réponse s’appuie sur des extraits réels de fichiers du dépôt connecté ; sinon, elle fournit des conseils généraux et suggère de connecter un dépôt. Renvoie le texte likely_fix_area, generated_at, repo_used et un indicateur grounded. Déclenché automatiquement à la création d’un bogue — les agents n’ont généralement besoin de l’appeler que pour une régénération manuelle.
• upgrade_plan — Obtenir le lien d’inscription Enterprise avec l’aide de l’équipe commerciale

⚡

Tests de performance

• create_performance_test — Créer une configuration de test de performance avec une URL, un appareil, des utilisateurs virtuels, une durée, un seuil de score et une option de création automatique de bogues. Le paramètre facultatif project accepte un UUID de projet, un slug, un nom exact ou un préfixe de ticket dans l’espace de travail actuel. S’il est omis, le projet par défaut de l’espace de travail est utilisé, puis le projet le plus ancien ; l’appelant doit y avoir accès. Utilisez list_projects pour choisir un projet. Un projet vide, inconnu ou inaccessible est refusé. name ne doit pas être vide et sa valeur est supprimée des espaces superflus. Les noms des tests de performance doivent être uniques dans l’espace de travail et le projet, sans tenir compte de la casse ni des espaces de début et de fin ; en cas de conflit, un autre nom vous sera demandé. Enterprise uniquement
• run_performance_test — Lancer un audit de page et un test de charge pour un test de performance Web. Renvoie un ID d’exécution à interroger pour obtenir les résultats. Les exécutions de profilage d’applications mobiles sont lancées depuis le tableau de bord
• get_performance_results — Obtenir les résultats complets, notamment les scores Lighthouse (Performance, Accessibilité, Bonnes pratiques, SEO), les Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) et les métriques du test de charge (VU, requêtes, RPS, latences p50/p90/p95/p99)
• list_performance_tests — Répertorier toutes les configurations de test de performance de l’équipe actuelle
• get_performance_usage — Vérifier l’utilisation mensuelle des tests de performance. Les tests de performance sont réservés à Enterprise. Free=0, Enterprise=illimité

Exemple de workflow

1. get_performance_usage → vérifier le quota restant
2. create_performance_test → configurer un test pour votre URL
3. run_performance_test → lancer l’audit et le test de charge
4. get_performance_results → examiner les scores et les indicateurs vitaux

🛡

Analyses de sécurité

• create_security_scan — Créer une configuration d’analyse de sécurité. Les analyses Web utilisent Quick Scanner et Nuclei (plus de 4 000 modèles) avec trois niveaux de profondeur et une analyse authentifiée facultative. Les analyses mobiles utilisent MobSF pour l’analyse des fichiers binaires APK/IPA. Création automatique de bogues configurable avec seuils de sévérité. Le paramètre facultatif project accepte un UUID de projet, un slug, un nom exact ou un préfixe de ticket dans l’espace de travail actuel. S’il est omis, le projet par défaut de l’espace de travail est utilisé, puis le projet le plus ancien ; l’appelant doit y avoir accès. Utilisez list_projects pour choisir un projet. Un projet vide, inconnu ou inaccessible est refusé. name ne doit pas être vide et sa valeur est supprimée des espaces superflus. Les noms des analyses de sécurité doivent être uniques dans l’espace de travail et le projet, sans tenir compte de la casse ni des espaces de début et de fin, indépendamment des noms des tests de performance ; en cas de conflit, un autre nom vous sera demandé. Enterprise uniquement
• run_security_scan — Lancer une analyse de vulnérabilités. Les analyses Web nécessitent la vérification DNS du domaine. Les analyses mobiles nécessitent le téléversement d’une application. Renvoie un ID d’exécution à interroger pour obtenir les résultats
• get_security_results — Obtenir les résultats complets, notamment le score de sécurité (0-100), les vulnérabilités classées par sévérité (Critique, Élevée, Moyenne, Faible, Info) avec références CWE, correspondances OWASP, éléments de preuve et conseils de correction
• list_security_scans — Répertorier toutes les configurations d’analyse de sécurité de l’équipe actuelle, avec le dernier score et des badges d’authentification/de profondeur
• get_security_usage — Vérifier l’utilisation mensuelle des analyses de sécurité. Les analyses de sécurité sont réservées à Enterprise. Enterprise=illimité
• list_security_schedules — Répertorier toutes les analyses de sécurité planifiées de l’équipe, avec cron, fuseau horaire, état d’activation, prochaine exécution et paramètres de notification. Jointure avec la configuration d’analyse parente (name, scan_type, target_url)
• create_security_schedule — Créer une planification récurrente pour une analyse de sécurité. Nécessite scan_id et cron_expression. Une planification par configuration d’analyse. Paramètres facultatifs timezone, notify_on_fail (none/email/slack/both), notify_email, slack_channel_id. Chaque exécution est décomptée du plafond mensuel ; les utilisateurs administrateurs ne sont pas soumis à ce plafond. La profondeur d’analyse est toujours lue dans la configuration d’analyse au moment de l’exécution
• delete_security_schedule — Supprimer une analyse de sécurité planifiée. N’affecte ni la configuration d’analyse parente ni les exécutions terminées

Exemple de workflow

1. get_security_usage → vérifier le quota restant
2. create_security_scan → configurer une analyse pour votre URL ou dépôt
3. run_security_scan → lancer une analyse de vulnérabilités ponctuelle
4. create_security_schedule → automatiser les exécutions récurrentes (par ex. SAST hebdomadaire sur la branche principale)
5. get_security_results → examiner les vulnérabilités et les corrections

📖

Revue de code

• list_code_reviews — Répertorier les revues de code IA récentes de l’équipe. Renvoie les scores de qualité, le nombre de vulnérabilités par sévérité, les informations sur les PR et les horodatages. Enterprise uniquement
• get_code_review — Obtenir une revue de code avec toutes les vulnérabilités détectées. Chaque résultat comprend la sévérité, la catégorie (bug/sécurité/performance/style/logique/maintenabilité), le titre, la description, une suggestion de code, le chemin du fichier et les numéros de ligne
• get_code_review_usage — Vérifier l’utilisation des revues de code. La revue de code IA est réservée à Enterprise ; utilisation illimitée avec Enterprise
• get_code_review_analytics — Obtenir les statistiques des revues : tendances, catégories/sources des résultats, répartition par sévérité, métriques de vélocité, principaux dépôts/auteurs. Prend en charge une période rétrospective de 7/30/90 jours

Exemple de workflow

1. get_code_review_usage → vérifier le nombre de revues restantes
2. Examiner une PR dans le tableau de bord à l’adresse /dashboard/code-review
3. list_code_reviews → consulter les revues récentes
4. get_code_review → obtenir les résultats et les suggestions

🔍

IA exploratoire

Outil autonome de recherche de bogues sur les sites Web, basé sur plusieurs agents, avec jusqu’à 10 agents parallèles, chacun utilisant une stratégie de test différente.

• list_explorations — Répertorier les configurations d’IA exploratoire de l’équipe
• create_exploration — Créer une exploration. Accepte agent_count (1–10, maximum 10) pour exécuter plusieurs agents en parallèle avec des stratégies distinctes : happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Cet outil ne permet pas de configurer les identifiants ni le mode d’authentification. Configurez et lancez explicitement Test login flow only depuis le tableau de bord ou l’API REST, puis utilisez get_exploration et get_exploration_run pour examiner la configuration et les résultats. Ne déduisez jamais le mode à partir des instructions et ne transmettez pas d’identifiants dans les arguments MCP. L’exploration par défaut basée sur des identifiants nécessite toujours une session réutilisable.
• get_exploration — Obtenir la configuration d’exploration avec les paramètres des agents, les métadonnées d’authentification sécurisées et les exécutions récentes. Les mots de passe et les textes chiffrés ne sont jamais renvoyés.
• get_exploration_run — Obtenir les résultats d’exécution avec la progression de chaque agent, les données des phases, les résultats avec attribution aux agents (agent_index, agent_strategy) et les bogues associés
• get_exploration_usage — Vérifier l’utilisation mensuelle. L’IA exploratoire est réservée à Enterprise ; Enterprise : illimité (10 agents)

Exemple de workflow

1. create_exploration avec agent_count: 5 → configurer 5 agents parallèles
2. Lancer une exécution depuis le tableau de bord ou via POST /api/explorations/run
3. get_exploration_run → suivre la progression et les résultats de chaque agent
4. Consulter dans le tableau de bord les résultats dédupliqués avec attribution aux agents

📝

Notes

• list_notes — Répertorier les notes avec des filtres facultatifs par mot-clé, projet, visibilité, dossier, étiquette, archivage, wiki, plage de dates et tri. Renvoie les notes appartenant à l’utilisateur ou partagées avec lui.
• create_note — Créer une note dans l’un des 5 formats : markdown, plain, bugtemplate, checklist, outline. Définissez visibility sur private ou shared. Si aucun titre n’est fourni, il est généré à partir des 30 premiers caractères. Le tableau facultatif attachments accepte des fichiers encodés en base64 jusqu’à 400 MB chacun : toute image, vidéo, fichier audio, PDF ou fichier texte/JSON. Transmettez time_spent_seconds pour suivre l’effort d’assurance qualité.
• get_note — Obtenir tous les détails d’une note, y compris son contenu et ses pièces jointes. Nécessite id.
• update_note — Mettre à jour le titre, le contenu, le format, la visibilité, le projet ou time_spent_seconds. Transmettez un tableau attachments pour ajouter de nouveaux fichiers (400 MB maximum chacun) aux pièces jointes existantes de la note, sans les remplacer. Seul l’auteur peut effectuer une mise à jour. Nécessite id.
• delete_note — Supprimer définitivement une note et ses pièces jointes. Seul l’auteur peut la supprimer. Nécessite id.
• list_note_folders — Répertorier les dossiers de notes/wiki, avec possibilité de limiter la recherche à un projet.
• create_note_folder — Créer un dossier de notes/wiki associé à un projet, avec des paramètres facultatifs de dossier parent, visibilité, favori et accès des coéquipiers.

Exemple de workflow

1. create_note → commencer une note de session de test
2. update_note → ajouter des observations au fil des tests
3. list_notes → rechercher des notes antérieures par mot-clé ou projet
4. get_note → récupérer la note complète avec ses pièces jointes

🤖

Automatisation

• create_automation — Créer une nouvelle automatisation avec un script Playwright personnalisé (aucun enregistrement FAB requis). Nécessite name. Facultatif : target_url (déduit automatiquement de la première URL page.goto(...) du script si omis), script (Node.js/JavaScript/TypeScript ou Python — le langage est détecté automatiquement ; valeur par défaut : un espace réservé), status (draft ou active, valeur par défaut : draft), project_id. Renvoie l’automatisation id. Conseil — Dupliquer une automatisation : utilisez get_automation pour récupérer le script d’origine, puis appelez create_automation avec name défini sur "[Copy] Original Name" et transmettez les valeurs d’origine script, target_url et project_id. Le doublon démarre avec le statut draft et sans historique de versions.
• list_automations — Lister les scripts d’automatisation Playwright. Filtrer par project_id ou status (draft, active, paused). Renvoie un tableau d’automatisations avec leur nom, target_url, last_run_status et run_count.
• get_automation — Obtenir tous les détails d’une automatisation, y compris le script Playwright et les exécutions récentes. Nécessite id. Renvoie l’automatisation avec le script actif, une pile script_versions (de la plus ancienne à la plus récente, jusqu’à 100 entrées précédentes, chacune { script, source, timestamp }) et un tableau recent_runs où chaque exécution contient le script_version_label / script_version_source utilisé. Appelez cet outil avant run_automation si vous devez choisir une version historique précise.
• run_automation — Déclencher immédiatement l’exécution d’un test Playwright. Nécessite automation_id. Locateurs auto-réparateurs (automatique) : lorsqu’une action sur un locateur expire, l’exécuteur demande à Claude un sélecteur fonctionnel et réessaie l’étape une fois — les assertions ne sont jamais réparées, de sorte que les régressions réelles échouent toujours — et chaque réparation est consignée dans la sortie standard de l’exécution. Mode émulation (par défaut) : device facultatif pour un profil d’appareil émulé (p. ex. desktop, iphone-15). Mode réel : définissez browserstack: true avec bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) et bs_os_version pour exécuter le test dans un navigateur de bureau réel. Mobile réel : définissez bs_os: "android" (appareils : "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") ou bs_os: "ios" (appareils : "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") et transmettez le nom de l’appareil dans bs_os_version. Les deux modes s’exécutent en arrière-plan ; « réel » décrit l’environnement d’exécution, et non une session interactive visible. Les scripts Node.js passent par browserstack-node-sdk (prend en charge les ordinateurs de bureau, Android et iPhone). Les scripts Python passent par browserstack-sdk (pytest-playwright) et ne prennent en charge que les ordinateurs de bureau — l’exécution mobile réelle avec Python n’est pas prise en charge, car le browser_type.connect() de pytest-playwright ne peut pas piloter les points de terminaison mobiles réels de BrowserStack. Les vidéos et les journaux réseau sont capturés automatiquement ; les journaux de console sont réservés aux ordinateurs de bureau. Relecture de version : examinez script_versions avec get_automation, puis transmettez le version_label durable de votre choix (par exemple "v103"). L’ancien version_index reste pris en charge, mais ne doit pas être combiné avec version_label. Par défaut : si les deux sélecteurs sont omis, le script actuellement enregistré est exécuté. Les libellés supprimés et les indices non valides sont rejetés au lieu d’exécuter silencieusement la version actuelle. L’enregistrement de l’exécution conserve l’instantané exact qui a été exécuté, et tout rapport de bogue créé automatiquement à la suite d’un échec renvoie directement à cette version dans l’éditeur.
• list_automation_runs — Lister les exécutions récentes d’une automatisation. Nécessite automation_id. Renvoie les exécutions avec leur statut, duration_ms et error_message.
• list_schedules — Lister toutes les exécutions d’automatisations Web planifiées, avec cron_expression nullable, run_at nullable, once_status, le fuseau horaire, l’appareil et les paramètres de notification. Les lignes récurrentes conservent run_at et once_status à null ; les lignes ponctuelles ont cron à null. États ponctuels : pending, claimed, missed, dispatched, failed, uncertain. Il s’agit d’états de distribution, et non de résultats de test ; consultez list_automation_runs pour les résultats.
• Planifications Web récurrentes : create_schedule valide cinq champs cron numériques et le fuseau horaire, puis renvoie un next_run_at UTC futur. Les récurrences mensuelles et annuelles sont prises en charge. Par exemple, 30 12 23 9 * dans America/Toronto signifie le 23 septembre à 12 h 30 chaque année, et non une exécution ponctuelle. Les horaires non valides ou impossibles sont rejetés avant la création. Lorsque le jour du mois et le jour de la semaine sont tous deux restreints, les deux doivent correspondre. Les heures inexistantes dues au passage à l’heure d’été sont ignorées ; les heures répétées peuvent se produire deux fois. La distribution a lieu lors du prochain cycle de vérification du planificateur, pas nécessairement à la minute exacte. Le comportement récurrent existant reste inchangé.
• Planifications Web ponctuelles : appelez create_schedule avec { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" }, en choisissant une date future et en omettant cron_expression. Fournissez exactement un champ de date et d’heure. run_at exige un horodatage ISO 8601 futur avec décalage horaire (décalage explicite ou Z) ; le fuseau horaire IANA sert à l’affichage. Une planification activée et en attente s’exécute au premier cycle cron après l’échéance ; si elle a plus d’une heure de retard, elle est marquée missed. Elle est revendiquée de manière atomique et désactivée avant la distribution, et ne peut pas être réactivée une fois consommée. Les échecs de distribution définitifs sont failed ; une distribution dont l’issue est incertaine est uncertain et n’est jamais réessayée automatiquement. Vérifiez les exécutions avant de planifier une nouvelle tentative. dispatched ne signifie pas que l’exécution est terminée ou réussie. La création est réservée à l’API/MCP ; il ne s’agit pas d’un nouveau mode de création dans le tableau de bord.
• Les fuseaux horaires des planifications Web sont des identifiants IANA tels que America/Argentina/Buenos_Aires. Le sélecteur du tableau de bord inclut toutes les régions et villes prises en charge par le serveur et utilise par défaut le fuseau horaire de votre profil ; le fuseau horaire MCP par défaut reste UTC.
• create_schedule — Créer une exécution d’automatisation Web planifiée. Nécessite automation_id et exactement l’un de cron_expression ou run_at. Prend en charge les paramètres facultatifs d’appareil, de fuseau horaire, de notification en cas d’échec, d’e-mail et de canal Slack. Connectez Slack via le tableau de bord au préalable et choisissez un canal auquel le bot appartient ; l’installation d’un webhook ne suffit pas. Consultez Configuration de Slack et découverte des canaux.
• Déploiement et récupération des exécutions ponctuelles : appliquez la migration de base de données 374_one_time_web_schedules.sql avant de déployer le code correspondant de l’API/MCP et du planificateur. claimed peut persister après le plantage d’un processus de travail : consultez l’historique des exécutions avant de créer un remplacement pour une distribution revendiquée ou incertaine. Un horodatage ayant plus d’une heure de retard n’est jamais exécuté automatiquement.
• Automatisations Web en brouillon : activez l’automatisation avant de créer une planification, de réactiver une planification ou de modifier son expression cron ou son fuseau horaire. create_schedule vérifie l’accès à l’espace de travail et au projet avant de rejeter le statut Brouillon. Les planifications existantes ignorent les cycles pendant que l’automatisation est en brouillon ; la mise en pause, la suppression, l’épinglage et les modifications portant uniquement sur les notifications restent disponibles. Il n’existe pas d’outil MCP Web update_schedule ; utilisez le tableau de bord pour ces mises à jour.
• delete_schedule — Supprimer une exécution d’automatisation Web planifiée
• list_mobile_schedules — Lister toutes les exécutions d’automatisations mobiles planifiées, avec les appareils, cron, le fuseau horaire et les notifications
• create_mobile_schedule — Créer une exécution d’automatisation mobile planifiée sur des appareils réels. Nécessite automation_id et cron_expression ; devices est facultatif.
• delete_mobile_schedule — Supprimer une exécution d’automatisation mobile planifiée
• optimize_automation_script — Envoyer un script Playwright à Sonnet 4 pour l’optimiser avec l’IA. Applique une liste de contrôle en 12 points pour corriger les sélecteurs, les stratégies d’attente, les assertions, la gestion des erreurs, les modèles d’authentification, la compatibilité mobile et le mode strict. Nécessite automation_id. La version actuelle du script est enregistrée avant l’optimisation. Renvoie le script optimisé et un résumé des modifications.
• undo_automation_script — Rétablir la version précédente d’un script d’automatisation. Jusqu’à 100 versions précédentes sont conservées. Nécessite automation_id. Renvoie le script restauré et le nombre de versions restantes.

Exemple de flux de travail

1. create_automation → créer un test avec un script personnalisé
2. list_automations → parcourir les tests disponibles
3. get_automation → examiner le script Playwright
4. run_automation → déclencher le test
5. list_automation_runs → vérifier les résultats et la durée

⏱️

Suivi du temps

• list_time_entries — Lister les entrées de temps de l’équipe. Filtrer par period (today, week, month, all), project_id, category et sort (newest, oldest, most_time, least_time). Réservé au forfait Enterprise.
• create_time_entry — Consigner le temps consacré aux tâches d’assurance qualité. Nécessite description, category et duration_minutes. Vous pouvez également définir project_id et entry_date (la valeur par défaut est aujourd’hui). Réservé au forfait Enterprise.
• update_time_entry — Mettre à jour une entrée de temps existante. Nécessite id. Peut mettre à jour description, category, duration_minutes, project_id ou entry_date. Réservé au forfait Enterprise.
• delete_time_entry — Supprimer définitivement une entrée de temps. Nécessite id. Réservé au forfait Enterprise.

Exemple de flux de travail

1. create_time_entry → consigner 45 minutes de tests de régression
2. list_time_entries → consulter les entrées de temps de cette semaine
3. update_time_entry → ajuster la durée ou la catégorie
4. delete_time_entry → supprimer une entrée incorrecte

☑️

Cas de test

Gestion des tests avec des dossiers hiérarchiques, des suites imbriquées (jusqu’à 3 niveaux de profondeur, avec développement automatique des sous-suites lors des exécutions), le réordonnancement par glisser-déposer et un onglet Rapports analytiques avec les tendances des KPI, l’analyse des échecs, l’état des suites, la couverture et la productivité des testeurs. Tous les outils appellent directement Supabase — aucun aller-retour HTTP, latence identique à celle du tableau de bord.

Limites du forfait Free : 10 cas de test stockés, 1 suite, 3 dossiers, 128 Ko de contenu structuré par cas, 2 clés API d’espace de travail actives et 10 exécutions de test au total par mois civil UTC. Jusqu’à 3 de ces exécutions peuvent utiliser Hermes ou un autre agent externe, avec 1 exécution externe active et au maximum 10 cas dans chaque plan externe. Le trafic MCP Free via clé API est limité à 30 requêtes par clé et à 60 par espace de travail par minute. Le stockage des cas de test et les exécutions sont illimités avec le forfait Enterprise, sous réserve des protections générales de la plateforme.

La génération de cas de test par IA, les suggestions de balises par IA, l’importation Figma et les pièces jointes aux fichiers des cas de test nécessitent le forfait Enterprise. La limite de 128 Ko de contenu structuré du forfait Free est distincte des pièces jointes de fichiers du forfait Enterprise. Le forfait Free permet de stocker des références URL. Les outils MCP essentiels pour les cas de test restent disponibles avec le forfait Free, dans les limites indiquées ci-dessus.

Exécution mains libres : la page de révision des exécutions est un carrousel affichant un cas à la fois, avec des raccourcis clavier (P Réussite · F Échec · B Bloqué · S Ignorer) et la commande vocale. Cliquez sur le micro, puis dites « Réussite », « Échec », « Bloqué », « Ignorer », « Suivant », « Précédent », « Ajouter des notes » (transcrit le texte dans le champ des notes), « Enregistrer les notes » ou « Désactiver la commande vocale ». En cas de réussite, passe automatiquement au prochain cas non testé ; en cas d’échec, reste sur le cas pour permettre aux testeurs de dicter les détails et de créer un bogue. Fonctionne dans Chrome, Edge et Safari.

Cas et dossiers

• list_test_cases — Répertorier les cas de test accessibles avec un sélecteur project facultatif, ainsi que les filtres search, priority, type, status et sort. Ajouter folder_id (null pour les cas non classés) ou suite_id pour l’appartenance directe, sans descendants. Les appelants utilisant une clé API doivent disposer de test_cases:read. limit vaut 50 par défaut (1-200) ; offset vaut 0 par défaut (0-1000000). Le tableau cases, inchangé, est accompagné de total / total_count pour toutes les correspondances autorisées, de limit, offset, has_more et de next_offset, qui peut être null. Auparavant, total désignait à tort la longueur de la page. Suivez next_offset jusqu’à ce qu’il soit null ; ne déduisez pas que la liste est complète à partir de la longueur de la page. Une continuation au-delà de l’offset 1000000 échoue explicitement ; affinez plutôt les filtres au lieu de recevoir un curseur inutilisable ou de conclure à tort que la liste est complète. Les pages dépassant 1 MiB de données de cas échouent explicitement : réessayez avec une limite plus basse au lieu d’accepter des enregistrements omis. Un tri stable par ID est utilisé, mais des modifications concurrentes peuvent décaler les pages d’offset.
• Exemple de pagination : appelez list_test_cases avec {"project":"test-bed","limit":50,"offset":0}. Pour 55 correspondances, la réponse contient total:55, has_more:true, next_offset:50. Répétez avec offset:50 pour les cinq restantes et has_more:false, next_offset:null.
• create_test_case — Créer un cas de test dans le sélecteur project requis (UUID, slug, nom exact ou préfixe de ticket ; appelez d’abord list_projects). Deux variantes de modèle : steps (par défaut) — grille { action, expected } par étape via le tableau steps ; text — description libre unique via text_content. Les deux champs peuvent être envoyés dans le même appel. Le tableau facultatif urls (10 URL http/https maximum) permet d’ajouter des liens de référence et est disponible avec l’offre Free. Les pièces jointes nécessitent l’offre Enterprise et une session de tableau de bord. Les appelants utilisant une clé API doivent disposer de test_cases:write.
• Récupération de la pagination : demander un offset de cas supérieur au nombre de résultats disponibles renvoie une erreur explicite ; recommencez à l’offset 0. Cela peut également se produire si des cas sont supprimés entre les requêtes. Suivez la continuation renvoyée au lieu de deviner l’offset suivant.
• Identifiants des cas : list_test_cases, get_test_case, create_test_case et update_test_case renvoient l’UUID id, le short_id immuable (par exemple TEST-BA-CASE-123) et le case_number numérique, y compris dans les réponses compactes de mise à jour/sans modification. Les anciens cas sans projet utilisent TEST-CASE-123. Les identifiants manquants sont renvoyés sous la forme null ; utilisez l’UUID comme solution de repli. La base de données attribue les identifiants ; les appelants ne peuvent ni les modifier ni les choisir lors de la création. Le renommage d’un préfixe ne réécrit pas les ID existants.
• Recherche d’un cas unique : get_test_case et update_test_case acceptent un UUID ou un ID court complet dans id ; link_test_case_to_bug et list_test_case_links acceptent l’un ou l’autre dans case_id. Les espaces environnants, la casse des lettres et le remplissage numérique sont normalisés avant la recherche exacte dans l’espace de travail actif. L’autorisation repose sur l’espace de travail et le projet enregistrés, et non sur le préfixe de l’ID. Les nombres seuls, les ID partiels et les recherches avec caractères génériques ne sont pas acceptés. Les tableaux de cas groupés, case_id des résultats d’exécution, les ID de bugs, les ID de dossiers et les ID de suites restent limités aux UUID. Les enregistrements de liens conservent l’UUID case_id.
• Lacunes dans la numérotation : les numéros de cas ne sont pas nécessairement consécutifs. Modifier une URL ou incrémenter un numéro peut mener à un cas manquant ou inaccessible ; cela ne garantit pas l’accès au cas suivant. Découvrez les cas avec l’outil de liste et suivez sa pagination.
• Portée de l’espace de travail : un même ID court peut exister dans différents espaces de travail. MCP le résout uniquement dans l’espace de travail actif ; changez de contexte d’espace de travail avant d’utiliser l’ID court d’un autre espace de travail. Lorsque vous partagez une URL de tableau de bord avec un ID court, conservez ?team=<case.team_id>, par exemple /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. Les permaliens UUID conservent le comportement existant d’accès autorisé entre espaces de travail. MCP ne construit pas de permalien.
• get_test_case — Obtenir l’enregistrement du cas autorisé, y compris les étapes et les identifiants. Ne charge pas l’historique des modifications ni l’historique d’exécution. Exemple : {"id":"TEST-BA-CASE-123"}.
• Estimations d’exécution : get_test_case renvoie estimated_time_seconds et l’alias de compatibilité estimated_time, tous deux en secondes. Une valeur 0 enregistrée reste 0 ; une estimation inconnue ou manquante vaut null. Le champ canonique prévaut lorsque les deux noms sont présents, y compris avec une valeur null explicite ; les valeurs estimated_time présentes uniquement dans l’ancien champ sont considérées comme des secondes, sans conversion. list_test_cases utilise estimated_time_seconds. L’entrée create_test_case reste estimated_time, également en secondes ; les requêtes et réponses REST utilisent estimated_time_seconds.
• list_test_case_folders — Répertorier les dossiers accessibles. Limite de 500 ; accepte un sélecteur project flexible et un filtre parent_folder_id (utilisez "root" pour les éléments de premier niveau uniquement). Les appelants utilisant une clé API doivent disposer de test_cases:read.
• get_test_case_folder — Lire directement un dossier de cas de test avec le champ id requis (UUID). Renvoie uniquement l’enregistrement du dossier, sans charger implicitement les dossiers descendants ni les cas de test. Nécessite l’accès à son espace de travail et à son projet ; les appelants utilisant une clé API doivent disposer de test_cases:read.
• Valeurs de type des cas de test pour list_test_cases, create_test_case et bulk_update_test_cases : functional (valeur par défaut à la création), regression, smoke, integration, performance, security, usability, exploratory. Les types non valides sont rejetés avant toute écriture. Utilisez integration pour les flux de bout en bout ; e2e, accessibility et other ne sont pas acceptés comme types de cas de test. Les types de scripts d’automatisation relèvent d’un contrat distinct.
• create_test_case_folder — Créer un dossier dans le project requis, renvoyé par list_projects (imbrication jusqu’à 3 niveaux via parent_folder_id). Nécessite un accès à l’espace de travail de niveau contributeur ou supérieur, ainsi qu’un accès au projet. Les appelants utilisant une clé API doivent également disposer de test_cases:write.
• update_test_case_folder — Mettre à jour par UUID de dossier : id, name facultatif (supprimé des espaces en début et fin, de 1 à 120 caractères), description nullable (50000 caractères maximum), parent_folder_id nullable et card_color nullable. Un UUID parent déplace le dossier et son sous-arbre au sein du même espace de travail et du même projet ; null le déplace à la racine. La couleur accepte la palette en minuscules #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd ; null l’efface. Les champs omis sont conservés. Au moins un champ de mise à jour est requis. Les champs inconnus, mal orthographiés ou non valides entraînent le rejet de toute la requête, sans enregistrer aucune modification. Les cycles impliquant le dossier lui-même ou ses descendants, les noms correspondant à un frère, au parent direct ou à un enfant direct (sans tenir compte de la casse ni des espaces environnants), ainsi que les profondeurs de sous-arbre supérieures à 3 (profondeur 0 à la racine) sont rejetés. Les profondeurs des descendants sont mises à jour de façon atomique ; les ID et l’appartenance des cas restent inchangés. Des modifications concurrentes conflictuelles peuvent échouer ; relisez le dossier avant de réessayer. Nécessite un accès actif au projet de niveau contributeur ou supérieur et test_cases:write pour les clés API. Exemple : {"id":"folder-uuid","card_color":"#93c5fd"}. Renvoie les champs id, team_id, project_id, name, description, card_color, parent_folder_id, depth et updated_at mis à jour. Les lectures de dossiers avec les outils get/list incluent également card_color.
• update_test_case — Modifier un cas existant par UUID ou ID court complet dans id, avec au moins un champ : name (ou l’alias title), description, preconditions, steps, template_type, text_content, priority, type, status ou folder_id. Les champs omis sont conservés ; steps remplace le tableau complet ([] l’efface). Une valeur null explicite efface la description, les préconditions, text_content ou l’emplacement du dossier ; un text_content vide efface également le contenu. Si name et title sont tous deux envoyés, ils doivent correspondre. La priorité et le type utilisent les énumérations de création ; le statut est active, draft ou deprecated. Un changement de type aligne type_tags sur le nouveau type, conformément à l’API PATCH. Aucun déplacement entre espaces de travail/projets ni aucune écriture de métadonnées de fichier. Les dossiers doivent appartenir exactement au même espace de travail et au même projet. Nécessite test_cases:write. Renvoie le résumé du cas, id, short_id, case_number et changed ; les valeurs inchangées produisent changed: false. Une mise à jour confirmée dont l’entrée d’historique n’est pas confirmée renvoie warnings ; ne répétez pas la mise à jour pour corriger l’historique. En cas d’erreur de modification concurrente, relisez le cas avant de réessayer. L’appartenance aux suites est distincte : utilisez l’outil groupé ci-dessous, et non suite_id dans cet outil. Aucun outil de suppression n’est exposé.
• bulk_update_test_cases — Appliquer une action à 1–500 UUID de cas ; transmettez un seul ID pour un cas unique. set_folder prend params.folder_id (UUID à déplacer, ou null explicite pour retirer le classement). add_to_suite et remove_from_suite prennent params.suite_id ; l’ajout ne supprime aucune autre appartenance et ne déplace pas le dossier. Prend également en charge set_priority, set_status, set_type, add_tags, remove_tags, pin et unpin. Les clés API nécessitent test_cases:write. Renvoie applied, skipped et errors ; les actions sur une organisation comptabilisent les lignes modifiées confirmées, dédupliquent les ID et ignorent les appartenances existantes.
• Placement à la création : create_test_case accepte folder_id et suite_id facultatifs. Découvrez les cibles avec list_test_case_folders et list_test_suites (la découverte de suites nécessite test_runs:read pour les clés API). Les dossiers constituent un emplacement unique dans le catalogue ; les suites sont des appartenances à des plans de test plusieurs-à-plusieurs. Les cibles doivent appartenir au même espace de travail autorisé et au même projet exact, y compris pour les cas anciens sans portée. Les ID de cas inaccessibles sont ignorés sans détails ; les cibles incompatibles sont rejetées. Les cibles de création non valides échouent avant la création d’un cas.
• Création partielle : la création du cas et son ajout à une suite sont deux écritures distinctes. Si l’ajout échoue, la réponse renvoie l’ID du cas créé, suite_id: null et un tableau warnings. Ne répétez pas create_test_case ; réessayez bulk_update_test_cases avec add_to_suite pour l’ID renvoyé.
• link_test_case_to_bug — Établir la traçabilité entre un cas de test et un UUID de rapport de bug (verified_by, covers ou relates). Les deux enregistrements doivent appartenir à l’espace de travail actif et à des projets auxquels l’appelant a accès.
• list_test_case_links — Répertorier tous les liens de traçabilité d’un cas de test.
• list_test_case_review_candidates — Indicateurs de tests obsolètes : never_run (90 jours ou plus depuis la création), always_passes (au moins 5 réussites consécutives en 90 jours), always_skipped (au moins 3 ignorés consécutifs).
• mark_test_case_review_flags — Enregistrer les indicateurs actuels de candidats à l’archivage dans test_cases.review_flag. S’exécute automatiquement tous les lundis à 09:00 UTC via pg_cron.

Imports

• Import Figma (Enterprise) (session de tableau de bord uniquement) : téléversez une archive zip d’export de frames Figma (jusqu’à 100 MiB) ; Claude analyse chaque écran et rédige des cas de test dans un dossier que vous choisissez ou créez. Avant le décodage, l’archive est limitée à 1 000 entrées, 20 MiB de données développées (décodées) par entrée et 100 MiB de données développées au total ; les fichiers et répertoires ignorés sont également comptabilisés. Les tampons de frames décodés doivent correspondre aux tailles déclarées. Les archives mal formées, les écarts de taille et les limites dépassées font échouer la tâche avant l’analyse par l’IA ; le téléversement d’origine est conservé en cas d’échec pour permettre une nouvelle tentative, sous réserve de la politique de nettoyage du stockage. Les archives valides passent par un pipeline en plusieurs étapes (classification → cas par écran → cas au niveau du flux couvrant les écrans partageant un préfixe → autocritique), avec mise en cache des invites, nouvelle tentative en cas de 429 et isolation des erreurs d’IA par frame. Les cas sont créés avec status=active, étiquetés ai_generated=true, tandis que source='figma' et source_frame_name conservent un lien vers la frame d’origine. Utilise la clé Anthropic de la plateforme — aucune connexion Claude par équipe n’est requise.

Suites et exécutions

• list_test_suites — Répertorier jusqu’à 50 suites de tests accessibles avec un filtre flexible project facultatif. Chaque suite inclut un case_count entier exact : les cas directement assignés, tous statuts confondus, sans descendants et à l’exclusion des cas d’autres espaces de travail ou projets (les anciens cas sans projet restent inclus). Les décomptes ne sont pas limités par les lignes d’appartenance récupérées. Pour assurer la rétrocompatibilité avec les workers d’exécution, les appelants utilisant une clé API doivent disposer de test_runs:read.
• get_test_suite — Lire directement une suite de tests avec le id requis (UUID). Renvoie uniquement l’enregistrement de la suite, sans charger implicitement les suites enfants ni les cas de test membres. Nécessite un accès à son espace de travail et à son projet ; les appelants utilisant une clé API doivent disposer de test_runs:read.
• create_test_suite — Créer une suite dans le project requis, renvoyé par list_projects. Imbrication jusqu’à 3 niveaux via parent_suite_id. Les appelants utilisant une clé API doivent disposer de test_cases:write.
• update_test_suite — Mettre à jour par UUID de suite : id, name facultatif (supprimé des espaces de début et de fin, de 1 à 120 caractères), description nullable (50000 caractères maximum) et status (actif/archivé). Les champs omis et l’appartenance aux cas sont conservés. Nécessite un accès au projet de niveau contributeur actif ou supérieur et test_cases:write. Les déplacements de parent et l’épinglage ne sont pas pris en charge ; les déplacements de parent nécessitent une mise à jour atomique de la profondeur des descendants. Renvoie id, team_id, project_id, name, description, parent_suite_id, depth, status et updated_at. Exemple : {"id":"suite-uuid","name":"Checkout regression","description":null}.
• list_test_runs — Répertorier les exécutions de tests avec le nom de la suite, la personne assignée et un récapitulatif des réussites et échecs. Les preuves d’exécution téléversées depuis le tableau de bord utilisent des liens privés qui nécessitent une session de tableau de bord et un accès à l’espace de travail et au projet de l’exécution ; une clé API MCP ne donne pas accès aux fichiers.
• create_test_run — Créer une exécution de suite gérée par le tableau de bord. L’exécution d’une suite parente inclut automatiquement chaque cas de toutes les sous-suites descendantes (un cas lié aux deux n’est ajouté qu’une seule fois). Chaque ligne test_run_results indique de quelle sous-suite d’origine provient le cas, afin que les pages de résultats puissent regrouper les cas par origine.

Exécution par un agent externe

Ces outils permettent à Hermes ou à un autre environnement d’exécution d’agent d’exécuter une suite approuvée sans devenir le système de référence de l’assurance qualité. Utilisez une clé limitée à l’espace de travail, avec uniquement test_runs:read et test_runs:write. La suite définit la limite du projet ; les appelants ne peuvent pas la remplacer.

• start_test_plan — Démarrer ou reprendre un instantané de suite immuable avec un external_run_id stable. Un ID répété renvoie l’exécution correspondante existante et sa première page au lieu d’en créer une copie.
• get_test_run_plan — Lire l’état canonique de l’exécution et une page de plan stable. Transmettez le next_cursor précédent ; les pages contiennent 100 cas par défaut et sont limitées à 200.
• report_test_results — Soumettre de 1 à 200 résultats avec le statut passed, failed, blocked ou skipped. Les nouvelles tentatives exactes sont sans risque ; toute tentative de remplacer le statut d’un cas par un autre est rejetée.
• abort_test_run — Arrêter une exécution interrompue de manière idempotente, tout en conservant les résultats partiels acceptés et le récapitulatif canonique.

Comportement des quotas : réessayez start_test_plan avec le même external_run_id pour reprendre l’exécution correspondante sans consommer une exécution supplémentaire. La suppression de données ne réinitialise pas l’utilisation mensuelle des exécutions.

Limites de l’environnement d’exécution : les instantanés de cas excluent les identifiants, le contenu des fichiers et les chemins des pièces jointes privées. Dans la version MVP, les preuves de résultat sont du texte. Les identifiants de la cible restent dans l’environnement d’exécution. Les coûts liés au navigateur, au modèle et au réseau restent à la charge du client, qui doit limiter l’accès à la cible et les sorties réseau. Un humain reste responsable des décisions concernant les défauts et les mises en production.

Le guide de l’agent Hermes présente cette boucle sous la forme d’une compétence communautaire maintenue par bugAgent. Le kit de démarrage public contient une configuration prête à copier et une compétence installable. Il ne s’agit pas d’une intégration officielle de Nous Research.

Rapports (analyses de niveau 1 et 4)

• get_test_reports_overview — Indicateurs clés pour une période (taux de réussite, exécutions terminées, cas exécutés) avec les variations par rapport à la période précédente équivalente. Il s’agit des mêmes chiffres que ceux affichés dans la bande des indicateurs clés de l’onglet Rapports. Cela ne crée pas de rapport de projet enregistré. Les rapports de projet XLSX Enterprise et leurs planifications sont gérés dans le tableau de bord ; aucun outil MCP n’est activé pour ces artefacts enregistrés dans cette version.
• Commandes des rapports du tableau de bord : l’onglet Rapports peut combiner plusieurs suites (y compris leurs descendants) dans un rapport filtré unique. Une exécution terminée propose également une action Exporter en PDF, dont le dénominateur de couverture correspond aux cas inclus dans cette exécution. Ces commandes du tableau de bord n’ajoutent aucun paramètre aux outils MCP ; le téléchargement d’un PDF pour une seule exécution nécessite une session de tableau de bord.
• Filtres de cas du tableau de bord : l’exportation CSV respecte les filtres de cas actuels sur toutes les pages correspondantes. L’état des suites et la couverture par suite regroupent les enfants sous leurs véritables suites parentes dans le périmètre de suites sélectionné. Les suites parentes présentes uniquement dans la hiérarchie affichent des tirets, et non des métriques cumulées à partir des enfants. Les suites sans lien entre elles qui partagent les mêmes cas restent exclues. Ces corrections ne modifient pas les paramètres des outils MCP.
• get_test_reports_failures — Quatre listes « que faut-il corriger ? » : failing_cases (≥50 % d’échecs, au moins 3 exécutions), flaky_cases (plus grand nombre d’alternances entre réussite et échec), failing_suites (≥30 % d’échecs, au moins 5 exécutions), regressed_cases (échec le plus récent précédé d’une réussite pendant la période).

Exemple de flux de travail

1. create_test_case_folder → créer une arborescence de dossiers (par ex. Smoke → Auth). Utilisez l’ID de dossier renvoyé lors de la création d’un cas de test dans le même projet ; le formulaire Nouveau cas de test du tableau de bord permet également de créer un dossier à la volée.
2. create_test_case → définir les cas ; modifier leur contenu avec update_test_case, organiser l’appartenance aux suites avec bulk_update_test_cases
3. Exemple d’appel d’outil : {"name":"update_test_case","arguments":{"id":"00000000-0000-4000-8000-000000000001","title":"Verify login rejection","steps":[{"action":"Submit an incorrect password","expected":"An error is shown; no session is created"}],"status":"active","folder_id":null}}. La priorité, le type et la description omis restent inchangés.
4. create_test_suite → créer un plan de test (les sous-suites sont facultatives, jusqu’à 3 niveaux de profondeur)
5. create_test_run → créer une exécution gérée par un humain ou le tableau de bord à partir d’une suite parente — les sous-suites sont incluses automatiquement
6. start_test_plan → démarrer ou reprendre une exécution par un agent externe, avec des tentatives répétées sans risque
7. get_test_run_plan → récupérer chaque page immuable du plan, puis l’exécuter dans l’environnement d’exécution sélectionné
8. report_test_results → renvoyer des lots de résultats limités ; appelez abort_test_run si l’exécution ne peut pas se poursuivre en toute sécurité
9. get_test_reports_failures → demander « que faut-il corriger cette semaine ? » une fois l’exécution terminée
10. get_test_reports_overview → suivre l’évolution du taux de réussite d’une semaine à l’autre

⚡

Team Booster

• scale_team — Augmentez instantanément la capacité de votre équipe d’assurance qualité grâce à des testeurs de renfort. Les comptes sont automatiquement créés avec un accès de testeur. Indiquez team_size (1–10), location, duration, budget et, facultativement, product_url, product_types et tech_levels. Disponible avec le forfait Enterprise. Aucun frais ne vous sera facturé avant l’approbation.

Exemple de flux de travail

1. scale_team → recruter 5 testeurs seniors aux États-Unis pour 1 mois
2. list_team_members → vérifier que les nouveaux testeurs apparaissent dans votre équipe
3. list_bug_reports → examiner les rapports déposés par les testeurs de renfort

📱

Tests mobiles (Enterprise)

Les ressources mobiles sont limitées au projet. Transmettez project_id ou un sélecteur flexible project lors des créations, des importations et des listes filtrées. Les automatisations héritent du projet de l’application associée ; sinon, le serveur utilise le projet par défaut de l’espace de travail. Les listes sans filtre peuvent encore inclure des enregistrements hérités au niveau de l’espace de travail jusqu’à leur migration.

• list_mobile_apps — Répertorier les applications téléversées, avec les filtres facultatifs project_id / project, platform et limit. Renvoie le project_id de chaque application afin que les agents puissent conserver les opérations suivantes dans le même projet.
• upload_mobile_app — Enregistrer une application APK (Android) ou IPA (iOS) pour les tests sur des appareils réels. Nécessite name, platform (android / ios) et file_url ; transmettez project_id pour l’affecter au projet actif. Pour iOS, téléversez l’IPA pour les exécutions sur appareil réel, puis utilisez le tableau de bord pour téléverser une version de simulateur .app à des fins d’enregistrement.
• update_mobile_app — Remplacer le binaire d’une application par une nouvelle version. Efface les URL mises en cache et les versions de simulateur afin que toutes les automatisations utilisent la nouvelle version lors de leur prochaine exécution. Nécessite app_id et file_url. Facultatif : version. Les profils de connexion privés associés nécessitent leur créateur actif ; les profils partagés nécessitent un accès actif au même projet. Les planifications héritent du paramètre par défaut de l’automatisation protégée.
• list_mobile_automations — Répertorier les automatisations mobiles, avec les filtres facultatifs project_id / project, app_id, status et limit. Les résultats incluent project_id et l’ID de l’application associée.
• create_mobile_automation — Créer un script de test. Nécessite name, app_id, script_type (maestro pour YAML, appium pour Appium Python, appium_js pour Appium JavaScript) et script ; transmettez project_id si l’application n’est pas déjà associée à un projet. Pour un flux Maestro YAML autonome et validé de l’extérieur, définissez execution_mode sur browserstack_maestro ; sinon, la valeur par défaut est appium_actions. Le appId YAML doit correspondre à l’ID de package ou d’ensemble enregistré pour l’application associée ; si aucun n’est enregistré, le premier flux natif validé le définit. Les ID d’application fictifs et les ID de ressources Android obfusqués sont rejetés. Le runFlow intégré est pris en charge, mais les références à des fichiers de flux/script externes sont rejetées dans la v1. Maestro natif conserve les commandes telles que inputRandomText et copyTextFrom, ainsi que les expressions d’exécution telles que ${maestro.copiedText} et ${output.value}. Un credential_id du même projet peut fournir des valeurs inputText complètes de ${USERNAME} / ${PASSWORD}. Un variable_profile_id du même projet peut enregistrer la valeur par défaut des valeurs ${DATA_*} référencées ; chaque clé référencée doit exister. Les profils de données ne contiennent que des données synthétiques non secrètes.
• import_mobile_script — Importer un script de test mobile existant et le convertir en automatisation exécutable, en conservant les sélecteurs propres au développeur afin que les exécutions résolvent précisément les éléments. Dialectes pris en charge : Appium‑Python, WebdriverIO, Maestro (flux YAML) et Playwright (mobile‑web). Les espaces réservés d’ID de ressources Android obfusqués sont ignorés et signalés dans le warnings de mappage des sélecteurs. Applications Android uniquement. Nécessite name, app_id et script ; target_devices et project_id sont facultatifs. Renvoie l’automatisation, ainsi que action_count, les dialect détectés et le warnings de mappage des sélecteurs.
• run_mobile_automation — Lancer une automatisation mobile sur un appareil réel. Nécessite automation_id ; device, os_version, credential_id et le variable_profile_id natif de Maestro sont facultatifs. Pour les données, omettez variable_profile_id pour hériter de la valeur par défaut de l’automatisation, transmettez null pour n’utiliser aucun profil, ou transmettez un UUID du même projet pour remplacer la valeur. Chaque clé ${DATA_*} référencée doit exister. Un profil de connexion privé nécessite son créateur actif ; un profil de connexion partagé nécessite un accès actif au même projet. Les valeurs d’identifiants connues exactes sont filtrées et les valeurs exactes des profils de données font l’objet d’un filtrage au mieux à partir des éléments textuels persistés ; les valeurs transformées, partielles, encodées ou dérivées de l’application peuvent subsister. Les vidéos et captures d’écran privées autorisées restent accessibles et peuvent afficher des valeurs rendues par l’application testée ; les profils de données doivent donc contenir uniquement des valeurs synthétiques non secrètes. Si le contexte de masquage des identifiants n’est pas disponible ou si l’innocuité de l’assainissement ne peut être démontrée, les textes détaillés contenant des identifiants sont masqués, tandis que l’état et les éléments visuels disponibles restent accessibles. Les diagnostics nécessitent une autorisation sur l’espace de travail et le projet ; les liens vers les médias expirent au bout de cinq minutes.
• list_mobile_runs — Obtenir les résultats d’exécution mobile autorisés (état, appareil, résumé des résultats, liens privés vers les vidéos et captures d’écran, session BrowserStack, journaux et échecs filtrés de Maestro natif avec identifiants lorsqu’ils sont disponibles en toute sécurité, ainsi que tout bug créé automatiquement). L’appartenance à l’espace de travail et l’accès au projet sont vérifiés pour les diagnostics d’exécution. Filtres facultatifs : project_id, automation_id, status (queued, running, passed, failed, error, archived) et limit. Les exécutions archivées sont exclues par défaut.
• create_login_profile — Créer un profil chiffré en écriture seule contenant un nom d’utilisateur et un mot de passe, réutilisable par Mobile, Web Automation et Exploratory AI. Nécessite project_id, name, username et password ; visibility est facultatif et vaut private (par défaut) ou shared. Les profils privés sont réservés à leur créateur. Les profils partagés sont utilisables par les membres actifs ayant accès au même projet.
• create_mobile_credential — Nom de compatibilité pour create_login_profile ; utilise les mêmes entrées et le même périmètre de sécurité.
• list_login_profiles — Répertorier uniquement les profils visibles par l’appelant, éventuellement pour un seul project_id. Renvoie des métadonnées non secrètes, notamment visibility ; les profils privés appartenant à d’autres utilisateurs et les projets inaccessibles sont omis.
• list_mobile_credentials — Nom de compatibilité pour list_login_profiles ; ne renvoie jamais les secrets d’identification.
• update_login_profile — Renommer, renouveler ou modifier visibility. Le créateur actif peut modifier n’importe quel champ. Un propriétaire ou administrateur actif de l’espace de travail peut renommer ou renouveler un profil partagé, mais ne peut pas en modifier la visibilité ; les profils privés restent réservés à leur créateur.
• update_mobile_credential — Nom de compatibilité pour update_login_profile ; applique les mêmes vérifications de propriété et de projet.
• delete_login_profile — Suppression réversible par le créateur, avec récupération du cycle de vie par le propriétaire/l’administrateur uniquement pour les profils partagés. Les valeurs par défaut pour les utilisations futures sont effacées, mais l’historique d’audit est conservé.
• delete_mobile_credential — Nom de compatibilité pour delete_login_profile ; les références historiques sont conservées à des fins d’audit.
• create_mobile_variable_profile — Créer des données de test synthétiques réutilisables et limitées à un projet avec project_id, name et un objet variables tel que {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Les clés doivent être des identifiants DATA_* en majuscules. Les profils acceptent de 1 à 100 chaînes, 4096 octets UTF-8 par valeur et 65536 octets au total. Les noms réservés aux identifiants et à l’exécution sont rejetés. Ne stockez jamais d’identifiants, de jetons, de données personnelles de production ni d’autres secrets.
• list_mobile_variable_profiles — Répertorier les profils Mobile/Both et leurs valeurs non secrètes lisibles pour un seul project_id autorisé. Les règles d’affectation des projets s’appliquent. Les profils existants et la création mobile utilisent par défaut both ; la création et la mise à jour acceptent platform (mobile ou both). Les profils Web uniquement sont exclus de l’accès au catalogue mobile et de l’exécution.
• update_mobile_variable_profile — Renommer un profil ou remplacer son objet variables complet par id. Seul le créateur actif ou un propriétaire/administrateur actif de l’espace de travail peut le modifier.
• delete_mobile_variable_profile — Supprimer un profil de manière réversible par id. Seul le créateur actif ou un propriétaire/administrateur actif de l’espace de travail peut le supprimer ; les valeurs par défaut des automatisations sont effacées, mais les références des exécutions historiques sont conservées.
• list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Répertorier, créer et supprimer des planifications sur appareil réel. Les planifications héritent du contexte du projet, du profil de connexion et du profil de variables non secrètes de l’automatisation sélectionnée. Les profils de connexion privés nécessitent leur créateur actif ; les profils de connexion partagés nécessitent un accès actif au même projet. Les profils de variables non secrètes conservent leur politique créateur ou propriétaire/administrateur. Les modifications et la suppression des planifications sont réservées au créateur actif de la planification ou à un propriétaire/administrateur actif de l’espace de travail.

Catalogue de données de test Web

Le même catalogue de projet non secret est disponible dans Automate Web. Ces outils nécessitent le droit automation de l’espace de travail et la portée de clé API automations:write, y compris pour les lectures. Ils ne nécessitent pas d’accès Mobile. Les valeurs ne partagent jamais d’enregistrements avec les profils de connexion chiffrés. Le catalogue ne permet pas encore d’associer des valeurs de profil aux exécutions Web ni de les y injecter.

• create_web_variable_profile : project_id, name et variables sont obligatoires ; platform est facultatif (web ou both), valeur par défaut web. Utilise les mêmes limites DATA_* que Mobile. Renvoie le profil, y compris son platform.
• list_web_variable_profiles : project_id est obligatoire ; renvoie { profiles: [...] } contenant uniquement les enregistrements Web/Both.
• get_web_variable_profile : id est obligatoire ; renvoie un profil Web/Both accessible et ses valeurs synthétiques.
• update_web_variable_profile : id est obligatoire ; name, le remplacement complet variables ou platform (web ou both) sont facultatifs. Nécessite le créateur actif ou un propriétaire/administrateur actif de l’espace de travail. Pour restreindre Both à Mobile, utilisez le catalogue Mobile avec un accès Mobile.
• delete_web_variable_profile : id est obligatoire ; mêmes autorisations de gestion. Effectue une suppression réversible et renvoie { deleted: true }, tout en conservant l’historique d’audit.

Exemple : résolvez un projet à l’aide de list_projects, appelez create_web_variable_profile avec {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}}, puis vérifiez-le avec list_web_variable_profiles. Les projets/profils inaccessibles échouent sans exposer leurs valeurs ; les données non valides ou les noms en double à l’échelle du projet sont rejetés.

Exemple de flux de travail — Android

1. list_projects → résoudre le project_id cible
2. upload_mobile_app → enregistrer l’APK dans ce projet
3. Enregistrer de manière sécurisée dans le tableau de bord, ou utiliser import_mobile_script / create_mobile_automation
4. list_mobile_automations → résoudre l’automatisation dans le même projet
5. run_mobile_automation → la lancer sur un appareil réel, éventuellement avec un profil de connexion
6. list_mobile_runs → vérifier l’état, le résumé des résultats, les liens visuels privés et les métadonnées de session BrowserStack
7. Les échecs créent automatiquement des rapports de bug avec une capture de l’échec et le détail des étapes

Exemple de flux de travail — iOS

1. upload_mobile_app → enregistrer votre IPA avec project_id pour les exécutions sur appareil réel
2. Téléverser la version de simulateur .app sur la page de détails de l’application (pour l’enregistrement)
3. Enregistrer le test dans le navigateur → les actions sont capturées depuis le simulateur
4. run_mobile_automation → lancer l’automatisation enregistrée sur un iPhone (utilise l’IPA)
5. update_mobile_app → remplacer l’IPA par une nouvelle version lorsqu’elle est prête

Exemple de flux de travail — Maestro natif

1. upload_mobile_app → enregistrer l’APK ou l’IPA dans le projet cible
2. create_mobile_credential → créer éventuellement un profil du même projet pour un flux authentifié
3. create_mobile_variable_profile → créer éventuellement des valeurs synthétiques DATA_* du même projet utilisées par le flux
4. create_mobile_automation → transmettre un flux YAML fonctionnel connu avec le package/bundle exact appId de l’application associée, script_type: maestro et execution_mode: browserstack_maestro. Utilisez ${USERNAME} / ${PASSWORD} pour la connexion et des espaces réservés de type ${DATA_EMAIL} pour les données synthétiques ; transmettez les ID de profil pour enregistrer les valeurs par défaut.
5. run_mobile_automation → sélectionner un appareil compatible et éventuellement remplacer le profil de connexion ou de variables. Omettez le profil de variables pour en hériter, ou transmettez null pour le désactiver lors d’une exécution.
6. list_mobile_runs → examiner les résumés autorisés de réussite/échec, les vidéos et captures d’écran privées, les journaux filtrés, les noms réels des étapes, les échecs détaillés et les métadonnées de session. Si l’assainissement sûr d’une exécution avec identifiants ne peut être établi, les textes détaillés sont masqués, tandis que l’état et les éléments visuels disponibles restent accessibles.

Améliorer avec l’IA : la version bêta sur liste d’autorisation est disponible via le tableau de bord et les points de terminaison REST d’amélioration. Aucun outil MCP d’amélioration ne fait encore partie du catalogue public.

✅

Conformité et preuves (Enterprise)

• collect_compliance_evidence — Déclenche la collecte automatisée de preuves à partir des services connectés (Cloudflare, GitHub, Sentry, Supabase, Railway). Renvoie un ID d’exécution. Collecte les paramètres SSL/TLS, l’état du WAF, les alertes Dependabot, les tendances des erreurs, l’historique des déploiements et bien plus.
• check_config_drift — Vérifie la dérive de configuration de sécurité par rapport aux références dans tous les services connectés (mode SSL, version TLS, HSTS, règles WAF, en-têtes de sécurité).
• generate_access_review — Crée un rapport trimestriel de revue des accès. Audite les membres de l’équipe, les rôles, l’état de la MFA et l’utilisation des clés API, puis génère des recommandations (par exemple, révoquer les clés inactives).
• get_security_events — Interroge la chronologie des événements de sécurité interservices. Filtre par source (cloudflare, sentry, github) et par gravité (critical, high, medium, low, info). Les événements sont automatiquement corrélés entre les services.

Couverture de conformité

Ces outils contribuent au respect des exigences de conformité SOC2 (CC4.1, CC6.1, CC7.2, CC8.1), ISO 27001 (A.5.18, A.8.8, A.8.9, A.8.15-16, A.8.29) et GDPR (Art. 5, 25, 32, 33).

Clients compatibles

bug Agent fonctionne avec tout client prenant en charge le Model Context Protocol. Voici des guides de configuration pour les clients populaires :

Ouvrez Settings → Developer → Edit Config, puis ajoutez :

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Redémarrez Claude Desktop après l’enregistrement.

✳️

Cursor

Ouvrez Settings → MCP Servers → Add Server, ou modifiez .cursor/mcp.json à la racine de votre projet :

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

🌊

Windsurf

Ouvrez Settings → MCP → Add Server, ou modifiez votre fichier de configuration MCP :

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Ajoutez bug Agent directement depuis le terminal :

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

Cette méthode se connecte directement au serveur HTTP Streamable hébergé.

Pour les clients qui nécessitent stdio, utilisez le pont bugagent-mcp publié :

• Commande : npx
• Ligne de commande : npx -y bugagent-mcp
• Arguments : ["-y", "bugagent-mcp"]
• Variables d’environnement : BUGAGENT_API_KEY

Obtenir de l’aide

Besoin d’aide ? Nous sommes là pour vous aider.

Communauté Discord

Rejoignez notre Discord pour obtenir de l’aide en temps réel et participer aux discussions de la communauté.

Assistance par e-mail

support@bugagent.com — Nous répondons généralement sous 24 heures.