Debugg AI
公式コード生成エージェントが、Debugg AIテストプラットフォームを介してリモートブラウザ上で新しいコード変更に対する0設定のエンドツーエンドテストを作成・実行できるようにします。
Debugg AI MCPで何ができますか？
- AIブラウザテストを実行 — アシスタントに
check_app_in_browserを任意のURLまたはlocalhostに対して実行するよう依頼し、テスト内容を自然言語で記述すると、スクリーンショット付きで合格/不合格の結果が得られます。 - 複数ページを素早く調査 —
probe_pageを使用して1〜20個のURLを一括チェックし、コンソールエラー、ネットワーク問題、レンダリング状態をLLMコストやエージェントループなしで確認できます。 - ナレッジグラフクロールをトリガー —
trigger_crawlを呼び出してサーバーサイドのブラウザエージェントクロールを実行し、HARおよびコンソールログの成果物でプロジェクトのナレッジグラフを構築します。 - テストスイートとテストケースを管理 —
test_suiteおよびtest_caseエンティティを作成、実行、結果を確認し、テストごとの結果と合格率を取得します。 - 実行成果物を検査 —
executionsを介してスクリーンショット、HARネットワークトレース、コンソールログを含む完全な実行詳細を取得し、ランタイムの問題をデバッグします。 - 環境とセッションを管理 —
environmentを使用して認証情報付きの環境を作成または更新し、sessions/clearSessionsを使用してウォームログインセッションの再利用を制御します。
ドキュメント
Debugg AI — MCP Server
AIを活用したブラウザテストを、Model Context Protocol経由で実現します。任意のURL（またはlocalhost）を指定してテスト内容を記述するだけで、AIエージェントがアプリを操作し、スクリーンショット付きで合格/不合格を返します。
セットアップ
Node.js 20.20.0以降が必要です（posthog-node@^5.26.0からの推移的な要件）。
http://localhost:... URLのテストにはcaddyバイナリが必要です — check_app_in_browser、
probe_page、およびtrigger_crawlは、ローカルのCaddyリバースプロキシを通じてlocalhostターゲットをトンネリングします。
これは自動的にインストールされます：@radically-straightforward/caddy npm依存関係が
プラットフォームに応じた固定バージョンの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を完全にバイパスします）は、いずれの場合もこれを必要としません。
debugg.aiでAPIキーを取得し、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
Dockerfileのnpm installステップは、原則としてローカルインストールと同じ自動的な方法でcaddyを取得します — ただし、本稿執筆時点ではDockerfileは
ビルドに必要な複数のディレクトリ（handlers、tools、types、config）をCOPYしておらず、
もはや存在しない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つのツールを公開しています：3つのブラウザツールに加え、管理対象エンティティごとに1つのアクションベースツールです。代表的なツールはcheck_app_in_browser（フルAIエージェント）とprobe_page（LLM不要の軽量ページプローブ）です。残り — project、environment、test_suite、test_case、executions — はそれぞれaction判別子（例：{"action":"list"}）を受け取り、操作を選択します。破壊的なdeleteアクションには確認が必要です（サポートされている場合はelicitationプロンプト、それ以外の場合はconfirm: true）。
ブラウザ
check_app_in_browser
AIブラウザエージェントをアプリに対して実行します。エージェントはナビゲートし、操作し、スクリーンショット付きでレポートを返します。localhost URLはngrok経由で自動トンネリングされます。
| パラメータ | 型 | 説明 |
|---|---|---|
description | string 必須 | テスト内容（自然言語） |
url | string 必須 | ターゲットURL — http://localhost:3000は自動トンネリングされます |
environmentId | string | 特定の環境のUUID |
credentialId | string | 特定の認証情報のUUID |
credentialRole | string | ロールで認証情報を選択（例：admin、guest） |
username | string | ログイン用ユーザー名（一時的 — 永続化されません） |
password | string | ログイン用パスワード（一時的 — 永続化されません） |
loginCredentials | array | エージェントがタスク中に遭遇するログイン用アカウント — [{username, password, label?}] |
useEnvironmentCredentials | boolean | デフォルトはtrue。falseは環境に保存された認証情報の自動入力を禁止します。アカウントが指定されていない場合はまったくログインしないことを意味します |
freshSession | boolean | デフォルトはfalse。trueはそのアカウントで保持されているウォームセッションを再利用する代わりに実際のログインを強制します |
auth | object | 認証の前提条件 — {precondition, entryUrl, deepUrl, environmentId, username, password} |
repoName | string | 自動検出されたgitリポジトリ名を上書き（例：my-org/my-repo） |
1回の呼び出しにつき1つの焦点を絞ったチェック。エージェントには約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"とともに自身を報告するため、実際にフォームが見つからなかった実行と区別できます。
セッションはアカウントごとにキー設定されるため、別のアカウントを指定しても他人のセッションを再利用することはありません。再利用をバイパスする2つの方法：
- 単一の呼び出しで
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ブロックを返します — キャプチャされたHAR（完全なネットワークトレース）とコンソールログ（すべてのJSコンソールメッセージ）用の事前署名付きS3 URLです。これらを使用して、型チェックと単体テストを通過するリフェッチループ、ハイドレーションエラー、その他のランタイム問題を検出します：
"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です — ステータスが'downloaded'に達するまでexecutions {action:"get", uuid: executionId}をポーリングします。Authorization / Cookie / token/secret/api_keyヘッダーは、アーティファクトが永続化される前にサーバー側でスクラブされます。
trigger_crawl
サーバーサイドのブラウザエージェントクロールを実行して、プロジェクトのナレッジグラフを構築します。localhost URLは自動的にトンネリングされます。正常な取り込み時にknowledgeGraph.imported === true付きの{executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?}を返します。browserSessionブロック（HAR + コンソールログURL、上記と同じ形状）も完了したクロールに存在します。
probe_page
LLM不要の軽量バッチページプローブ。 1〜20個のURLを渡します。各URLはナビゲートし、コンテンツに落ち着きます（DOMが静かになる — 制限付き。ライブアプリが到達しないネットワークサイレンスには依存しません）、レンダリングされた状態を返します — スクリーンショット + ページメタデータ + 構造化されたコンソールエラー + ネットワークサマリー。エージェントループなし、LLMコストなし、シナリオアサーションなし。「/settingsを壊したか？」、リファクタリング後のマルチルートスモーク、CIのPRごとのスイープ、check_app_in_browserの60〜150秒のエージェントループが過剰な場合のクイック稼働確認に使用します。
| パラメータ | 型 | 説明 |
|---|---|---|
targets | array 必須 | 1〜20エントリ：[{url, waitForSelector?, waitForLoadState?, timeoutMs?}] |
targets[].url | string 必須 | パブリックURLまたはlocalhost（自動トンネリング） |
targets[].waitForLoadState | enum | 'domcontentloaded'（デフォルト、+ 制限付きコンテンツセトル）/ 'load'（サードパーティの埋め込みもブロック）/ 'networkidle'（受け入れられるが発行されない — ライブサイトのネットワークはアイドルにならない） |
targets[].waitForSelector | string | ナビゲーション後に待機するオプションのCSSセレクタ |
targets[].timeoutMs | number | URLごとのタイムアウト、1000〜30000（デフォルト10000） |
includeHtml | boolean | 各結果に生のHTMLを返す（デフォルトfalse） |
captureScreenshots | boolean | ターゲットごとに1つのPNGを返す（デフォルトtrue） |
バッチ内のすべてのターゲットは1つのセッショントンネルを共有しますが、同じポート（またはすべてパブリック）のバッチのみが単一のバックエンド実行を共有します — 1つの呼び出しで1つのポート上の5つのURLは、5つの並列単一URL呼び出しよりも劇的に高速です。複数のローカルポートを混在させるバッチは、ポートグループごとに1つのシーケンシャルバックエンド実行に分解されます（依然として1つの呼び出し、元の順序で1つのマージされたresults[]ですが、1つの代わりにN回のバックエンドラウンドトリップ — 遅くなりますが、拒否はされません）。URLごとのerrorフィールドはバッチの回復力を維持します：単一の失敗したターゲットは他のターゲットを失敗させません。
networkSummary集約キーはorigin + pathnameです — リフェッチループ（同じエンドポイントに繰り返しヒットする?n=0..4）はカウント付きの単一エントリに折りたたまれ、/api/pollがcount: 47とともに表示されることが、ユーザーが元々求めた実行可能な「無限リフェッチループ」シグナルです。
パフォーマンス予算：1 URLで<10秒、20 URLで<25秒。localhostのデッドポートは、ワークフロー実行を消費せずに<2秒でLocalServerUnreachableを返します。
project
| アクション | パラメータ | 結果 |
|---|---|---|
get | {uuid} | キュレーションされたプロジェクト詳細 |
list | {q?, page?, pageSize?} | ページネーションされたサマリー |
create | {name, platform, (teamUuid|teamName), (repoUuid|repoName)} | 作成されたプロジェクト |
チームとリポジトリはuuidまたは名前のいずれかで解決されます（大文字小文字を区別しない完全一致。該当なしの場合はNotFound、複数ある場合はAmbiguousMatch）。update/deleteはありません — プロジェクトの名前変更または削除はDebuggAI Webアプリから行います。
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 は、バックエンドがログインをスキップするために再利用するウォーム認証セッションを管理します（セッション再利用 を参照）。セッションの内容は決して返されません — セッションクッキーはベアラークレデンシャルです。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 は、{error: 'NotFound', message, uuid} を伴う isError: true として表面化します。認証情報は 常に パスワードなしで返されます。
ページネーション
すべてのフィルターモードのレスポンスはページネーションされます。レスポンスの形状：
{
"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} | 1 つのプロジェクト、完全な詳細 |
debugg-ai://environment/{uuid} | 1 つの環境（認証情報はインライン、パスワードは編集済み） |
debugg-ai://execution/{uuid} | 1 つの実行、完全なノード詳細 + アーティファクトリンク |
読み取りは project / environment /
executions ツールと同じハンドラーにディスパッチされるため、データと認証は同一です。リソースは追加的なものです —
リソースサポートのないクライアントは引き続きツールを使用します。
セキュリティの不変条件
- パスワードは書き込み専用です。どのツールのレスポンスボディにも決して表示されません。
- トンネル URL（
*.ngrok.debugg.ai）は、エージェント作成のテキストを含むすべてのブラウザエージェントのレスポンスから削除されます。 - バックエンドからの 404 は、スローされた例外ではなく、
{error: 'NotFound', ...}を伴うisError: trueとして表面化します。 - 欠落した
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 Web アプリを使用してください |
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 | いいえ | check_app_in_browser がディスパッチする App Evaluation ワークフローの スラッグ を上書きします。デフォルトは flow/e2es/app-eval。ディスパッチはこのスラッグに固定されるため、バックエンドのテンプレート名変更で壊れることはありません。 |
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）を話します。代わりに、
ステートレス Streamable HTTP + OAuth を介したホスト型のマルチユーザーリモート MCP として実行できます：
DEBUGGAI_MCP_TRANSPORT=http PORT=3000 DEBUGGAI_TOKEN_TYPE=bearer npx -y @debugg-ai/debugg-ai-mcp@latest
これは OAuth リソースサーバー です：すべての POST /mcp には
Authorization: Bearer <token> が必要です。欠落/無効なトークンは、RFC 9728 メタデータを指す
WWW-Authenticate を伴う 401 を取得し、クライアントはアドバタイズされた
認可サーバーに対して OAuth フローを実行します。ベアラーはリクエストスコープです —
api.debugg.ai がそれを検証します。
| エンドポイント | 目的 |
|---|---|
POST /mcp | MCP Streamable HTTP（ベアラー保護） |
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 | OAuth トークンが Authorization: Bearer として転送されるように bearer に設定 |
stdio インストールにはこれらは必要ありません。
マルチレプリカデプロイメント（ロールアウト前のゴー/ノーゴー）： トンネル状態（ngrok セッショントンネル、
その Caddy インスタンス、およびそのポートルートロック）はプロセス内にあり、ベアラートークンのハッシュによって
呼び出し元ごとにキー設定されます — プロセス間の調整はありません。プレーンなラウンドロビン
ロードバランサーの背後で複数のレプリカを実行すると、1 つの呼び出し元の呼び出しが異なるレプリカに
着地し、セッション全体で 1 つではなく、ヒットしたレプリカごとに 1 つのトンネルを生成する可能性があります
（追加の ngrok コスト、レプリカ数で制限され、既存の 55 分間のアイドル自動シャットオフで自己修復 —
単一のツール呼び出しはその全期間中 1 つのレプリカに留まるため、セッション間の正確性のバグにはなりません）。
マルチレプリカ HTTP デプロイメントで意図した「セッションごとに 1 つのトンネル」動作を実現するには、
ロードバランサーで セッションアフィンルーティング を設定します（getSessionKey() が導出するのと同じアイデンティティ
— 実際には、呼び出し元の 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 を伴うキャッシュヒット/ミス |
プライバシーポリシー：
- 個別 ID は
SHA-256(api_key).slice(0, 16)— 生のキーではなく、PII はありません。 phc_*キーは PostHog の慣例により書き込み専用です。ソースに埋め込んでも安全です。- 完全にオプトアウトするには
DEBUGGAI_TELEMETRY_DISABLED=1を設定します（no-op プロバイダーに解決され、イベントはプロセスを離れません）。
アクティブモードは起動時にログに記録されます：
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
このリポジトリには、node dist/index.js — 新しくビルドされたローカルコード — を指す debugg-ai-local という名前の プロジェクトスコープ サーバーを登録する .mcp.json が同梱されています。これは、Claude Code の作業ディレクトリがこのリポジトリである場合にのみアクティブになります。
他のプロジェクトでは、公開された npm パッケージから取得する ユーザースコープ の debugg-ai 登録を使用する必要があります：
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