Debugg AI

Debugg AI — MCP Server

AI-управляемое тестирование браузера через Model Context Protocol. Укажите любой URL (или localhost) и опишите, что нужно протестировать — AI-агент просматривает ваше приложение и возвращает результат «пройдено/не пройдено» со скриншотами.

Настройка

Требуется Node.js 20.20.0 или новее (транзитивное требование от posthog-node@^5.26.0).

Для тестирования URL-адресов http://localhost:... требуется бинарный файл caddy — check_app_in_browser, probe_page и trigger_crawl туннелируют локальные цели через локальный обратный прокси Caddy. Это устанавливается автоматически: npm-зависимость @radically-straightforward/caddy загружает закреплённый релиз Caddy для вашей платформы во время npm install/npx, так же, как этот проект уже делает для бинарного файла ngrok — в обычном случае ничего устанавливать самостоятельно не нужно. Если эта загрузка никогда не выполнялась (npm install --ignore-scripts, офлайн/изолированная установка), укажите CADDY_BIN на свою собственную установку (brew install caddy / apt install caddy / см. caddyserver.com/docs/install) — при её отсутствии появится понятная ошибка при первом вызове localhost-URL, а не тихое зависание. Вызовы публичных URL, все инструменты, не связанные с браузером, и test_suite {action:"run"} (который использует собственный выделенный туннель и полностью обходит Caddy) в любом случае не требуют этого.

Получите API-ключ на debugg.ai, затем добавьте в конфигурацию вашего MCP-клиента:

{
  "mcpServers": {
    "debugg-ai": {
      "command": "npx",
      "args": ["-y", "@debugg-ai/debugg-ai-mcp"],
      "env": {
        "DEBUGGAI_API_KEY": "your_api_key_here"
      }
    }
  }
}

Или с Docker:

docker run -i --rm --init -e DEBUGGAI_API_KEY=your_api_key quinnosha/debugg-ai-mcp

Шаг npm install в Dockerfile в принципе подхватил бы caddy тем же автоматическим способом, что и локальные установки — но на момент написания Dockerfile не COPY несколько каталогов, которые теперь нужны для сборки (handlers, tools, types, config), и по-прежнему ссылается на каталог tunnels/, которого больше не существует, поэтому свежая сборка, скорее всего, завершится ошибкой раньше, чем это станет актуально. Это существующий пробел, не связанный с Caddy. Текущий опубликованный образ quinnosha/debugg-ai-mcp в любом случае предшествует зависимости от Caddy — вызовы localhost-URL к check_app_in_browser/probe_page/trigger_crawl будут завершаться ошибкой CaddyBinaryNotFoundError внутри этого образа, пока он не будет пересобран (исправлен Dockerfile) и переиздан, или CADDY_BIN не будет указывать на отдельно встроенный. Вызовы публичных URL, инструменты, не связанные с браузером, и test_suite {action:"run"} в любом случае не затрагиваются.

Инструменты

Сервер предоставляет 8 инструментов: три браузерных инструмента плюс один основанный на действиях инструмент для каждой управляемой сущности. Ключевые инструменты — check_app_in_browser (полноценный AI-агент) и probe_page (лёгкий зонд страниц без LLM). Остальные — project, environment, test_suite, test_case, executions — каждый принимает дискриминатор action (например, {"action":"list"}), который выбирает операцию. Деструктивные действия delete требуют подтверждения (запрос уточнения там, где это поддерживается, в противном случае confirm: true).

Браузер

check_app_in_browser

Запускает AI-браузерного агента против вашего приложения. Агент перемещается, взаимодействует и сообщает результаты со скриншотами. URL-адреса localhost автоматически туннелируются через ngrok.

Параметр	Тип	Описание
description	строка обязательно	Что тестировать (естественный язык)
url	строка обязательно	Целевой URL — http://localhost:3000 автоматически туннелируется
environmentId	строка	UUID конкретной среды
credentialId	строка	UUID конкретных учётных данных
credentialRole	строка	Выбор учётных данных по роли (например, admin, guest)
username	строка	Имя пользователя для входа (временное — не сохраняется)
password	строка	Пароль для входа (временный — не сохраняется)
loginCredentials	массив	Учётные записи для входов, которые агент встречает во время задачи — [{username, password, label?}]
useEnvironmentCredentials	логический	По умолчанию true. false запрещает автоматическое заполнение сохранённых учётных данных среды; без указанной учётной записи это означает вообще не входить в систему
freshSession	логический	По умолчанию false. true принудительно выполняет реальный вход вместо повторного использования тёплой сессии, хранящейся для этой учётной записи
auth	объект	Предусловие аутентификации — {precondition, entryUrl, deepUrl, environmentId, username, password}
repoName	строка	Переопределение автоматически определённого имени git-репозитория (например, my-org/my-repo)

Одна сфокусированная проверка за вызов. У агента есть внутренний бюджет примерно в 25 шагов; разбивайте более широкие наборы проверок на несколько вызовов.

Учётные данные: передавайте их как параметры, а не в тексте

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

• username / password (или credentialId / credentialRole) — идентичность запуска.
• auth.username / auth.password — закрепляет предусловный вход, когда вы также используете auth.precondition: "login".
• loginCredentials — учётные записи для формы входа, которую агент достигает в середине задачи. Это то, что нужно для сценариев вроде установить пароль → перенаправление на вход → войти как только что созданная учётная запись, где разделение на отдельные вызовы потеряло бы состояние браузера.

Установите useEnvironmentCredentials: false, когда тихий возврат к тестовому пользователю по умолчанию сделал бы проверку недействительной.

Проверяете страницу, которая вообще не требует входа? Передайте useEnvironmentCredentials: false и не указывайте ни одной учётной записи. Эта комбинация означает ровно то, что говорит — не входить в систему — и запуск полностью пропускает аутентификацию вместо поиска формы входа. Используйте это для публичных страниц, маркетинговых сайтов, документации и всего, что находится до аутентификации. Это также быстрее: по умолчанию (auto) агент перейдёт по ссылке «Войти» с вашей страницы и попробует сохранённую учётную запись среды, прежде чем что-либо оценивать.

Повторное использование сессии: почему проверка может сообщить «нет формы входа»

Запуски не входят в систему каждый раз. После подтверждённого входа бэкенд захватывает сессию этой учётной записи и восстанавливает её при следующем запуске для той же идентичности, что полностью пропускает вход — именно поэтому проверка может обоснованно вернуться с submitted: false и без формы входа: она уже была выполнена. Восстановленный запуск сообщает о себе в logins с reason: "restored_session", так что вы можете отличить его от запуска, который действительно не нашёл форму.

Сессии привязаны к каждой учётной записи, поэтому указание другой учётной записи никогда не использует чужую. Два способа обойти повторное использование:

• freshSession: true в одном вызове — выполнить реальный вход на этот раз, затем повторно захватить. Используйте, когда проверяете именно процесс входа, когда подозреваете, что сохранённая сессия устарела, или когда единственный путь приложения между персонами — выход из системы.
• Инструмент environment, action: "clearSessions" — аннулировать сохранённые сессии, чтобы последующие запуски выполняли вход. Сузьте с помощью username / credentialId; неограниченные очистки требуют подтверждения, потому что каждая учётная запись в среде затем повторно аутентифицируется.

Используйте action: "sessions", чтобы увидеть, что среда в данный момент хранит и будет ли каждая сессия повторно использована.

Результаты сообщают фактически использованную идентичность, поэтому неправильная видна, а не маскируется под сломанное приложение:

"logins": [
  { "username": "qa+invitefix@example.com", "source": "task", "submitted": true, "authenticated": true }
],
"credentialWarning": {
  "requested": "qa+invitefix@example.com",
  "used": ["qatest123@example.com"],
  "message": "This run signed in with an environment default credential even though '…' was specified. …"
}

source — это task | explicit | credential_id (учётная запись, которую вы указали) или env | env_default (сохранённая учётная запись среды). credentialWarning появляется только тогда, когда вы указали учётную запись, но всё равно было использовано значение по умолчанию среды. loginError появляется, когда указанную учётную запись не удалось разрешить, и запуск отказался подставлять другую.

Каждый успешный запуск возвращает блок browserSession вместе со скриншотом — предварительно подписанные URL-адреса S3 для захваченного HAR (полный сетевой трафик) и журнала консоли (все сообщения JS-консоли). Используйте их для обнаружения циклов повторной загрузки, ошибок гидратации и других проблем времени выполнения, которые проходят проверки типов и модульные тесты:

"browserSession": {
  "harUrl": "https://...session_18139.har?X-Amz-...",
  "consoleLogUrl": "https://...session_18139_console.json?X-Amz-...",
  "recordingUrl": "https://...session_18139_recording.webm?X-Amz-...",
  "harStatus": "downloaded",
  "consoleLogStatus": "downloaded",
  "harRedactionStatus": "redacted",
  "consoleLogRedactionStatus": "redacted"
}

URL-адреса — это кратковременные предварительно подписанные S3 — повторно получите родительское выполнение через executions {action:"get", uuid}, чтобы обновить. harStatus / consoleLogStatus различают 'downloaded' (URL доступен для получения), 'not_available' (страница ничего не выдала), 'failed' (захват сломался). При новом запуске URL-адреса обычно null, потому что захват загружается асинхронно после завершения агента — опрашивайте executions {action:"get", uuid: executionId}, пока статус не достигнет 'downloaded'. Заголовки Authorization / Cookie / token/secret/api_key очищаются на стороне сервера перед сохранением артефактов.

trigger_crawl

Запускает серверный обход браузерного агента для заполнения графа знаний проекта. URL-адреса localhost туннелируются автоматически. Возвращает {executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?} с knowledgeGraph.imported === true при успешной загрузке. Блок browserSession (URL-адреса HAR + журнала консоли, той же формы, что и выше) также присутствует в завершённых обходах.

probe_page

Лёгкий пакетный зонд страниц без LLM. Передайте 1–20 URL-адресов; каждый переходит, дожидается стабилизации контента (DOM затихает, с ограничением — никогда не по сетевой тишине, которой живой сайт не достигает) и возвращает отрисованное состояние — скриншот + метаданные страницы + структурированные ошибки консоли + сводку по сети. Нет цикла агента, нет затрат на LLM, нет проверок сценариев. Используйте для «я только что сломал /settings?», много-маршрутных проверок после рефакторинга, прогонов CI на каждый PR и быстрых проверок доступности, где цикл агента check_app_in_browser на 60–150 секунд избыточен.

Параметр	Тип	Описание
targets	массив обязательно	1–20 записей: [{url, waitForSelector?, waitForLoadState?, timeoutMs?}]
targets[].url	строка обязательно	Публичный URL или localhost (автоматически туннелируется)
targets[].waitForLoadState	перечисление	'domcontentloaded' (по умолчанию, + ограниченное ожидание стабилизации контента) / 'load' (также ожидает сторонние встраивания) / 'networkidle' (принято, никогда не выдаётся — сеть живого сайта не переходит в состояние простоя)
targets[].waitForSelector	строка	Необязательный CSS-селектор для ожидания после навигации
targets[].timeoutMs	число	Тайм-аут на URL, 1000–30000 (по умолчанию 10000)
includeHtml	логический	Возвращать необработанный HTML в каждом результате (по умолчанию false)
captureScreenshots	логический	Возвращать один PNG на цель (по умолчанию true)

Все цели в пакете используют один общий туннель сессии, но только пакеты с одним портом (или все публичные) используют одно бэкенд-выполнение — 5 URL-адресов на одном порту в одном вызове значительно быстрее, чем 5 параллельных вызовов по одному URL. Пакет, смешивающий несколько локальных портов, разбивается на одно последовательное бэкенд-выполнение на группу портов (по-прежнему один вызов, по-прежнему один объединённый results[] в вашем исходном порядке, но N бэкенд-циклов вместо одного — медленнее, но не отклоняется). Поле error на URL сохраняет устойчивость пакета: одна неудачная цель не приводит к сбою остальных.

Ключ агрегации networkSummary — это origin + pathname — циклы повторной загрузки (?n=0..4 многократно обращающийся к одной и той же конечной точке) схлопываются в одну запись с количеством, поэтому появление /api/poll с count: 47 — это действенный сигнал «бесконечного цикла повторной загрузки», который пользователи изначально просили.

Бюджет производительности: <10 с для 1 URL, <25 с для 20. Мёртвый порт localhost возвращает LocalServerUnreachable за <2 с без затрат выполнения рабочего процесса.

project

Действие	Параметры	Результат
get	{uuid}	Подробная информация о проекте
list	{q?, page?, pageSize?}	Постраничные сводки
create	{name, platform, (teamUuid|teamName), (repoUuid|repoName)}	Созданный проект

Команда и репозиторий определяются либо по uuid, либо по имени (точное совпадение без учёта регистра; NotFound, если ни одного, AmbiguousMatch, если несколько). Нет update/delete — переименуйте или удалите проект в веб-приложении DebuggAI.

environment

Действие	Параметры	Результат
get	{uuid, projectUuid?}	Окружение с встроенными учетными данными (пароли никогда не возвращаются)
list	{projectUuid?, q?, page?, pageSize?}	Постраничные окружения, каждое с массивом учетных данных
create	{name, url, description?, projectUuid?, credentials?}	Созданное окружение (опционально заполняет учетные данные)
update	{uuid, name?, url?, description?, addCredentials?, updateCredentials?, removeCredentialIds?}	Измененное окружение; операции с учетными данными выполняются в порядке удалить → обновить → добавить
delete	{uuid, projectUuid?, confirm?}	Удаляет окружение (каскадно удаляет учетные данные) — требуется подтверждение
sessions	{uuid, username?, credentialId?}	Захваченные сеансы входа, которые хранит окружение, по каждой учетной записи, с isUsable и usableCount
clearSessions	{uuid, username?, credentialId?, confirm?}	Делает их недействительными, чтобы следующий запуск выполнил реальный вход — очистка без области действия требует подтверждения

projectUuid автоматически определяется из git-репозитория, если не указано. Сбои отдельных учетных данных отображаются в credentialWarnings[] без блокировки операции с окружением.

sessions / clearSessions управляют активными аутентифицированными сеансами, которые бэкенд повторно использует для пропуска входа (см. Повторное использование сеансов). Содержимое сеансов никогда не возвращается — cookie сеанса является учетным данным типа bearer. clearSessions помечает сеансы как недействительные, а не удаляет строки, поэтому повторное использование прекращается немедленно, а история захвата остается читаемой.

test_suite

Действие	Параметры	Результат
list	{projectUuid|projectName, search?, page?, pageSize?}	Постраничные наборы тестов со статусом и процентом прохождения
create	{name, description, projectUuid|projectName}	Созданный набор тестов
run	{suiteUuid|(suiteName+project), targetUrl?}	Запускает все тесты асинхронно
results	{suiteUuid|(suiteName+project)}	Набор тестов + результаты по каждому тесту
delete	{suiteUuid|(suiteName+project), confirm?}	Мягкое удаление — требуется подтверждение

test_case

Действие	Параметры	Результат
create	{name, description, agentTaskDescription, suiteUuid|(suiteName+project), relativeUrl?, maxSteps?}	Созданный тестовый сценарий (не запускается автоматически)
update	{testUuid, name?, description?, agentTaskDescription?}	Измененный тестовый сценарий
delete	{testUuid, confirm?}	Мягкое удаление — требуется подтверждение

executions

Действие	Параметры	Результат
get	{uuid}	Полная информация (nodeExecutions + состояние + errorInfo) + артефакты скриншотов/GIF
list	{status?, projectUuid?, page?, pageSize?}	Постраничные сводки

Ошибка 404 от бэкенда отображается как isError: true с {error: 'NotFound', message, uuid}. Учетные данные всегда возвращаются без паролей.

Постраничная выдача

Каждый ответ в режиме фильтра разбит на страницы. Форма ответа:

{
  "filter": { "...echoed query params..." },
  "pageInfo": { "page": 1, "pageSize": 20, "totalCount": 47, "totalPages": 3, "hasMore": true },
  "<items>": [ ... ]
}

Передайте необязательные page (с индексом 1, по умолчанию 1) и pageSize (по умолчанию 20, максимум 200; значения сверх лимита ограничиваются). Ни один ответ никогда не обрезается молча.

Ресурсы

Помимо инструментов, сервер предоставляет доступные только для чтения сущности как MCP ресурсы, чтобы клиенты могли просматривать и упоминать их через @ как контекст:

URI	Что это
debugg-ai://projects	Все проекты (первая страница)
debugg-ai://environments	Окружения для автоматически определенного проекта
debugg-ai://executions	Недавние выполнения (первая страница)
debugg-ai://project/{uuid}	Один проект, полная информация
debugg-ai://environment/{uuid}	Одно окружение (учетные данные встроены, пароли скрыты)
debugg-ai://execution/{uuid}	Одно выполнение, полная информация об узле + ссылки на артефакты

Чтение направляется в те же обработчики, что и инструменты project / environment / executions, поэтому данные и аутентификация идентичны. Ресурсы являются дополнительными — клиенты без поддержки ресурсов продолжают использовать инструменты.

Инварианты безопасности

• Пароли доступны только для записи. Они никогда не появляются в теле ответа ни одного инструмента.
• URL туннелей (*.ngrok.debugg.ai) удаляются из всех ответов браузерного агента, включая текст, созданный агентом.
• Ошибки 404 от бэкенда отображаются как isError: true с {error: 'NotFound', ...}, а не как выброшенные исключения.
• Отсутствие DEBUGGAI_API_KEY отображается как структурированная ошибка инструмента при первом вызове — сервер по-прежнему регистрирует и перечисляет инструменты в обычном режиме.

Миграция на v3.0.0 (инструменты на основе действий)

В v3 20 инструментов с отдельными глаголами объединены в 8 инструментов на основе действий. Старый инструмент → новый tool {action}:

Удаленный	Замена
search_projects	project {action:"get"} / project {action:"list"}
create_project	project {action:"create"}
update_project, delete_project	Удалены — используйте веб-приложение DebuggAI
search_environments	environment {action:"get"} / {action:"list"}
create_environment / update_environment / delete_environment	environment {action:"create"|"update"|"delete"}
create_test_suite / search_test_suites / run_test_suite / get_test_suite_results / delete_test_suite	test_suite {action:"create"|"list"|"run"|"results"|"delete"}
create_test_case / update_test_case / delete_test_case	test_case {action:"create"|"update"|"delete"}
search_executions	executions {action:"get"|"list"}
Параметр trigger_crawl headless	Удален — всегда безголовый режим

Действия delete теперь требуют подтверждения (запрос на уточнение или confirm: true). Клиенты подхватывают новый интерфейс при перезапуске MCP.

Миграция с v1.x (критическое изменение в v2.0.0)

В v2 интерфейс из 22 инструментов сокращен до 11. Сопоставление старый инструмент → новый инструмент:

Удаленный	Замена
list_projects, get_project	search_projects (режим uuid против режима фильтра)
list_environments, get_environment	search_environments
list_credentials, get_credential	search_environments — учетные данные встроены в каждое окружение
create_credential	Начальное значение create_environment({credentials: [...]}) или update_environment({addCredentials: [...]})
update_credential	update_environment({updateCredentials: [{uuid, ...patch}]})
delete_credential	update_environment({removeCredentialIds: [uuid]})
list_teams, list_repos	create_project({teamName, repoName}) — разрешение имен с обработкой неоднозначности
list_executions, get_execution	search_executions
cancel_execution	Удален — остановка бэкенда выполняется автоматически

Изменения формы ответа: поле count в ответах списков удалено — используйте pageInfo.totalCount.

Конфигурация

Переменная окружения	Обязательна	Назначение
DEBUGGAI_API_KEY	да	Ключ API бэкенда. Псевдонимы: DEBUGGAI_API_TOKEN, DEBUGGAI_JWT_TOKEN.
DEBUGGAI_API_URL	нет	Базовый URL бэкенда. По умолчанию https://api.debugg.ai.
DEBUGGAI_TOKEN_TYPE	нет	token (по умолчанию) или bearer.
DEBUGGAI_EVAL_TEMPLATE	нет	Переопределяет slug рабочего процесса App Evaluation, на который отправляет check_app_in_browser. По умолчанию flow/e2es/app-eval. Отправка привязывается к этому slug, чтобы переименование шаблона бэкенда не могло его сломать.
LOG_LEVEL	нет	error / warn / info (по умолчанию) / debug.
POSTHOG_API_KEY	нет	Переопределяет встроенный ключ проекта телеметрии (например, для частного форка).
DEBUGGAI_TELEMETRY_DISABLED	нет	Установите в 1 / true / yes / on, чтобы полностью отключить телеметрию.

DEBUGGAI_API_KEY=your_api_key

Удаленный / HTTP транспорт (опционально)

По умолчанию сервер использует stdio (локальный npx). Он также может работать как размещенный многопользовательский удаленный MCP через stateless Streamable HTTP + OAuth:

DEBUGGAI_MCP_TRANSPORT=http PORT=3000 DEBUGGAI_TOKEN_TYPE=bearer npx -y @debugg-ai/debugg-ai-mcp@latest

Это OAuth Resource Server: каждый POST /mcp требует Authorization: Bearer <token>; отсутствующие/недействительные токены получают 401 с WWW-Authenticate, указывающим на метаданные RFC 9728, и клиенты выполняют OAuth поток против объявленного сервера авторизации. Bearer-токен ограничен запросом — api.debugg.ai проверяет его.

Конечная точка	Назначение
POST /mcp	MCP Streamable HTTP (защищено bearer-токеном)
GET /.well-known/oauth-protected-resource	Метаданные RFC 9728 (обнаружение сервера авторизации)
GET /health	Проверка работоспособности балансировщика / ECS

Переменная окружения	По умолчанию	Назначение
DEBUGGAI_MCP_TRANSPORT	stdio	Установите в http для удаленного транспорта
PORT	3000	Порт прослушивания HTTP
DEBUGGAI_MCP_PUBLIC_URL	https://mcp.debugg.ai	Публичный URL ресурса этого сервера (RFC 9728 resource)
DEBUGGAI_OAUTH_ISSUER	https://auth.debugg.ai	Сервер авторизации, объявляемый клиентам
DEBUGGAI_TOKEN_TYPE	token	Установите в bearer, чтобы OAuth-токены передавались как Authorization: Bearer

Установки через stdio не требуют ничего из этого.

Мультирепличные развертывания (go/no-go перед развертыванием): состояние туннеля (сеансовый туннель ngrok, его экземпляр Caddy и его блокировка портового маршрута) находится в процессе, привязано к каждому вызывающему по хешу bearer-токена — нет межпроцессной координации. Запуск нескольких реплик за простым балансировщиком round-robin означает, что вызовы одного вызывающего могут попадать на разные реплики и создавать один туннель на каждую затронутую реплику вместо одного на весь сеанс (дополнительные затраты ngrok, ограниченные числом реплик, самовосстановление через существующее автоматическое отключение после 55 минут простоя — никогда не является ошибкой корректности между сеансами, поскольку любой отдельный вызов инструмента остается на одной реплике на всю свою длительность). Чтобы получить ожидаемое поведение «один туннель на сеанс» в мультирепличном HTTP-развертывании, настройте маршрутизацию, привязанную к сеансу на балансировщике (липкая/консистентная хеш-маршрутизация по той же идентичности, которую выводит getSessionKey() — на практике, bearer-токен вызывающего Authorization). См. docs/local-tunnel-multiplexer-architecture-2026-07-31.md §2.1 для полного обоснования и честного пути деградации, если это не настроено.

Телеметрия

MCP-сервер поставляется с включенной по умолчанию телеметрией — встроенный ключ проекта PostHog только для записи (phc_*), чтобы команда могла наблюдать за частотой попаданий в кэш, частотой опросов, надежностью туннелей и другими операционными метриками по всей установленной базе. Захватываемые события:

Событие	Когда
tool.executed / tool.failed	На каждый вызов инструмента
workflow.executed	На каждое выполнение браузерного агента (несет pollCount, durationMs, finalIntervalMs)
tunnel.provisioned / tunnel.provision_retry / tunnel.stopped	На каждое событие жизненного цикла туннеля
template.lookup / project.lookup	Попадание/промах в кэше с durationMs при холодном вызове

Политика конфиденциальности:

• Отдельный идентификатор — это SHA-256(api_key).slice(0, 16) — никогда не сырой ключ, без PII.
• Ключи phc_* доступны только для записи по соглашению PostHog; безопасно встраивать в исходный код.
• Установите DEBUGGAI_TELEMETRY_DISABLED=1, чтобы полностью отказаться (разрешается в провайдер-заглушку; никакие события не покидают процесс).

Активный режим регистрируется при запуске:

Telemetry enabled (PostHog, DebuggAI default project). Set DEBUGGAI_TELEMETRY_DISABLED=1 to opt out.
Telemetry enabled (PostHog, custom POSTHOG_API_KEY)
Telemetry disabled (DEBUGGAI_TELEMETRY_DISABLED is set)

Локальная разработка

npm install
npm run build
npm run test:e2e        # real end-to-end evals against the backend

Набор для оценки запускает собранный MCP-сервер как подпроцесс, проверяет каждый инструмент против реального бэкенда и записывает артефакты каждого потока в scripts/evals/artifacts/<timestamp>/. См. scripts/evals/flows/ для отдельных сценариев.

Регистрация MCP: debugg-ai-local против debugg-ai

Этот репозиторий содержит .mcp.json, который регистрирует сервер в области проекта с именем debugg-ai-local, указывающий на node dist/index.js — только что собранный локальный код. Он активируется только когда рабочая директория Claude Code — этот репозиторий.

Ваши другие проекты должны использовать регистрацию в области пользователя debugg-ai, которая берет код из опубликованного npm-пакета:

npm run mcp:global      # registers debugg-ai in ~/.claude.json to npx -y @debugg-ai/debugg-ai-mcp

После редактирования кода здесь запустите npm run mcp:local (который просто пересобирает), чтобы следующий вызов debugg-ai-local подхватил ваши изменения.

Ссылки

Дашборд · Документация · Проблемы · Discord

---

Лицензия Apache-2.0 © 2025 DebuggAI