bugAgent

Connect bug Agent к любому MCP-совместимому ИИ-клиенту.

Создавайте, классифицируйте и управляйте багами, запросами функций и другим напрямую из вашего ИИ-ассистента для программирования. Никакого переключения контекста, никакого копирования и вставки — просто опишите проблему, и bug Agent сделает всё остальное.

Внешние MCP-клиенты отделены от ИИ-ассистента дашборда bug Agent. Ассистент дашборда по умолчанию отключен во всех тарифных планах и требует явного включения в рабочем пространстве; его шлюз ai_assistant не отключает MCP или интеграции. Аутентификация MCP, области действия, разрешения рабочего пространства/проекта и права конкретных инструментов по-прежнему применяются.

Начало работы

bug Agent запускает размещенный MCP-сервер, чтобы ИИ-клиенты могли создавать, запрашивать и управлять отчетами об ошибках, запросами функций, улучшениями и другим через Model Context Protocol. Клиенты подключаются напрямую к размещенной конечной точке Streamable HTTP.

Получите свой API-ключ

Создайте бесплатную учетную запись; новые владельцы рабочих пространств сразу переходят к настройке API-ключа. Вернувшиеся пользователи могут сгенерировать ключ в Настройки → Разработчикам → API-ключи.

Настройте свой ИИ-клиент

Добавьте bug Agent как MCP-сервер в конфигурацию вашего клиента (см. настройку ниже).

Начните создавать баги

Опишите ошибку на естественном языке, и bug Agent автоматически классифицирует, обогатит и сохранит её.

# 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

Настройка

Рекомендуется: размещенный Streamable HTTP

Подключитесь напрямую к https://mcp.bugagent.com/mcp. Ничего устанавливать или запускать локально не нужно. Добавьте API-ключ рабочего пространства как bearer-токен:

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

💡

Замените ba_live_YOUR_KEY_HERE на ваш фактический API-ключ из Настройки → Разработчикам.

Необязательный мост stdio

Используйте опубликованный мост только тогда, когда клиенту требуется stdio и он не может подключиться к удаленному HTTP-серверу. Запускайте его по требованию с помощью npx -y bugagent-mcp:

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

Подключение к серверу

MCP-сервер bug Agent работает по адресу https://mcp.bugagent.com/mcp через транспорт Streamable HTTP. Подключитесь из любого из восьми клиентов ниже — выберите тот, который подходит вашему рабочему процессу.

Для небольшой готовой к копированию конфигурации, руководства по ключам с ограниченными областями и безопасных стартовых подсказок используйте публичный MCP quickstart.

🔑

Сначала получите свой API-ключ. Войдите в Настройки → Разработчикам, нажмите Создать API-ключ, выберите области, необходимые вашему клиенту, и скопируйте значение (начинается с ba_live_). Вы увидите его только один раз, поэтому сохраните его в безопасном месте. MCP-клиенты перечисляют только те инструменты, которые разрешены этими областями. Примеры подключения ниже используют этот ключ; подсказки, требующие интерактивного OAuth/сеанса или права платного тарифа, указаны отдельно.

Вариант 1 — MCP Inspector (веб-интерфейс, рекомендуется для первого тестирования)

Официальный инструмент Anthropic. Запускает локальный веб-интерфейс, где вы можете просмотреть каждый инструмент, заполнить параметры и увидеть ответы. Ноль конфигурации, IDE не требуется.

macOS (Терминал)

npx @modelcontextprotocol/inspector

Windows (PowerShell или CMD)

npx @modelcontextprotocol/inspector

В открывшемся браузерном интерфейсе:

1. Тип транспорта: выберите Streamable HTTP
2. URL: https://mcp.bugagent.com/mcp
3. Тип подключения: выберите Прокси (по умолчанию — Inspector проксирует через локальный процесс Node, чтобы обойти CORS браузера)
4. Откройте Настройки сервера → Пользовательские заголовки и добавьте:
   • Имя заголовка: X-Api-Key
     • Значение: ba_live_YOUR_KEY_HERE (без префикса Bearer)
5. Нажмите Подключить. Левая панель перечисляет инструменты bug Agent, разрешенные выбранными областями API-ключа.
6. Нажмите на любой инструмент (например, list_bug_reports), заполните параметры, нажмите Запустить инструмент. Ответ отображается справа.

Предварительные требования: MCP Inspector v2 требует Node.js 22.19 или новее. Установите текущую версию Node.js с nodejs.org, если у вас её нет.

Если Inspector возвращает invalid_client, он пытается использовать сохраненное OAuth-подключение вместо аутентификации по API-ключу. Удалите сохраненный сервер (или очистите его сохраненное состояние OAuth), добавьте его снова и используйте пользовательский заголовок X-Api-Key выше. Не помещайте ключ ba_live_ в поле OAuth client_id.

Вариант 2 — Claude Desktop (Mac + Windows)

Если вы используете приложение Claude Desktop, вы можете добавить bug Agent как постоянный MCP-сервер. С API-ключом рабочего пространства Claude получает только те инструменты, которые разрешены областями этого ключа. Делегированный OAuth открывает полный интерактивный каталог.

macOS

1. Откройте Claude Desktop → в строке меню Claude → Настройки → Разработчик → Изменить конфигурацию. Откроется ~/Library/Application Support/Claude/claude_desktop_config.json.
2. Добавьте запись bug Agent в раздел mcpServers:

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

3. Сохраните файл и полностью закройте Claude Desktop (Cmd+Q, не просто закройте окно).
4. Перезапустите Claude Desktop. Значок молотка инструментов внизу поля ввода чата теперь должен показывать инструменты bug Agent.
5. Попробуйте: введите «Список моих 5 последних отчетов об ошибках» — Claude автоматически вызовет list_bug_reports.

Windows

1. Откройте Claude Desktop → Файл → Настройки → Разработчик → Изменить конфигурацию. Откроется %APPDATA%\Claude\claude_desktop_config.json (обычно C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
2. Добавьте тот же JSON-блок, показанный в разделе macOS.
3. Сохраните файл и полностью закройте Claude Desktop из системного трея (щелкните правой кнопкой мыши по значку Claude → Выйти), затем перезапустите.
4. Значок молотка инструментов покажет инструменты bug Agent.

Вариант 3 — Claude Code (CLI)

Если вы используете Claude Code из терминала (CLI-версия Claude), зарегистрируйте сервер bug Agent одной командой. Работает одинаково на macOS, Linux и Windows.

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

Затем перезапустите сеанс Claude Code. Проверьте подключение:

claude mcp list

Вы должны увидеть bugagent в списке с зеленой точкой. Начните с подсказки, совместимой с API-ключом: «Список моих 5 последних открытых отчетов об ошибках».

Подключено, но некоторые инструменты отсутствуют?

Проверьте количество инструментов сервера в /mcp, а не только инструменты, уже загруженные в разговор. Claude Code может обнаруживать инструменты по запросу с помощью поиска инструментов. Попросите его найти bugAgent для list_test_cases, list_test_suites или get_test_run_plan. См. документацию по поиску инструментов Claude Code.

Каталог фильтруется по областям API-ключа. Для чтения тестовых случаев требуется test_cases:read; для чтения наборов/запусков требуется test_runs:read. Запрашивайте только те области записи, которые вам действительно нужны. Сравните аутентифицированный tools/list с той же конечной точкой и ключом, что и ваш клиент; анонимное обнаружение или другой ключ не являются допустимым сравнением. Проверьте наличие конфигурации уровня проекта, переопределяющей ваше подключение уровня пользователя, затем переподключитесь или перезапустите после изменения учетных данных.

Если аутентифицированный каталог сервера включает инструмент, но клиент все еще не может его обнаружить, запишите версию клиента, версию сервера, имена/количество инструментов и любые ошибки схемы, удалив учетные данные и данные клиента. Сеанс, начатый с ENABLE_TOOL_SEARCH=false claude, может отличить отложенное обнаружение от проблем загрузки, но загружает все определения инструментов и использует больше контекста; используйте его только как временную диагностику. Не расширяйте разрешения и не разделяйте конечные точки только для увеличения количества инструментов.

Чтобы удалить позже:

claude mcp remove bugagent

Вариант 4 — OpenAI Codex CLI

Если вы используете OpenAI Codex CLI, экспортируйте свой API-ключ и добавьте bug Agent в ~/.codex/config.toml.

Постоянная регистрация (добавить в конфигурацию)

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

Установите API-ключ

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

Запустите или перезапустите Codex из этого окружения. Codex автоматически разрешает вызовы инструментов из вашей подсказки на естественном языке. Попробуйте: «Список моих открытых ошибок, отсортированных по серьезности».

Вариант 5 — Cursor (Mac + Windows)

Cursor имеет встроенную поддержку MCP. С соответствующим образом ограниченным API-ключом рабочего пространства ИИ-ассистент внутри Cursor может создавать ошибки, перечислять отчеты и запускать поддерживаемые рабочие процессы автоматизации, не покидая редактор. Сканирование безопасности, производительности и исследовательские сканы требуют делегированного OAuth и доступа к соответствующему плану.

1. Откройте Cursor → Настройки (Cmd+, на Mac / Ctrl+, на Windows) → MCP на левой боковой панели.
2. Нажмите + Добавить новый MCP-сервер.
3. Выберите тип транспорта HTTP.
4. Заполните:
   • Имя: bugagent
     • URL: https://mcp.bugagent.com/mcp
     • Имя заголовка: Authorization
     • Значение заголовка: Bearer ba_live_YOUR_KEY_HERE
5. Нажмите Сохранить. Cursor покажет зеленый индикатор при подключении.
6. Откройте чат Cursor (Cmd+L / Ctrl+L) и введите «Создай отчет об ошибке с названием «Логин сломан» с высоким приоритетом». Cursor вызовет create_bug_report.

Альтернатива: Cursor также читает ~/.cursor/mcp.json (Mac) или %USERPROFILE%\.cursor\mcp.json (Windows). Добавьте тот же JSON-формат, показанный в разделе Claude Desktop.

Вариант 6 — VS Code с расширением Continue (Mac + Windows)

Если вы предпочитаете VS Code, расширение Continue поддерживает MCP-серверы нативно.

1. Установите расширение Continue из маркетплейса VS Code.
2. Откройте конфигурацию Continue: Палитра команд (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Открыть config.json. Файл находится по адресу:
   • macOS: ~/.continue/config.json
     • Windows: %USERPROFILE%\.continue\config.json
3. Добавьте запись mcpServers:

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

4. Сохраните. Continue автоматически перезагрузится и покажет инструменты bug Agent на боковой панели.
5. Откройте панель чата Continue и попробуйте: «Список моих 5 последних открытых отчетов об ошибках».

Другие расширения VS Code с поддержкой MCP: Cline, Roo Code и Windsurf (форк) следуют аналогичным шаблонам JSON-конфигурации с ключом mcpServers и HTTP-транспортом.

Вариант 7 — OAuth-совместимые хосты (веб-приложение Claude.ai показано как пример)

Некоторые MCP-хосты аутентифицируются через OAuth 2.0 и запрашивают статические client_id и client_secret заранее, вместо принятия bearer API-ключа. Сгенерируйте пару учетных данных коннектора из дашборда bug Agent и вставьте её в форму коннектора хоста. Пара идентифицирует MCP-клиента; после согласия выполнение инструментов использует вошедшего пользователя и его активное рабочее пространство bug Agent. Пошаговое руководство ниже использует веб-приложение Claude.ai как наиболее распространенный пример.

i

OAuth, привязанный к ресурсу. Идентификатор защищенного ресурса — https://mcp.bugagent.com/mcp. Хосты, поддерживающие стандарты, обнаруживают его из /.well-known/oauth-protected-resource/mcp и отправляют как параметр RFC 8707 resource. bug Agent выпускает непрозрачные токены, привязанные к этому ресурсу, OAuth-клиенту, вошедшему пользователю и предоставленным областям; токен не может быть воспроизведен против другой службы или использован другим клиентом.

1. В bug Agent: откройте Настройки → Разработчикам → MCP-коннекторы. Нажмите Сгенерировать коннектор, дайте ему имя, описывающее хост (например, «Claude.ai (рабочий)»), вставьте URI перенаправления, который требует ваш MCP-хост (для веб-приложения Claude.ai это https://claude.ai/api/mcp/auth_callback — проверьте документацию коннектора вашего хоста для других), и выберите Конфиденциальный для метода аутентификации. Скопируйте client_id и client_secret, показанные один раз на экране успеха.
2. В настройках коннектора/OAuth вашего MCP-хоста вставьте:
   • URL сервера: https://mcp.bugagent.com/mcp
     • Client ID + Client Secret: из шага 1
     • URL авторизации: https://mcp.bugagent.com/authorize
     • URL токена: https://mcp.bugagent.com/token
     • Защищенный ресурс / аудитория, если запрашивается: https://mcp.bugagent.com/mcp Для Claude.ai конкретно: перейдите на claude.ai/customize/connectors и нажмите Добавить MCP-коннектор.
3. Сохраните. Хост перенаправит вас в bug Agent для входа (Google или email/пароль — любой метод, который вы используете для дашборда) и одобрения согласия, затем завершит OAuth-рукопожатие.
4. Управляйте и отзывайте сгенерированные коннекторы на той же странице настроек. Отзыв немедленный — следующий запрос от этого коннектора вернет invalid_client.

Примечание: Claude Code, Cursor, VS Code и MCP Inspector не нуждаются в этом процессе — они обрабатывают динамическую регистрацию клиента (RFC 7591) автоматически и аутентифицируются через API-ключ, как показано выше. Форма MCP-коннекторов предназначена только для хостов, требующих статические OAuth-учетные данные.

Значения доступа и обновления OAuth отображаются только хосту. Они непрозрачны, ротируются при обновлении и хранятся bug Agent только как односторонние хэши; учетные данные обновления вышестоящей идентичности зашифрованы в состоянии покоя. Никогда не копируйте OAuth-токен в запрос REST API или другой MCP-сервер.

Вариант 8 — Прямой HTTP с curl (Терминал)

Если вы хотите протестировать сервер напрямую без какого-либо клиента или интегрировать его в скрипт, вы можете обратиться к HTTP-эндпоинту с curl. Протокол MCP — это JSON-RPC 2.0 поверх 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

Ответы могут быть в формате JSON или Server-Sent Events. Каждый фрагмент SSE — это строка с префиксом data:, за которым следует JSON-объект. Соответствующие стандартам клиенты должны отправлять Accept: application/json, text/event-stream; bug Agent в настоящее время нормализует отсутствующие или неполные значения Accept для совместимости.

ℹ️

Устранение ошибки 401 Unauthorized: Проверьте, что ваш API-ключ не был отозван в Settings → Developers. Ключи начинаются с ba_live_. Если проблема не устранена, сгенерируйте ключ заново и повторите попытку.

Модель доступа и области с минимальными привилегиями

Полный каталог OAuth содержит 141 инструмент. API-ключ рабочей области видит только те инструменты, которые сопоставлены с одной из выбранных областей. Неаутентифицированное обнаружение может показывать метаданные инструментов, но tools/call всегда требует API-ключ или OAuth-токен.

Чтение отчетов об ошибках и разрешение проектов reports:read

Создание и обновление отчетов об ошибках reports:read, reports:write

Мониторинг использования usage:read

Проверка состояния синхронизации Jira jira:read

Синхронизация или объединение отчетов Jira jira:write

Авторизация веб-автоматизаций automations:write

Запуск веб-автоматизаций и чтение запусков automations:run

Наблюдение за мобильными активами и запусками mobile:read

Управление мобильными активами mobile:read, mobile:write

Запуск мобильной автоматизации mobile:read, mobile:run

Управление каталогом тестов reports:read, test_cases:read, test_cases:write

Внешний исполнитель тестов test_runs:read, test_runs:write

API-ключи привязаны к рабочей области, в которой они созданы. Входные данные инструмента могут сузить вызов до авторизованного проекта, но не могут переключить ключ на другую рабочую область. Разрешайте UUID проектов с помощью list_projects и отклоняйте неоднозначные имена.

Названия инструментов и аннотации

Каждый инструмент, возвращаемый tools/list, включает понятное название и подсказки о чтении/записи. Отсутствующие подсказки о чтении берутся из явно проверенного списка, а не из префиксов названий инструментов или областей API-ключей. Явные аннотации, включая false, сохраняются.

• readOnlyHint: true описывает инструмент, который не изменяет свою среду.
• readOnlyHint: false с destructiveHint: false описывает аддитивные записи, а не операцию только для чтения.
• readOnlyHint: false с destructiveHint: true описывает потенциально разрушительные записи. Неклассифицированные инструменты используют эти консервативные значения по умолчанию. Подсказка о разрушительности значима только для записей.

login не является операцией только для чтения: в режиме stdio она сохраняет учетные данные. analyze_fix_area и check_config_drift являются потенциально разрушительными записями, поскольку они заменяют сохраненные результаты анализа или базовые конфигурации.

Аннотации не предоставляют доступ и не заменяют аутентификацию, авторизацию рабочей области/проекта, области API-ключей или проверки прав. Подсказки подтверждения зависят от политики разрешений клиента и настроек пользователя; подсказки не гарантируют, будет ли вызов запрашивать подтверждение.

Для программного обнаружения и аудита загрузите сгенерированный mcp-tool-index.json. Он записывает все 141 инструментов времени выполнения, доступ через API-ключ или только OAuth, семейство прав, имена входных данных, режим выходной схемы и явно объявленные аннотации MCP. Аннотация null означает, что она не объявлена в месте вызова; используйте ответ tools/list подключенного сервера для эффективных аннотаций после применения значений по умолчанию.

!

Инструменты только для OAuth: управление учетной записью, API-ключами и командой, управление подключениями Jira, другие интеграции, премиальные элементы управления тестированием, заметки, учет времени и другие интерактивные операции не разблокируются добавлением областей API-ключей. Проверка отчетов Jira, синхронизация и объединение — узкое исключение через jira:read и jira:write.

Попробуйте — подсказки на простом английском

После подключения вам не нужно знать названия инструментов или параметры. Опишите, что вы хотите, на простом английском, и ваш ИИ-ассистент автоматически вызовет правильный инструмент bug Agent.

Подсказки для отчетов об ошибках, управления тестами с ограниченной областью, автоматизации Playwright, мобильной автоматизации и использования доступны для API-ключей с соответствующими областями. Безопасность, производительность, исследовательские, учетные записи, команды, заметки, учет времени и другие записи без указанной области API-ключа требуют делегированного OAuth и любых применимых прав плана.

Отчеты об ошибках

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

Управление тестами

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

Безопасность и производительность

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?

Автоматизация 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

Исследовательский ИИ

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?

Использование и статистика

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?

Краткий справочник

Справочники по настройке для всех восьми вариантов подключения. Клиенты с API-ключами подключаются к https://mcp.bugagent.com/mcp с заголовком Authorization: Bearer ba_live_YOUR_KEY_HERE через Streamable HTTP; хосты с поддержкой OAuth используют учетные данные коннектора, сгенерированные в панели управления.

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

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

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

Codex CLI ~/.codex/config.toml

Cursor — macOS Settings → MCP UI или ~/.cursor/mcp.json

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

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

Хост с поддержкой OAuth Settings → Developers → MCP Connectors — сгенерируйте client_id и client_secret хоста

Прямой HTTP (curl) curl / Invoke-RestMethod — включите Accept: application/json, text/event-stream

Устранение неполадок

401 Unauthorized Ключ неверный, истек или отозван. Проверьте Settings → Developers — ключи начинаются с ba_live_. При необходимости сгенерируйте заново.

Инструменты не отображаются в клиенте Клиенты с API-ключами перечисляют только инструменты, разрешенные выбранными областями ключа. Проверьте ключ в Settings → Developers, затем полностью закройте и перезапустите клиент после изменения его конфигурации. В Claude Desktop — Cmd+Q (не просто закрытие окна). В Cursor проверьте Settings → MCP на наличие зеленой точки.

Поле отсутствует в клиенте Сравните схему клиента с необработанным tools/list того же эндпоинта. Если они различаются, обновите или переподключите каталог инструментов и начните новый чат. Если проблема сохраняется, соберите эндпоинт, версию клиента и необработанный ответ tools/list; устаревший кэш — лишь одна из возможных причин.

Accept header required Отправьте Accept: application/json, text/event-stream для соответствующего стандартам Streamable HTTP. bug Agent в настоящее время нормализует отсутствующие или неполные значения, но интеграции не должны полагаться на такое поведение совместимости.

Данные не той рабочей области Каждый API-ключ ограничен одной рабочей областью. Сгенерируйте новый ключ из рабочей области, которую вы хотите запрашивать, в Settings → Developers.

Инструменты отображаются, но вызовы молча завершаются с ошибкой Проверьте ответ на наличие isError: true и возвращенного содержимого. Видимый инструмент все равно может быть отклонен из-за плана, роли, прав функции, членства в проекте, владения или неверных входных данных. Проверяйте работоспособность сервера только после чтения ошибки инструмента.

Ошибка CORS в MCP Inspector Выберите Proxy (не Direct) для Connection Type в интерфейсе Inspector. Inspector проксирует через локальный процесс Node, чтобы обойти ограничения CORS браузера.

MCP Inspector v2 завершается с кодом 5 Inspector v2 возвращает ненулевой код выхода, когда ответ инструмента содержит isError: true. Прочитайте сообщение ответа для ошибки плана, разрешения, входных данных или времени выполнения; Inspector v1 мог возвращать код выхода 0 для того же неудачного ответа инструмента.

Codex CLI — инструменты не распознаются Убедитесь, что ~/.codex/config.toml использует [mcp_servers.bugagent], установите bearer_token_env_var = "BUGAGENT_API_KEY" и экспортируйте эту переменную перед запуском Codex. Проверьте codex --version, если инструменты все еще не отображаются.

Возможности MCP

Разговорные сеансы остаются пилотной функцией, ограниченной рабочей областью. Сохранение скрипта, сгенерированного сеансом, требует явного одобрения Workbench его владельца через эндпоинт сохранения скрипта только для сеанса. Нет инструмента одобрения MCP: запрос агенту на создание черновика скрипта не создает и не планирует автоматизацию.

Полный интерактивный/OAuth каталог содержит 141 инструмент. API-ключи рабочей области обнаруживают только подмножество с минимальными привилегиями, разрешенное их выбранными областями; инструменты управления учетной записью, API-ключами, командой, премиального тестирования, заметок и учета времени доступны только в интерактивном сеансе, если запись явно не называет область API-ключа.

🐛

Управление отчетами об ошибках

Возобновляемые импорты скриншотов Google Sheets используют отдельный REST POST /api/reports/import-attachment эндпоинт с reports:write и GET статус с reports:read. Инструмент MCP для импорта скриншотов не добавлен. Этот API только для JPEG/PNG проверяет приватное хранилище и точную сопоставленную проблему Jira перед сообщением о завершении; загрузка устаревших отчетов остается только для сеанса.

• create_bug_report — Создание нового отчёта с автоматической классификацией по 19 типам — ошибки, запросы функций, улучшения, технический долг и другое (заголовок: 3–500 символов). Необязательный массив attachments принимает файлы в base64-кодировке размером до 400 МБ каждый: любые изображения, видео, аудио, PDF или текст/JSON. Установите format_description: true, чтобы автоматически переформатировать описание в структурированный шаблон с помощью ИИ. Передайте time_spent_seconds для отслеживания усилий по обеспечению качества. Передайте priority (urgent / high / normal / low), чтобы задать срочность исправления независимо от серьёзности. Передайте is_epic: true для создания Epic или parent_epic_id (UUID/короткий ID) для создания дочернего элемента в том же авторизованном проекте. Ответ включает поля иерархии, а также project_id, project, short_id, legacy_short_id и project_short_id.
• list_bug_reports — Список и фильтрация отчётов (максимум 100 на страницу). Фильтры проектов применяются на стороне сервера до пагинации. Фильтрация по project (UUID, slug, точное имя или префикс тикета), project_id, project_slug, project_prefix, workspace (UUID, точное имя или префикс тикета рабочего пространства), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause или reporter_user_id. Фильтр search ищет по тексту отчёта; ввод, содержащий только цифры, например 366, является точным поиском как по устаревшим, так и по проектным номерам тикетов, поэтому несвязанный текст, содержащий эти цифры, исключается. Каждый результат включает идентификаторы людей/проектов в рамках тенанта, а также is_epic, parent_epic_id, parent_epic и ограниченный epic_progress. Инструменты чтения отчётов не раскрывают адреса электронной почты участников.
• pick_next_bug — Возвращает следующую(ие) ошибку(и), над которой(ыми) должен работать цикл агента, в порядке приоритета (S1 → S2 → S3, сначала самые старые в каждой группе). Автоматически ограничено вашим рабочим пространством — возвращает тикеты во всех проектах вашей команды с status new, awaiting-triage или confirmed и серьёзностью S1–S3. Только чтение — не выполняет атомарное закрепление тикетов. Необязательный severity (один уровень), limit (1–50, по умолчанию 1). Возвращает объект с count и bugs; каждая ошибка представляет собой сокращённую строку очереди, а не полную форму list_bug_reports. Используйте вместе с claim_bug для шаблона «чтение-затем-закрепление».
• claim_bug — Атомарный переход ошибки из status new, awaiting-triage или confirmed в status='in-progress', установка assigned_to на вызывающего пользователя и отметка claimed_at=NOW(). Без гонок между параллельными вызовами благодаря паттерну UPDATE-WHERE-RETURNING в Postgres — если два агента вызывают claim_bug для одного и того же id почти одновременно, ровно один получает claimed:true с телом ошибки, а другой получает claimed:false со строкой причины. Успешные ответы включают reporter_user_id, reporter_name, assigned_to и assignee_name. Демон pg_cron автоматически освобождает устаревшие закрепления (статус = in-progress + claimed_at старше 30 минут) обратно в new, поэтому тикеты упавшего агента снова попадают в очередь без ручного вмешательства. Входные данные: id (UUID или короткий ID).
• get_bug_report — Получение полных сведений об отчёте по UUID или короткому ID рабочего пространства/проекта. Возвращает стандартные поля людей/проекта/качества, а также is_epic, идентичность родителя, агрегированный прогресс и ограниченную первую страницу дочерних элементов для Epic.
• Встроенные теги отчётов: create_bug_report и update_bug_report принимают tags как массив строк, например {"tags":["login","regression"]}. До 20 необработанных элементов принимается до дедупликации. Строки обрезаются, должны быть непустыми и не длиннее 50 кодовых точек Unicode, и не могут содержать управляющие символы ASCII (U+0000–U+001F или U+007F). Точные дубликаты удаляются после обрезки; регистр сохраняется, и Login отличается от login. При обновлении массив заменяет все теги, [] очищает их, а пропуск сохраняет их. При создании пропуск означает отсутствие тегов. null и недопустимые элементы отклоняются. Результаты создания, получения, списка и обновления раскрывают встроенные tags.
• Фильтрация по тегам: вызов list_bug_reports с {"project":"bugagent","tags":["login","regression"]} для сопоставления ВСЕХ запрошенных тегов с учётом регистра до пагинации. Применяются те же ограничения на теги; пропуск или [] не применяет фильтр по тегам. Существующие области reports:read / reports:write и авторизация рабочего пространства/проекта не изменяются. Это не добавляет визуального интерфейса тегов или автоматического импорта, синхронизации или обратного заполнения меток Jira.
• get_epic — Чтение одного Epic напрямую с обязательным id (UUID или короткий ID рабочего пространства/проекта). Возвращает только запись Epic без неявной загрузки дочерних отчётов. Требуется доступ к его рабочему пространству и проекту; вызывающим с API-ключом требуется reports:read. Используйте list_epic_children отдельно для чтения дочерних элементов.
• list_epic_children — Постраничный просмотр дочерних отчётов Epic с помощью id, limit (1–100) и offset. Возвращает children, total, has_more и агрегированный SQL epic_progress без загрузки каждого дочернего отчёта.
• update_bug_report — Обновление стандартных полей отчёта, а также is_epic и parent_epic_id. Передайте parent_epic_id: null для отсоединения; повторное родительство/отсоединение атомарно и требует авторизации в том же рабочем пространстве и проекте. Повышение до Epic отсоединяет существующего родителя, а Epic с дочерними элементами не может быть понижен. Существующие правила уведомлений о статусе/резолюции/корневой причине и назначении по-прежнему применяются. Изменение status в отчёте, связанном с Jira, зеркалируется в задачу Jira через её переходы рабочего процесса, когда ровно один допустимый переход соответствует сопоставленному статусу; в противном случае задача остаётся нетронутой.
• add_comment — Добавление комментария к отчёту об ошибке (UUID или короткий ID, тело 1–10000 символов). Если отчёт синхронизирован с Jira, комментарий автоматически отправляется в связанную задачу Jira. Приватная разметка вложений, такая как ![proof](/api/attachments/ATTACHMENT_UUID), становится абсолютной аутентифицированной умной ссылкой bugAgent в Jira. Зрители должны войти в bugAgent с доступом к рабочему пространству и проекту отчёта; встроенные предпросмотры Jira не гарантируются.
• list_comments — Список сохранённой ветки комментариев отчёта, сначала самые старые — каждый комментарий с именем автора, parentId (вложенные ответы), createdAt и updatedAt. Комментарии не являются частью get_bug_report, поэтому это способ прочитать обсуждение тикета. Принимает UUID или короткий ID. Это чтение не обновляет Jira. Планируемые интеграции, которым нужны свежие комментарии Jira, могут сначала вызвать POST /api/jira/comments-refresh с авторизованным API-ключом менеджера. Используйте ID комментариев и ревизии содержимого, чтобы отличать новые комментарии от правок, и не заявляйте о полном отчёте активности, если обновление не удалось.
• link_bug_reports — Создание направленной семантической ссылки между двумя отчётами в одном авторизованном проекте. Для parent-of отчёт-источник должен быть Epic, а отчёт-назначение — стандартным дочерним элементом. Предпочитайте parent_epic_id при создании/обновлении для назначения Epic.
• unlink_bug_reports — Удаление ранее созданной ссылки отчёта об ошибке по её UUID (link_id, возвращается link_bug_reports или list_bug_report_links).
• list_bug_report_links — Список всех пользовательских ссылок, касающихся отчёта об ошибке. Возвращает каждую ссылку так, как она читается с точки зрения предоставленного отчёта — например, сохранённая строка duplicate-of, где этот отчёт является целью, отображается как duplicated-by; parent-of, где этот отчёт является целью, отображается как subtask-of; depends-on, где этот отчёт является целью, отображается как blocks; testing-blocked-by, где этот отчёт является целью, отображается как blocks-testing. related-to симметричен. Дополняет автоматически обнаруженное поле similar_reports, возвращаемое get_bug_report.
• classify_bug — Классификация описания в один из 19 типов отчётов (ошибки, запросы функций, улучшения и т. д.) с оценкой уверенности
• flush_reports — Массовое удаление старых отчётов (только для администраторов)

📊

Использование и аналитика

• get_usage — Проверка использования относительно лимитов плана. Вызывающим с API-ключом требуется usage:read.
• get_stats — Ежедневные подсчёты, разбивки по типу/серьёзности/статусу

📁

Управление проектами

• list_projects — Список доступных проектов с id, name, slug, ticket_prefix, описанием и статусом по умолчанию. Используйте эти значения с инструментами отчётов об ошибках и каталога тестов для нацеливания на правильный проект.
• create_project — Создание нового проекта (автоматически становится проектом по умолчанию, если он первый)
• delete_project — Полное удаление проекта и всех связанных данных (отчёты об ошибках, автоматизации, тестовые случаи, мобильные приложения, расписания, гео-снимки, заметки, записи времени). Только владелец/менеджер. Нельзя удалить последний проект. Хранилище освобождается автоматически
• export_okf_bundle — Экспорт знаний по обеспечению качества проекта — отчёты об ошибках, тестовые случаи, автоматизации, а также тесты производительности, безопасности и исследовательские тесты — как пакет разметки OKF/OQA (формат Open Query Agent, используемый oqa.ai). По умолчанию используется активный проект; передайте необязательный project (slug или имя), чтобы экспортировать другой. Возвращает список файлов в пакете, а также сам пакет как zip-архив в base64-кодировке

🔐

Аутентификация и учётная запись

• register_account — Создание новой учётной записи (пароль: 8–128 символов, ограничение скорости: 5/15 мин)
• login — Вход и получение токенов доступа (ограничение скорости: 5/15 мин)
• update_profile — Обновление отображаемого имени
• change_password — Смена пароля учётной записи
• get_settings — Чтение профиля и предпочтений уведомлений.
• update_settings — Обновление поддерживаемых профилей и предпочтений уведомлений. Изменение только через OAuth.

🔑

Управление API-ключами

• generate_api_key — Создание именованного API-ключа
• list_api_keys — Список активных ключей (только префикс)
• regenerate_api_key — Отзыв и замена ключа
• delete_api_key — Полный отзыв ключа

👥

Управление командой

• list_workspaces — Список рабочих пространств, к которым вы принадлежите, вашу роль в каждом и то, какое из них сессия использует по умолчанию. Хосты с несколькими рабочими пространствами могут закрепить запрос с заголовком X-BugAgent-Workspace (только активные участники)
• list_team_members — Список всех участников вашего рабочего пространства с ролями, статусом и флагами бустера
• invite_team_member — Приглашение пользователя по электронной почте (менеджеры могут приглашать участников и менеджеров; только владельцы могут приглашать администраторов). Ссылка со сроком действия 5 дней

🎯

Интеграции

Синхронизация отчётов Jira Cloud включена в Free и Enterprise. Менеджер рабочего пространства должен сначала подключить Jira в панели управления. Затем API-ключи рабочего пространства могут использовать jira:read для сравнения и jira:write для синхронизации/слияния; ограничения плана Atlassian и API по-прежнему применяются.

• sync_to_jira — Отправить отчёт в Jira, используя общее подключение команды. Направляет в проект Jira, сопоставленный с проектом bugAgent отчёта (по умолчанию используется рабочее пространство), используя его карту полей: v2 разделяет приоритет и пользовательскую серьёзность, в то время как несвязанные карты сохраняют устаревшее преобразование серьёзности в приоритет. Необязательный projectKey может выбрать только это настроенное сопоставление или рабочее пространство по умолчанию; произвольные проекты Jira отклоняются. Обычно вам это не нужно: когда режим синхронизации проекта — auto_new или auto_all, созданные вами отчёты отправляются автоматически — вызывайте это для ручной отправки в режиме manual.
• check_jira_sync — Сравнение только для чтения заголовка и сопоставленных статуса, приоритета и серьёзности для авторизованного связанного отчёта. Использует сохранённый проект отчёта и подключение к Jira. Версия 2 сопоставляет приоритет Jira отдельно от поддерживаемого пользовательского поля серьёзности; несвязанные сопоставления сохраняют устаревшее поведение приоритета к серьёзности. Этот инструмент не сравнивает комментарии, вложения, тип или каждое поле Jira.
• merge_jira_sync — Объединить эти сопоставленные поля, используя prefer: jira для получения значений Jira или prefer: bugagent для отправки локальных значений. Отправка статуса использует допустимые переходы рабочих процессов Jira. Несопоставленные исходящие конфликты, неудачные удалённые записи и одновременные локальные изменения возвращают ошибки, а не утверждают, что всё синхронизировано. Комментарии и вложения остаются отдельными рабочими процессами синхронизации на панели управления. Межсистемные записи не являются атомарными.
• push_to_claude — Сгенерировать (или перегенерировать) Developer Notes для отчёта об ошибке — корневая причина, предлагаемое исправление, шаги проверки и оценка риска. Принимает UUID или короткий ID (WRKID-545). Использует ключи платформы — не требуется подключение Claude для каждой команды. Запускает адаптивную цепочку: три шага для ошибок s3 / medium или s4 / low (черновик Sonnet → критика OpenAI gpt-5 → синтез Sonnet), пять шагов для двух верхних уровней серьёзности — s1 / critical или s2 / high — (черновик → критика → опровержение Sonnet → арбитр Claude Opus, который читает полную стенограмму и пишет финальные заметки с независимым суждением). Ответ раскрывает каждый раунд: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model и флаг debated. Любой сбойный шаг переходит к следующему лучшему ответу. Автоматически запускается при создании ошибки; обычно вызывается только для ручной перегенерации.
• analyze_fix_area — Сгенерировать (или перегенерировать) подблок "Likely Fix Area" в Developer Notes — узкий вывод Sonnet, который указывает, где в кодовой базе, скорее всего, находится исправление. Принимает UUID или короткий ID. Использует ключ Anthropic платформы. Когда у команды есть строка github_connections и у проекта сопоставлен github_repo, вывод основан на реальных фрагментах файлов из подключённого репозитория; в противном случае возвращается к общим рекомендациям с подсказкой подключить репозиторий. Возвращает текст likely_fix_area, generated_at, repo_used и флаг grounded. Автоматически запускается при создании ошибки — агентам обычно нужно вызывать это только для ручной перегенерации.
• upgrade_plan — Получить ссылку на корпоративное включение с помощью продаж

⚡

Тестирование производительности

• create_performance_test — Создать конфигурацию теста производительности с URL, устройством, виртуальными пользователями, продолжительностью, порогом оценки и переключателем автоматического создания ошибок. Только для Enterprise
• run_performance_test — Запустить аудит страницы и нагрузочный тест для веб-теста производительности. Возвращает ID запуска для опроса результатов. Запуски профилирования мобильных приложений запускаются с панели управления
• get_performance_results — Получить полные результаты, включая оценки Lighthouse (Performance, Accessibility, Best Practices, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) и метрики нагрузочного теста (VU, запросы, RPS, задержки p50/p90/p95/p99)
• list_performance_tests — Список всех конфигураций тестов производительности для текущей команды
• get_performance_usage — Проверить ежемесячное использование тестов производительности. Тестирование производительности доступно только в Enterprise. Free=0, Enterprise=безлимитно

Пример рабочего процесса

1. get_performance_usage → проверить оставшуюся квоту
2. create_performance_test → настроить тест для вашего URL
3. run_performance_test → запустить аудит + нагрузочный тест
4. get_performance_results → просмотреть оценки и показатели

🛡

Сканирование безопасности

• create_security_scan — Создать конфигурацию сканирования безопасности. Веб-сканирования используют Quick Scanner + Nuclei (4,000+ шаблонов) с тремя уровнями глубины и необязательным аутентифицированным сканированием. Мобильные сканирования используют MobSF для анализа бинарных файлов APK/IPA. Настраиваемое автоматическое создание ошибок с порогами серьёзности. Только для Enterprise
• run_security_scan — Запустить сканирование уязвимостей. Веб-сканирования требуют проверки домена DNS. Мобильные сканирования требуют загруженного приложения. Возвращает ID запуска для опроса результатов
• get_security_results — Получить полные результаты, включая оценку безопасности (0-100), находки, классифицированные по серьёзности (Critical, High, Medium, Low, Info) со ссылками CWE, сопоставлениями OWASP, доказательствами и рекомендациями по исправлению
• list_security_scans — Список всех конфигураций сканирования безопасности для текущей команды с последней оценкой и значками auth/depth
• get_security_usage — Проверить ежемесячное использование сканирования безопасности. Сканирование безопасности доступно только в Enterprise. Enterprise=безлимитно
• list_security_schedules — Список всех запланированных сканирований безопасности для команды с cron, часовым поясом, состоянием включения, следующим запуском и настройками уведомлений. Объединяется с родительской конфигурацией сканирования (name, scan_type, target_url)
• create_security_schedule — Создать повторяющееся расписание для сканирования безопасности. Требует scan_id и cron_expression. Одно расписание на конфигурацию сканирования. Необязательные timezone, notify_on_fail (none/email/slack/both), notify_email, slack_channel_id. Каждый запуск учитывается в вашем ежемесячном лимите; пользователи с правами администратора обходят лимит. Глубина сканирования всегда считывается из конфигурации сканирования во время запуска
• delete_security_schedule — Удалить запланированное сканирование безопасности. Не влияет на родительскую конфигурацию сканирования или завершённые запуски

Пример рабочего процесса

1. get_security_usage → проверить оставшуюся квоту
2. create_security_scan → настроить сканирование для вашего URL или репозитория
3. run_security_scan → запустить разовое сканирование уязвимостей
4. create_security_schedule → автоматизировать повторяющиеся запуски (например, еженедельный SAST на основной ветке)
5. get_security_results → просмотреть находки и исправления

📖

Проверка кода

• list_code_reviews — Список последних AI-проверок кода для команды. Возвращает оценки качества, количество по серьёзности, информацию о PR и временные метки. Только для Enterprise
• get_code_review — Получить проверку кода со всеми находками. Каждая находка включает серьёзность, категорию (bug/security/performance/style/logic/maintainability), заголовок, описание, предложение по коду, путь к файлу и номера строк
• get_code_review_usage — Проверить использование проверки кода. AI-проверка кода доступна только в Enterprise; безлимитно на Enterprise
• get_code_review_analytics — Получить аналитику проверок: тенденции, категории/источники находок, разбивку по серьёзности, метрики скорости, лучшие репозитории/авторы. Поддерживает период 7/30/90 дней

Пример рабочего процесса

1. get_code_review_usage → проверить оставшиеся проверки
2. Проверить PR на панели управления по адресу /dashboard/code-review
3. list_code_reviews → посмотреть недавние проверки
4. get_code_review → получить находки и предложения

🔍

Исследовательский AI

Многоагентный автономный поиск ошибок на сайте с до 10 параллельными агентами, каждый из которых использует свою стратегию тестирования.

• list_explorations — Список конфигураций Exploratory AI для команды
• create_exploration — Создать новое исследование. Принимает agent_count (1–10, максимум 10) для запуска нескольких параллельных агентов с уникальными стратегиями: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Этот инструмент не может настраивать учётные данные или режим аутентификации. Настройте и запустите Test login flow only явно через панель управления или REST, затем используйте get_exploration и get_exploration_run для проверки конфигурации и результатов. Никогда не выводите режим из инструкций и не помещайте учётные данные в аргументы MCP. Исследование по умолчанию на основе учётных данных по-прежнему требует повторно используемую сессию.
• get_exploration — Получить конфигурацию исследования с настройками агентов, безопасными метаданными аутентификации и недавними запусками. Пароли и шифротекст никогда не возвращаются.
• get_exploration_run — Получить результаты запуска с прогрессом по каждому агенту, данными фаз, находками с атрибуцией агента (agent_index, agent_strategy) и связанными ошибками
• get_exploration_usage — Проверить ежемесячное использование. Exploratory AI доступен только в Enterprise; Enterprise: безлимитно (10 агентов)

Пример рабочего процесса

1. create_exploration с agent_count: 5 → настроить 5 параллельных агентов
2. Запустить выполнение с панели управления или через POST /api/explorations/run
3. get_exploration_run → опрашивать прогресс и находки по каждому агенту
4. Просмотреть дедуплицированные находки с атрибуцией агента на панели управления

📝

Заметки

• list_notes — Список заметок с необязательными фильтрами по ключевому слову, проекту, видимости, папке, тегу, архиву, вики, диапазону дат и сортировке. Возвращает заметки, которыми владеет пользователь или которые доступны ему.
• create_note — Создать заметку в одном из 5 форматов: markdown, plain, bugtemplate, checklist, outline. Установите visibility на private или shared. Автоматический заголовок из первых 30 символов, если заголовок не указан. Необязательный массив attachments принимает файлы в base64 до 400 МБ каждый: любое изображение, видео, аудио, PDF или текст/JSON. Передайте time_spent_seconds для отслеживания усилий QA.
• get_note — Получить полные детали заметки, включая содержимое и вложения. Требует id.
• update_note — Обновить заголовок, содержимое, формат, видимость, проект или time_spent_seconds. Передайте массив attachments, чтобы добавить новые файлы (максимум 400 МБ каждый) к существующим вложениям заметки без их замены. Только автор может обновлять. Требует id.
• delete_note — Навсегда удалить заметку и её вложения. Только автор может удалять. Требует id.
• list_note_folders — Список папок заметок/вики, опционально ограниченных проектом.
• create_note_folder — Создать папку заметок/вики в рамках проекта с необязательными настройками родителя, видимости, избранного и доступа для коллег.

Пример рабочего процесса

1. create_note → начать заметку о сессии тестирования
2. update_note → добавлять наблюдения по мере тестирования
3. list_notes → искать прошлые заметки по ключевому слову или проекту
4. get_note → получить полную заметку с вложениями

🤖

Автоматизация

• create_automation — Создание новой автоматизации с пользовательским Playwright-скриптом (запись FAB не требуется). Требуется name. Необязательно: target_url (автоматически определяется из первого URL page.goto(...) в скрипте, если опущено), script (Node.js/JavaScript/TypeScript или Python — язык определяется автоматически; по умолчанию используется заполнитель), status (draft или active, по умолчанию: draft), project_id. Возвращает id автоматизации. Совет — Дублирование автоматизации: используйте get_automation для получения исходного скрипта, затем вызовите create_automation с name, установленным в "[Copy] Original Name", и передайте исходные script, target_url и project_id. Дубликат запускается со статусом draft без истории версий.
• list_automations — Список Playwright-скриптов автоматизации. Фильтрация по project_id или status (draft, active, paused). Возвращает массив автоматизаций с именем, target_url, last_run_status и run_count.
• get_automation — Получение полных деталей автоматизации, включая Playwright-скрипт и недавние запуски. Требуется id. Возвращает автоматизацию с актуальным script, стеком script_versions (от старых к новым, до 100 предыдущих записей, каждая { script, source, timestamp }) и массивом recent_runs, где каждый запуск содержит script_version_label / script_version_source, которые выполнялись. Вызовите это перед run_automation, если нужно выбрать конкретную историческую версию.
• run_automation — Запуск немедленного выполнения Playwright-теста. Требуется automation_id. Самовосстанавливающиеся локаторы (автоматически): когда действие локатора истекает по таймауту, исполнитель запрашивает у Claude рабочий селектор и повторяет шаг один раз — утверждения никогда не восстанавливаются, поэтому реальные регрессии по-прежнему приводят к сбоям — и каждое восстановление регистрируется в stdout запуска. Режим эмуляции (по умолчанию): необязательный device для профиля эмулируемого устройства (например, desktop, iphone-15). Реальный режим: установите browserstack: true с bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) и bs_os_version для запуска в реальном настольном браузере. Реальный мобильный: установите bs_os: "android" (устройства: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") или bs_os: "ios" (устройства: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") и передайте имя устройства в bs_os_version. Оба режима работают в фоновом режиме; «Реальный» описывает среду выполнения, а не видимую интерактивную сессию. Скрипты Node.js маршрутизируются через browserstack-node-sdk (покрывает desktop + Android + iPhone). Скрипты Python маршрутизируются через browserstack-sdk (pytest-playwright) и покрывают только desktop — реальный мобильный через Python не поддерживается, потому что browser_type.connect() от pytest-playwright не может управлять реальными мобильными конечными точками BrowserStack. Видео и сетевые журналы захватываются автоматически; консольные журналы только для desktop. Воспроизведение версий: проверьте script_versions с помощью get_automation, затем передайте предпочтительный устойчивый version_label (например, "v103"). Устаревший version_index по-прежнему поддерживается, но не должен комбинироваться с version_label. По умолчанию: когда оба селектора опущены, выполняется текущий сохраненный скрипт. Удаленные метки и недопустимые индексы отклоняются вместо молчаливого выполнения текущего. Запись запуска хранит точный снимок, который выполнялся, и любой отчет об ошибке, автоматически созданный из неудачного запуска, содержит глубокую ссылку на эту версию в редакторе.
• list_automation_runs — Список недавних запусков для автоматизации. Требуется automation_id. Возвращает запуски со статусом, duration_ms и error_message.
• list_schedules — Список всех запланированных запусков веб-автоматизации с nullable cron_expression, nullable run_at, once_status, часовым поясом, устройством и настройками уведомлений. Повторяющиеся строки сохраняют null run_at и once_status; одноразовые строки имеют null cron. Одноразовые состояния: pending, claimed, missed, dispatched, failed, uncertain. Это состояния диспетчеризации, а не результаты тестов; проверьте list_automation_runs для результатов.
• Повторяющиеся веб-расписания: create_schedule проверяет пять числовых полей cron и часовой пояс и возвращает будущую UTC next_run_at. Поддерживаются ежемесячные и ежегодные повторения. Например, 30 12 23 9 * в America/Toronto означает 23 сентября в 12:30 каждый год, а не одноразовый запуск. Недопустимое или невозможное время отклоняется до создания. Когда ограничены и день месяца, и день недели, оба должны совпадать. Несуществующее время перехода на летнее время пропускается; повторяющееся настенное время может встречаться дважды. Диспетчеризация происходит при следующем опросе планировщика, не обязательно в точную минуту. Существующее повторяющееся поведение не изменяется.
• Одноразовые веб-расписания: вызовите create_schedule с { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" }, выбрав будущую дату и опустив cron_expression. Укажите ровно одно поле времени. run_at требует будущую временную метку ISO 8601 с указанием смещения (явное смещение или Z); часовой пояс IANA предназначен для отображения. Включенное ожидающее расписание выполняется при первом опросе cron после наступления срока; более чем на один час позже помечается как missed. Оно атомарно захватывается и отключается перед диспетчеризацией и не может быть повторно включено после использования. Окончательные сбои диспетчеризации — это failed; неоднозначная диспетчеризация — это uncertain и никогда не повторяется автоматически. Проверьте запуски перед планированием новой попытки. dispatched не означает завершено или пройдено. Создание доступно только через API/MCP, а не через новый режим создания в панели управления.
• Часовые пояса веб-расписаний — это идентификаторы IANA, такие как America/Argentina/Buenos_Aires. Селектор в панели управления включает все поддерживаемые сервером регионы и города и по умолчанию использует часовой пояс вашего профиля; часовой пояс MCP по умолчанию остается UTC.
• create_schedule — Создание запланированного запуска веб-автоматизации. Требуется automation_id и ровно одно из cron_expression или run_at. Поддерживаются необязательные настройки устройства, часового пояса, уведомлений о сбоях, электронной почты и Slack-канала. Сначала подключите Slack через панель управления и выберите канал, в котором состоит бот; установки вебхука недостаточно. См. Настройка Slack и обнаружение каналов.
• Одноразовое развертывание и восстановление: примените миграцию базы данных 374_one_time_web_schedules.sql перед развертыванием соответствующего кода API/MCP и планировщика. claimed может сохраняться после сбоя воркера: проверьте историю запусков перед созданием замены для захваченной или неоднозначной диспетчеризации. Временная метка более чем на один час позже никогда не выполняется автоматически.
• Черновики веб-автоматизаций: активируйте автоматизацию перед созданием расписания, повторным включением расписания или изменением его cron-выражения или часового пояса. create_schedule проверяет доступ к рабочему пространству и проекту перед отклонением статуса «Черновик». Существующие расписания пропускают циклы, пока автоматизация находится в статусе «Черновик»; пауза, удаление, закрепление и изменения только уведомлений остаются доступными. Нет веб-инструмента MCP update_schedule; используйте панель управления для этих обновлений.
• delete_schedule — Удаление запланированного запуска веб-автоматизации
• list_mobile_schedules — Список всех запланированных запусков мобильной автоматизации с устройствами, cron, часовым поясом и уведомлениями
• create_mobile_schedule — Создание запланированного запуска мобильной автоматизации на реальных устройствах. Требуется automation_id и cron_expression; devices необязателен.
• delete_mobile_schedule — Удаление запланированного запуска мобильной автоматизации
• optimize_automation_script — Отправка Playwright-скрипта в Sonnet 4 для оптимизации с помощью ИИ. Применяется контрольный список из 12 пунктов, который исправляет селекторы, стратегии ожидания, утверждения, обработку ошибок, паттерны аутентификации, мобильную совместимость и строгий режим. Требуется automation_id. Текущая версия скрипта сохраняется перед оптимизацией. Возвращает оптимизированный скрипт и сводку изменений.
• undo_automation_script — Откат скрипта автоматизации к предыдущей версии. Сохраняется до 100 предыдущих версий. Требуется automation_id. Возвращает восстановленный скрипт и количество оставшихся версий.

Пример рабочего процесса

1. create_automation → создание теста с пользовательским скриптом
2. list_automations → просмотр доступных тестов
3. get_automation → проверка Playwright-скрипта
4. run_automation → запуск теста
5. list_automation_runs → проверка результатов и длительности

⏱️

Учет времени

• list_time_entries — Список записей времени для команды. Фильтрация по period (today, week, month, all), project_id, category и sort (newest, oldest, most_time, least_time). Только для тарифа Enterprise.
• create_time_entry — Запись времени, затраченного на задачи контроля качества. Требуется description, category и duration_minutes. Необязательно можно установить project_id и entry_date (по умолчанию — сегодня). Только для тарифа Enterprise.
• update_time_entry — Обновление существующей записи времени. Требуется id. Можно обновить description, category, duration_minutes, project_id или entry_date. Только для тарифа Enterprise.
• delete_time_entry — Окончательное удаление записи времени. Требуется id. Только для тарифа Enterprise.

Пример рабочего процесса

1. create_time_entry → запись 45 минут регрессионного тестирования
2. list_time_entries → просмотр записей времени за эту неделю
3. update_time_entry → корректировка длительности или категории
4. delete_time_entry → удаление неверной записи

☑️

Тестовые случаи

Управление тестами с иерархическими папками, вложенными наборами (до 3 уровней глубины с автоматическим разворачиванием поднаборов при запусках), перетаскиванием для изменения порядка и вкладкой аналитики «Отчеты» с трендами KPI, анализом сбоев, состоянием наборов, покрытием и производительностью тестировщиков. Все инструменты обращаются к Supabase напрямую — без HTTP-передачи, та же задержка, что и в панели управления.

Бесплатные ограничения: 10 сохраненных тестовых случаев, 1 набор, 3 папки, 128 КБ структурированного содержимого на случай, 2 активных ключа API рабочего пространства и 10 всего тестовых запусков за календарный месяц UTC. До 3 из этих запусков могут использовать Hermes или другого внешнего агента, с 1 активным внешним запуском и максимум 10 случаями в каждом внешнем плане. Бесплатный трафик MCP с API-ключами ограничен 30 запросами на ключ и 60 на рабочее пространство в минуту. Хранилище тестовых случаев и запуски Enterprise не ограничены, при условии общих защитных мер платформы.

Генерация тестовых случаев с помощью ИИ, предложения тегов с помощью ИИ, импорт из Figma и вложения файлов тестовых случаев требуют Enterprise. Бесплатное ограничение структурированного содержимого в 128 КБ отделено от вложений файлов Enterprise. Бесплатный тариф может хранить ссылки URL. Основные инструменты MCP для тестовых случаев остаются доступными на бесплатном тарифе в пределах указанных выше ограничений.

Выполнение без рук: страница обзора запуска — это карусель с одним видимым случаем за раз, сочетания клавиш (P Пройден · F Провален · B Заблокирован · S Пропущен) и голосовое управление. Нажмите на микрофон, затем скажите «Пройден», «Провален», «Заблокирован», «Пропущен», «Далее», «Назад», «Добавить заметки» (транскрибируется в поле заметок), «Сохранить заметки» или «Выключить голос». Автоматически переходит к следующему непротестированному случаю при успешных результатах; остается на месте при провале, чтобы тестировщики могли продиктовать детали и создать ошибку. Работает в Chrome, Edge и Safari.

Случаи и папки

• list_test_cases — Список доступных тест-кейсов с необязательным селектором project и фильтрами search, priority, type, status и sort. Добавьте folder_id (null для несгруппированных) или suite_id для прямого членства, без потомков. Вызывающим с API-ключом требуется test_cases:read. Значение limit по умолчанию — 50 (1–200); значение offset по умолчанию — 0 (0–1000000). Неизмененный массив cases сопровождается total / total_count для всех авторизованных совпадений, limit, offset, has_more и обнуляемым next_offset. Ранее total ошибочно означал длину страницы. Следуйте next_offset, пока не получите null; не делайте вывод о завершении по длине страницы. Продолжение за пределами смещения 1000000 явно завершается ошибкой; сузьте фильтры, а не получайте непригодный курсор или ложное завершение. Страницы, превышающие 1 МиБ данных кейсов, явно завершаются ошибкой: повторите с меньшим лимитом, а не принимайте пропущенные записи. Используется стабильное разрешение конфликтов по ID, но параллельные изменения могут сдвигать страницы смещения.
• Пример пагинации: вызовите list_test_cases с {"project":"test-bed","limit":50,"offset":0}. Для 55 совпадений ответ содержит total:55, has_more:true, next_offset:50. Повторите с offset:50 для оставшихся пяти и has_more:false, next_offset:null.
• create_test_case — Создание тест-кейса в обязательном селекторе project (UUID, слаг, точное имя или префикс тикета; сначала вызовите list_projects). Два варианта шаблона: steps (по умолчанию) — сетка { action, expected } для каждого шага через массив steps; text — одно свободное описание через text_content. Оба поля можно отправить в одном вызове. Необязательный массив urls (максимум 10 URL http/https) прикрепляет ссылки и доступен на Free. Вложения файлов требуют Enterprise и сеанса в панели управления. Вызывающим с API-ключом требуется test_cases:write.
• Восстановление пагинации: запрос смещения кейса за пределами доступных результатов возвращает явную ошибку; перезапустите со смещения 0. Это также может произойти, если кейсы удалены между запросами. Следуйте возвращенному продолжению, а не угадывайте следующее смещение.
• Идентификаторы кейсов: list_test_cases, get_test_case, create_test_case и update_test_case возвращают UUID id, неизменяемый short_id (например, TEST-BA-CASE-123) и числовой case_number, включая компактные ответы обновления/без изменений. Устаревшие кейсы без проекта используют TEST-CASE-123. Отсутствующие идентификаторы возвращаются как null; используйте UUID как запасной вариант. База данных назначает идентификаторы; вызывающие не могут изменить их или выбрать при создании. Переименование префикса не переписывает существующие ID.
• Поиск одного кейса: get_test_case и update_test_case принимают UUID или полный короткий ID в id; link_test_case_to_bug и list_test_case_links принимают любой из них в case_id. Окружающие пробелы, регистр букв и числовое дополнение нормализуются перед точным поиском в активном рабочем пространстве. Авторизация использует сохраненное рабочее пространство и проект, а не префикс ID. Голые числа, частичные ID и поиск по подстановочным знакам не принимаются. Массовые массивы кейсов, результат выполнения case_id, ID ошибок, ID папок и ID наборов остаются только UUID. Записи ссылок сохраняют UUID case_id.
• Пробелы в нумерации: номера кейсов не обязательно должны быть последовательными. Редактирование URL или увеличение номера может привести к отсутствующему или недоступному кейсу; это не гарантированное действие для следующего кейса. Обнаруживайте кейсы с помощью инструмента списка и следуйте его пагинации.
• Область рабочего пространства: один и тот же короткий ID может существовать в разных рабочих пространствах. MCP разрешает его только в активном рабочем пространстве; переключите контекст рабочего пространства перед использованием короткого ID другого рабочего пространства. При обмене URL-адресом короткого ID панели управления сохраняйте ?team=<case.team_id>, например /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. Постоянные ссылки UUID сохраняют существующее авторизованное поведение между рабочими пространствами. MCP не создает постоянную ссылку.
• get_test_case — Получение авторизованной записи кейса, включая шаги и идентификаторы. Не загружает историю изменений или историю выполнения. Пример: {"id":"TEST-BA-CASE-123"}.
• Оценки выполнения: get_test_case возвращает estimated_time_seconds и псевдоним совместимости estimated_time, оба в секундах. Сохраненное значение 0 остается 0; неизвестная или отсутствующая оценка — null. Каноническое поле побеждает, когда присутствуют оба имени, включая явное null; значения только для устаревшего estimated_time обрабатываются как секунды без преобразования. list_test_cases использует estimated_time_seconds. Входное значение create_test_case остается estimated_time, также в секундах; REST-запросы и ответы используют estimated_time_seconds.
• list_test_case_folders — Список доступных папок. Ограничено 500; принимает гибкий селектор project и фильтр parent_folder_id (используйте "root" только для верхнего уровня). Вызывающим с API-ключом требуется test_cases:read.
• get_test_case_folder — Чтение одной папки тест-кейсов напрямую с обязательным id (UUID). Возвращает только запись папки, без неявной загрузки вложенных папок или тест-кейсов. Требуется доступ к ее рабочему пространству и проекту; вызывающим с API-ключом требуется test_cases:read.
• Значения type тест-кейсов для list_test_cases, create_test_case и bulk_update_test_cases: functional (по умолчанию при создании), regression, smoke, integration, performance, security, usability, exploratory. Недействительные типы отклоняются перед записью. Используйте integration для сквозных потоков; e2e, accessibility и other не принимаются как типы тест-кейсов. Типы скриптов автоматизации — отдельный контракт.
• create_test_case_folder — Создание папки в обязательном project, возвращаемом list_projects (вложенность до 3 уровней через parent_folder_id). Требуется доступ к рабочему пространству на уровне участника или выше и доступ к проекту. Вызывающим с API-ключом также требуется test_cases:write.
• update_test_case_folder — Обновление по UUID папки: id, необязательный name (обрезка, 1–120 символов), обнуляемый description (максимум 50000 символов), обнуляемый parent_folder_id и обнуляемый card_color. UUID родителя перемещает папку и ее поддерево в том же рабочем пространстве и проекте; null перемещает ее в корень. Цвет принимает палитру в нижнем регистре #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd; null очищает его. Опущенные поля сохраняются. Требуется хотя бы одно поле обновления. Неизвестные, с ошибками или недействительные поля отклоняют весь запрос без сохранения изменений. Циклы себя/потомков, имена, совпадающие с соседним, прямым родителем или прямым потомком (без учета регистра и окружающих пробелов), и глубины поддерева выше 3 (корень — глубина 0) отклоняются. Глубины потомков обновляются атомарно; ID кейсов и членство не изменяются. Конфликтующие параллельные изменения могут завершиться ошибкой; перечитайте папку перед повторной попыткой. Требуется активный доступ к проекту на уровне участника или выше и test_cases:write для API-ключей. Пример: {"id":"folder-uuid","card_color":"#93c5fd"}. Возвращает обновленные id, team_id, project_id, name, description, card_color, parent_folder_id, depth и updated_at. Чтение папок get/list также включает card_color.
• update_test_case — Изменение существующего кейса по UUID или полному короткому ID в id с хотя бы одним полем: name (или псевдоним title), description, preconditions, steps, template_type, text_content, priority, type, status или folder_id. Опущенные поля сохраняются; steps заменяет полный массив ([] очищает). Явное null очищает описание, предварительные условия, text_content или размещение в папке; пустой text_content также очищает. Если отправлены и name, и title, они должны совпадать. Приоритет и тип используют перечисления создания; статус — active, draft или deprecated. Изменение типа выравнивает type_tags с новым типом, соответствуя PATCH API. Нет перемещений рабочего пространства/проекта или записи метаданных файлов. Папки должны иметь точно такое же рабочее пространство и проект. Требуется test_cases:write. Возвращает сводку кейса, id, short_id, case_number и changed; неизмененные значения дают changed: false. Подтвержденное обновление с неподтвержденной записью истории возвращает warnings; не повторяйте обновление для исправления истории. При ошибке параллельного изменения перечитайте кейс перед повторной попыткой. Членство в наборе отдельно: используйте массовый инструмент ниже, а не suite_id в этом инструменте. Инструмент удаления не предоставляется.
• bulk_update_test_cases — Применение одного действия к 1–500 UUID кейсов; передайте один ID для одного кейса. set_folder принимает params.folder_id (UUID для перемещения, явный null для снятия с группировки). add_to_suite и remove_from_suite принимают params.suite_id; добавление никогда не удаляет другие членства и не перемещает папку. Также поддерживает set_priority, set_status, set_type, add_tags, remove_tags, pin и unpin. API-ключи требуют test_cases:write. Возвращает applied, skipped и errors; организационные действия подсчитывают подтвержденные измененные строки, дедуплицируют ID и пропускают существующие членства.
• Размещение при создании: create_test_case принимает необязательные folder_id и suite_id. Обнаруживайте цели с помощью list_test_case_folders и list_test_suites (обнаружение наборов требует test_runs:read для API-ключей). Папки — единое место каталога; наборы — членства в тест-планах «многие ко многим». Цели должны принадлежать тому же авторизованному рабочему пространству и точному проекту, включая устаревшие кейсы без области. Недоступные ID кейсов пропускаются без деталей; несовпадающие цели отклоняются. Недействительные цели создания завершаются ошибкой до создания кейса.
• Частичное создание: создание кейса и прикрепление к набору — отдельные записи. Если прикрепление не удается, ответ возвращает созданный ID кейса, suite_id: null и массив warnings. Не повторяйте create_test_case; повторите bulk_update_test_cases с add_to_suite для этого возвращенного ID.
• link_test_case_to_bug — Установление трассируемости между тест-кейсом и UUID отчета об ошибке (verified_by, covers или relates). Обе записи должны принадлежать активному рабочему пространству и проектам, доступным вызывающему.
• list_test_case_links — Список всех ссылок трассируемости для тест-кейса.
• list_test_case_review_candidates — Флаги мертвых тестов: never_run (90+ дней с создания), always_passes (5+ последовательных прохождений за 90 дней), always_skipped (3+ последовательных пропуска).
• mark_test_case_review_flags — Сохранение текущих флагов кандидатов в архив в test_cases.review_flag. Запускается автоматически каждый понедельник в 09:00 UTC через pg_cron.

Импорт

• Импорт Figma (Enterprise) (только сеанс панели управления): загрузите zip-экспорт кадров Figma (до 100 МиБ), Claude анализирует каждый экран и создает черновики тест-кейсов в выбранную или созданную вами папку. Перед декодированием архив ограничен 1000 записей, 20 МиБ развернутых (декодированных) данных на запись и 100 МиБ совокупных развернутых данных, включая игнорируемые файлы и каталоги в бюджетах. Декодированные буферы кадров должны соответствовать заявленным размерам. Некорректные архивы, несоответствия размеров и превышенные лимиты завершают задачу до AI-анализа; исходная загрузка сохраняется при сбое для повторной попытки, в соответствии с политикой очистки хранилища. Допустимые архивы проходят многоэтапный конвейер (классификация → кейсы для каждого экрана → кейсы уровня потока для экранов с общим префиксом → самокритика) с кэшированием подсказок, повтором при 429 и изоляцией ошибок AI для каждого кадра. Кейсы попадают как status=active, помеченные ai_generated=true, с source='figma' и source_frame_name, сохраняющими ссылку на исходный кадр. Используется ключ платформы Anthropic — отдельное подключение Claude для команды не требуется.

Наборы и запуски

• list_test_suites — Выводит до 50 доступных тестовых наборов с необязательным гибким фильтром project. Каждый набор включает точное целочисленное значение case_count: непосредственно назначенные случаи всех статусов, без вложенных элементов, исключая случаи из других рабочих областей или проектов (устаревшие случаи без проекта остаются включенными). Количество не ограничивается полученными строками членства. Вызывающим с API-ключом требуется test_runs:read для обратной совместимости с исполнительными рабочими процессами.
• get_test_suite — Читает один тестовый набор напрямую с обязательным параметром id (UUID). Возвращает только запись набора, без неявной загрузки дочерних наборов или входящих тестовых случаев. Требуется доступ к рабочей области и проекту; вызывающим с API-ключом требуется test_runs:read.
• create_test_suite — Создает набор в обязательной рабочей области project, возвращаемой list_projects. Вложенность до 3 уровней через parent_suite_id. Вызывающим с API-ключом требуется test_cases:write.
• update_test_suite — Обновляет набор по UUID: id, необязательный name (обрезанный, 1–120 символов), допускающий null description (максимум 50000 символов) и status (активен/архивирован). Пропущенные поля и членство в случаях сохраняются. Требуется активный доступ к проекту уровня «участник или выше» и test_cases:write. Перемещение родительских наборов и закрепление не поддерживаются; перемещение родительских наборов требует атомарного обслуживания глубины вложенных элементов. Возвращает id, team_id, project_id, name, description, parent_suite_id, depth, status и updated_at. Пример: {"id":"suite-uuid","name":"Checkout regression","description":null}.
• list_test_runs — Выводит список тестовых прогонов с именем набора, исполнителем и сводкой по пройденным/непройденным.
• create_test_run — Создает прогон набора, управляемый панелью управления. Запуск родительского набора автоматически включает каждый случай во всех вложенных под-наборах (случай, связанный с обоими, добавляется ровно один раз). Каждая строка test_run_results записывает, из какого исходного под-набора поступил случай, чтобы страницы результатов могли группироваться по происхождению.

Выполнение внешним агентом

Эти инструменты позволяют Hermes или другой среде агента выполнить одобренный набор, не становясь системой учета качества. Используйте ключ с областью рабочей области, имеющий только test_runs:read и test_runs:write. Набор задает границы проекта; вызывающие не могут их переопределить.

• start_test_plan — Запускает или возобновляет неизменяемый снимок набора со стабильным external_run_id. Повторный идентификатор возвращает существующий соответствующий прогон и первую страницу вместо создания дубликата.
• get_test_run_plan — Читает каноническое состояние прогона и стабильную страницу плана. Передайте предыдущий next_cursor; страницы по умолчанию содержат 100 случаев и ограничены 200.
• report_test_results — Отправляет 1–200 результатов со статусом passed, failed, blocked или skipped. Точные повторные попытки безопасны; попытка перезаписать случай другим статусом отклоняется.
• abort_test_run — Идемпотентно останавливает прерванный прогон, сохраняя принятые частичные результаты и каноническую сводку.

Поведение квоты: повторите start_test_plan с тем же external_run_id, чтобы возобновить соответствующий прогон без расходования дополнительного прогона. Удаление данных не сбрасывает ежемесячное использование прогонов.

Граница выполнения: снимки случаев исключают учетные данные, тела файлов и частные пути вложений. Доказательства результатов — текст в MVP. Целевые учетные данные остаются в среде выполнения. Затраты на браузер, модель и сеть остаются на стороне клиента, и клиенты должны ограничивать целевой доступ и исходящий сетевой трафик. Ответственность за решения о дефектах и выпусках остается на человеке.

Руководство по Hermes Agent упаковывает этот цикл как поддерживаемое сообществом умение bugAgent. Публичный стартовый набор содержит готовую конфигурацию и устанавливаемое умение. Это не официальная интеграция Nous Research.

Отчеты (аналитика Tier 1 + Tier 4)

• get_test_reports_overview — Ключевые показатели для окна (процент прохождения, завершенные прогоны, выполненные случаи) с дельтами относительно предыдущего эквивалентного окна. Те же числа, что показывает полоса KPI на вкладке «Отчеты». Это не создает сохраненный проектный отчет. Корпоративные XLSX-отчеты проектов и их расписания управляются на панели управления; в этом выпуске для этих сохраненных артефактов не включен ни один инструмент MCP.
• get_test_reports_failures — Четыре списка «что исправить?»: failing_cases (≥50% неудач, минимум 3 прогона), flaky_cases (наибольшее количество переключений пройдено/не пройдено), failing_suites (≥30% неудач, минимум 5 прогонов), regressed_cases (самая последняя неудача с более ранним прохождением в окне).

Пример рабочего процесса

1. create_test_case_folder → создайте дерево папок (например, Smoke → Auth). Используйте возвращенный идентификатор папки при создании тестового случая в том же проекте; форма «Новый тестовый случай» на панели управления также предлагает встроенное создание папок.
2. create_test_case → определите случаи; редактируйте содержимое с помощью update_test_case, организуйте членство в наборах с помощью bulk_update_test_cases
3. Пример инструментов/вызовов: {"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}}. Пропущенные приоритет, тип и описание остаются без изменений.
4. create_test_suite → создайте тестовый план (под-наборы необязательны, до 3 уровней глубины)
5. create_test_run → создайте прогон, управляемый человеком/панелью управления, из родительского набора — под-наборы включаются автоматически
6. start_test_plan → запустите или возобновите безопасный для повторных попыток прогон внешнего агента
7. get_test_run_plan → получите каждую неизменяемую страницу плана, затем выполните его в выбранной среде
8. report_test_results → возвращайте ограниченные пакеты результатов; вызовите abort_test_run, если выполнение не может безопасно продолжаться
9. get_test_reports_failures → спросите «что исправить на этой неделе?», когда прогон завершится
10. get_test_reports_overview → отслеживайте тенденцию процента прохождения неделя за неделей

⚡

Усиление команды

• scale_team — Мгновенно масштабируйте свою команду QA с помощью бустерных тестировщиков. Учетные записи предоставляются автоматически с доступом тестировщика. Укажите team_size (1–10), location, duration, budget и, необязательно, product_url, product_types и tech_levels. Доступно на тарифном плане Enterprise. Плата не взимается до получения одобрения.

Пример рабочего процесса

1. scale_team → предоставьте 5 старших тестировщиков в США на 1 месяц
2. list_team_members → убедитесь, что новые тестировщики появились в вашей команде
3. list_bug_reports → просмотрите отчеты, поданные бустерными тестировщиками

📱

Мобильное тестирование (Enterprise)

Мобильные ресурсы ограничены проектом. Передайте project_id или гибкий селектор project при создании, импорте и фильтрованных списках. Автоматизации наследуют проект связанного приложения; в противном случае сервер использует проект рабочей области по умолчанию. Нефильтрованные списки могут по-прежнему включать устаревшие строки уровня рабочей области, пока они не будут перенесены.

• list_mobile_apps — Список загруженных приложений с необязательными фильтрами project_id / project, platform и limit. Возвращает project_id каждого приложения, чтобы агенты могли выполнять последующие операции в том же проекте.
• upload_mobile_app — Регистрация приложения APK (Android) или IPA (iOS) для тестирования на реальных устройствах. Требует name, platform (android / ios) и file_url; передайте project_id, чтобы назначить его активному проекту. Для iOS загрузите IPA для запусков на реальных устройствах, затем используйте панель управления для загрузки сборки .app симулятора для записи.
• update_mobile_app — Замена бинарного файла приложения новой версией. Очищает кэшированные URL-адреса и сборки симулятора, чтобы все автоматизации использовали новую версию при следующем запуске. Требует app_id и file_url. Необязательно: version. Приватные связанные профили входа требуют их активного создателя; общие профили требуют активного доступа к тому же проекту. Расписания наследуют защищённое значение по умолчанию автоматизации.
• list_mobile_automations — Список мобильных автоматизаций с необязательными фильтрами project_id / project, app_id, status и limit. Результаты включают project_id и связанный идентификатор приложения.
• create_mobile_automation — Создание тестового скрипта. Требует name, app_id, script_type (maestro для YAML, appium для Appium Python, appium_js для Appium JavaScript) и script; передайте project_id, если приложение ещё не привязано к проекту. Для одного внешне проверенного автономного YAML-потока Maestro установите execution_mode в browserstack_maestro; в противном случае по умолчанию используется appium_actions. YAML appId должен соответствовать сохранённому пакету или идентификатору bundle связанного приложения; если ничего не сохранено, первый проверенный нативный поток устанавливает его. Идентификаторы приложений-заглушек и обфусцированные идентификаторы ресурсов Android отклоняются. Встроенный runFlow поддерживается, но внешние ссылки на файлы потоков/скриптов отклоняются в v1. Нативный Maestro сохраняет такие команды, как inputRandomText и copyTextFrom, а также выражения времени выполнения, такие как ${maestro.copiedText} и ${output.value}. credential_id того же проекта может предоставить полные значения inputText для ${USERNAME} / ${PASSWORD}. variable_profile_id того же проекта может сохранить значение по умолчанию для указанных значений ${DATA_*}; каждый указанный ключ должен существовать. Профили данных содержат только несекретные синтетические данные.
• import_mobile_script — Импорт существующего мобильного тестового скрипта и превращение его в исполняемую автоматизацию с сохранением собственных локаторов разработчика, чтобы запуски точно разрешали элементы. Поддерживаемые диалекты: Appium‑Python, WebdriverIO, Maestro (YAML-потоки) и Playwright (мобильный веб). Обфусцированные заполнители идентификаторов ресурсов Android пропускаются и сообщаются в warnings сопоставления селекторов. Только для приложений Android. Требует name, app_id и script; необязательно target_devices и project_id. Возвращает автоматизацию, а также action_count, обнаруженные dialect и warnings сопоставления селекторов.
• run_mobile_automation — Запуск мобильной автоматизации на реальном устройстве. Требует automation_id; необязательно device, os_version, credential_id и нативный Maestro variable_profile_id. Для данных опустите variable_profile_id, чтобы унаследовать значение по умолчанию автоматизации, передайте null, чтобы не использовать профиль, или передайте UUID того же проекта для переопределения. Каждый указанный ключ ${DATA_*} должен существовать. Приватный профиль входа требует его активного создателя; общий профиль входа требует активного доступа к тому же проекту. Точные известные значения учётных данных фильтруются, а точные значения профилей данных получают фильтрацию по мере возможности из сохранённых текстовых свидетельств; преобразованные, частичные, закодированные или производные от приложения значения данных могут остаться. Авторизованные приватные видео/скриншоты остаются доступными и могут показывать значения, отображаемые тестируемым приложением, поэтому профили данных должны содержать только синтетические несекретные значения. Если контекст редактирования учётных данных недоступен или безопасность санитизации не может быть доказана, подробный текст с учётными данными скрывается, при этом статус и доступные визуальные свидетельства остаются. Диагностика требует авторизации рабочего пространства и проекта; ссылки на медиа истекают через пять минут.
• list_mobile_runs — Получение авторизованных результатов мобильных запусков (статус, устройство, сводка результатов, приватные ссылки на видео и скриншоты, сессия BrowserStack, отфильтрованные нативные журналы Maestro с учётными данными и сбои, когда это безопасно доступно, а также любые автоматически созданные ошибки). Членство в рабочем пространстве и доступ к проекту обязательны для диагностики запусков. Необязательные фильтры: project_id, automation_id, status (queued, running, passed, failed, error, archived) и limit. Архивные запуски исключаются по умолчанию.
• create_login_profile — Создание профиля имени пользователя/пароля только для записи с шифрованием, пригодного для Mobile, Web Automation и Exploratory AI. Требует project_id, name, username и password; необязательный visibility — это private (по умолчанию) или shared. Приватные профили доступны только создателю. Общие профили доступны активным участникам с доступом к тому же проекту.
• create_mobile_credential — Совместимое имя для create_login_profile; использует те же входные данные и границы безопасности.
• list_login_profiles — Список только профилей, видимых вызывающему, необязательно для одного project_id. Возвращает несекретные метаданные, включая visibility; приватные профили, принадлежащие другим пользователям, и недоступные проекты опускаются.
• list_mobile_credentials — Совместимое имя для list_login_profiles; никогда не возвращает секреты учётных данных.
• update_login_profile — Переименование, ротация или изменение visibility. Активный создатель может обновить любое поле. Активный владелец/администратор рабочего пространства может переименовать или ротировать общий профиль, но не может изменить видимость; приватные профили остаются доступными только создателю.
• update_mobile_credential — Совместимое имя для update_login_profile; использует те же проверки владения и проекта.
• delete_login_profile — Мягкое удаление создателем, с возможностью восстановления жизненного цикла владельцем/администратором только для общих профилей. Значения по умолчанию для будущего использования очищаются, при этом история аудита сохраняется.
• delete_mobile_credential — Совместимое имя для delete_login_profile; исторические ссылки остаются для аудита.
• create_mobile_variable_profile — Создание повторно используемых, привязанных к проекту синтетических тестовых данных с project_id, name и объектом variables, таким как {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Ключи должны быть идентификаторами DATA_* в верхнем регистре. Профили допускают 1–100 строк, 4096 байт UTF-8 на значение и 65536 байт всего. Зарезервированные имена учётных данных/времени выполнения отклоняются. Никогда не храните учётные данные, токены, производственные персональные данные или другие секреты.
• list_mobile_variable_profiles — Список профилей Mobile/Both и их читаемых несекретных значений для одного авторизованного project_id. Применяются правила назначения проектов. Существующие профили и мобильное создание по умолчанию используют both; создание/обновление принимает platform (mobile или both). Веб-профили исключаются из мобильного каталога и использования во время выполнения.
• update_mobile_variable_profile — Переименование профиля или замена его полного объекта variables по id. Только активный создатель или активный владелец/администратор рабочего пространства может обновить его.
• delete_mobile_variable_profile — Мягкое удаление профиля по id. Только активный создатель или активный владелец/администратор рабочего пространства может удалить его; значения по умолчанию автоматизации очищаются, при этом исторические ссылки на запуски остаются.
• list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Список, создание и удаление расписаний реальных устройств. Расписания наследуют контекст проекта, профиль входа и несекретный профиль переменных от выбранной автоматизации. Приватные профили входа требуют их активного создателя; общие профили входа требуют активного доступа к тому же проекту. Несекретные профили переменных сохраняют политику создателя-или-владельца/администратора. Изменения и удаление расписаний ограничены активным создателем расписания или активным владельцем/администратором рабочего пространства.

Каталог веб-тестовых данных

Тот же несекретный каталог проекта доступен из Automate Web. Эти инструменты требуют права automation рабочего пространства и области automations:write API-ключа, включая чтение. Они не требуют доступа Mobile. Значения никогда не разделяют записи с зашифрованными профилями входа. Поддержка каталога ещё не связывает и не внедряет значения профилей в веб-запуски.

• create_web_variable_profile: требуется project_id, name, variables; необязательно platform (web или both), по умолчанию web. Использует те же ограничения DATA_*, что и мобильный. Возвращает профиль, включая его platform.
• list_web_variable_profiles: требуется project_id; возвращает { profiles: [...] }, содержащий только записи Web/Both.
• get_web_variable_profile: требуется id; возвращает доступный профиль Web/Both и его синтетические значения.
• update_web_variable_profile: требуется id; необязательно name, полная замена variables или platform (web или both). Требует активного создателя или активного владельца/администратора рабочего пространства. Чтобы сузить Both до Mobile, используйте мобильный каталог с доступом Mobile.
• delete_web_variable_profile: требуется id; те же права управления. Мягко удаляет и возвращает { deleted: true }, сохраняя историю аудита.

Пример: разрешите проект с помощью list_projects, вызовите create_web_variable_profile с {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}}, затем проверьте его с помощью list_web_variable_profiles. Недоступные проекты/профили завершаются ошибкой без раскрытия их значений; недопустимые данные или дублирующиеся имена в рамках проекта отклоняются.

Пример рабочего процесса — Android

1. list_projects → разрешите целевой project_id
2. upload_mobile_app → зарегистрируйте APK в этом проекте
3. Запишите безопасно в панели управления или используйте import_mobile_script / create_mobile_automation
4. list_mobile_automations → разрешите автоматизацию в том же проекте
5. run_mobile_automation → запустите её на реальном устройстве, необязательно с профилем входа
6. list_mobile_runs → проверьте статус, сводку результатов, приватные визуальные ссылки и метаданные сессии BrowserStack
7. Сбои автоматически создают отчёты об ошибках со снимком сбоя и разбивкой по шагам

Пример рабочего процесса — iOS

1. upload_mobile_app → зарегистрируйте ваш IPA с project_id для запусков на реальных устройствах
2. Загрузите сборку симулятора .app на странице сведений о приложении (для записи)
3. Запишите тест в браузере → действия захватываются из симулятора
4. run_mobile_automation → запустите сохранённую автоматизацию на iPhone (использует IPA)
5. update_mobile_app → замените IPA новой версией, когда будет готово

Пример рабочего процесса — Native Maestro

1. upload_mobile_app → зарегистрируйте APK или IPA в целевом проекте
2. create_mobile_credential → необязательно создайте профиль того же проекта для аутентифицированного потока
3. create_mobile_variable_profile → необязательно создайте синтетические значения DATA_* того же проекта, используемые потоком
4. create_mobile_automation → передайте один известный рабочий YAML-поток с точным пакетом/bundle appId связанного приложения, script_type: maestro и execution_mode: browserstack_maestro. Используйте ${USERNAME} / ${PASSWORD} для входа и заполнители в стиле ${DATA_EMAIL} для синтетического ввода; передайте идентификаторы профилей, чтобы сохранить значения по умолчанию.
5. run_mobile_automation → выберите совместимое устройство и необязательно переопределите профиль входа или переменных. Опустите профиль переменных, чтобы унаследовать, или передайте null, чтобы отключить его для одного запуска.
6. list_mobile_runs → проверьте авторизованные сводки прохождения/непрохождения, приватные видео/скриншоты, отфильтрованные журналы, реальные имена шагов, подробные сбои и метаданные сессии. Если безопасная санитизация не может быть установлена для запуска с учётными данными, подробный текст скрывается, при этом статус и доступные визуальные свидетельства остаются.

Уточнение с помощью AI: разрешённая бета-версия доступна через панель управления и конечные точки REST для уточнения. Инструменты Refine MCP не являются частью публичного каталога.

✅

Соответствие требованиям и доказательства (Enterprise)

• collect_compliance_evidence — Запуск автоматического сбора доказательств из подключенных сервисов (Cloudflare, GitHub, Sentry, Supabase, Railway). Возвращает ID запуска. Собирает настройки SSL/TLS, статус WAF, оповещения Dependabot, тенденции ошибок, историю развертываний и многое другое.
• check_config_drift — Проверка всех подключенных сервисов на отклонение конфигурации безопасности от базовых показателей (режим SSL, версия TLS, HSTS, правила WAF, заголовки безопасности).
• generate_access_review — Создание ежеквартального отчета о проверке доступа. Аудит членов команды, ролей, статуса MFA, использования ключей API и формирование рекомендаций (например, отзыв неактивных ключей).
• get_security_events — Запрос к межсервисной временной шкале событий безопасности. Фильтрация по источнику (cloudflare, sentry, github) и уровню серьезности (critical, high, medium, low, info). События автоматически коррелируются между сервисами.

Покрытие соответствия

Эти инструменты помогают выполнить требования 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) и GDPR (ст. 5, 25, 32, 33).

Совместимые клиенты

bug Agent работает с любым клиентом, поддерживающим Model Context Protocol. Вот руководства по настройке для популярных клиентов:

Откройте Settings → Developer → Edit Config, затем добавьте:

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

Перезапустите Claude Desktop после сохранения.

✳️

Cursor

Откройте Settings → MCP Servers → Add Server или отредактируйте .cursor/mcp.json в корне вашего проекта:

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

🌊

Windsurf

Откройте Settings → MCP → Add Server или отредактируйте файл конфигурации MCP:

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

Добавьте bug Agent напрямую из терминала:

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

Это подключается напрямую к размещенному Streamable HTTP серверу.

Для клиентов, требующих stdio, используйте опубликованный мост bugagent-mcp:

• Команда: npx
• Командная строка: npx -y bugagent-mcp
• Аргументы: ["-y", "bugagent-mcp"]
• Переменные окружения: BUGAGENT_API_KEY

Получить помощь

Нужна помощь? Мы здесь, чтобы помочь.

Discord Community

Присоединяйтесь к нашему Discord для поддержки в реальном времени и обсуждений в сообществе.

Email Support

support@bugagent.com — Обычно мы отвечаем в течение 24 часов.