bugAgent

公式

bugAgentをMCP互換のAIクライアントに接続。AIコーディングアシスタントから直接、バグや機能リクエストなどをファイル化、分類、管理できます。コンテキストの切り替えやコピーペーストは不要—問題を説明するだけで、bugAgentが残りを処理します。

bugagent.com で表示

bugAgent MCPで何ができますか？

File bug reports — Describe a bug in natural language and bugAgent auto-classifies it by type and severity, then stores it.
File feature requests — Ask your assistant to file a feature request and bugAgent auto-classifies it as feature-request with a severity.
List recent reports — Ask your assistant to list your most recent bug reports, e.g. via list_bug_reports.
Search and filter reports — Query open critical bugs in a specific project or group everything filed this week by severity.
Update and comment on tickets — Change a report's status, assign it to yourself, or add a comment to an existing ticket.
Connect from your client — Add the hosted Streamable HTTP endpoint to Claude Desktop, Claude Code, Codex, Cursor, VS Code, or via curl-example.

ドキュメント

MCP 対応の AI クライアントに bug Agent を接続できます。

AI コーディングアシスタントから直接、バグや機能リクエストなどを登録、分類、管理できます。コンテキストの切り替えも、コピー＆ペーストも不要です。問題を説明するだけで、bug Agent があとは処理します。

外部 MCP クライアントは、bug Agent のダッシュボード AI Assistant とは別のものです。ダッシュボードアシスタントはすべてのプランでデフォルトでは無効で、明示的にワークスペースで有効化する必要があります。その ai_assistant ゲートは MCP やインテグレーションを無効にしません。MCP 認証、スコープ、ワークスペース／プロジェクトの権限、ツール固有の利用条件は引き続き適用されます。

はじめに

bug Agent はホスト型 MCP サーバーを実行し、AI クライアントが Model Context Protocol を通じてバグレポート、機能リクエスト、機能強化などを作成、検索、管理できるようにします。クライアントはホスト型 Streamable HTTP エンドポイントに直接接続します。

API キーを取得する

無料アカウントを作成してください。新しいワークスペースのオーナーは、API キーの設定画面に直接移動します。既存ユーザーは Settings → Developers → API Keys からキーを生成できます。

AI クライアントを設定する

クライアントの設定に 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

セットアップ

バグ報告に特化したプラグイン

公開プラグインのソースとセットアップチェックリストをご覧ください。これはソースのプレビューです。ホスト型 OAuth の検証と OpenAI ディレクトリへの掲載は保留中です。

特化型エンドポイント https://mcp.bugagent.com/mcp/capture で利用できるのは、capture_get_profile、capture_list_projects、capture_search_reports、capture_get_report、capture_create_report のみです。管理、削除、コメント、テスト実行機能は公開されません。OpenAI ディレクトリでの公開には、別途審査と掲載が必要です。

OAuth で接続します。Capture 権限はこのエンドポイントに紐付けられており、完全版の /mcp エンドポイントでは使用できません。読み取りには bugs:read が必要で、作成には bugs:write が必要です。ワークスペース API キーも引き続き reports:read と reports:write でサポートされ、キーのワークスペースに制限されます。

最初に、認可されたワークスペースとプロジェクトを選択してください。検索とレポートの読み取りには、明示的な workspace_id と project_id が必要です。結果には上限があり、ページ分割されます。検索結果は重複の可能性がある候補であり、重複が存在しないことを保証するものではありません。

作成前に、登録先、タイトル、説明、種類、重大度を確認してください。承認済みの内容とともに approved: true と安定した UUID request_id を送信します。同一の再試行に限り、同じリクエスト ID を再利用してください。内容が変更されたリクエストは拒否されます。既存のプラン上限と設定済みの Jira 転送も引き続き適用されます。

画像の解釈は下書きの作成に役立つ場合がありますが、このエンドポイントでは添付ファイルをアップロードできません。作成したチケットを開いて、非公開の証拠資料を添付してください。パスワード、トークン、その他の秘密情報を会話に貼り付けないでください。

推奨: ホスト型 Streamable HTTP

https://mcp.bugagent.com/mcp に直接接続します。ローカルにインストールしたり、起動し続けたりする必要はありません。ワークスペース API キーをベアラートークンとして追加します。

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

💡

ba_live_YOUR_KEY_HERE を Settings → Developers から取得した実際の 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"
      }
    }
  }
}

サーバーに接続する

タッチデバイスのダッシュボードでは、サイドバーのラベルを1回タップすると移動します。Options と Restore は別々のコントロールで、キーボードからも操作できます。サイドバーの表示状態によって MCP 権限が付与または取り消されることはありません。

bug Agent MCP サーバーは、Streamable HTTP トランスポートで https://mcp.bugagent.com/mcp にて稼働しています。以下の8つのクライアントのいずれかから接続してください。ワークフローに合ったものを選びましょう。

コピーしてすぐ使える小規模な設定、スコープ付きキーのガイダンス、安全なスタータープロンプトについては、公開されている MCP クイックスタートをご利用ください。

🔑

まず API キーを取得してください。 Settings → Developers にサインインし、Create API Key をクリックして、クライアントに必要なスコープを選択し、値（ba_live_ で始まります）をコピーします。表示されるのは一度だけなので、安全な場所に貼り付けてください。MCP クライアントには、そのスコープで許可されたツールのみが表示されます。以下の接続例ではこのキーを使用します。対話型 OAuth／セッションや有料プランの利用条件が必要なプロンプトには、その旨を別途記載しています。

オプション 1 — MCP Inspector（Web UI、初回テストにおすすめ）

Anthropic 公式ツールです。ローカルの Web UI を起動し、各ツールをクリックしてパラメーターを入力し、応答を確認できます。設定は不要で、IDE も必要ありません。

macOS（Terminal）

npx @modelcontextprotocol/inspector

Windows（PowerShell または CMD）

npx @modelcontextprotocol/inspector

ブラウザーで開いた UI で:

Transport Type: Streamable HTTP を選択
URL: https://mcp.bugagent.com/mcp
Connection Type: Proxy を選択（デフォルト。Inspector がローカルの Node プロセス経由でプロキシし、ブラウザーの CORS を回避します）
Server Settings → Custom Headers を開き、次を追加:
- Header Name: X-Api-Key
  - Value: ba_live_YOUR_KEY_HERE（Bearer プレフィックスは付けません）
Connect をクリックします。左側のパネルに、選択した API キーのスコープで許可された bug Agent のツールが表示されます。
任意のツール（例: list_bug_reports）をクリックし、パラメーターを入力して Run Tool をクリックします。応答は右側に表示されます。

前提条件: MCP Inspector v2 には Node.js 22.19 以降が必要です。インストールされていない場合は、nodejs.org から現行の Node.js リリースをインストールしてください。

Inspector が invalid_client を返す場合、API キー認証ではなく、保存済みの OAuth 接続を試みています。保存済みサーバーを削除する（または保存された OAuth 状態を消去する）か、サーバーを再追加して、上記の X-Api-Key カスタムヘッダーを使用してください。OAuth の client_id フィールドに ba_live_ キーを入力しないでください。

オプション 2 — Claude Desktop（Mac + Windows）

Claude Desktop アプリを使用している場合、bug Agent を常設の MCP サーバーとして追加できます。ワークスペース API キーを使用すると、Claude に表示されるのはそのキーのスコープで許可されたツールのみです。委任 OAuth では、対話型カタログ全体が公開されます。

macOS

Claude Desktop を開き、メニューバーから Claude → Settings → Developer → Edit Config を選択します。~/Library/Application Support/Claude/claude_desktop_config.json が開きます。

mcpServers の下に bug Agent のエントリーを追加します:

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

ファイルを保存し、Claude Desktop を完全に終了します（ウィンドウを閉じるだけでなく、Cmd+Q を使用）。
Claude Desktop を再起動します。チャット入力欄の下部にあるツールのハンマーアイコンに、bug Agent のツールが表示されます。
試してみましょう: 「最新のバグレポートを5件一覧表示して」 と入力すると、Claude が自動的に list_bug_reports を呼び出します。

Windows

Claude Desktop を開き、File → Settings → Developer → Edit Config を選択します。%APPDATA%\Claude\claude_desktop_config.json が開きます（通常は C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json）。
macOS のセクションに示されている同じ JSON ブロックを追加します。
ファイルを保存し、システムトレイから Claude Desktop を完全に終了します（Claude アイコンを右クリック → Quit）。その後、再起動します。
ツールのハンマーアイコンに bug Agent のツールが表示されます。

オプション 3 — Claude Code（CLI）

ターミナルから Claude Code（Claude の CLI 版）を使用している場合、1つのコマンドで 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 内の AI アシスタントからエディターを離れずにバグを登録したり、レポートを一覧表示したり、サポート対象の自動化ワークフローを実行したりできます。セキュリティ、パフォーマンス、探索的スキャンには、委任 OAuth と該当するプランの利用権限が必要です。

Cursor を開き、Settings（Mac では Cmd+,／Windows では Ctrl+,）→ 左サイドバーの MCP を選択します。
+ Add new MCP server をクリックします。
トランスポートタイプとして HTTP を選択します。
次の項目を入力します:
- Name: bugagent
  - URL: https://mcp.bugagent.com/mcp
  - Header name: Authorization
  - Header value: Bearer ba_live_YOUR_KEY_HERE
Save をクリックします。接続されると、Cursor に緑色のインジケーターが表示されます。
Cursor のチャットを開き（Cmd+L／Ctrl+L）、「重大度 high で、タイトルが『Login broken』のバグレポートを作成して。」 と入力します。Cursor が create_bug_report を呼び出します。

別の方法: Cursor は ~/.cursor/mcp.json（Mac）または %USERPROFILE%\.cursor\mcp.json（Windows）も読み込みます。Claude Desktop のセクションに示されているものと同じ JSON 形式を追加してください。

オプション 6 — Continue 拡張機能を使った VS Code（Mac + Windows）

VS Code を使いたい場合、Continue 拡張機能は MCP サーバーをネイティブにサポートしています。

VS Code マーケットプレイスから Continue 拡張機能をインストールします。
Continue の設定を開きます: Command Palette（Cmd+Shift+P／Ctrl+Shift+P）→ Continue: Open config.json。ファイルの場所:
- macOS: ~/.continue/config.json
  - Windows: %USERPROFILE%\.continue\config.json

mcpServers エントリーを追加します:

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

保存します。Continue が自動で再読み込みされ、サイドバーに bug Agent のツールが表示されます。
Continue のチャットパネルを開き、次を試してください: 「最近の未解決バグレポートを5件一覧表示して。」

その他の VS Code 対応 MCP 拡張機能: Cline、Roo Code、Windsurf（フォーク）も、mcpServers キーと HTTP トランスポートを使う同様の JSON 設定パターンに従います。

オプション 7 — OAuth 対応ホスト（例として Claude.ai Web を使用）

一部の MCP ホストは OAuth 2.0 で認証し、ベアラー API キーを受け付ける代わりに、事前に静的な client_id と client_secret を要求します。bug Agent ダッシュボードでコネクター認証情報のペアを生成し、ホストのコネクターフォームに貼り付けてください。このペアは MCP クライアントを識別します。同意後、ツールの実行にはサインイン中のユーザーと、そのユーザーが現在使用している bug Agent ワークスペースが使われます。以下の手順では、最も一般的な例として Claude.ai Web アプリを使用します。

リソースに紐付けられた OAuth。 保護対象リソースの識別子は https://mcp.bugagent.com/mcp です。標準に対応したホストは /.well-known/oauth-protected-resource/mcp からこれを検出し、RFC 8707 の resource パラメーターとして送信します。bug Agent が発行する不透明トークンは、そのリソース、OAuth クライアント、サインイン中のユーザー、付与されたスコープに紐付けられます。別のサービスに対してトークンを再利用したり、別のクライアントで引き換えたりすることはできません。

bug Agent で、Settings → Developers → MCP Connectors を開きます。Generate connector をクリックし、ホストを説明する名前（例：“Claude.ai (work)”）を付け、MCP ホストが必要とするリダイレクト URI を貼り付け（Claude.ai の Web アプリの場合は https://claude.ai/api/mcp/auth_callback。その他についてはホストのコネクタのドキュメントを確認してください）、認証方法として Confidential を選択します。成功画面に一度だけ表示される client_id と client_secret をコピーします。
MCP ホストのコネクタ / OAuth 設定に、次の値を貼り付けます。
- Server URL: https://mcp.bugagent.com/mcp
  - Client ID + Client Secret: 手順 1 の値
  - Authorization URL: https://mcp.bugagent.com/authorize
  - Token URL: https://mcp.bugagent.com/token
  - Protected resource / audience（要求された場合）: https://mcp.bugagent.com/mcp Claude.ai の場合は、claude.ai/customize/connectors に移動して Add MCP connector をクリックします。
保存します。ホストから bug Agent にリダイレクトされるので、ダッシュボードで使用している方法（Google またはメールアドレス / パスワード）でサインインして同意を承認すると、OAuth ハンドシェイクが完了します。
生成したコネクタは、同じ Settings ページから管理できます。テナントのコネクタを取り消せるのは作成者のみです。ワークスペース管理者であっても、他のメンバーの登録を取り消す権限はありません。取り消しが確定すると、その登録は有効な一覧から削除されます。同じ名前の登録が複数ある場合も、それぞれ別の登録です。Client ID を比較してください。取り消しを確認できない場合、ページには成功ではなくエラーが表示されます。取り消すと、新しいコネクタ認証がブロックされます。発行済みのアクセストークンは、有効期限が切れるまで有効な場合があります。

注: Claude Code、Cursor、VS Code、MCP Inspector では、このフローは不要です。これらは動的クライアント登録（RFC 7591）を自動的に処理し、上記のとおり API キーで認証します。MCP Connectors フォームは、静的 OAuth 認証情報を必要とするホスト専用です。

OAuth のアクセス値とリフレッシュ値はホストにのみ表示されます。これらは不透明な値で、リフレッシュ時にローテーションされます。bug Agent では一方向ハッシュとしてのみ保存され、上流 ID のリフレッシュ認証情報は保存時に暗号化されます。OAuth トークンを REST API リクエストや別の MCP サーバーにコピーしないでください。

オプション 8 — curl による直接 HTTP 接続（ターミナル）

クライアントを使わずにサーバーを直接テストする場合や、スクリプトに組み込む場合は、curl を使って HTTP エンドポイントにアクセスできます。MCP プロトコルは、Streamable HTTP 上の JSON-RPC 2.0 です。

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

Web オートメーションの作成 automations:write

Web オートメーションの実行と実行履歴の読み取り 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 キーは、作成されたワークスペースに紐付けられます。ツールの入力で呼び出し対象を認可済みプロジェクトに絞り込むことはできますが、キーを別のワークスペースに切り替えることはできません。list_projects でプロジェクト UUID を解決し、曖昧な名前は拒否してください。

ツールのタイトルと注釈

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 を通じて限定的に利用できます。

お試しください — 平易な英語のプロンプト

接続後は、ツール名やパラメーターを知っている必要はありません。実行したいことを平易な英語で説明すると、AI アシスタントが適切な 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

探索的 AI

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?

クイックリファレンス

8 種類すべての接続オプションのセットアップ情報です。API キーを使うクライアントは、Streamable HTTP 経由で https://mcp.bugagent.com/mcp に Authorization: Bearer ba_live_YOUR_KEY_HERE ヘッダーを付けて接続します。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 標準準拠の Streamable HTTP では Accept: application/json, text/event-stream を送信してください。bug Agent は現在、値がない場合や不完全な場合に正規化しますが、連携側はこの互換動作に依存しないでください。

別のワークスペースのデータが表示される各 API キーは 1 つのワークスペースにスコープ設定されています。クエリ対象のワークスペースで新しいキーを Settings → Developers から生成してください。

ツールは表示されるが、呼び出しが失敗しても何も表示されないレスポンスの isError: true と返された内容を確認してください。ツールが表示されていても、プラン、ロール、機能の利用資格、プロジェクトメンバーシップ、所有権、または無効な入力によって拒否される場合があります。ツールのエラーを確認してから、サーバーの状態を確認してください。

MCP Inspector で CORS エラーが発生する Inspector UI の Connection Type で Direct ではなく Proxy を選択してください。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 承認ツールはありません。エージェントにスクリプトの作成を依頼しても、オートメーションが作成またはスケジュールされることはありません。

クラウドブラウザーのスクリーンショットを保持すると、所有者セッション保持エンドポイントを通じて、所見の下書きのみが作成されます。ライブ更新によって選択済みのスクリーンショットが置き換わることはありません。保存には、現在の所有者アクセス、元の認可済みブラウザー世代、および利用可能なソースが引き続き必要です。バグとその非公開の証拠を登録する前に、所有者が Workbench で確認して承認する必要があります。フレームを保持したり、この承認を回避したりする MCP ツールはありません。

ブラウザー起動の同意もダッシュボード所有者のみが行えます。API キー、MCP ツール、一般的なチャットの回答では同意を付与できません。承認の対象は、読み取り専用ブラウザー 1 つと非公開スクリーンショットのキャプチャであり、ログイン、フォーム操作、会議の録画は含まれません。これらの同意制御によって、本番環境のクラウドブラウザーホストが有効になることはありません。

対話型 / OAuth カタログには 141 個のツールが含まれます。ワークスペース API キーで検出できるのは、選択したスコープで許可される最小権限のサブセットのみです。アカウント、API キー管理、チーム管理、プレミアムテスト、メモ、時間記録の各ツールは、項目に API キーのスコープが明記されている場合を除き、対話型セッション専用です。

🐛

バグレポート管理

バグレポートの更新では、再現手順、内部メモ、タグを含め、実際の変更前 / 変更後の値がアトミックに記録されます。変更されていない値や失敗した書き込みによって、フィールド履歴が作成されることはありません。ダッシュボードの Change Log では、テキストのみの差分を展開し、古いエントリをページ送りで確認できます。添付ファイルの履歴に保持されるのは説明用メタデータであり、署名付き URL や削除済みファイルは保持されません。欠落している過去の値が後から補完されることはありません。MCP の履歴ツールやライブ編集の競合プロトコルは追加されません。認可されたクライアントはレポート履歴 REST エンドポイントを使用できます。 update_bug_report は、文字列フィールド steps_to_reproduce、expected_result、actual_result も受け付けます。省略されたフィールドは保持され、空文字列を指定するとテキストが消去されます。更新時も、既存のワークスペース／プロジェクトの認可と reports:write のスコープ要件が適用されます。

再開可能な Google Sheets のスクリーンショットインポートには、reports:write を指定する別の REST POST /api/reports/import-attachment エンドポイントを使用し、reports:read でステータスを取得します。スクリーンショットインポート用の MCP ツールは追加されません。この JPEG/PNG 専用 API は、完了を報告する前に、プライベートストレージと正確にマッピングされた Jira イシューを検証します。従来のレポートアップロードは引き続きセッション専用です。

プライベートなレポートおよびテスト実行の添付ファイルリンクを開く際は、アクティブなワークスペースメンバーシップと現在のプロジェクト権限が再確認されます。テスト実行のダウンロードにはダッシュボードセッションが必要で、MCP API キーでは利用できません。発行済みのストレージリンクは最大60秒間有効な場合があるため、共有しないでください。

create_bug_report — 19種類のタイプ（バグ、機能リクエスト、機能強化、技術的負債など）に自動分類して新しいレポートを登録します（タイトル：3～500文字）。任意の attachments 配列では、各最大400 MBのBase64エンコードファイルを受け付けます。対応形式は画像、動画、音声、PDF、テキスト／JSONです。format_description: true を設定すると、AIを使用して説明を構造化テンプレートに自動整形します。QA作業量を記録するには time_spent_seconds を指定します。重大度とは独立して修正の緊急度を設定するには、priority（urgent / high / normal / low）を指定します。Epicを作成するには is_epic: true を指定し、同じ認可済みプロジェクト内に子レポートを作成するには parent_epic_id（UUID／短縮ID）を指定します。レスポンスには階層フィールドに加え、project_id、project、short_id、legacy_short_id、project_short_id が含まれます。
list_bug_reports — レポートを一覧表示し、絞り込みます（1ページあたり最大100件）。プロジェクトの絞り込みはページネーション前にサーバー側で適用されます。project（UUID、スラッグ、完全一致の名前、またはチケットプレフィックス）、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() を記録します。PostgresのUPDATE-WHERE-RETURNINGパターンにより、同時呼び出しでも競合が発生しません。2つのエージェントが同じIDに対して短時間の間に claim_bug を呼び出した場合、バグ本文を含む claimed:true を受け取るのは一方だけで、もう一方は理由文字列を含む claimed:false を受け取ります。成功時のレスポンスには reporter_user_id、reporter_name、assigned_to、assignee_name が含まれます。pg_cron のリーパーが、古くなった取得（status= 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個です。文字列はトリミング後に空であってはならず、Unicodeコードポイント数で50文字以下とし、ASCII制御文字（U+0000～U+001FまたはU+007F）を含めることはできません。トリミング後の完全一致する重複は削除されます。大文字と小文字は区別され、Login と login は異なる値として扱われます。更新時に配列を指定するとすべてのタグが置き換えられ、[] を指定するとタグが消去され、省略すると既存のタグが保持されます。作成時に省略した場合、タグは設定されません。null および無効な要素は拒否されます。作成、取得、一覧表示、更新の結果には、ネイティブの tags が含まれます。
タグによる絞り込み： list_bug_reports を {"project":"bugagent","tags":["login","regression"]} とともに呼び出すと、ページネーション前に、指定したすべてのタグに大文字と小文字を区別して一致するレポートを検索します。同じタグ制限が適用されます。省略するか [] を指定すると、タグによる絞り込みは適用されません。既存の reports:read / reports:write スコープとワークスペース／プロジェクトの認可に変更はありません。タグのビジュアルUIや、Jiraラベルの自動インポート、同期、バックフィルは追加されません。
get_epic — 必須の id（UUIDまたはワークスペース／プロジェクトの短縮ID）を指定して、Epicを直接読み取ります。子レポートを暗黙的に読み込まず、Epicレコードのみを返します。ワークスペースとプロジェクトへのアクセスが必要です。APIキーを使用する場合は reports:read が必要です。子レポートの読み取りには、別途 list_epic_children を使用してください。
list_epic_children — id、limit（1～100）、offset を指定して、Epicの子レポートをページネーションします。すべての子レポートを読み込まずに、children、total、has_more、およびSQLで集計された epic_progress を返します。
update_bug_report — 標準のレポートフィールドに加え、is_epic と parent_epic_id を更新します。親から切り離すには parent_epic_id: null を指定します。親の変更／切り離しはアトミックに行われ、同一ワークスペースかつ同一プロジェクトの認可が必要です。Epicに昇格すると既存の親から切り離されますが、子を持つEpicを降格することはできません。既存のステータス／解決方法／根本原因および割り当て通知のルールは引き続き適用されます。Jiraにリンクされたレポートで status を変更すると、マッピングされたステータスに一致する有効な遷移が1つだけある場合、そのワークフロー遷移を通じてJiraイシューにも反映されます。それ以外の場合、イシューは変更されません。
add_comment — バグレポートにコメントを追加します（UUIDまたは短縮ID、本文は1～10000文字）。レポートがJiraと同期されている場合、コメントはリンクされたJiraイシューに自動的に送信されます。![proof](/api/attachments/ATTACHMENT_UUID) のようなプライベート添付ファイルのMarkdownは、Jira内で絶対URLの認証済みbugAgentスマートリンクになります。閲覧者は、レポートのワークスペースとプロジェクトへのアクセス権を持つbugAgentアカウントでサインインする必要があります。Jiraのネイティブなインラインプレビューは保証されません。
list_comments — レポートに保存されたコメントスレッドを古い順に一覧表示します。各コメントには、投稿者名、parentId（スレッド形式の返信）、createdAt、updatedAt が含まれます。コメントは get_bug_report に含まれないため、チケットの議論を読むにはこのツールを使用します。UUIDまたは短縮IDを受け付けます。この読み取りではJiraは更新されません。最新のJiraコメントが必要なスケジュール済みインテグレーションは、認可済みのマネージャー所有APIキーを使用して、最初に POST /api/jira/comments-refresh を呼び出せます。新しいコメントと編集を区別するにはコメントIDと内容のリビジョンを使用し、更新に失敗した場合は完全なアクティビティレポートであると主張しないでください。
link_bug_reports — 同じ認可済みプロジェクト内の2つのレポート間に、方向性のあるセマンティックリンクを作成します。parent-of の場合、fromレポートはEpic、toレポートは標準の子レポートである必要があります。Epicへの割り当てには、作成／更新時に parent_epic_id を優先して使用してください。
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 は対称です。get_bug_report が返す自動検出フィールド similar_reports を補完します。
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 — プロジェクトのQAナレッジ（バグレポート、テストケース、自動化、パフォーマンス／セキュリティ／探索的テスト）を、OKF/OQA Markdownバンドル（oqa.aiで使用されるOpen Query Agent形式）としてエクスポートします。デフォルトではアクティブなプロジェクトが対象です。別のプロジェクトをエクスポートするには、任意の project（スラッグまたは名前）を指定します。バンドル内のファイル一覧と、Base64エンコードされたzip形式のバンドル本体を返します

🔐

認証とアカウント

register_account — 新しいアカウントを作成します（パスワード：8～128文字、レート制限：15分あたり5回）
login — サインインしてアクセストークンを受け取ります（レート制限：15分あたり5回）
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 にプッシュします。レポートの bugAgent プロジェクトにマッピングされた Jira プロジェクト（フォールバックはワークスペースのデフォルト）に、対応するフィールドマップを使ってルーティングします。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 — バグレポートの開発者向けメモ（根本原因、修正案、検証手順、リスク評価）を生成（または再生成）します。UUID または短縮 ID（WRKID-545）を受け付けます。プラットフォームキーを使用するため、チームごとの Claude 接続は不要です。適応型の連鎖を実行します。s3 / medium または s4 / low のバグでは3 ステップ（Sonnet の草案 → OpenAI gpt-5 による批評 → Sonnet による統合）、重大度が上位 2 段階のバグ（s1 / critical または s2 / high）では5 ステップ（草案 → 批評 → Sonnet による反論 → 全トランスクリプトを読み、独自の判断で最終メモを作成する Claude Opus の裁定者）を実行します。レスポンスには各ラウンド（analysis、draft、critique、rebuttal、challenger_model、adjudicator_model）と debated フラグが含まれます。いずれかのステップが失敗した場合は、次善の回答にフォールバックします。バグ作成時に自動実行されるため、通常は手動で再生成する場合にのみ呼び出します。
analyze_fix_area — 開発者向けメモの「修正が必要と思われる領域」サブブロックを生成（または再生成）します。コードベース内で修正が最も必要と思われる箇所を示す、簡潔な Sonnet の出力です。UUID または短縮 ID を受け付けます。プラットフォームの Anthropic キーを使用します。チームに github_connections 行があり、プロジェクトに github_repo がマッピングされている場合、接続済みリポジトリの実際のファイルスニペットに基づいて出力します。それ以外の場合は、リポジトリの接続を促す案内を添えた一般的なガイダンスにフォールバックします。likely_fix_area テキスト、generated_at、repo_used、および grounded フラグを返します。バグ作成時に自動実行されるため、通常、エージェントが呼び出すのは手動で再生成する場合のみです。
upgrade_plan — 営業担当者の支援を受けて Enterprise に登録するためのリンクを取得します

⚡

パフォーマンステスト

create_performance_test — URL、デバイス、仮想ユーザー数、実行時間、スコアしきい値、自動バグ作成の切り替えを指定して、パフォーマンステスト設定を作成します。省略可能な project には、現在のワークスペース内のプロジェクト UUID、スラッグ、完全一致する名前、またはチケットプレフィックスを指定できます。省略した場合は、ワークスペースのデフォルトプロジェクト、次に最も古いプロジェクトを使用します。呼び出し元にはアクセス権が必要です。プロジェクトを選択するには list_projects を使用してください。空欄、不明、またはアクセスできないプロジェクトは拒否されます。name は空欄以外である必要があり、前後の空白は削除されます。パフォーマンステスト名は、ワークスペースとプロジェクト内で、大文字小文字と前後の空白を無視して一意である必要があります。重複する場合は、別の名前を選ぶよう求められます。Enterprise 専用
run_performance_test — Web パフォーマンステストのページ監査と負荷テストを開始します。結果をポーリングするための実行 ID を返します。モバイルアプリのプロファイリング実行はダッシュボードから開始します
get_performance_results — Lighthouse スコア（パフォーマンス、アクセシビリティ、ベストプラクティス、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 は無制限です

ワークフロー例

get_performance_usage → 残りの利用枠を確認
create_performance_test → URL のテストを設定
run_performance_test → 監査と負荷テストを開始
get_performance_results → スコアとバイタルを確認

🛡

セキュリティスキャン

create_security_scan — セキュリティスキャン設定を作成します。Web スキャンでは、3 段階の深度と任意の認証済みスキャンに対応した Quick Scanner + Nuclei（4,000 以上のテンプレート）を使用します。モバイルスキャンでは、APK/IPA バイナリ分析に MobSF を使用します。重大度しきい値を指定して、自動バグ作成を設定できます。省略可能な project には、現在のワークスペース内のプロジェクト UUID、スラッグ、完全一致する名前、またはチケットプレフィックスを指定できます。省略した場合は、ワークスペースのデフォルトプロジェクト、次に最も古いプロジェクトを使用します。呼び出し元にはアクセス権が必要です。プロジェクトを選択するには list_projects を使用してください。空欄、不明、またはアクセスできないプロジェクトは拒否されます。name は空欄以外である必要があり、前後の空白は削除されます。セキュリティスキャン名は、パフォーマンステスト名とは別に、ワークスペースとプロジェクト内で、大文字小文字と前後の空白を無視して一意である必要があります。重複する場合は、別の名前を選ぶよう求められます。Enterprise 専用
run_security_scan — 脆弱性スキャンを開始します。Web スキャンには DNS ドメインの検証が必要です。モバイルスキャンにはアプリのアップロードが必要です。結果をポーリングするための実行 ID を返します
get_security_results — セキュリティスコア（0～100）、重大度（Critical、High、Medium、Low、Info）別に分類された検出結果（CWE 参照、OWASP マッピング、証拠、修正ガイダンスを含む）など、完全な結果を取得します
list_security_scans — 現在のチームのセキュリティスキャン設定をすべて、最終スコアと認証/深度バッジとともに一覧表示します
get_security_usage — 月間のセキュリティスキャン利用状況を確認します。セキュリティスキャンは Enterprise 専用です。Enterprise は無制限です
list_security_schedules — チームのスケジュール済みセキュリティスキャンをすべて、cron、タイムゾーン、有効状態、次回実行、通知設定とともに一覧表示します。親スキャン設定（name、scan_type、target_url）と結合します
create_security_schedule — セキュリティスキャンの定期スケジュールを作成します。scan_id と cron_expression が必要です。スキャン設定ごとにスケジュールは 1 つです。timezone、notify_on_fail（none/email/slack/both）、notify_email、slack_channel_id は省略可能です。実行ごとに月間上限に加算されます。管理者ユーザーは上限を回避できます。スキャン深度は実行時に常にスキャン設定から読み取られます
delete_security_schedule — スケジュール済みセキュリティスキャンを削除します。親スキャン設定や完了済みの実行には影響しません

ワークフロー例

get_security_usage → 残りの利用枠を確認
create_security_scan → URL またはリポジトリのスキャンを設定
run_security_scan → 単発の脆弱性スキャンを開始
create_security_schedule → 定期実行を自動化（例: main ブランチで毎週 SAST を実行）
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 日を指定できます

ワークフロー例

get_code_review_usage → 残りのレビュー数を確認
/dashboard/code-review のダッシュボードで PR をレビュー
list_code_reviews → 最近のレビューを確認
get_code_review → 検出結果と提案を取得

🔍

探索型 AI

最大 10 個のエージェントを並列実行し、それぞれ異なるテスト戦略を使用して Web サイトのバグを自律的に検出します。

list_explorations — チームの探索型 AI 設定を一覧表示します
create_exploration — 新しい探索を作成します。agent_count（1～10、最大 10）を指定すると、happy_path、edge_case、security、accessibility、error_path、performance、mobile、data_integrity、navigation、custom の各戦略を使う複数のエージェントを並列実行できます。このツールでは認証情報や認証モードを設定できません。ログインフローのみをテストする設定と開始は、ダッシュボードまたは REST から明示的に行ってください。その後、get_exploration と get_exploration_run を使って設定と結果を確認します。指示からモードを推測したり、MCP 引数に認証情報を含めたりしないでください。デフォルトの認証情報ベースの探索でも、再利用可能なセッションが必要です。
get_exploration — エージェント設定、安全な認証メタデータ、最近の実行を含む探索設定を取得します。パスワードと暗号文は返されません。
get_exploration_run — エージェントごとの進捗、フェーズデータ、エージェントの帰属情報（agent_index、agent_strategy）付きの検出結果、リンク済みバグを含む実行結果を取得します
get_exploration_usage — 月間利用状況を確認します。探索型 AI は Enterprise 専用です。Enterprise は無制限（10 エージェント）です

ワークフロー例

agent_count: 5 を指定して create_exploration → 5 つのエージェントを並列実行するよう設定
ダッシュボードまたは POST /api/explorations/run から実行を開始
get_exploration_run → エージェントごとの進捗と検出結果をポーリング
ダッシュボードで、エージェントの帰属情報付きの重複排除済み検出結果を確認

📝

メモ

list_notes — キーワード、プロジェクト、公開範囲、フォルダー、タグ、アーカイブ、Wiki、日付範囲、並べ替えの各フィルターを任意で指定して、メモを一覧表示します。ユーザーが所有するメモ、またはユーザーと共有されているメモを返します。
create_note — 5 種類の形式（markdown、plain、bugtemplate、checklist、outline）のいずれかでメモを作成します。visibility に private または shared を設定します。タイトルが指定されていない場合は、先頭 30 文字から自動的にタイトルを付けます。省略可能な attachments 配列では、各ファイル最大 400 MB の Base64 エンコード済みファイルを受け付けます。画像、動画、音声、PDF、テキスト/JSON が対象です。QA 作業量を記録するには time_spent_seconds を渡します。
get_note — 内容と添付ファイルを含むメモの詳細を取得します。id が必要です。
update_note — タイトル、内容、形式、公開範囲、プロジェクト、または time_spent_seconds を更新します。attachments 配列を渡すと、既存の添付ファイルを置き換えずに、新しいファイル（各最大 400 MB）をメモに追加します。更新できるのは作成者のみです。id が必要です。
delete_note — メモとその添付ファイルを完全に削除します。削除できるのは作成者のみです。id が必要です。
list_note_folders — 必要に応じてプロジェクトを指定し、メモ/Wiki フォルダーを一覧表示します。
create_note_folder — 親フォルダー、公開範囲、お気に入り、チームメイトのアクセス設定を任意で指定して、プロジェクトスコープのメモ/Wiki フォルダーを作成します。

ワークフロー例

create_note → テストセッションのメモを開始
update_note → テスト中に観察事項を追記
list_notes → キーワードまたはプロジェクトで過去のメモを検索
get_note → 添付ファイルを含むメモの全内容を取得

🤖

自動化

create_automation — カスタム Playwright スクリプトで新しい自動化を作成します（FAB の記録は不要）。name が必要です。任意: target_url（省略した場合、スクリプト内の最初の page.goto(...) URL から自動的に導出）、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）で絞り込みます。name、target_url、last_run_status、run_count を含む自動化の配列を返します。
get_automation — Playwright スクリプトと最近の実行を含む、自動化の詳細を取得します。id が必要です。現在の script、古い順に最大 100 件の過去エントリを含む script_versions スタック（各エントリは { script, source, timestamp }）、および各実行に実行された script_version_label / script_version_source が含まれる recent_runs 配列を含む自動化を返します。特定の過去バージョンを選ぶ必要がある場合は、run_automation の前にこれを呼び出してください。
run_automation — Playwright テストをただちに実行します。automation_id が必要です。自己修復ロケーター（自動）: ロケーター操作がタイムアウトすると、ランナーは Claude に動作するセレクターを問い合わせ、そのステップを 1 回再試行します。アサーションは修復されないため、実際のリグレッションは引き続き失敗します。修復はそれぞれ実行時の 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 経由で実行されます（デスクトップ + Android + iPhone に対応）。Python スクリプトは browserstack-sdk（pytest-playwright）経由で実行され、デスクトップのみ対応します。pytest-playwright の browser_type.connect() では BrowserStack の実機モバイルエンドポイントを操作できないため、Python による実機モバイルはサポートされていません。動画とネットワークログは自動的に記録されます。コンソールログはデスクトップのみです。バージョンの再実行: get_automation を使って script_versions を確認し、優先する永続的な version_label を渡します（例: "v103"）。従来の version_index も引き続きサポートされますが、version_label と併用してはいけません。デフォルト: どちらのセレクターも省略した場合、現在保存されているスクリプトが実行されます。 削除済みのラベルや無効なインデックスは、現在のスクリプトを暗黙に実行するのではなく、拒否されます。実行レコードには実行された正確なスナップショットが保存され、失敗した実行から自動作成されたバグ報告は、エディター内のそのバージョンに直接リンクされます。
list_automation_runs — 自動化の最近の実行を一覧表示します。automation_id が必要です。status、duration_ms、error_message を含む実行を返します。
list_schedules — スケジュール済みの Web 自動化実行をすべて一覧表示します。nullable の cron_expression、nullable の run_at、once_status、タイムゾーン、デバイス、通知設定が含まれます。繰り返し実行の行では run_at と once_status は null のままです。1 回限りの実行では cron が null です。1 回限りの状態: pending、claimed、missed、dispatched、failed、uncertain。これらはディスパッチ状態であり、テスト結果ではありません。結果は list_automation_runs で確認してください。
繰り返し Web スケジュール: create_schedule は 5 つの数値 cron フィールドとタイムゾーンを検証し、将来の UTC 時刻 next_run_at を返します。月次および年次の繰り返しに対応しています。たとえば、America/Toronto の 30 12 23 9 * は、1 回限りの実行ではなく、毎年 9 月 23 日の 12:30 を意味します。無効または実行不可能な時刻指定は、作成前に拒否されます。日付と曜日の両方が制限されている場合は、両方が一致する必要があります。存在しない夏時間の時刻はスキップされ、時計上で重複する時刻は 2 回発生することがあります。ディスパッチはスケジューラーの次回のポーリング時に行われ、必ずしも指定した分ちょうどとは限りません。既存の繰り返し動作に変更はありません。
1 回限りの Web スケジュール: { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" } を指定して create_schedule を呼び出し、将来の日付を選択して cron_expression を省略します。時刻フィールドはちょうど 1 つ指定してください。run_at には、オフセット付きの ISO 8601 形式の将来のタイムスタンプ（明示的なオフセットまたは Z）が必要です。IANA タイムゾーンは表示用です。有効な保留中スケジュールは、期限到来後の最初の cron ポーリング時に実行されます。1 時間を超えて遅れた場合は missed としてマークされます。ディスパッチ前にアトミックに確保されて無効化され、消費後に再度有効化することはできません。確定的なディスパッチ失敗は failed です。不確定なディスパッチは uncertain となり、自動再試行されません。別の試行をスケジュールする前に実行を確認してください。dispatched は完了または合格を意味しません。作成は API/MCP のみで可能であり、新しいダッシュボード作成モードはありません。
Web スケジュールのタイムゾーンには、America/Argentina/Buenos_Aires のような IANA 識別子を使用します。ダッシュボードのピッカーにはサーバーがサポートするすべての地域と都市が含まれ、デフォルトはプロフィールのタイムゾーンです。MCP のタイムゾーンのデフォルトは引き続き UTC です。
create_schedule — スケジュール済みの Web 自動化実行を作成します。automation_id と、cron_expression または run_at のいずれか一方が必要です。デバイス、タイムゾーン、失敗通知、メール、Slack チャンネルの設定は任意です。まずダッシュボードで Slack を接続し、ボットが参加しているチャンネルを選択してください。Webhook をインストールしただけでは不十分です。Slack の設定とチャンネルの検出を参照してください。
1 回限りのスケジュールのロールアウトと復旧: 対応する API/MCP およびスケジューラーのコードをデプロイする前に、データベースマイグレーション 374_one_time_web_schedules.sql を適用してください。ワーカーのクラッシュ後も claimed が残ることがあります。確保済みまたはディスパッチ状態が不確定な実行について、置き換えを作成する前に実行履歴を確認してください。1 時間を超えて遅れたタイムスタンプが自動実行されることはありません。
下書きの Web 自動化: スケジュールの作成、スケジュールの再有効化、cron 式またはタイムゾーンの変更を行う前に、自動化を有効化してください。create_schedule は、下書きステータスを拒否する前にワークスペースとプロジェクトへのアクセスを確認します。自動化が下書きの間、既存のスケジュールは実行サイクルをスキップします。一時停止、削除、ピン留め、通知のみの変更は引き続き可能です。Web の update_schedule MCP ツールはありません。これらの更新にはダッシュボードを使用してください。
delete_schedule — スケジュール済みの Web 自動化実行を削除します
list_mobile_schedules — デバイス、cron、タイムゾーン、通知を含む、スケジュール済みのモバイル自動化実行をすべて一覧表示します
create_mobile_schedule — 実機でスケジュール済みのモバイル自動化実行を作成します。automation_id と cron_expression が必要です。devices は任意です。
delete_mobile_schedule — スケジュール済みのモバイル自動化実行を削除します
optimize_automation_script — AI による最適化のため、Playwright スクリプトを Sonnet 4 に送信します。セレクター、待機方法、アサーション、エラー処理、認証パターン、モバイル互換性、strict mode を修正する 12 項目のチェックリストを適用します。automation_id が必要です。最適化の前に現在のスクリプトバージョンが保存されます。最適化されたスクリプトと変更の概要を返します。
undo_automation_script — 自動化スクリプトを以前のバージョンに戻します。以前のバージョンは最大 100 件保持されます。automation_id が必要です。復元されたスクリプトと残りのバージョン数を返します。

ワークフローの例

create_automation → カスタムスクリプトでテストを作成
list_automations → 利用可能なテストを参照
get_automation → Playwright スクリプトを確認
run_automation → テストを実行
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 — QA タスクに費やした時間を記録します。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 プラン限定です。

ワークフローの例

create_time_entry → リグレッションテストの 45 分を記録
list_time_entries → 今週の時間エントリを表示
update_time_entry → 所要時間またはカテゴリを調整
delete_time_entry → 誤ったエントリを削除

☑️

テストケース

階層フォルダー、ネストされたスイート（最大 3 階層。実行時にはサブスイートが自動展開）、ドラッグ＆ドロップによる並べ替え、KPI の推移、失敗分析、スイートの健全性、カバレッジ、テスターの生産性を確認できる分析用の Reports タブを備えたテスト管理機能です。すべてのツールは Supabase を直接呼び出すため、HTTP の往復はなく、ダッシュボードと同等のレイテンシです。

Free の上限: 保存できるテストケースは 10 件、スイートは 1 件、フォルダーは 3 件、各ケースの構造化コンテンツは 128 KB、アクティブなワークスペース API キーは 2 個、UTC 暦月あたりのテスト実行は合計 10 回です。そのうち最大 3 回は Hermes などの外部エージェントを使用でき、アクティブな外部実行は 1 件まで、各外部プランに含められるケースは最大 10 件です。Free の API キーによる MCP トラフィックは、キーごとに 1 分あたり 30 リクエスト、ワークスペースごとに 60 リクエストに制限されます。Enterprise では、一般的なプラットフォーム保護の範囲内で、テストケースの保存数と実行回数に上限はありません。

AI によるテストケース生成、AI タグ候補、Figma インポート、テストケースのファイル添付には Enterprise が必要です。Free の構造化コンテンツ上限 128 KB は、Enterprise のファイル添付とは別です。Free では URL 参照を保存できます。基本的な MCP テストケースツールは、上記の上限内で Free でも利用できます。

ハンズフリー実行: 実行レビュー画面は、1 回に 1 ケースを表示するカルーセル形式です。キーボードショートカット（P 合格 · F 不合格 · B ブロック · S スキップ）と音声操作に対応しています。マイクをクリックして、「Pass」「Fail」「Block」「Skip」「Next」「Previous」「Add notes」（メモ欄に文字起こし）、「Save notes」、または「Voice off」と話します。成功結果の場合は未テストの次のケースに自動で進みます。不合格の場合はその場にとどまり、テスターが詳細を音声入力してバグを作成できます。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、および null 許容の next_offset が返されます。以前は total がページ長を誤って意味していました。next_offset が null になるまで続けてください。ページ長から完了を推測しないでください。オフセット 1000000 を超える続きの要求は明示的に失敗します。使用できないカーソルや誤った完了判定を避けるため、フィルターを絞り込んでください。ケースデータが 1 MiB を超えるページも明示的に失敗します。レコードが省略された状態で受け入れるのではなく、limit を小さくして再試行してください。安定した ID によるタイブレークを使用しますが、同時編集によってオフセットページの内容がずれることがあります。
ページネーションの例: {"project":"test-bed","limit":50,"offset":0} を指定して list_test_cases を呼び出します。一致件数が 55 件の場合、応答には total:55, has_more:true, next_offset:50 が含まれます。残り 5 件を取得するには offset:50 を指定して繰り返し、has_more:false, next_offset:null を確認します。
create_test_case — 必須の project セレクター（UUID、slug、完全一致の名前、またはチケットのプレフィックス。先に list_projects を呼び出してください）でテストケースを作成します。テンプレートは 2 種類あります。steps（デフォルト）は steps 配列を使ったステップごとの { action, expected } グリッド、text は text_content を使った単一の自由形式の説明です。両方のフィールドを同じ呼び出しで送信できます。任意の urls 配列（http/https URL を最大 10 件）を指定すると、参照リンクを添付できます。この機能は 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 は id で UUID または完全な短縮 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 を使う前に、ワークスペースのコンテキストを切り替えてください。ダッシュボードの短縮 ID URL を共有する場合は、?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）を指定して、テストケースフォルダーを 1 件直接読み取ります。フォルダーレコードのみを返し、子孫フォルダーやテストケースを暗黙的に読み込むことはありません。そのワークスペースとプロジェクトへのアクセスが必要です。API キーを使用する呼び出し元には test_cases:read が必要です。
list_test_cases、create_test_case、bulk_update_test_cases に対するテストケースの type 値: functional（作成時のデフォルト）、regression、smoke、integration、performance、security、usability、exploratory。無効な型は書き込み前に拒否されます。エンドツーエンドのフローには integration を使用してください。e2e、accessibility、other はテストケースの型として受け付けられません。自動化スクリプトの型は別の仕様です。
create_test_case_folder — list_projects が返す必須の project 内にフォルダーを作成します（parent_folder_id を使って最大 3 階層までネストできます）。ワークスペースへの contributor 以上のアクセス権と、プロジェクトへのアクセス権が必要です。API キーを使用する呼び出し元には test_cases:write も必要です。
update_test_case_folder — フォルダー UUID で更新します。id、任意の name（前後の空白を除去した 1～120 文字）、null 許容の description（最大 50000 文字）、null 許容の parent_folder_id、および null 許容の card_color を指定できます。親 UUID を指定すると、同じワークスペースとプロジェクト内でフォルダーとそのサブツリーを移動します。null を指定するとルートに移動します。色には小文字のパレット #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd を指定できます。null を指定すると色がクリアされます。省略したフィールドは保持されます。少なくとも 1 つの更新フィールドが必要です。不明なフィールド、スペルミスのあるフィールド、無効なフィールドがあると、変更を一切保存せずリクエスト全体を拒否します。自分自身または子孫を親にする循環、兄弟・直接の親・直接の子と一致する名前（大文字・小文字と前後の空白を無視）、およびサブツリーの深さが 3 を超える場合（ルートの深さは 0）は拒否されます。子孫の深さはアトミックに更新されます。ケース ID と所属関係は変わりません。同時に競合する変更があると失敗する場合があります。再試行する前にフォルダーを再読み込みしてください。アクティブなプロジェクトへの contributor 以上のアクセス権が必要です。API キーには test_cases:write も必要です。例: {"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 — id で UUID または完全な短縮 ID を指定し、既存のケースをパッチ更新します。次のうち少なくとも 1 つのフィールドが必要です: name（またはエイリアス title）、description、preconditions、steps、template_type、text_content、priority、type、status、folder_id。省略したフィールドは保持されます。steps は配列全体を置き換えます（[] はクリアします）。明示的な null を指定すると、description、preconditions、text_content、またはフォルダー配置がクリアされます。空の text_content もクリアとして扱われます。name と title の両方を送信する場合は、一致している必要があります。優先度と型には作成時の列挙値を使用します。status は active、draft、または deprecated です。型を変更すると、PATCH API と同様に type_tags が新しい型に合わせて更新されます。ワークスペースやプロジェクトの移動、ファイルメタデータの書き込みには対応していません。フォルダーは同一のワークスペースとプロジェクトに属している必要があります。test_cases:write が必要です。ケースの概要、id、short_id、case_number、changed を返します。値に変更がない場合は changed: false が返されます。更新が確認されても履歴エントリが確認できない場合は warnings が返されます。履歴を修復するために更新を繰り返さないでください。同時変更エラーが発生した場合は、再試行前にケースを再読み込みしてください。スイートへの所属は別の操作です。このツールで suite_id を使わず、以下の一括ツールを使用してください。削除ツールは公開されていません。
bulk_update_test_cases — 1～500 件のケース UUID に対して 1 つの操作を適用します。単一ケースの場合は ID を 1 つ渡してください。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 で対象を検索してください（スイートの検索には、API キーの場合 test_runs:read が必要です）。フォルダーは単一のカタログ上の配置先です。スイートは多対多のテスト計画への所属です。対象は、認可された同一ワークスペースと完全一致するプロジェクトに属している必要があります。従来のスコープ未指定ケースも同様です。アクセスできないケース ID は詳細を示さずスキップされます。不一致の対象は拒否されます。作成対象が無効な場合、ケースを作成する前に失敗します。
部分的な作成: ケースの作成とスイートへの追加は別々の書き込みです。追加に失敗すると、応答には作成されたケース ID、suite_id: null、および warnings 配列が含まれます。create_test_case を繰り返さないでください。返された ID に対して add_to_suite を指定し、bulk_update_test_cases を再試行してください。
link_test_case_to_bug — テストケースとバグレポート UUID（verified_by、covers、または relates）の間にトレーサビリティを設定します。両方のレコードがアクティブなワークスペースに属し、呼び出し元がアクセスできるプロジェクトに属している必要があります。
list_test_case_links — テストケースのトレーサビリティリンクをすべて一覧表示します。
list_test_case_review_candidates — デッドテストのフラグ: never_run（作成から 90 日以上）、always_passes（90 日間に 5 回以上連続で成功）、always_skipped（3 回以上連続でスキップ）。
mark_test_case_review_flags — 現在のアーカイブ候補フラグを test_cases.review_flag に保存します。pg_cron により毎週月曜日 09:00 UTC に自動実行されます。

インポート

Figma インポート（Enterprise）（ダッシュボードセッションのみ）: Figma フレームの zip エクスポートをアップロードします（最大 100 MiB）。Claude が各画面を分析し、選択または作成したフォルダーにテストケースのドラフトを作成します。デコード前に、アーカイブはエントリ数 1,000 件、エントリごとの展開後（デコード後）サイズ 20 MiB、展開後データの合計 100 MiB に制限されます。無視されるファイルやディレクトリも予算に含まれます。デコードされたフレームバッファーは、宣言されたサイズと一致する必要があります。不正なアーカイブ、サイズの不一致、制限超過がある場合、AI 分析の前にジョブが失敗します。ストレージのクリーンアップポリシーに従い、失敗時も元のアップロードは再試行用に保持されます。有効なアーカイブは、プロンプトキャッシュ、429 再試行、フレームごとの AI エラー分離を備えた複数パスのパイプライン（分類 → 画面ごとのケース → 共通プレフィックスを持つ画面をまたぐフローレベルのケース → 自己批評）に進みます。ケースは status=active として作成され、ai_generated=true のタグが付与されます。source='figma' と source_frame_name により、元のフレームへのリンクが保持されます。プラットフォームの Anthropic キーを使用するため、チームごとの Claude 接続は不要です。

スイートと実行

list_test_suites — 任意の柔軟な project フィルターを指定して、アクセス可能なテストスイートを最大50件一覧表示します。各スイートには正確な整数の case_count が含まれます。これは、すべてのステータスの直接割り当てられたケース数であり、子孫は含まず、他のワークスペースまたは他のプロジェクトのケースは除外されます（従来のプロジェクト未設定のケースは引き続き含まれます）。件数は取得したメンバーシップ行数によって制限されません。APIキーを使用する呼び出し元は、実行ワーカーとの後方互換性のために test_runs:read が必要です。
get_test_suite — 必須の id（UUID）を指定して、1つのテストスイートを直接読み取ります。子スイートやメンバーのテストケースを暗黙的に読み込まず、スイートレコードのみを返します。そのワークスペースとプロジェクトへのアクセスが必要です。APIキーを使用する呼び出し元には test_runs:read が必要です。
create_test_suite — list_projects が返す必須の project にスイートを作成します。parent_suite_id を使って最大3階層までネストできます。APIキーを使用する呼び出し元には test_cases:write が必要です。
update_test_suite — スイートUUIDで更新します。対象は id、任意の name（トリミング後1～120文字）、nullを指定できる description（最大50000文字）、および status（active/archived）です。省略したフィールドとケースのメンバーシップは保持されます。アクティブなコントリビューター以上のプロジェクトアクセスと 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 — スイート名、担当者、合格／不合格の概要とともにテスト実行を一覧表示します。ダッシュボードにアップロードされた実行証跡は、ダッシュボードのセッションと、その実行のワークスペースおよびプロジェクトへのアクセスが必要なプライベートリンクを使用します。MCP APIキーではファイルにアクセスできません。
create_test_run — ダッシュボード管理のスイート実行を作成します。親スイートを実行すると、すべての子孫サブスイートに含まれるすべてのケースが自動的に追加されます（両方にリンクされたケースは1回だけ追加されます）。各 test_run_results 行には、ケースの元となったサブスイートが記録されるため、結果ページで起点ごとにグループ化できます。

外部エージェントによる実行

これらのツールを使うと、Hermesなどのエージェントランタイムが、QAの信頼できる情報源にならずに承認済みスイートを実行できます。test_runs:read と test_runs:write のみを持つ、ワークスペーススコープのキーを使用してください。プロジェクトの境界はスイートによって決まり、呼び出し元が上書きすることはできません。

start_test_plan — 安定した external_run_id を使って、不変のスイートスナップショットを開始または再開します。同じIDを再度指定すると、重複した実行を作成せず、一致する既存の実行と最初のページを返します。
get_test_run_plan — 正規の実行状態と安定したプランページを読み取ります。前回の next_cursor を渡してください。ページのデフォルトは100ケースで、上限は200です。
report_test_results — passed、failed、blocked、または skipped のステータスで、1～200件の結果を送信します。同一内容の再試行は安全です。別のステータスでケースを上書きしようとすると拒否されます。
abort_test_run — 中断された実行を冪等に停止し、受け付け済みの部分的な結果と正規の概要を保持します。

クォータの動作： 同じ external_run_id を指定して start_test_plan を再試行すると、追加の実行枠を消費せずに一致する実行を再開できます。データを削除しても、月間の実行使用量はリセットされません。

ランタイムの境界： ケースのスナップショットには、認証情報、ファイル本文、プライベートな添付ファイルのパスは含まれません。MVPでは、結果の証跡はテキストです。対象の認証情報は実行ランタイム内に保持されます。ブラウザー、モデル、ネットワークのコストは引き続き顧客側の負担となり、顧客は対象へのアクセスとネットワークの送信先を制限する必要があります。不具合とリリースの判断は、引き続き人間が責任を負います。

Hermes Agent guide は、この一連の処理をbugAgentが保守するコミュニティスキルとしてまとめています。public starter kit には、そのまま使える設定とインストール可能なスキルが含まれています。これはNous Researchの公式インテグレーションではありません。

レポート（Tier 1 + Tier 4分析）

get_test_reports_overview — 指定期間の主要KPI（合格率、完了した実行数、実行したケース数）と、直前の同等期間との差分を返します。ReportsタブのKPI欄に表示されるものと同じ数値です。保存済みのProject Reportは作成されません。EnterpriseのXLSX Project Reportとそのスケジュールはダッシュボードで管理します。このリリースでは、保存済みのレポート成果物に対応するMCPツールは有効になっていません。
ダッシュボードのレポート操作： Reportsタブでは、複数のスイート（子孫を含む）を組み合わせて、1つのフィルタ済みレポートを作成できます。完了した実行には、対象範囲の分母としてその実行に含まれるケースを使う「Export PDF」操作もあります。これらのダッシュボード操作によってMCPツールのパラメーターが追加されることはありません。単一実行のPDFダウンロードにはダッシュボードのセッションが必要です。
ダッシュボードのケースフィルター： CSVエクスポートには、現在のCasesフィルターが一致するすべてのページに適用されます。Suite HealthとCoverage by suiteでは、選択したスイート範囲内で、子スイートが実際の親の下にグループ化されます。階層のみの親には、子の指標を集計せず、ダッシュが表示されます。同じケースを共有する無関係なスイートは引き続き除外されます。これらの修正によってMCPツールのパラメーターが変わることはありません。
get_test_reports_failures — 「何を修正すべきか？」を示す4つのリスト：failing_cases（不合格率50%以上、実行数3回以上）、flaky_cases（合格／不合格の切り替わりが最多）、failing_suites（不合格率30%以上、実行数5回以上）、regressed_cases（期間内に以前は合格しており、直近の実行で不合格）。

ワークフローの例

create_test_case_folder → フォルダーツリーを作成します（例：Smoke → Auth）。同じプロジェクトでテストケースを作成する際は、返されたフォルダーIDを使用してください。ダッシュボードのNew Test Caseフォームでも、フォルダーをインラインで作成できます。
create_test_case → ケースを定義し、update_test_case で内容を編集し、bulk_update_test_cases でスイートのメンバーシップを整理します。
tools/callの例：{"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}}。省略した優先度、タイプ、説明は変更されません。
create_test_suite → テスト計画を作成します（サブスイートは任意、最大3階層）。
create_test_run → 親スイートから、人間／ダッシュボード管理の実行を作成します。サブスイートは自動的に含まれます。
start_test_plan → 再試行に安全な外部エージェント実行を開始または再開します。
get_test_run_plan → 不変のプランの全ページを取得し、選択したランタイムで実行します。
report_test_results → 上限付きの結果バッチを返します。安全に実行を続けられない場合は abort_test_run を呼び出します。
get_test_reports_failures → 実行完了後に「今週は何を修正すべきか？」を確認します。
get_test_reports_overview → 週ごとの合格率の推移を追跡します。

⚡

Team Booster

scale_team — ブースターテスターを活用して、QAチームをすぐに拡大できます。アカウントはテスター権限で自動的にプロビジョニングされます。team_size（1～10）、location、duration、budget、および任意の product_url、product_types、tech_levels を指定してください。Enterpriseプランで利用できます。承認されるまで料金は発生しません。

ワークフローの例

scale_team → 米国でシニアテスター5名を1か月間プロビジョニングします。
list_team_members → 新しいテスターがチームに表示されることを確認します。
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 とリンク済みアプリ ID が含まれます。
create_mobile_automation — テストスクリプトを作成します。name、app_id、script_type（YAML の場合は maestro、Appium Python の場合は appium、Appium JavaScript の場合は appium_js）、および script が必要です。アプリがすでにプロジェクトに紐付いていない場合は project_id を渡します。外部検証済みの自己完結型 Maestro YAML フローを 1 つ使用する場合は、execution_mode を browserstack_maestro に設定します。それ以外の場合、デフォルトは appium_actions です。YAML の appId は、リンク済みアプリに保存されたパッケージ ID またはバンドル ID と一致する必要があります。保存されていない場合は、最初に検証されたネイティブフローによって設定されます。プレースホルダーのアプリ ID と難読化された Android リソース ID は拒否されます。インラインの runFlow はサポートされていますが、外部フロー／スクリプトファイルへの参照は v1 では拒否されます。ネイティブ Maestro は、inputRandomText や copyTextFrom などのコマンドと、${maestro.copiedText} や ${output.value} などのランタイム式を保持します。同じプロジェクトの credential_id から、${USERNAME} / ${PASSWORD} の完全な inputText 値を指定できます。同じプロジェクトの variable_profile_id を使うと、参照される ${DATA_*} 値のデフォルトを保存できます。参照されるすべてのキーが存在している必要があります。データプロファイルには、秘密情報を含まない合成データのみを使用してください。
import_mobile_script — 既存のモバイルテストスクリプトをインポートし、実行可能な自動化に変換します。開発者独自のロケーターを保持するため、実行時に要素を正確に特定できます。サポートされる方言: Appium‑Python、WebdriverIO、Maestro（YAML フロー）、Playwright（モバイル Web）。難読化された Android リソース ID のプレースホルダーはスキップされ、セレクターマッピングの 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_*} キーが存在している必要があります。非公開のログインプロファイルには、その作成者がアクティブである必要があります。共有ログインプロファイルには、同じプロジェクトへのアクティブなアクセスが必要です。既知の認証情報と完全に一致する値はフィルタリングされ、データプロファイルの値と完全に一致するものは、保存されたテキスト上の証拠に基づいてベストエフォートでフィルタリングされます。変換済み、一部のみ、エンコード済み、またはアプリから取得したデータ値は残る場合があります。許可された非公開の動画／スクリーンショットは引き続き利用でき、テスト対象アプリに表示された値が映る場合があります。そのため、データプロファイルには秘密情報を含まない合成値のみを使用してください。認証情報の秘匿化に必要なコンテキストを利用できない場合、または安全なサニタイズを証明できない場合は、認証情報を含む詳細なテキストは非表示になりますが、ステータスと利用可能な視覚的証拠は引き続き表示されます。診断情報の利用には、ワークスペースとプロジェクトの認可が必要です。メディアリンクの有効期限は 5 分です。
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 — 呼び出し元が閲覧できるプロファイルのみを一覧表示します。任意で 1 つの 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、および {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"} などの variables オブジェクトを使って、再利用可能なプロジェクトスコープの合成テストデータを作成します。キーは大文字の DATA_* 識別子である必要があります。プロファイルには 1～100 個の文字列を設定でき、各値は UTF-8 で 4096 バイト、合計で 65536 バイトまでです。予約済みの認証情報／ランタイム名は拒否されます。認証情報、トークン、本番環境の個人データ、その他の秘密情報は保存しないでください。
list_mobile_variable_profiles — 認可された 1 つの project_id に対して、Mobile/Both プロファイルと、読み取り可能な秘密情報を含まない値を一覧表示します。プロジェクトの割り当てルールが適用されます。既存のプロファイルとモバイル作成時のデフォルトは both です。作成／更新では platform（mobile または both）を指定できます。Web 専用プロファイルは、モバイルのカタログアクセスとランタイム使用から除外されます。
update_mobile_variable_profile — プロファイル名を変更するか、id によって完全な variables オブジェクトを置き換えます。アクティブな作成者、またはアクティブなワークスペースのオーナー／管理者のみが更新できます。
delete_mobile_variable_profile — id によってプロファイルをソフト削除します。アクティブな作成者、またはアクティブなワークスペースのオーナー／管理者のみが削除できます。自動化のデフォルト設定はクリアされますが、過去の実行参照は保持されます。
list_mobile_schedules、create_mobile_schedule、delete_mobile_schedule — 実機スケジュールを一覧表示、作成、削除します。スケジュールには、選択した自動化のプロジェクトコンテキスト、ログインプロファイル、秘密情報を含まない変数プロファイルが引き継がれます。非公開のログインプロファイルには、その作成者がアクティブである必要があります。共有ログインプロファイルには、同じプロジェクトへのアクティブなアクセスが必要です。秘密情報を含まない変数プロファイルには、作成者またはオーナー／管理者のポリシーが適用されます。スケジュールの変更と削除は、アクティブなスケジュール作成者、またはアクティブなワークスペースのオーナー／管理者に制限されます。

Web テストデータカタログ

同じ秘密情報を含まないプロジェクトカタログを Automate Web から利用できます。これらのツールには、読み取りを含め、ワークスペースの automation エンタイトルメントと automations:write API キースコープが必要です。Mobile へのアクセスは不要です。値が暗号化されたログインプロファイルのレコードと共有されることはありません。カタログはまだ Web 実行へのプロファイル値の紐付けや注入には対応していません。

create_web_variable_profile: 必須項目は project_id、name、variables です。platform（web または both）は任意で、デフォルトは web です。モバイルと同じ DATA_* の制限が適用されます。platform を含むプロファイルを返します。
list_web_variable_profiles: 必須項目は project_id です。Web/Both レコードのみを含む { profiles: [...] } を返します。
get_web_variable_profile: 必須項目は id です。アクセス可能な Web/Both プロファイルと、その合成値を返します。
update_web_variable_profile: 必須項目は id です。name、完全な置き換え用の variables、または platform（web または both）は任意です。アクティブな作成者、またはアクティブなワークスペースのオーナー／管理者が必要です。Both を Mobile に絞り込むには、Mobile へのアクセス権を使って Mobile カタログを利用してください。
delete_web_variable_profile: 必須項目は id です。同じ管理権限が適用されます。ソフト削除を行い、監査履歴を保持したまま { deleted: true } を返します。

例: list_projects を使ってプロジェクトを解決し、{"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}} を指定して create_web_variable_profile を呼び出した後、list_web_variable_profiles で確認します。アクセスできないプロジェクト／プロファイルは、値を公開せずにエラーになります。無効なデータやプロジェクト全体で重複する名前は拒否されます。

ワークフロー例 — Android

list_projects → 対象の project_id を解決
upload_mobile_app → そのプロジェクトに APK を登録
ダッシュボードに安全に記録するか、import_mobile_script / create_mobile_automation を使用
list_mobile_automations → 同じプロジェクト内の自動化を解決
run_mobile_automation → 必要に応じてログインプロファイルを指定し、実機で実行
list_mobile_runs → ステータス、結果の概要、非公開の視覚的リンク、BrowserStack セッションのメタデータを確認
失敗時には、失敗時のスナップショットとステップの内訳を含むバグレポートが自動作成されます

ワークフロー例 — iOS

upload_mobile_app → 実機実行用に project_id を指定して IPA を登録
アプリ詳細ページでシミュレーター .app ビルドをアップロード（録画用）
ブラウザーでテストを記録 → シミュレーターから操作をキャプチャ
run_mobile_automation → 保存済みの自動化を iPhone で実行（IPA を使用）
update_mobile_app → 新しいバージョンが用意できたら IPA を置き換え

ワークフロー例 — ネイティブ Maestro

upload_mobile_app → 対象プロジェクトに APK または IPA を登録
create_mobile_credential → 認証が必要なフローの場合、同じプロジェクトのプロファイルを任意で作成
create_mobile_variable_profile → フローで使用する、同じプロジェクトの合成 DATA_* 値を任意で作成
create_mobile_automation → リンク済みアプリの正確なパッケージ／バンドル appId、script_type: maestro、および execution_mode: browserstack_maestro を含む、動作確認済みの YAML フローを 1 つ渡します。ログインには ${USERNAME} / ${PASSWORD} を、合成入力には ${DATA_EMAIL} 形式のプレースホルダーを使用します。デフォルトを保存するにはプロファイル ID を渡します。
run_mobile_automation → 互換性のあるデバイスを選択し、必要に応じてログインプロファイルまたは変数プロファイルを上書きします。変数プロファイルを省略すると引き継がれ、null を渡すとその実行では無効になります。
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（Art. 5、25、32、33）のコンプライアンス要件への対応に役立ちます。

対応クライアント

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

ターミナルから bugAgent 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 コミュニティ

Discord に参加して、リアルタイムのサポートやコミュニティでのディスカッションをご利用ください。

メールサポート

support@bugagent.com — 通常、24 時間以内に返信します。