bugAgent

officiel

Connectez bugAgent à tout client IA compatible MCP. Signalez, classez et gérez des bugs, demandes de fonctionnalités et plus encore directement depuis votre assistant de codage IA. Pas de changement de contexte, pas de copier-coller — décrivez simplement le problème et bugAgent s'occupe du reste.

Voir sur bugagent.comEssayer ce MCPSponsorisé

Que pouvez-vous faire avec bugAgent MCP ?

Signaler des bugs — Demandez à votre assistant de créer un rapport de bug avec une classification automatique sur 19 types, incluant les paramètres de sévérité et de priorité.
Lister et filtrer les rapports — Utilisez list_bug_reports pour interroger les bugs par projet, sévérité, statut, type ou texte de recherche, avec une pagination allant jusqu’à 100 résultats.
Choisir le prochain bug à traiter — Laissez votre assistant appeler pick_next_bug pour obtenir le bug non assigné de plus haute priorité (S1→S3, le plus ancien d’abord) pour votre équipe.
Réclamer les bugs de manière atomique — Utilisez claim_bug pour faire passer un bug à l’état « en cours » sans risque de concurrence et l’assigner à vous-même, évitant ainsi le travail en double.
Gérer les suites et cas de test — Créez des suites de test, exécutez des suites de régression et listez les cas de test échoués des 7 derniers jours.

Documentation

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

Signalez, classez et gérez les bugs, demandes de fonctionnalités et plus encore directement depuis votre assistant de codage IA. Aucun changement de contexte, aucun copier-coller — décrivez simplement le problème et bug Agent s’occupe du reste.

Les clients MCP externes sont distincts de l’assistant IA du tableau de bord de bug Agent. L’assistant du tableau de bord est désactivé par défaut sur tous les plans et nécessite une activation explicite de l’espace de travail ; sa passerelle ai_assistant ne désactive pas MCP ni les intégrations. L’authentification MCP, les portées, les autorisations d’espace de travail/projet et les droits spécifiques aux outils s’appliquent toujours.

Pour commencer

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

Obtenez 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 Paramètres → Développeurs → Clés API.

Configurez votre client IA

Ajoutez bug Agent comme serveur MCP dans la configuration de votre client (voir la configuration ci-dessous).

Commencez à signaler des bugs

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

# 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

Recommandé : HTTP Streamable hébergé

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

{
  "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 clé API réelle depuis Paramètres → Développeurs.

Pont stdio optionnel

Utilisez le pont publié uniquement lorsqu’un client exige stdio et ne peut pas se connecter à un serveur HTTP distant. Exécutez-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"
      }
    }
  }
}

Connexion au serveur

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

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

🔑

Obtenez d’abord votre clé API. Connectez-vous à Paramètres → Développeurs, cliquez sur Créer une clé API, sélectionnez les portées dont votre client a besoin, puis copiez la valeur (commence par ba_live_). Vous ne la verrez qu’une seule fois, alors collez-la dans un endroit sûr. Les clients MCP ne listent que les outils accordé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 de plan payant sont identifiées séparément.

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

L’outil officiel d’Anthropic. Lance une interface Web locale où vous pouvez parcourir chaque outil, remplir les paramètres et voir les réponses. Zéro configuration, aucun IDE requis.

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell ou CMD)

npx @modelcontextprotocol/inspector

Dans l’interface du navigateur qui s’ouvre :

Type de transport : sélectionnez Streamable HTTP
URL : https://mcp.bugagent.com/mcp
Type de connexion : sélectionnez Proxy (par défaut — l’Inspector passe par un processus Node local pour contourner le CORS du navigateur)
Ouvrez Paramètres du serveur → En-têtes personnalisés et ajoutez :
- Nom de l’en-tête : X-Api-Key
  - Valeur : ba_live_YOUR_KEY_HERE (sans préfixe Bearer)
Cliquez sur Connecter. Le panneau de gauche liste les outils de bug Agent autorisés par les portées de la clé API que vous avez sélectionnées.
Cliquez sur un outil (par ex. list_bug_reports), remplissez les paramètres, cliquez sur Exécuter l’outil. La réponse s’affiche à droite.

Prérequis : MCP Inspector v2 nécessite Node.js 22.19 ou ultérieur. Installez une version actuelle de Node.js depuis nodejs.org si vous ne l’avez pas.

Si l’Inspector renvoie invalid_client, il tente 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 + Windows)

Si vous utilisez l’application Claude Desktop, vous pouvez ajouter bug Agent 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é. L’OAuth délégué expose le catalogue interactif complet.

macOS

Ouvrez Claude Desktop → barre de menu Claude → Paramètres → Développeur → Modifier la configuration. Cela ouvre ~/Library/Application Support/Claude/claude_desktop_config.json.

Ajoutez l’entrée bug Agent sous mcpServers :

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

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

Windows

Ouvrez Claude Desktop → Fichier → Paramètres → Développeur → Modifier la configuration. Cela ouvre %APPDATA%\Claude\claude_desktop_config.json (généralement C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
Ajoutez le même bloc JSON que celui de la section macOS.
Enregistrez le fichier et quittez complètement Claude Desktop depuis la barre système (clic droit sur l’icône Claude → Quitter), puis relancez.
L’icône marteau des outils affichera les outils de bug Agent.

Option 3 — Claude Code (CLI)

Si vous utilisez Claude Code depuis votre terminal (la version CLI de Claude), enregistrez le serveur bug Agent avec une seule commande. Fonctionne de manière 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 qu’il est connecté :

claude mcp list

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

Connecté, mais certains outils manquent ?

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

Le catalogue est filtré par les portées de la clé API. Les lectures de cas de test nécessitent test_cases:read ; les lectures de suite/exécution nécessitent 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 ; la découverte anonyme ou une clé différente n’est pas une comparaison valide. Vérifiez une configuration au niveau du projet qui remplace votre connexion au niveau utilisateur, puis reconnectez-vous ou redémarrez après des changements d’informations d’identification.

Si le catalogue du serveur authentifié inclut un outil mais que le client ne peut toujours pas le découvrir, enregistrez la version du client, la version du serveur, les noms/nombres d’outils et toute erreur de schéma, avec les informations d’identification et les données client supprimées. Une session démarrée avec ENABLE_TOOL_SEARCH=false claude peut distinguer la découverte différée des problèmes de chargement, mais charge toutes les définitions d’outils et utilise plus de contexte ; utilisez-la uniquement comme diagnostic temporaire. N’élargissez pas les autorisations ni ne divisez les points de terminaison uniquement pour augmenter un nombre d’outils.

Pour le supprimer plus tard :

claude mcp remove bugagent

Option 4 — OpenAI Codex CLI

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

Enregistrement permanent (ajout à 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 : « Listez mes bugs ouverts triés par gravité. »

Option 5 — Cursor (Mac + Windows)

Cursor a un support MCP intégré. Avec une clé API d’espace de travail à portée appropriée, l’assistant IA dans 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 performance et exploratoires nécessitent un OAuth délégué et un accès au plan applicable.

Ouvrez Cursor → Paramètres (Cmd+, sur Mac / Ctrl+, sur Windows) → MCP dans la barre latérale gauche.
Cliquez sur + Ajouter un nouveau serveur MCP.
Sélectionnez le type de transport HTTP.
Remplissez :
- Nom : bugagent
  - URL : https://mcp.bugagent.com/mcp
  - Nom de l’en-tête : Authorization
  - Valeur de l’en-tête : Bearer ba_live_YOUR_KEY_HERE
Cliquez sur Enregistrer. Cursor affiche un indicateur vert lorsqu’il est connecté.
Ouvrez le chat de Cursor (Cmd+L / Ctrl+L) et tapez « Créez un rapport de bugs intitulé « Connexion cassée » avec une gravité élevée. » Cursor invoquera create_bug_report.

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

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

Si vous préférez VS Code, l’extension Continue prend en charge les serveurs MCP nativement.

Installez l’extension Continue depuis le marketplace VS Code.
Ouvrez la configuration de Continue : Palette de commandes (Cmd+Shift+P / Ctrl+Shift+P) → Continue : Ouvrir config.json. Le fichier se trouve à :
- macOS : ~/.continue/config.json
  - Windows : %USERPROFILE%\.continue\config.json

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"
        }
      }
    }
  ]
}

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

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

Option 7 — Hôtes compatibles OAuth (Claude.ai web montré comme exemple)

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

OAuth lié aux ressources. L’identifiant de ressource protégée est https://mcp.bugagent.com/mcp. Les hôtes conformes aux normes le découvrent depuis /.well-known/oauth-protected-resource/mcp et l’envoient comme paramètre RFC 8707 resource. bug Agent é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 rejoué contre un autre service ni échangé par un autre client.

Dans bug Agent : ouvrez Paramètres → Développeurs → Connecteurs MCP. Cliquez sur Générer un connecteur, donnez-lui un nom décrivant l’hôte (par ex. « Claude.ai (travail) »), collez l’URI de redirection requis par votre hôte MCP (pour l’application web Claude.ai, c’est https://claude.ai/api/mcp/auth_callback — consultez la documentation des connecteurs de votre hôte pour d’autres), et choisissez Confidentiel pour la méthode d’authentification. Copiez le client_id et le client_secret affichés une seule fois sur l’écran de succès.
Dans les paramètres de connecteur / OAuth de votre hôte MCP, collez :
- URL du serveur : https://mcp.bugagent.com/mcp
  - ID client + Secret client : depuis l’étape 1
  - URL d’autorisation : https://mcp.bugagent.com/authorize
  - URL de jeton : https://mcp.bugagent.com/token
  - Ressource protégée / audience, si demandée : https://mcp.bugagent.com/mcp Pour Claude.ai spécifiquement : allez sur claude.ai/customize/connectors et cliquez sur Ajouter un connecteur MCP.
Enregistrez. L’hôte vous redirige vers bug Agent pour vous connecter (Google ou e-mail/mot de passe — selon la méthode que vous utilisez pour le tableau de bord) et approuver le consentement, puis termine la poignée de main OAuth.
Gérez et révoquez les connecteurs générés depuis la même page Paramètres. La révocation est immédiate — la prochaine requête de ce connecteur renvoie invalid_client.

Remarque : Claude Code, Cursor, VS Code et MCP Inspector n’ont pas besoin de ce flux — ils gèrent l’enregistrement dynamique du client (RFC 7591) automatiquement et s’authentifient via clé API comme indiqué ci-dessus. Le formulaire Connecteurs MCP est uniquement pour les hôtes qui exigent des informations d’identification OAuth statiques.

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

Option 8 — HTTP direct avec curl (Terminal)

Si vous souhaitez tester le serveur directement sans client, ou l'intégrer dans un script, vous pouvez appeler le point de terminaison HTTP avec curl. Le protocole MCP est 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 en JSON ou en Server-Sent Events. Chaque bloc 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 des raisons de compatibilité.

ℹ️

Dépannage 401 Non autorisé : Vérifiez que votre clé API n'a pas été révoquée dans Paramètres → Développeurs. Les clés commencent par ba_live_. Si vous êtes toujours bloqué, régénérez la 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 mappés à l'une de ses portées sélectionnées. La découverte non authentifiée peut afficher les métadonnées des outils, mais tools/call exige toujours une clé API ou un jeton OAuth.

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

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

Moniteur d'utilisation usage:read

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

Synchroniser ou fusionner les 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 actifs et exécutions mobiles mobile:read

Gérer les actifs 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 où elles sont créées. Les entrées d'outils peuvent restreindre un appel à un projet autorisé, mais ne peuvent pas changer 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 inclut un titre lisible par l'humain et des indications de lecture/écriture. Les indications de lecture manquantes proviennent d'une liste explicitement examinée, et non de préfixes de noms d'outils ou de portées de clés API. Les annotations explicites, y compris false, sont préservé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 destructives. Les outils non classifiés utilisent ces valeurs par défaut conservatrices. L'indication de destructivité 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 destructives car elles remplacent les résultats d'analyse persistés ou les références de configuration.

Les annotations n'accordent pas d'accès et ne remplacent pas l'authentification, l'autorisation d'espace de travail/projet, les portées de clés API ou les contrôles de droits. Les invites de confirmation dépendent de la politique d'autorisation du client et des paramètres utilisateur ; les indications ne garantissent pas si un appel déclenchera une invite.

Pour la découverte et l'audit programmatiques, téléchargez le mcp-tool-index.json généré. Il enregistre les 141 outils d'exécution, l'accès par portée de clé API ou OAuth uniquement, la famille de droits, les noms d'entrées, le mode de 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 site d'appel ; utilisez la réponse tools/list du serveur connecté pour les annotations effectives après application des valeurs par défaut.

Outils OAuth uniquement : la gestion des comptes, des clés API et des équipes, la gestion des connexions Jira, d'autres intégrations, les contrôles de test premium, les notes, le suivi du temps et d'autres opérations interactives ne sont pas déverrouillés en ajoutant des portées de clés API. Les outils de vérification, synchronisation et fusion des rapports Jira sont l'exception étroite via jira:read et jira:write.

Essayez — Invites en langage naturel

Une fois connecté, vous n'avez pas besoin de connaître les noms d'outils ou les paramètres. Décrivez ce que vous voulez en langage naturel et votre assistant IA appelle automatiquement le bon outil bug Agent.

Les invites de rapports de bugs, de gestion de tests limitée, d'automatisation Playwright, d'automatisation mobile et d'utilisation sont disponibles pour les clés API avec les portées correspondantes. Les entrées de sécurité, performance, exploration, compte, équipe, notes, suivi du temps et autres sans portée de clé API nommée nécessitent un OAuth délégué et tout droit de plan applicable.

Rapports de bugs

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 performance

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 avec 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 Paramètres → Interface MCP, 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 Paramètres → Développeurs → Connecteurs MCP — 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 Paramètres → Développeurs — les clés commencent par ba_live_. Régénérez si nécessaire.

Les outils n'apparaissent pas dans le client Les clients avec clé API ne listent que les outils autorisés par les portées sélectionnées de la clé. Vérifiez la clé dans Paramètres → Développeurs, puis quittez complètement et relancez le client après avoir modifié sa configuration. Dans Claude Desktop, Cmd+Q (pas seulement fermer la fenêtre). Dans Cursor, vérifiez Paramètres → MCP pour un point vert.

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

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

Données du mauvais espace de travail Chaque clé API est limitée à un espace de travail. Générez une nouvelle clé depuis l'espace de travail que vous souhaitez interroger dans Paramètres → Développeurs.

Les outils apparaissent mais les appels échouent silencieusement Inspectez la réponse pour isError: true et le contenu renvoyé. Un outil visible peut toujours être refusé par le plan, le rôle, le droit de fonctionnalité, l'appartenance au projet, la propriété ou une entrée invalide. Vérifiez l'état du serveur uniquement après avoir lu l'erreur de l'outil.

Erreur CORS de MCP Inspector Sélectionnez Proxy (pas Direct) pour le type de connexion dans l'interface de l'Inspector. L'Inspector passe par un processus Node local pour contourner les restrictions CORS du navigateur.

MCP Inspector v2 se termine avec le code 5 L'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 une erreur de plan, d'autorisation, d'entrée ou d'exécution ; l'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 pilote limité à l'espace de travail. L'enregistrement d'un script généré en session nécessite l'approbation explicite du Workbench de son propriétaire via le point de terminaison d'enregistrement de script en session uniquement. Il n'existe aucun outil d'approbation MCP : demander à un agent de rédiger un script ne crée ni ne planifie une automatisation.

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 de clés API, d'administration d'équipe, de test premium, de notes et de suivi du temps sont réservés aux sessions interactives, sauf si une entrée nomme explicitement une portée de clé API.

🐛

Gestion des rapports de bugs

Les importations de captures d'écran Google Sheets reprenables utilisent le point de terminaison REST séparé POST /api/reports/import-attachment avec reports:write, et le statut GET avec reports:read. Aucun outil MCP d'importation de captures d'écran n'est ajouté. Cette API JPEG/PNG uniquement vérifie le stockage privé et le problème Jira mappé exact avant de signaler l'achèvement ; le téléchargement de rapport hérité reste réservé aux sessions.

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 (titre : 3 à 500 caractères). Le tableau optionnel attachments accepte des fichiers encodés en base64 jusqu'à 400 Mo chacun : toute image, vidéo, audio, PDF, ou texte/JSON. Définissez format_description: true pour reformater automatiquement la description dans un modèle structuré via l'IA. Passez time_spent_seconds pour suivre l'effort QA. Passez priority (urgent / high / normal / low) pour définir l'urgence de correction indépendamment de la gravité. Passez is_epic: true pour créer un 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 (max 100 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 d'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 du rapport ; une saisie composée uniquement de chiffres comme 366 est une recherche exacte sur les numéros de ticket hérités et de projet, donc tout texte non lié contenant ces chiffres est exclu. Chaque résultat inclut les identifiants de personnes/projets limités au locataire ainsi que is_epic, parent_epic_id, parent_epic et epic_progress borné. Les outils de lecture de rapports n'exposent pas les adresses e-mail des membres.
pick_next_bug — Renvoie le(s) prochain(s) bug(s) sur lesquels la boucle d'agent doit travailler, par ordre de priorité (S1 → S2 → S3, les plus anciens d'abord dans chaque groupe). Automatiquement limité à 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 optionnel (niveau unique), limit (1-50, défaut 1). Renvoie un objet avec count et bugs ; chaque bug est une ligne de file réduite plutôt que la forme complète list_bug_reports. Associez avec claim_bug pour le modèle lecture-puis-réclamation.
claim_bug — Transition atomique d'un bug de status new, awaiting-triage ou confirmed vers status='in-progress', définit assigned_to sur l'utilisateur appelant et horodate claimed_at=NOW(). Sans course entre appelants concurrents via le modèle UPDATE-WHERE-RETURNING de Postgres — si deux agents appellent claim_bug sur le même identifiant en succession rapprochée, exactement un obtient claimed:true avec le corps du bug et l'autre obtient claimed:false avec une chaîne de 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éclamations obsolètes (statut= in-progress + claimed_at > 30 minutes) vers new, donc les tickets d'un agent 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 personnes/projet/qualité ainsi que is_epic, l'identité parente, la progression agrégée et une première page d'enfants bornée pour les Epics.
Étiquettes natives de rapport : create_bug_report et update_bug_report acceptent tags comme tableau de chaînes, par exemple {"tags":["login","regression"]}. Au plus 20 éléments bruts sont acceptés avant déduplication. Les chaînes sont tronquées, doivent être non vides et d'au plus 50 points de code Unicode, et ne peuvent pas contenir de contrôles ASCII (U+0000 à U+001F ou U+007F). Les doublons exacts sont supprimés après troncature ; la casse est préservée et Login diffère de login. Lors d'une mise à jour, le tableau remplace toutes les étiquettes, [] les efface et l'omission les préserve. À la création, l'omission signifie aucune étiquette. null et les éléments invalides sont rejetés. Les résultats de création, lecture, liste et mise à jour exposent tags natif.
Filtrage par étiquettes : appelez list_bug_reports avec {"project":"bugagent","tags":["login","regression"]} pour correspondre à TOUTES les étiquettes demandées, en respectant la casse, avant la pagination. Les mêmes limites d'étiquettes s'appliquent ; l'omission ou [] n'applique aucun filtre d'étiquettes. Les portées existantes reports:read / reports:write et l'autorisation d'espace de travail/projet sont inchangées. Cela n'ajoute aucune interface visuelle d'étiquettes ni import, synchronisation ou rétro-remplissage automatique des étiquettes Jira.
get_epic — Lire un Epic directement avec id requis (UUID ou ID court d'espace de travail/projet). Renvoie uniquement l'enregistrement Epic, sans charger implicitement les rapports enfants. Nécessite l'accès à son espace de travail et projet ; les appelants par clé API nécessitent reports:read. Utilisez list_epic_children séparément pour lire les enfants.
list_epic_children — Paginer les rapports enfants d'un Epic avec id, limit (1–100) et offset. Renvoie children, total, has_more et epic_progress agrégé par SQL sans charger chaque rapport enfant.
update_bug_report — Mettre à jour les champs standard du rapport ainsi que is_epic et parent_epic_id. Passez parent_epic_id: null pour détacher ; le re-parentage/détachement est atomique et nécessite une autorisation de même espace de travail, même projet. La promotion en Epic détache un parent existant, tandis qu'un Epic avec enfants ne peut pas être rétrogradé. Les règles existantes de statut/résolution/cause racine et de notification d'affectation s'appliquent toujours. Un changement de status sur un rapport lié à Jira est reflété sur le ticket Jira via ses transitions de workflow lorsqu'exactement une transition légale correspond au statut mappé ; sinon, le ticket est laissé intact.
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 poussé vers le ticket Jira lié. Le markdown d'attachement privé tel que ![proof](/api/attachments/ATTACHMENT_UUID) devient un lien intelligent bugAgent absolu et authentifié dans Jira. Les lecteurs doivent se connecter à bugAgent avec accès à l'espace de travail et au projet du rapport ; les aperçus natifs intégrés Jira ne sont pas garantis.
list_comments — Lister le fil de commentaires stocké 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 lisez la discussion d'un ticket. Accepte UUID ou ID court. Cette lecture ne rafraîchit pas Jira. Les intégrations planifiées nécessitant des commentaires Jira frais peuvent d'abord appeler POST /api/jira/comments-refresh avec une clé API appartenant à un gestionnaire autorisé. Utilisez les ID de commentaires et les révisions de contenu pour distinguer les nouveaux commentaires des modifications, et ne prétendez pas à un rapport d'activité complet si le rafraîchissement échoue.
link_bug_reports — Créer un lien sémantique directionnel entre deux rapports dans le même projet autorisé. Pour parent-of, le rapport source doit être un Epic et le rapport cible un enfant standard. Préférez parent_epic_id lors de la création/mise à jour pour l'affectation Epic.
unlink_bug_reports — Supprimer un lien de rapport de bug précédemment créé par son UUID (link_id, renvoyé par link_bug_reports ou list_bug_report_links).
list_bug_report_links — Lister chaque lien organisé par l'utilisateur touchant un rapport de bug. Renvoie chaque lien tel qu'il se lit depuis la perspective du rapport fourni — par exemple, une ligne stockée duplicate-of où ce rapport est la cible s'affiche comme duplicated-by ; parent-of où ce rapport est la cible s'affiche comme subtask-of ; depends-on où ce rapport est la cible s'affiche comme blocks ; testing-blocked-by où ce rapport est la cible s'affiche comme blocks-testing. related-to est symétrique. Complète le champ auto-détecté similar_reports renvoyé par get_bug_report.
classify_bug — Classifier une description dans l'un des 19 types de rapports (bugs, fonctionnalités, améliorations, etc.) avec un score de confiance
flush_reports — Suppression groupée des anciens rapports (admin uniquement)

📊

Utilisation et Analytique

get_usage — Vérifier l'utilisation par rapport aux limites du plan. Les appelants par clé API nécessitent usage:read.
get_stats — Comptes quotidiens, répartitions par type/gravité/statut

📁

Gestion de Projet

list_projects — Lister les projets accessibles avec id, name, slug, ticket_prefix, description et statut par défaut. Utilisez ces valeurs avec les outils de rapports de bug et de catalogue de tests pour cibler le projet correct.
create_project — Créer un nouveau projet (devient automatiquement le défaut s'il est le premier)
delete_project — Supprimer définitivement un projet et toutes les données associées (rapports de bug, automatisations, cas de test, applications mobiles, planifications, captures géo, notes, entrées de temps). Propriétaire/gestionnaire uniquement. Impossible de supprimer le dernier projet. Le stockage est libéré automatiquement
export_okf_bundle — Exporter les connaissances QA d'un projet — rapports de bug, cas de test, automatisations et tests de performance, sécurité et exploratoires — sous forme de bundle markdown OKF/OQA (le format Open Query Agent utilisé par oqa.ai). Par défaut sur le projet actif ; passez le project optionnel (slug ou nom) pour en exporter un autre. Renvoie la liste des fichiers du bundle ainsi que le bundle lui-même sous forme de zip encodé en base64

🔐

Authentification et Compte

register_account — Créer un nouveau compte (mot de passe : 8-128 caractères, limité en débit : 5/15 min)
login — Se connecter et recevoir des jetons d'accès (limité en débit : 5/15 min)
update_profile — Mettre à jour le nom d'affichage
change_password — Changer 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. Mutation 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 d'Équipe

list_workspaces — Lister les espaces de travail auxquels vous appartenez, votre rôle dans chacun et celui que la session utilise par défaut. 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 rôles, statut et indicateurs de boost
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 d'expiration de 5 jours

🎯

Intégrations

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

sync_to_jira — Envoyer un rapport à Jira en utilisant la connexion partagée de l'équipe. Achemine vers le projet Jira mappé au projet bugAgent du rapport (le projet par défaut de l'espace de travail en secours), en utilisant sa cartographie de champs : la v2 sépare la priorité et la sévérité personnalisée, tandis que les cartographies non versionnées conservent la traduction héritée sévérité-vers-priorité. L'option projectKey peut sélectionner uniquement cette cartographie configurée ou le projet par défaut de l'espace de travail ; les projets Jira arbitraires sont rejetés. Vous n'en avez généralement pas besoin : lorsque le mode de synchronisation du projet est auto_new ou auto_all, les rapports que vous créez sont poussés automatiquement — appelez cette fonction 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é mappés pour un rapport lié autorisé. Utilise le projet enregistré du rapport et la connexion Jira. La version 2 mappe la priorité Jira séparément d'un champ de sévérité personnalisé pris en charge ; les cartographies non versionnées conservent le comportement hérité priorité-vers-sévérité. Cet outil ne compare pas les commentaires, les pièces jointes, le type ou chaque champ Jira.
merge_jira_sync — Fusionner ces champs mappés en utilisant prefer: jira pour récupérer les valeurs Jira ou prefer: bugagent pour pousser les valeurs locales. Les envois de statut utilisent les transitions de workflow Jira légales. Les conflits sortants non mappés, les écritures distantes échouées et les modifications locales simultanées renvoient des erreurs plutôt que 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 inter-systèmes ne sont pas atomiques.
push_to_claude — Générer (ou régénérer) les Notes du développeur pour un rapport de bug — cause racine, correction suggérée, é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 requise. Exécute une chaîne adaptative : trois étapes sur les bugs s3 / medium ou s4 / low (brouillon Sonnet → critique OpenAI gpt-5 → synthèse Sonnet), cinq étapes sur 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 avec un jugement indépendant). La réponse expose chaque tour : analysis, draft, critique, rebuttal, challenger_model, adjudicator_model et un indicateur debated. Toute étape échouée retombe sur la meilleure réponse suivante. Se déclenche automatiquement à la création du bug ; 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 « Zone de correction probable » des Notes du développeur — une sortie Sonnet étroite qui indique où dans le codebase la correction appartient le plus probablement. Accepte un UUID ou un identifiant court. Utilise la clé Anthropic de la plateforme. Lorsque l'équipe a une ligne github_connections et que le projet a un github_repo mappé, la sortie est ancrée dans de véritables extraits de fichiers du dépôt connecté ; sinon, elle retombe sur des conseils généraux avec une incitation à connecter un dépôt. Renvoie le texte likely_fix_area, generated_at, repo_used et un indicateur grounded. Se déclenche automatiquement à la création du bug — les agents n'ont généralement besoin d'appeler cette fonction que pour une régénération manuelle.
upgrade_plan — Obtenir le lien d'inscription Enterprise assistée par les ventes

⚡

Tests de performance

create_performance_test — Créer une configuration de test de performance avec URL, appareil, utilisateurs virtuels, durée, seuil de score et bascule de création automatique de bug. Enterprise uniquement
run_performance_test — Déclencher un audit de page et un test de charge pour un test de performance web. Renvoie un identifiant d'exécution à interroger pour les résultats. Les exécutions de profilage d'applications mobiles sont déclenchées depuis le tableau de bord
get_performance_results — Obtenir les résultats complets, y compris les scores Lighthouse (Performance, Accessibilité, Bonnes pratiques, SEO), les Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) et les métriques de test de charge (VU, requêtes, RPS, latences p50/p90/p95/p99)
list_performance_tests — Lister toutes les configurations de test de performance pour l'équipe actuelle
get_performance_usage — Vérifier l'utilisation mensuelle des tests de performance. Les tests de performance sont réservés à Enterprise. Gratuit = 0, Enterprise = illimité

Workflow d'exemple

get_performance_usage → vérifier le quota restant
create_performance_test → configurer un test pour votre URL
run_performance_test → déclencher l'audit + le test de charge
get_performance_results → examiner les scores et les indicateurs de santé

🛡

Analyse de sécurité

create_security_scan — Créer une configuration d'analyse de sécurité. Les analyses web utilisent Quick Scanner + 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 binaire APK/IPA. Création automatique de bug configurable avec seuils de sévérité. Enterprise uniquement
run_security_scan — Déclencher une analyse de vulnérabilité. Les analyses web nécessitent une vérification de domaine DNS. Les analyses mobiles nécessitent une application téléchargée. Renvoie un identifiant d'exécution à interroger pour les résultats
get_security_results — Obtenir les résultats complets, y compris le score de sécurité (0-100), les constatations classées par sévérité (Critique, Élevée, Moyenne, Faible, Info) avec références CWE, mappages OWASP, preuves et conseils de remédiation
list_security_scans — Lister toutes les configurations d'analyse de sécurité pour l'équipe actuelle avec le dernier score et les badges d'authentification/profondeur
get_security_usage — Vérifier l'utilisation mensuelle des analyses de sécurité. L'analyse de sécurité est réservée à Enterprise. Enterprise = illimité
list_security_schedules — Lister toutes les analyses de sécurité planifiées pour l'équipe avec cron, fuseau horaire, état activé, prochaine exécution et paramètres de notification. Rejoint la configuration d'analyse parente (nom, scan_type, target_url)
create_security_schedule — Créer un calendrier récurrent pour une analyse de sécurité. Nécessite scan_id et cron_expression. Un calendrier par configuration d'analyse. timezone, notify_on_fail (aucun/e-mail/slack/les deux), notify_email, slack_channel_id facultatifs. Chaque exécution compte dans votre plafond mensuel ; les utilisateurs administrateurs contournent le plafond. La profondeur d'analyse est toujours lue depuis la configuration d'analyse au moment de l'exécution
delete_security_schedule — Supprimer une analyse de sécurité planifiée. N'affecte pas la configuration d'analyse parente ni les exécutions terminées

Workflow d'exemple

get_security_usage → vérifier le quota restant
create_security_scan → configurer une analyse pour votre URL ou dépôt
run_security_scan → déclencher une analyse de vulnérabilité ponctuelle
create_security_schedule → automatiser les exécutions récurrentes (par ex. SAST hebdomadaire sur la branche principale)
get_security_results → examiner les constatations et la remédiation

📖

Revue de code

list_code_reviews — Lister les revues de code IA récentes pour l'équipe. Renvoie les scores de qualité, les comptes de sévérité, les informations PR et les horodatages. Enterprise uniquement
get_code_review — Obtenir une revue de code avec toutes les constatations. Chaque constatation inclut la sévérité, la catégorie (bug/sécurité/performance/style/logique/maintenabilité), le titre, la description, la suggestion de code, le chemin du fichier et les numéros de ligne
get_code_review_usage — Vérifier l'utilisation de la revue de code. La revue de code IA est réservée à Enterprise ; illimitée sur Enterprise
get_code_review_analytics — Obtenir les analyses de revue : tendances, catégories/sources de constatations, répartition par sévérité, métriques de vélocité, principaux dépôts/auteurs. Prend en charge les périodes de 7/30/90 jours

Workflow d'exemple

get_code_review_usage → vérifier les revues restantes
Examiner un PR dans le tableau de bord à /dashboard/code-review
list_code_reviews → voir les revues récentes
get_code_review → obtenir les constatations et suggestions

🔍

IA exploratoire

Outil autonome multi-agents de recherche de bugs sur site web avec jusqu'à 10 agents parallèles, chacun utilisant une stratégie de test différente.

list_explorations — Lister les configurations d'IA exploratoire pour l'équipe
create_exploration — Créer une nouvelle exploration. Accepte agent_count (1–10, max 10) pour exécuter plusieurs agents parallèles avec des stratégies uniques : happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Cet outil ne peut pas configurer les identifiants ou le mode d'authentification. Configurez et lancez Test du flux de connexion uniquement explicitement via le tableau de bord ou REST, puis utilisez get_exploration et get_exploration_run pour inspecter la configuration et les résultats. Ne déduisez jamais le mode des instructions et ne placez jamais d'identifiants dans les arguments MCP. L'exploration par défaut basée sur les 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 le texte chiffré ne sont jamais renvoyés.
get_exploration_run — Obtenir les résultats d'exécution avec la progression par agent, les données de phase, les constatations avec attribution d'agent (agent_index, agent_strategy) et les bugs liés
get_exploration_usage — Vérifier l'utilisation mensuelle. L'IA exploratoire est réservée à Enterprise ; Enterprise : illimitée (10 agents)

Workflow d'exemple

create_exploration avec agent_count: 5 → configurer 5 agents parallèles
Déclencher une exécution depuis le tableau de bord ou via POST /api/explorations/run
get_exploration_run → interroger la progression par agent et les constatations
Afficher les constatations dédupliquées avec attribution d'agent dans le tableau de bord

📝

Notes

list_notes — Lister les notes avec filtres facultatifs par mot-clé, projet, visibilité, dossier, étiquette, archive, wiki, plage de dates et tri. Renvoie les notes que l'utilisateur possède ou qui sont partagées avec lui.
create_note — Créer une note dans l'un des 5 formats : markdown, plain, bugtemplate, checklist, outline. Définir visibility sur private ou shared. Titre automatique à partir des 30 premiers caractères si aucun titre n'est fourni. Tableau attachments facultatif acceptant des fichiers encodés en base64 jusqu'à 400 Mo chacun : toute image, vidéo, audio, PDF ou texte/JSON. Passer time_spent_seconds pour suivre l'effort d'assurance qualité.
get_note — Obtenir les détails complets de la note, y compris le contenu et les pièces jointes. Nécessite id.
update_note — Mettre à jour le titre, le contenu, le format, la visibilité, le projet ou time_spent_seconds. Passer un tableau attachments pour ajouter de nouveaux fichiers (max 400 Mo chacun) aux pièces jointes existantes de la note sans les remplacer. Seul l'auteur peut mettre à jour. Nécessite id.
delete_note — Supprimer définitivement une note et ses pièces jointes. Seul l'auteur peut supprimer. Nécessite id.
list_note_folders — Lister les dossiers de notes/wiki, éventuellement limités à un projet.
create_note_folder — Créer un dossier de notes/wiki limité à un projet avec paramètres facultatifs de parent, visibilité, favori et accès aux coéquipiers.

Workflow d'exemple

create_note → démarrer une note de session de test
update_note → ajouter des observations pendant vos tests
list_notes → rechercher des notes passées par mot-clé ou projet
get_note → récupérer la note complète avec pièces jointes

🤖

Automatisation

create_automation — Créez une nouvelle automatisation avec un script Playwright personnalisé (aucun enregistrement FAB requis). Nécessite name. Optionnel : target_url (dérivé 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 ; par défaut, un espace réservé), status (draft ou active, défaut : draft), project_id. Renvoie l'automatisation id. Astuce — 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 le script, target_url et project_id d'origine. La copie démarre avec le statut draft et sans historique de versions.
list_automations — Liste les scripts d'automatisation Playwright. Filtrez par project_id ou status (draft, active, paused). Renvoie un tableau d'automatisations avec le nom, target_url, last_run_status et run_count.
get_automation — Obtenez les détails complets d'une automatisation, y compris le script Playwright et les exécutions récentes. Nécessite id. Renvoie l'automatisation avec le script en direct, 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 porte le script_version_label / script_version_source qui a été exécuté. Appelez ceci avant run_automation si vous devez choisir une version historique spécifique.
run_automation — Déclenchez une exécution immédiate d'un test Playwright. Nécessite automation_id. Localisateurs auto-réparateurs (automatiques) : lorsqu'une action de localisateur 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, donc les vraies régressions échouent toujours — et chaque réparation est consignée dans la sortie standard de l'exécution. Mode émulation (par défaut) : device optionnel pour un profil d'appareil émulé (par 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 sur 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, pas une session interactive visible. Les scripts Node.js passent par browserstack-node-sdk (couvre bureau + Android + iPhone). Les scripts Python passent par browserstack-sdk (pytest-playwright) et couvrent uniquement le bureau — le mobile réel via Python n'est pas pris en charge car le browser_type.connect() de pytest-playwright ne peut pas piloter les points de terminaison mobiles réels de BrowserStack. La vidéo et les journaux réseau sont capturés automatiquement ; les journaux de console sont limités au bureau. Relecture de version : inspectez script_versions avec get_automation, puis transmettez le version_label durable préféré (par exemple "v103"). Le version_index hérité reste pris en charge mais ne doit pas être combiné avec version_label. Défaut : lorsque les deux sélecteurs sont omis, le script enregistré actuel s'exécute. Les étiquettes élaguées et les indices invalides sont rejetés au lieu d'exécuter silencieusement le script actuel. L'enregistrement d'exécution stocke l'instantané exact qui a été exécuté, et tout rapport de bug créé automatiquement à partir d'une exécution échouée renvoie en lien profond vers cette version dans l'éditeur.
list_automation_runs — Liste les exécutions récentes d'une automatisation. Nécessite automation_id. Renvoie les exécutions avec le statut, duration_ms et error_message.
list_schedules — Liste toutes les exécutions d'automatisation web planifiées avec cron_expression nullable, run_at nullable, once_status, fuseau horaire, appareil et paramètres de notification. Les lignes récurrentes conservent run_at et once_status nuls ; les lignes ponctuelles ont un cron nul. États ponctuels : pending, claimed, missed, dispatched, failed, uncertain. Ce sont des états de répartition, pas des résultats de test ; inspectez list_automation_runs pour les résultats.
Planifications web récurrentes : create_schedule valide cinq champs cron numériques et le fuseau horaire, et 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 à 12h30 chaque année, pas une exécution ponctuelle. Un timing invalide ou impossible est rejeté 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 liées à l'heure d'été sont ignorées ; les heures répétées sur le mur peuvent se produire deux fois. La répartition se produit au prochain sondage du planificateur, pas nécessairement à la minute exacte. Le comportement récurrent existant est 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 timing. run_at nécessite un horodatage ISO 8601 futur avec décalage qualifié (décalage explicite ou Z) ; le fuseau horaire IANA est pour l'affichage. Une planification en attente activée s'exécute au premier sondage cron après l'échéance ; plus d'une heure de retard est marquée missed. Elle est réclamée et désactivée atomiquement avant la répartition, et ne peut pas être réactivée une fois consommée. Les échecs de répartition définitifs sont failed ; la répartition ambiguë est uncertain et n'est jamais automatiquement réessayée. Vérifiez les exécutions avant de planifier une autre tentative. dispatched ne signifie pas terminé ou réussi. La création est uniquement via API/MCP, pas 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 par défaut MCP reste UTC.
create_schedule — Créez une exécution d'automatisation web planifiée. Nécessite automation_id et exactement un de cron_expression ou run_at. Prend en charge les paramètres optionnels d'appareil, de fuseau horaire, de notification d'échec, d'e-mail et de canal Slack. Connectez Slack via le tableau de bord d'abord et choisissez un canal auquel le bot appartient ; l'installation de webhook seule est insuffisante. Voir Configuration Slack et découverte de canaux.
Déploiement et récupération ponctuels : appliquez la migration de base de données 374_one_time_web_schedules.sql avant de déployer le code API/MCP et planificateur correspondant. claimed peut persister après un crash de worker : inspectez l'historique des exécutions avant de créer un remplacement pour une répartition réclamée ou incertaine. Un horodatage de 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 sautent des cycles pendant que l'automatisation est en Brouillon ; la mise en pause, la suppression, l'épinglage et les modifications de notification uniquement restent disponibles. Il n'y a pas d'outil MCP web update_schedule ; utilisez le tableau de bord pour ces mises à jour.
delete_schedule — Supprimez une exécution d'automatisation web planifiée
list_mobile_schedules — Liste toutes les exécutions d'automatisation mobile planifiées avec appareils, cron, fuseau horaire et notifications
create_mobile_schedule — Créez une exécution d'automatisation mobile planifiée sur des appareils réels. Nécessite automation_id et cron_expression ; devices est optionnel.
delete_mobile_schedule — Supprimez une exécution d'automatisation mobile planifiée
optimize_automation_script — Envoyez un script Playwright à Sonnet 4 pour une optimisation assistée par IA. Applique une liste de contrôle en 12 points qui corrige 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 — Revenez à 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

create_automation → créez un test avec un script personnalisé
list_automations → parcourez les tests disponibles
get_automation → inspectez le script Playwright
run_automation → déclenchez le test
list_automation_runs → vérifiez les résultats et la durée

⏱️

Suivi du temps

list_time_entries — Liste les entrées de temps de l'équipe. Filtrez par period (today, week, month, all), project_id, category et sort (newest, oldest, most_time, least_time). Plan Enterprise uniquement.
create_time_entry — Consignez le temps passé sur les tâches d'assurance qualité. Nécessite description, category et duration_minutes. Définissez éventuellement project_id et entry_date (par défaut aujourd'hui). Plan Enterprise uniquement.
update_time_entry — Mettez à jour une entrée de temps existante. Nécessite id. Peut mettre à jour description, category, duration_minutes, project_id ou entry_date. Plan Enterprise uniquement.
delete_time_entry — Supprimez définitivement une entrée de temps. Nécessite id. Plan Enterprise uniquement.

Exemple de flux de travail

create_time_entry → consignez 45 minutes de tests de régression
list_time_entries → consultez les entrées de temps de cette semaine
update_time_entry → ajustez la durée ou la catégorie
delete_time_entry → supprimez une entrée incorrecte

☑️

Cas de test

Gestion des tests avec dossiers hiérarchiques, suites imbriquées (jusqu'à 3 niveaux de profondeur avec expansion automatique des sous-suites lors des exécutions), réorganisation par glisser-déposer et un onglet Rapports d'analyse avec tendances KPI, analyse des échecs, santé des suites, couverture et productivité des testeurs. Tous les outils appellent Supabase directement — aucun aller-retour HTTP, même latence que le tableau de bord.

Limites gratuites : 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 calendaire UTC. Jusqu'à 3 de ces exécutions peuvent utiliser Hermes ou un autre agent externe, avec 1 exécution externe active et au plus 10 cas dans chaque plan externe. Le trafic MCP gratuit avec clé API est limité à 30 requêtes par clé et 60 par espace de travail par minute. Le stockage et les exécutions de cas de test Enterprise sont illimités, 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'import Figma et les pièces jointes de fichiers de cas de test nécessitent Enterprise. La limite gratuite de 128 Ko de contenu structuré est distincte des pièces jointes de fichiers Enterprise. Le plan gratuit peut stocker des références URL. Les outils MCP de base pour les cas de test restent disponibles sur le plan gratuit dans les limites ci-dessus.

Exécution mains libres : la page de revue d'exécution est un carrousel avec un cas visible à la fois, des raccourcis clavier (P Réussite · F Échec · B Bloqué · S Ignorer) et contrôle vocal. Cliquez sur le micro, puis dites « Réussite », « Échec », « Bloqué », « Ignorer », « Suivant », « Précédent », « Ajouter des notes » (transcrit dans le champ de notes), « Enregistrer les notes » ou « Voix désactivée ». Avance automatiquement au prochain cas non testé en cas de résultat réussi ; reste en place en cas d'échec pour que les testeurs puissent dicter les détails et créer un bug. Fonctionne dans Chrome, Edge et Safari.

Cas et dossiers

list_test_cases — Liste les cas de test accessibles avec un sélecteur project optionnel, ainsi que les filtres search, priority, type, status et sort. Ajoutez folder_id (null pour non classé) ou suite_id pour une appartenance directe, sans descendants. Les appelants avec clé API nécessitent test_cases:read. limit est par défaut 50 (1-200) ; offset est par défaut 0 (0-1000000). Le tableau inchangé cases est accompagné de total / total_count pour toutes les correspondances autorisées, limit, offset, has_more et next_offset nullable. Précédemment, total signifiait incorrectement la longueur de page. Suivez next_offset jusqu'à null ; ne déduisez pas la fin de la longueur de page. Une continuation au-delà du décalage 1000000 échoue explicitement ; affinez les filtres au lieu de recevoir un curseur inutilisable ou une fin fausse. Les pages dépassant 1 Mio de données de cas échouent explicitement : réessayez avec une limite plus petite, plutôt que d'accepter des enregistrements omis. Le départage par ID stable est utilisé, mais les modifications concurrentes peuvent décaler les pages de décalage.
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ée un cas de test dans le sélecteur project requis (UUID, slug, nom exact ou préfixe de ticket ; appelez list_projects d'abord). Deux variantes de modèle : steps (par défaut) — grille { action, expected } par étape via le tableau steps ; text — description unique en texte libre via text_content. Les deux champs peuvent être envoyés dans le même appel. Le tableau optionnel urls (max 10 URL http/https) attache des liens de référence et est disponible sur Free. Les pièces jointes nécessitent Enterprise et une session de tableau de bord. Les appelants avec clé API nécessitent test_cases:write.
Récupération de pagination : demander un décalage de cas au-delà des résultats disponibles renvoie une erreur explicite ; redémarrez au décalage 0. Cela peut aussi se produire lorsque des cas sont supprimés entre les requêtes. Suivez la continuation renvoyée plutôt que de deviner le prochain décalage.
Identifiants de 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 les réponses compactes de mise à jour/sans opération. Les cas hérités sans projet utilisent TEST-CASE-123. Les identifiants manquants sont renvoyés comme null ; utilisez l'UUID comme solution de repli. La base de données attribue les identifiants ; les appelants ne peuvent pas les modifier ni les choisir lors de la création. Un renommage de préfixe ne réécrit pas les ID existants.
Recherche de 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 utilise l'espace de travail et le projet stockés, pas le préfixe de l'ID. Les nombres nus, les ID partiels et les recherches par caractère générique ne sont pas acceptés. Les tableaux de cas en masse, le case_id de résultat d'exécution, les ID de bug, les ID de dossier et les ID de suite restent uniquement en UUID. Les enregistrements de lien conservent l'UUID case_id.
Lacunes de numérotation : les numéros de cas ne doivent pas être contigus. Modifier une URL ou incrémenter un numéro peut conduire à un cas manquant ou inaccessible ; ce n'est pas une action garantie de cas suivant. Découvrez les cas avec l'outil de liste et suivez sa pagination.
Portée de l'espace de travail : le même ID court peut exister dans différents espaces de travail. MCP le résout uniquement dans l'espace de travail actif ; changez le contexte d'espace de travail avant d'utiliser l'ID court d'un autre espace de travail. Lors du partage d'une URL d'ID court de tableau de bord, préservez ?team=<case.team_id>, par exemple /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. Les permaliens UUID conservent le comportement autorisé inter-espaces de travail existant. MCP ne construit pas de permalien.
get_test_case — Obtient l'enregistrement de 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. Un 0 stocké reste 0 ; une estimation inconnue ou manquante est null. Le champ canonique gagne lorsque les deux noms sont présents, y compris un null explicite ; les valeurs estimated_time héritées uniquement sont traité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 — Liste les dossiers accessibles. Plafonné à 500 ; accepte un sélecteur flexible project et un filtre parent_folder_id (utilisez "root" pour le niveau supérieur uniquement). Les appelants avec clé API nécessitent test_cases:read.
get_test_case_folder — Lit un dossier de cas de test directement avec id requis (UUID). Renvoie uniquement l'enregistrement du dossier, sans charger implicitement les dossiers descendants ou les cas de test. Nécessite l'accès à son espace de travail et à son projet ; les appelants avec clé API nécessitent test_cases:read.
Valeurs type de cas de test pour list_test_cases, create_test_case et bulk_update_test_cases : functional (défaut de création), regression, smoke, integration, performance, security, usability, exploratory. Les types invalides sont rejetés avant l'écriture. Utilisez integration pour les flux de bout en bout ; e2e, accessibility et other ne sont pas des types de cas de test acceptés. Les types de scripts d'automatisation sont un contrat séparé.
create_test_case_folder — Crée un dossier dans le project requis renvoyé par list_projects (imbrication jusqu'à 3 niveaux via parent_folder_id). Nécessite un accès contributeur ou supérieur à l'espace de travail et un accès au projet. Les appelants avec clé API nécessitent également test_cases:write.
update_test_case_folder — Met à jour par UUID de dossier : id, name optionnel (tronqué, 1-120 caractères), description nullable (max 50000 caractères), parent_folder_id nullable et card_color nullable. Un UUID parent déplace le dossier et son sous-arbre dans le même espace de travail et 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 préservés. Au moins un champ de mise à jour est requis. Les champs inconnus, mal orthographiés ou invalides rejettent toute la requête sans enregistrer aucune modification. Les cycles auto/descendant, les noms correspondant à un frère, un parent direct ou un enfant direct (en ignorant la casse et les espaces environnants), et les profondeurs de sous-arbre supérieures à 3 (profondeur racine 0) sont rejetés. Les profondeurs des descendants se mettent à jour atomiquement ; les ID de cas et l'appartenance sont inchangés. Les modifications concurrentes conflictuelles peuvent échouer ; relisez le dossier avant de réessayer. Nécessite un accès contributeur ou supérieur actif au projet et test_cases:write pour les clés API. Exemple : {"id":"folder-uuid","card_color":"#93c5fd"}. Renvoie l'id, team_id, project_id, name, description, card_color, parent_folder_id, depth et updated_at mis à jour. Les lectures get/list de dossiers incluent également card_color.
update_test_case — Corrige un cas existant par UUID ou ID court complet dans id, avec au moins un champ : name (ou alias title), description, preconditions, steps, template_type, text_content, priority, type, status ou folder_id. Les champs omis sont préservés ; steps remplace le tableau complet ([] efface). null explicite efface la description, les préconditions, text_content ou le placement du dossier ; text_content vide efface également. Si name et title sont tous deux envoyés, ils doivent correspondre. Priority et type utilisent les énumérations de création ; status est active, draft ou deprecated. Un changement de type aligne type_tags avec le nouveau type, correspondant à l'API PATCH. Aucun déplacement d'espace de travail/projet ni écriture de métadonnées de fichier. Les dossiers doivent partager exactement le même espace de travail et 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 avec une entrée d'historique non confirmée renvoie warnings ; ne répétez pas la mise à jour pour réparer l'historique. En cas d'erreur de modification concurrente, relisez le cas avant de réessayer. L'appartenance à une suite est séparée : utilisez l'outil en masse ci-dessous, pas suite_id sur cet outil. Aucun outil de suppression n'est exposé.
bulk_update_test_cases — Applique une action à 1-500 UUID de cas ; passez un ID pour un cas unique. set_folder prend params.folder_id (UUID à déplacer, null explicite pour déclasser). add_to_suite et remove_from_suite prennent params.suite_id ; l'ajout ne supprime jamais d'autres appartenances ni ne déplace 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 d'organisation comptent 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 optionnels. Découvrez les cibles avec list_test_case_folders et list_test_suites (la découverte de suite nécessite test_runs:read pour les clés API). Les dossiers sont un emplacement de catalogue unique ; les suites sont des appartenances de plan de test plusieurs-à-plusieurs. Les cibles doivent appartenir au même espace de travail autorisé et au projet exact, y compris les cas hérités sans portée. Les ID de cas inaccessibles sont ignorés sans détails ; les cibles non correspondantes sont rejetées. Les cibles de création invalides échouent avant la création d'un cas.
Création partielle : la création de cas et l'attachement de suite sont des écritures séparées. Si l'attachement échoue, la réponse renvoie l'ID de 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 cet ID renvoyé.
link_test_case_to_bug — Établit une 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 aux projets accessibles à l'appelant.
list_test_case_links — Liste tous les liens de traçabilité pour un cas de test.
list_test_case_review_candidates — Indicateurs de test mort : never_run (90+ jours depuis la création), always_passes (5+ réussites consécutives en 90j), always_skipped (3+ sauts consécutifs).
mark_test_case_review_flags — Persiste les indicateurs actuels de candidat à l'archivage sur test_cases.review_flag. S'exécute automatiquement chaque lundi à 09:00 UTC via pg_cron.

Imports

Import Figma (Enterprise) (session de tableau de bord uniquement) : téléversez une exportation zip de cadres Figma (jusqu'à 100 Mio), 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 Mio développés (décodés) par entrée, et 100 Mio de données développées agrégées, y compris les fichiers et répertoires ignorés dans les budgets. Les tampons de cadre décodés doivent correspondre à leurs tailles déclarées. Les archives malformées, les écarts de taille et les limites dépassées font échouer le travail avant l'analyse IA ; le téléversement original est conservé en cas d'échec pour réessayer, sous réserve de la politique de nettoyage du stockage. Les archives valides entrent dans un pipeline multi-passes (classifier → cas par écran → cas au niveau du flux sur les écrans à préfixe partagé → auto-critique) avec mise en cache des invites, nouvelle tentative 429 et isolation des erreurs IA par cadre. Les cas arrivent comme status=active, étiquetés ai_generated=true, avec source='figma' et source_frame_name préservant un lien vers le cadre original. Utilise la clé Anthropic de la plateforme — aucune connexion Claude par équipe requise.

Suites & Exécutions

list_test_suites — Liste jusqu'à 50 suites de tests accessibles avec un filtre flexible optionnel project. Chaque suite inclut un entier exact case_count : cas assignés directs de tous les statuts, sans descendants, excluant les cas d'autres espaces de travail ou d'autres projets (les cas hérités sans projet restent inclus). Les compteurs ne sont pas limités par les lignes d'appartenance récupérées. Les appelants avec clé API nécessitent test_runs:read pour la rétrocompatibilité avec les workers d'exécution.
get_test_suite — Lit une suite de tests directement avec id requis (UUID). Renvoie uniquement l'enregistrement de la suite, sans charger implicitement les suites enfants ou les cas de test membres. Nécessite l'accès à son espace de travail et à son projet ; les appelants avec clé API nécessitent test_runs:read.
create_test_suite — Crée une suite dans le project requis renvoyé par list_projects. Imbrique jusqu'à 3 niveaux via parent_suite_id. Les appelants avec clé API nécessitent test_cases:write.
update_test_suite — Met à jour par UUID de suite : id, name optionnel (tronqué, 1-120 caractères), description nullable (max 50000 caractères), et status (actif/archivé). Les champs omis et l'appartenance aux cas sont préservés. Nécessite un accès actif au projet en tant que contributeur 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 maintenance 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 — Liste les exécutions de tests avec le nom de la suite, la personne assignée et le résumé réussite/échec.
create_test_run — Crée 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 chaque sous-suite descendante (un cas lié aux deux est ajouté exactement une fois). Chaque ligne test_run_results enregistre la sous-suite d'origine d'où provient le cas, afin que les pages de résultats puissent regrouper par origine.

Exécution par agent externe

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

start_test_plan — Démarre ou reprend un instantané de suite immuable avec un external_run_id stable. Un ID répété renvoie l'exécution correspondante existante et la première page au lieu de créer un doublon.
get_test_run_plan — Lit l'état canonique de l'exécution et une page de plan stable. Passez le next_cursor précédent ; les pages contiennent par défaut 100 cas et sont plafonnées à 200.
report_test_results — Soumet 1 à 200 résultats avec le statut passed, failed, blocked ou skipped. Les nouvelles tentatives exactes sont sûres ; tenter d'écraser un cas avec un autre statut est rejeté.
abort_test_run — Arrête de manière idempotente une exécution interrompue tout en préservant les résultats partiels acceptés et le résumé canonique.

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

Limite d'exécution : les instantanés de cas excluent les identifiants, les corps de fichiers et les chemins de pièces jointes privés. Les preuves de résultats sont du texte dans le MVP. Les identifiants cibles restent dans le runtime d'exécution. Les coûts de navigateur, de modèle et de réseau restent à la charge du client, et les clients doivent restreindre l'accès cible et la sortie réseau. Un humain reste responsable des décisions de défauts et de versions.

Le guide de l'agent Hermes regroupe cette boucle en 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 (analytique Tier 1 + Tier 4)

get_test_reports_overview — KPI principaux pour une fenêtre (taux de réussite, exécutions terminées, cas exécutés) avec écarts par rapport à la fenêtre équivalente précédente. Mêmes chiffres que la bande KPI 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.
get_test_reports_failures — Quatre listes « quoi corriger ? » : failing_cases (≥50 % d'échec, min 3 exécutions), flaky_cases (plus grand nombre de bascules réussite/échec), failing_suites (≥30 % d'échec, min 5 exécutions), regressed_cases (échec le plus récent avec une réussite antérieure dans la fenêtre).

Exemple de flux de travail

create_test_case_folder → créez 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 propose également la création de dossier en ligne.
create_test_case → définissez les cas ; modifiez le contenu avec update_test_case, organisez l'appartenance à la suite avec bulk_update_test_cases
Exemple d'outils/appel : {"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.
create_test_suite → créez un plan de test (sous-suites optionnelles, jusqu'à 3 niveaux de profondeur)
create_test_run → créez une exécution gérée par un humain/tableau de bord à partir d'une suite parente — les sous-suites sont automatiquement incluses
start_test_plan → démarrez ou reprenez une exécution d'agent externe sûre contre les nouvelles tentatives
get_test_run_plan → récupérez chaque page de plan immuable, puis exécutez-la dans le runtime sélectionné
report_test_results → renvoyez des lots de résultats limités ; appelez abort_test_run si l'exécution ne peut pas continuer en toute sécurité
get_test_reports_failures → demandez « quoi corriger cette semaine ? » une fois l'exécution terminée
get_test_reports_overview → suivez la tendance du taux de réussite semaine après semaine

⚡

Team Booster

scale_team — Faites évoluer instantanément votre équipe QA avec des testeurs booster. Les comptes sont provisionnés automatiquement avec un accès testeur. Spécifiez team_size (1-10), location, duration, budget, et éventuellement product_url, product_types et tech_levels. Disponible sur le plan Enterprise. Vous ne serez pas facturé tant que l'approbation n'a pas été donnée.

Exemple de flux de travail

scale_team → provisionnez 5 testeurs seniors aux États-Unis pour 1 mois
list_team_members → vérifiez que les nouveaux testeurs apparaissent dans votre équipe
list_bug_reports → examinez les rapports déposés par les testeurs booster

📱

Tests mobiles (Enterprise)

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

list_mobile_apps — Liste les applications téléchargées avec des 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 — Enregistre une application APK (Android) ou IPA (iOS) pour des tests sur des appareils réels. Nécessite name, platform (android / ios) et file_url ; transmettez project_id pour l’assigner au projet actif. Pour iOS, téléversez l’IPA pour les exécutions sur appareils réels, puis utilisez le tableau de bord pour téléverser une version simulateur .app pour l’enregistrement.
update_mobile_app — Remplace un binaire d’application par une nouvelle version. Efface les URL en cache et les versions simulateur afin que toutes les automatisations utilisent la nouvelle version lors de la prochaine exécution. Nécessite app_id et file_url. Facultatif : version. Les profils de connexion liés privé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 de la valeur par défaut d’automatisation protégée.
list_mobile_automations — Liste les automatisations mobiles avec des filtres facultatifs project_id / project, app_id, status et limit. Les résultats incluent project_id et l’ID d’application lié.
create_mobile_automation — Crée 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 lorsque l’application n’est pas déjà limitée au projet. Pour un flux Maestro YAML autonome et validé en externe, définissez execution_mode sur browserstack_maestro ; sinon, la valeur par défaut est appium_actions. Le appId YAML doit correspondre au package ou à l’identifiant de bundle stocké de l’application liée ; si aucun n’est stocké, le premier flux natif validé l’établit. Les ID d’application de remplacement et les ID de ressources Android obscurcis sont rejetés. Le runFlow en ligne est pris en charge, mais les références externes aux fichiers de flux/scripts sont rejetées dans v1. Maestro natif préserve des commandes telles que inputRandomText et copyTextFrom ainsi que des expressions d’exécution telles que ${maestro.copiedText} et ${output.value}. Un credential_id du même projet peut fournir des valeurs complètes de inputText de ${USERNAME} / ${PASSWORD}. Un variable_profile_id du même projet peut enregistrer la valeur par défaut pour les valeurs de ${DATA_*} référencées ; chaque clé référencée doit exister. Les profils de données sont uniquement des données synthétiques non secrètes.
import_mobile_script — Importe un script de test mobile existant et le transforme en automatisation exécutable, en préservant les localisateurs du développeur afin que les exécutions résolvent les éléments avec précision. Dialectes pris en charge : Appium‑Python, WebdriverIO, Maestro (flux YAML) et Playwright (mobile‑web). Les espaces réservés d’ID de ressources Android obscurcis sont ignorés et signalés dans le warnings de mappage de sélecteurs. Applications Android uniquement. Nécessite name, app_id et script ; facultatif target_devices et project_id. Renvoie l’automatisation ainsi que action_count, le dialect détecté et le warnings de mappage de sélecteurs.
run_mobile_automation — Démarre une automatisation mobile sur un appareil réel. Nécessite automation_id ; facultatif device, os_version, credential_id et variable_profile_id natif-Maestro. 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. Chaque clé de ${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 exactes connues des identifiants sont filtrées et les valeurs exactes des profils de données reçoivent un filtrage de meilleur effort à partir des preuves textuelles persistées ; les valeurs transformées, partielles, encodées ou dérivées de l’application peuvent rester. Les vidéos/captures d’écran privées autorisées restent disponibles et peuvent afficher des valeurs rendues par l’application testée, donc les profils de données doivent contenir uniquement des valeurs synthétiques non secrètes. Si le contexte de rédaction des identifiants est indisponible ou si l’assainissement ne peut pas être prouvé sûr, le texte détaillé des identifiants est retenu tandis que le statut et les preuves visuelles disponibles restent. Les diagnostics nécessitent l’autorisation de l’espace de travail et du projet ; les liens média expirent après cinq minutes.
list_mobile_runs — Obtient les résultats d’exécution mobiles autorisés (statut, appareil, résumé des résultats, liens vidéo et captures d’écran privés, session BrowserStack, journaux natifs Maestro filtrés et échecs lorsqu’ils sont sûrement disponibles, et tout bug auto-créé). L’appartenance à l’espace de travail et l’accès au projet sont appliqué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ée un profil chiffré nom d’utilisateur/mot de passe en écriture seule réutilisable par Mobile, Web Automation et Exploratory AI. Nécessite project_id, name, username et password ; le visibility facultatif est private (par défaut) ou shared. Les profils privés sont réservés au 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 la même frontière de sécurité.
list_login_profiles — Liste uniquement les profils visibles par l’appelant, éventuellement pour un project_id. Renvoie des métadonnées non secrètes incluant 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’identifiants.
update_login_profile — Renomme, fait pivoter ou modifie visibility. Le créateur actif peut mettre à jour n’importe quel champ. Un propriétaire/administrateur d’espace de travail actif peut renommer ou faire pivoter un profil partagé mais ne peut pas changer la visibilité ; les profils privés restent réservés au créateur.
update_mobile_credential — Nom de compatibilité pour update_login_profile ; utilise les mêmes vérifications de propriété et de projet.
delete_login_profile — Suppression douce par le créateur, avec récupération du cycle de vie par le propriétaire/administrateur uniquement pour les profils partagés. Les valeurs par défaut d’utilisation future sont effacées tandis que l’historique d’audit reste.
delete_mobile_credential — Nom de compatibilité pour delete_login_profile ; les références historiques restent pour l’audit.
create_mobile_variable_profile — Crée des données de test synthétiques réutilisables et limitées au 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 autorisent 1 à 100 chaînes, 4096 octets UTF-8 par valeur et 65536 octets au total. Les noms réservés d’identifiants/exécution sont rejetés. Ne stockez jamais d’identifiants, de jetons, de données personnelles de production ou d’autres secrets.
list_mobile_variable_profiles — Liste les profils Mobile/Both et leurs valeurs non secrètes lisibles pour un project_id autorisé. Les règles d’assignation de projet s’appliquent. Les profils existants et la création mobile utilisent par défaut both ; la création/mise à jour accepte platform (mobile ou both). Les profils Web uniquement sont exclus de l’accès au catalogue mobile et de l’utilisation à l’exécution.
update_mobile_variable_profile — Renomme un profil ou remplace son objet variables complet par id. Seul le créateur actif ou un propriétaire/administrateur d’espace de travail actif peut le mettre à jour.
delete_mobile_variable_profile — Supprime doucement un profil par id. Seul le créateur actif ou un propriétaire/administrateur d’espace de travail actif peut le supprimer ; les valeurs par défaut d’automatisation sont effacées tandis que les références historiques d’exécution restent.
list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Liste, crée et supprime les planifications d’appareils réels. Les planifications héritent du contexte de projet, du profil de connexion et du profil de variables non secrètes de leur 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 suppressions de planification sont restreintes au créateur de planification actif ou à un propriétaire/administrateur d’espace de travail actif.

Catalogue de données de test Web

Le même catalogue de projet non secret est disponible depuis Automate Web. Ces outils nécessitent l’entitlement automation de l’espace de travail et la portée de clé API automations:write, y compris les lectures. Ils ne nécessitent pas l’accès Mobile. Les valeurs ne partagent jamais d’enregistrements avec les profils de connexion chiffrés. La prise en charge du catalogue ne lie ni n’injecte pas encore les valeurs de profil dans les exécutions web.

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

Exemple : résolvez un projet en utilisant 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 invalides ou les noms en double à l’échelle du projet sont rejetés.

Exemple de flux de travail — Android

list_projects → résolvez le project_id cible
upload_mobile_app → enregistrez l’APK dans ce projet
Enregistrez en toute sécurité dans le tableau de bord, ou utilisez import_mobile_script / create_mobile_automation
list_mobile_automations → résolvez l’automatisation dans le même projet
run_mobile_automation → déclenchez-la sur un appareil réel, éventuellement avec un profil de connexion
list_mobile_runs → vérifiez le statut, le résumé des résultats, les liens visuels privés et les métadonnées de session BrowserStack
Les échecs créent automatiquement des rapports de bug avec un instantané d’échec et une répartition des étapes

Exemple de flux de travail — iOS

upload_mobile_app → enregistrez votre IPA avec project_id pour les exécutions sur appareils réels
Téléversez la version simulateur .app sur la page de détails de l’application (pour l’enregistrement)
Enregistrez le test dans le navigateur → les actions sont capturées depuis le simulateur
run_mobile_automation → déclenchez l’automatisation enregistrée sur un iPhone (utilise l’IPA)
update_mobile_app → remplacez l’IPA par une nouvelle version lorsque vous êtes prêt

Exemple de flux de travail — Maestro natif

upload_mobile_app → enregistrez l’APK ou l’IPA dans le projet cible
create_mobile_credential → créez éventuellement un profil du même projet pour un flux authentifié
create_mobile_variable_profile → créez éventuellement des valeurs synthétiques DATA_* du même projet utilisées par le flux
create_mobile_automation → transmettez un flux YAML connu et fonctionnel avec le package/bundle exact de l’application liée appId, script_type: maestro et execution_mode: browserstack_maestro. Utilisez ${USERNAME} / ${PASSWORD} pour la connexion et les espaces réservés de style ${DATA_EMAIL} pour les entrées synthétiques ; transmettez les ID de profil pour enregistrer les valeurs par défaut.
run_mobile_automation → sélectionnez un appareil compatible et remplacez éventuellement le profil de connexion ou de variables. Omettez le profil de variables pour hériter, ou transmettez null pour le désactiver pour une exécution.
list_mobile_runs → inspectez les résumés autorisés de réussite/échec, les vidéos/captures d’écran privées, les journaux filtrés, les noms d’étapes réels, les échecs détaillés et les métadonnées de session. Si un assainissement sûr ne peut pas être établi pour une exécution avec identifiants, le texte détaillé est retenu tandis que le statut et les preuves visuelles disponibles restent.

Affiner avec l’IA : la bêta sur liste blanche est disponible via le tableau de bord et les points de terminaison REST d’affinement. Aucun outil MCP Refine ne fait encore partie du catalogue public.

✅

Conformité et preuves (Entreprise)

collect_compliance_evidence — Déclenchez la collecte automatisée de preuves depuis les services connectés (Cloudflare, GitHub, Sentry, Supabase, Railway). Renvoie un identifiant d'exécution. Collecte les paramètres SSL/TLS, l'état du WAF, les alertes Dependabot, les tendances d'erreurs, l'historique de déploiement, et plus encore.
check_config_drift — Vérifiez tous les services connectés pour détecter tout écart de configuration de sécurité par rapport aux références (mode SSL, version TLS, HSTS, règles WAF, en-têtes de sécurité).
generate_access_review — Créez un rapport de revue d'accès trimestriel. Audite les membres de l'équipe, les rôles, l'état MFA, l'utilisation des clés API, et génère des recommandations (par exemple, révoquer les clés inactives).
get_security_events — Interrogez la chronologie des événements de sécurité inter-services. Filtrez par source (cloudflare, sentry, github) et par gravité (critique, élevée, moyenne, faible, info). Les événements sont automatiquement corrélés entre les services.

Couverture de conformité

Ces outils aident à répondre aux 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 RGPD (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 Paramètres → Développeur → Modifier la configuration, 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 Paramètres → Serveurs MCP → Ajouter un serveur, 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 Paramètres → MCP → Ajouter un serveur, 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"

Cela se connecte directement au serveur HTTP Streamable hébergé.

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

Commande : npx
Ligne de commande : npx -y bugagent-mcp
Arguments : ["-y", "bugagent-mcp"]
Environnement : BUGAGENT_API_KEY

Obtenir de l'aide

Besoin d'assistance ? Nous sommes là pour vous aider.

Communauté Discord

Rejoignez notre Discord pour un support en temps réel et des discussions communautaires.

Support par e-mail

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