Testdino MCP

TestDino MCP

TestDino を AI エージェントに接続する Model Context Protocol（MCP）サーバーです。このサーバーを使うと、自然言語のコマンドで TestDino のテストデータを直接操作できます。

クイックスタート

これを MCP クライアントの設定（Cursor の場合は ~/.cursor/mcp.json）に追加し、クライアントを再起動します。

{
  "mcpServers": {
    "TestDino": {
      "command": "npx",
      "args": ["-y", "@testdino/mcp"],
      "env": {
        "TESTDINO_PAT": "your-pat-here"
      }
    }
  }
}

TestDino → User Settings → Personal Access Tokens から PAT を取得し、アシスタントに 「TestDino の状態を確認して」 と尋ねてください。アカウント、組織、プロジェクトが表示されます。Cursor と Claude Desktop の詳しい設定方法は、インテグレーションをご覧ください。

これは何ですか？

この MCP サーバーは、TestDino のテスト管理プラットフォームと AI エージェントをつなぎます。TestDino のダッシュボードを手動で操作する代わりに、AI アシスタントに次のように依頼できます。

• テスト実行の結果を確認する
• テストの失敗を分析する
• テストケースの詳細情報を取得する
• 手動テストケースとスイートを管理する
• リリースを計画し、手動テスト実行を開始して、テスターを割り当てる
• 探索的テストのセッションを実行する
• チャットからテストケースごとの判定（合格／失敗／ブロックなど）を記録する

すべて、簡単な会話形式のコマンドで行えます。

機能

• 🔍 ヘルスチェック：接続を確認し、TestDino PAT を検証します。アカウント情報を取得し、利用可能なすべての組織とプロジェクトを一覧表示します。
• 📊 テスト実行管理：テスト実行を一覧表示し、詳細情報を取得します。ブランチ、日時、作成者、コミット、環境によるフィルタリングが可能です。
• 🧪 テストケース分析：個々のテストケースについて、エラー、ログ、実行手順、アーティファクト（スクリーンショット、動画、トレース）などの包括的な詳細を取得します。
• 🐛 AI 支援デバッグ：履歴データの集約、失敗パターンの分析、AI に適したデバッグ用プロンプトを活用して、テストケースの失敗をデバッグします。複数回の実行にわたるパターンを分析し、根本原因を特定します。
• 🧭 テスト品質監査：サーバーが用意した監査プロンプトとブランチのシグナルを取得し、ローカルのテストコードを分析して、ソースファイルをアップロードせずに監査レポートを TestDino に保存します。
• 📝 テストケース管理：手動テストケースの作成、更新、一覧表示、取得ができます。ステータス、優先度、重大度、タイプ、レイヤー、動作、タグによる包括的なフィルタリングと整理が可能です。
• 📁 テストスイートの整理：テストスイートの階層を作成、管理して、手動テストケースを整理します。
• 🚀 リリース計画：リリース（別名マイルストーン）の作成、閲覧、更新ができ、最大 3 階層までネストして、リリース内のすべての実行について集計された進捗統計を追跡できます。
• ▶️ 手動テスト実行：特定のスイートまたはプロジェクト全体を対象とする実行を開始し、リリースに関連付けて、チャットから離れずにワークフローの状態を更新できます。
• ✅ ケースごとの割り当てと判定：実行内で、各テストケースをテスター（ユーザー _id またはメールアドレスで指定）に割り当て、結果を passed、failed、blocked、skipped、retest に設定できます。UI と同じ操作が可能です。
• 🔭 探索的テストセッション：ミッション／チャーターを設定した探索的テストセッションを作成し、テスターを割り当て、リリースにリンクして、状態を追跡できます。
• 🧩 大規模な失敗トリアージ：実行で失敗したテストを根本にあるエラーの特徴ごとにグループ化し、複数の失敗が同じ根本原因によるものか、別々の原因によるものかを確認できます。これにより、本当の問題を優先して修正できます。
• 🔗 課題トラッカーとの連携：Jira、Linear、Asana、または monday.com に接続し、失敗したテストや実行から直接、追跡可能な課題を登録できます。チャットから離れずに、その後のステータスも確認できます。
• 🔌 MCP 互換：Model Context Protocol 標準に基づいて構築されています。MCP 互換の IDE や AI エージェント（Cursor、Claude Desktop など）で TestDino MCP を設定できます。
• ⚡ 簡単なセットアップ：npx を使って数分でインストール、設定できます。インストールは不要です！
• 🔐 セキュア：PAT はローカル設定に安全に保存されます。1 つの PAT で、権限を持つすべての組織とプロジェクトにアクセスできます。

利用可能なツール

サーバーは 12 のドメインにわたって 57 個のツールを提供します。ホスト型 TestDino MCP と同じツール、プロンプト、スキルガイドを利用できます。

テスト実行と結果：

1. health - 接続を確認し、PAT を検証します。アカウント情報、アクセス可能な組織、アクセス権限のあるプロジェクトを表示します。
2. list_testruns - フィルター（ブランチ、期間、作成者、コミット、環境）を指定してテスト実行を参照します。ページネーションと一括操作に対応しています。
3. get_run_details - 統計、テストスイート、テストケース、メタデータなど、特定のテスト実行の詳細情報を取得します。一括操作に対応しています（カンマ区切りの ID、最大 20 件）。
4. list_testcase - 包括的なフィルター（テスト実行、ステータス、ブラウザー、エラーカテゴリー、ブランチ、環境、コミット、作成者、仕様ファイル、タグ、実行時間、アーティファクトなど）を指定してテストケースを一覧表示します。テスト実行の条件、またはテストケースのプロパティを直接指定して絞り込めます。
5. get_testcase_details - エラーメッセージ、スタックトレース、テスト手順、コンソールログ、アーティファクトなど、特定のテストケースの詳細情報を取得します。testcase_id のみ、または testrun_id/counter と testcase_name を指定して識別できます。
6. debug_testcase - 複数回の実行にわたる過去の失敗データを集約して、テストケースをデバッグします。失敗パターン、エラーカテゴリー、よくあるエラーメッセージ、エラー箇所、ブラウザー固有の問題、および AI 分析用に事前に整形されたデバッグプロンプトを返します。根本原因の分析や、不安定なテストの挙動の特定に最適です。
7. get_debug_evidence - 失敗したテストの調査は、まずここから始めてください。1 回の呼び出しで、試行ごとのシグネチャを含むフレーク判定、回帰の境界（最後の成功 → 最初の失敗）、保存済みアーティファクト（トレース、スクリーンショット、画像差分）の短時間有効なダウンロードリンクをすべて取得します。JSON または Markdown で返します。
8. get_flake_verdict - 1 回の実行内でテストの再試行を比較し、失敗が繰り返されるかどうかを deterministic、flaky、inconclusive のいずれかで判定します。
9. verify_fix - 新しい実行が記録された後、失敗が確認された実行と照らし合わせて、修正が有効かどうかを確認します。fixed、not_fixed、changed_failure、still_failing、unstable、no_runs_since_baseline、baseline_not_found のいずれかを返します。
10. get_audit_report - 監査コンテキスト（サーバーが用意したプロンプトと、ブランチで失敗が多いテスト、フレークが多いテスト、遅いテストの一覧）を取得します。新しい監査の開始、過去のレポートの参照、または reportId によるレポートの取得に使用できます。
11. submit_audit_report - 完了した監査レポート（スコア、指摘事項、推奨事項、Markdown）を TestDino に送信します。

テストケース管理：

12. list_manual_test_cases - 包括的なフィルター（プロジェクト、スイート、ステータス、優先度、重大度、タイプ、レイヤー、動作、自動化ステータス、タグ、フレークの有無）を指定して、手動テストケースを検索し、一覧表示します。
13. get_manual_test_case - 手順、カスタムフィールド、事前条件、事後条件、すべてのメタデータなど、特定の手動テストケースの詳細情報を取得します。
14. create_manual_test_case - 手順、事前条件、事後条件、メタデータ（優先度、重大度、タイプ、レイヤー、動作）を指定して、新しい手動テストケースを作成します。
15. update_manual_test_case - 既存の手動テストケース（タイトル、説明、手順、ステータス、優先度、重大度、タイプ、レイヤー、動作、事前条件、事後条件）を更新します。
16. list_manual_test_suites - テストスイートの階層を一覧表示し、整理に使用するスイート ID を確認します。親スイートで絞り込めます。
17. create_manual_test_suite - テストケースを整理するための新しいテストスイートフォルダーを作成します。parentSuiteId を指定すると、ネストされたスイートを作成できます。

自動化との紐付け： 18. list_automated_tests - プロジェクトについて TestDino が把握している Playwright テストを一覧表示します。リンクに使用する pwTestId と fullTitle の情報源です。スペックファイル、スイート、またはタイトルのフリーテキストで絞り込めます。 19. get_test_case_links - 手動テストケースにリンクされている自動テストと、その最新の自動化結果を表示します。 20. link_automated_test - 1 つの Playwright テストを手動テストケースにリンクし、そのケースに自動化結果が表示されるようにします。 21. unlink_automated_test - 手動テストケースと Playwright テストのリンクを解除します。 22. bulk_link_automated_tests - 1 回の呼び出しで最大 500 組のケースとテストをリンクします。項目ごとの結果が返されるため、一部失敗を確認できます。

リリース（マイルストーンとも呼ばれます）：

23. list_releases - プロジェクトのリリースを、検索、種類、完了状況、親リリースで絞り込んで表示します。リリースには実行とセッションがまとめられ、最大 3 階層までネストできます。
24. get_release - 日付、ステータス、親／ルートの階層、およびこのリリースと子孫リリースのすべての実行を集計した進捗状況など、1 つのリリースの詳細を取得します。内部 _id または MS-12 のようなカウンター形式の ID を指定できます。
25. create_release - 名前、種類、日付、および任意の親リリースを指定して、新しいリリースを作成します。
26. update_release - 既存のリリースの名前、日付、完了フラグ、種類、リンク済み課題を変更します。クローズ済みのリリースも編集できます。

手動テスト実行：

27. list_manual_runs - プロジェクトの手動テスト実行を表示します。ステータス、状態、環境、リリース、タグ、または名前のフリーテキスト検索で絞り込めます。
28. get_manual_run - 1 つの実行の詳細を取得します。テスト統計（合計／成功／失敗／ブロック／未テスト）、担当者、添付ファイル、リンク済みリリースが含まれます。内部 _id または RUN-12 のようなカウンター形式の ID を指定できます。
29. create_manual_run - 新しい手動テスト実行を作成します。プロジェクト内のすべてのケースを対象にするには selectionMode='all' を、スイート ID またはケース ID で範囲を指定するには 'selected' を選択します。releaseId を指定してリリースに紐付けられます。
30. update_manual_run - 実行のメタデータ（名前、環境、状態、リリースの紐付け、タグ）を変更します。クローズ済みの実行は読み取り専用ですが、releaseId は変更できます。
31. list_run_test_cases - 実行内のケースごとの実行行を取得します。UI の実行テストケーステーブルに表示される内容と同じです。各行には現在の担当者と現在の結果が含まれます。担当者（メールアドレスまたは _id）や結果で絞り込めます。
32. update_run_test_case - 実行内の 1 つのテストケースの担当者および／または結果を設定します。UI の「Assign to」と結果ピルをクリックする操作と同じです。未テストのケースでも動作し、初回編集時にケースごとの行が自動作成されます。caseKey（TC-156）、テストケースの _id、または内部 tcm_rtc_… ID を指定できます。

探索的テストセッション：

33. list_sessions - プロジェクトの探索的テストセッションを表示します。ステータス、状態、sessionType、担当者（メールアドレスまたは _id）、リリース、タグで絞り込めます。
34. get_session - 1 つのセッションの詳細を取得します。名前、ミッション、ステータス、担当者、リンク済みリリース、検出事項が含まれます。内部 _id または SES-12 のようなカウンター形式の ID を指定できます。
35. create_session - ミッション／チャーター、sessionType、担当者、見積もり、および任意のリリース紐付けを指定して、新しい探索的テストセッションを作成します。
36. update_session - セッションのメタデータ（名前、ミッション、担当者、状態、見積もり、リンク済み課題、添付ファイル）を変更します。

エラー分析：

37. get_run_error_clusters - 実行内の失敗したテストをエラーシグネチャごとにグループ化し、大規模なトリアージを可能にします。同じ根本原因のエラーを共有するテストのクラスターを表示し、任意で status（all、failed、flaky）による絞り込みもできます。実行が失敗した理由を把握するには、list_testruns の後に使用します。

インテグレーション（課題トラッカー）： 38. connect_integration - プロバイダー（Jira、Linear、Asana、monday.com、GitHub）のOAuth接続URLを返します。ユーザーにURLを表示して認証してもらいます。プログラムから開かないでください。 39. get_integration_status - プロジェクトでプロバイダーが接続されているかどうかを報告します。includeCreateOptionsを設定すると、課題作成に利用できるフィールドも取得します。create_external_issueの前に呼び出してください。 40. create_external_issue - 失敗したテストケースや実行などのTestDinoのソースエンティティから、接続済みのトラッカー（Jira、Linear、Asana、monday.com）に課題を登録します。previewと、idempotencyKeyによる冪等な再試行に対応しています。 41. get_external_issue - IDまたはキー（1つまたは複数）を指定して、以前に作成した課題を取得し、プロバイダーでの現在のステータスを返します（Jira、Linear、Asana）。

プロバイダーの対応状況：すべてのプロバイダーで接続とステータス確認ができます。課題の作成はJira、Linear、Asana、monday.comに対応しています。課題の再取得はJira、Linear、Asanaに対応しています。GitHubはPR／CI連携として対応しており、課題トラッカーではありません。

AIインサイト：

42. get_ai_insights - TestDinoのAI分析を3つのレベルで取得します。プロジェクト概要（日付範囲内のカテゴリ別失敗数と主な失敗要因）、実行（AIによる失敗の分類、失敗クラスター、エラー分析テーブル、LLMが作成した要約）、テストケース（推奨事項と簡単な修正案）です。プロジェクトでAI機能がオフになっている場合（Settings → AI）は、disabledステータスを返します。
43. get_trace_analysis - 失敗したテストのホスト済みPlaywrightトレースを、有効期限の短いダウンロードURLに変換し、ローカルでトレースCLIを使ってデバッグするための手順（open → actions → snapshot → close）を返します。

再実行：

44. get_rerun_selection - 完了した実行のテストのうち、再実行の対象となるもの（失敗、フレーキー、両方、または手動で選択したリスト）を判定し、Playwrightの正確な--test-list行と、ローカルで実行するCLIコマンドを返します。また、rerun_mechanismも返します。これは、同じコミットでの再実行が実行自身のGitHub実行内で行われる（そのため失敗チェックが成功に変わる）のか、別のワークフロー実行が開始されるのか、そしてその理由を示します。読み取り専用です。実行は行われません。
45. rerun_test - CIで再実行を開始します。ユーザーが同意した後にconfirm: trueが必要で、modeも必要です。same-commit（失敗したコミット：これらの失敗は実際のものか、フレーキーか？）またはlatest（ブランチの先端：修正は機能したか？）を指定します。デフォルトのモードはありません。モードを省略すると拒否され、選択はユーザーに委ねられます。拒否はすべて、何もディスパッチされる前に行われます。

必ず先に確認してください。 get_rerun_selectionを呼び出し、実行される内容とrerun_mechanismの内容をユーザーに示してから、希望するモードを尋ねてください。再実行にはCIの実行時間がかかります。

テストコントロール（隔離、重要設定、担当者、ウォッチ）：

46. list_test_controls - テストコントロールページに表示されるテストを一覧表示します。隔離中（有効、終了間近、解除済み）、重要設定、ウォッチ中のテスト、または隔離候補のフレーキーテストを表示できます。
47. get_test_controls - 1つのテストの担当者、重要フラグ、ウォッチ状態、有効な隔離設定に加え、過去90日間に隔離によって失敗を防いだ実行を返します。
48. get_quarantine - 1つの隔離設定について、全履歴と対象となった実行を返します。
49. quarantine_tests - 理由を必須として、1～100件のテストを終了日まで隔離します。dry_runを指定すると、実行前に結果を確認できます。
50. update_quarantine - 隔離期間の延長、担当者やメモの変更、チケットのリンクを行います。
51. release_quarantine - 隔離を今すぐ終了します。以降、そのテストの失敗は再びビルドを失敗させます。
52. set_test_critical - テストを重要に設定、または重要設定を解除します（オーナーと管理者が対象です）。
53. assign_test - メールアドレス、ユーザーID、または"me"を指定してテストを割り当てるか、割り当てを解除します。
54. watch_test - テストのウォッチを開始または停止します。

アカウント、プロジェクト、プルリクエスト： 55. get_org_details - プラン、残りの実行回数とリセット時期、実行回数がなくなった場合の動作、プランに対するシート数とプロジェクト数、追加の実行回数、プロジェクトごとのテストの健全性。 56. get_project_details - 1つのプロジェクトの健全性、使用状況、接続済みのインテグレーション、ブランチ → 環境のマッピング、および不安定、低速、失敗、慢性的に失敗、低速化しているテストの上位10件。 57. get_pull_requests - 最新のプルリクエストとそれぞれの最新のテスト実行、または1つのプルリクエストとそのテスト実行。

先に確認してください。 隔離、隔離解除、重要としてマークする操作は、ビルドの失敗条件を変更します。これらのツールは破壊的な操作として設定されているため、クライアントは実行前に確認を求めます。

プロンプト： testdino_guide（スキルガイド）、fix_run（失敗した実行をトリアージして修正計画にまとめる）、fix_case（失敗したテストの根本原因を特定する）、fix_flake（再試行後に失敗したテストを適切な種類の修正に振り分ける）、optimize_swarm（複数マシンでの実行にかかった時間の理由と、改善に役立つ変更点を提示する）。

AI Insights はインラインでも利用できます。get_run_details に include_ai_insights: true を渡すと、実行の AI Insights が ai_insights に追加されます。また、debug_testcase に渡すと、推奨事項と簡単な修正方法が ai_fixes に追加されます。

インストール方法

TestDino MCP の利用方法は主に3つあります。

オプション1：npx 経由（推奨・インストール不要）

• インストールは不要です
• 必要なときに自動でダウンロードして実行します
• 常に最新バージョンを使用します
• MCP 対応プラットフォームで設定できます

オプション2：グローバルインストール

npm install -g @testdino/mcp

• 一度インストールすれば、どのプロジェクトでも使用できます
• Node.js 20+ と npm が必要です
• コマンド testdino-mcp を使用します

オプション3：プロジェクトへのインストール

npm install @testdino/mcp

• プロジェクトの node_modules にインストールされます
• コマンド npx @testdino/mcp を使用します

インテグレーション

Cursor IDE の簡単なインテグレーションガイド：

ステップ1：個人用アクセストークン（PAT）を取得する

1. TestDino アカウントにログインします
2. ユーザー設定 → 個人用アクセストークンに移動します
3. 個人用アクセストークンセクションから新しい PAT を生成します。
4. 重要：この PAT を使用すると、権限のあるすべての組織とプロジェクトにアクセスできます

ステップ2：Cursor を設定する

1. MCP 設定ファイルを開くか作成します：

   • Windows：%APPDATA%\Cursor\mcp.json
   • macOS/Linux：~/.cursor/mcp.json
   • プロジェクト固有：プロジェクトのルートにある .cursor/mcp.json

2. npx を使用する場合、またはプロジェクト内にインストールする場合は、設定を追加します：

{
  "mcpServers": {
    "TestDino": {
      "command": "npx",
      "args": ["-y", "@testdino/mcp"],
      "env": {
        "TESTDINO_PAT": "Your PAT here"
      }
    }
  }
}

重要：Your PAT here を、ステップ1で取得した実際の個人用アクセストークン（PAT）に置き換えてください。

ステップ3：再起動して確認する

1. Cursor を完全に終了して再起動します
2. 「TestDino の状態を確認して」と尋ねて、接続を確認します
3. アカウント名、利用可能な組織、プロジェクトが表示されます！

代替方法：グローバルインストール

npx の使用やプロジェクトへのインストールではなく、グローバルインストールを希望する場合：

npm install -g @testdino/mcp

次に、この設定を使用します：

{
  "mcpServers": {
    "TestDino": {
      "command": "testdino-mcp",
      "env": {
        "TESTDINO_PAT": "Your PAT here"
      }
    }
  }
}

このサーバーは標準の MCP プロトコルを使用しているため、ほかの MCP 対応クライアントでも動作します。

Claude Desktop

Claude Desktop では同じ形式の設定を使用しますが、ファイルの場所は異なります：

• macOS：~/Library/Application Support/Claude/claude_desktop_config.json
• Windows：%APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "TestDino": {
      "command": "npx",
      "args": ["-y", "@testdino/mcp"],
      "env": {
        "TESTDINO_PAT": "your-pat-here"
      }
    }
  }
}

Claude Desktop を再起動し、「TestDino の状態を確認して」と尋ねて確認します。

ローカル開発

デフォルトでは、サーバーは https://mcp.testdino.com と通信します。開発中にローカル API を指定するには、TESTDINO_API_URL を設定します（.env.example を参照）：

TESTDINO_API_URL=http://localhost:3001

使用方法

設定が完了したら、AI アシスタントに自然な言葉で話しかけるだけです。重要：ツールを使用するには、個人用アクセストークン（PAT）を mcp.json の TESTDINO_PAT として設定する必要があります。この PAT を使用すると、権限のあるすべての組織とプロジェクトに自動的にアクセスできます。

コマンドの例

Cursor、Claude Desktop（またはその他のMCP互換クライアント）で、以下の自然言語コマンドを試してみてください。

接続とセットアップ：

• 「TestDinoへの接続が機能しているか確認してください」
• 「TestDinoのPATを検証してください」

テスト実行の確認：

• 「直近5件のテスト実行を表示してください」
• 「developブランチでは、どのテストが実行されていますか？」
• 「過去3日間のテスト実行を一覧表示してください」
• 「作成者johnによるテスト実行を表示してください」
• 「コミットabc123のテスト実行を検索してください」
• 「本番環境のテスト実行をすべて一覧表示してください」

テスト結果の分析：

• 「テスト実行test_run_6901b2abc6b187e63f536a6bの詳細を取得してください」
• 「カウンター42のテスト実行の詳細を取得してください」
• 「テスト実行test_run_6901b2abc6b187e63f536a6bで失敗したテストケースは何ですか？」
• 「直近のテスト実行で不安定だったテストをすべて表示してください」
• 「本番環境で失敗したテストケースをすべて一覧表示してください」
• 「mainブランチのテストケースのうち、実行に100秒以上かかったものを表示してください」
• 「コミットabc123のテストケースで、すべてのタイムアウト問題を検索してください」

テストの失敗のデバッグ：

• 「プロジェクトproj_123のテストケース『Verify user login』をデバッグしてください」
• 「testdinoのレポートから『Verify that User Can Complete the Journey from Login to Order Placement @webkit』をデバッグしてください」
• 「プロジェクトproj_123のテストケース『Checkout flow』の失敗を分析してください」
• 「テスト『API authentication』の失敗にはどのようなパターンがありますか？」
• 「テストケース『User registration』が失敗するのはなぜですか？」
• 「テストケース『Verify that user can login and logout successfully @chromium』をデバッグしてください」

手動テストケースの管理：

• 「プロジェクトproj_123の手動テストケースをすべて一覧表示してください」
• 「プロジェクトproj_123で、タグ『smoke』が付いた手動テストケースを検索してください」
• 「プロジェクトproj_123の優先度が『critical』の手動テストケースをすべて表示してください」
• 「プロジェクトproj_123の手動テストケースTC-123の詳細を取得してください」
• 「Authentication Testsスイートに、ログイン機能の新しい手動テストケースを作成してください」
• 「テストケースTC-123を更新し、非推奨としてマークしてください」
• 「プロジェクトproj_123のテストスイートをすべて一覧表示してください」
• 「プロジェクトproj_123に『Authentication Tests』という新しいテストスイートを作成してください」

リリース：

• 「プロジェクトproj_123のリリースをすべて一覧表示してください」
• 「このプロジェクトで進行中のイテレーションを表示してください」
• 「リリースMS-12の詳細を取得し、集計されたテストの進捗を表示してください」
• 「5月12日から5月26日までのイテレーションとして、『Sprint 42』というリリースを作成してください」
• 「リリースMS-12を完了としてマークしてください」

手動テスト実行：

• 「リリースMS-12の手動テスト実行を一覧表示してください」
• 「stagingで進行中のテスト実行をすべて表示してください」
• 「実行RUN-7の詳細を取得してください」
• 「stagingでAuthenticationスイートを対象に、リリースMS-12に紐づけた『Sprint 42 Smoke』という手動テスト実行を作成してください」
• 「実行RUN-7の状態をDoneに設定してください」
• 「実行RUN-7をリリースMS-13に再度紐づけてください」

テストケースの割り当てと、テスト実行での判定記録：

• 「実行RUN-1のテストケースを現在の担当者と結果とともに一覧表示してください」
• 「実行RUN-1のTC-156を[email protected]に割り当て、Passedにしてください」
• 「実行RUN-1のTC-157をFailedにしてください」
• 「実行RUN-1のTC-158を[email protected]に割り当ててください。結果は未テストのままにしてください」
• 「実行RUN-1で[email protected]に割り当てられていて、まだ未テストのケースをすべて表示してください」

探索的テストセッション：

• 「プロジェクトproj_123のアクティブな探索的テストセッションを一覧表示してください」
• 「[email protected]に割り当てられたセッションを表示してください」
• 「セッションSES-3の詳細を取得してください」
• 「『Auth charter — May 12』という探索的テストセッションを作成してください。ミッションは『2FA周辺のセッション処理のバグを見つける』で、[email protected]に割り当て、見積もり時間は60分にしてください」
• 「セッションSES-3を更新し、Doneとしてマークしてください」

ドキュメント

• インストールガイド：Cursor、Claude Desktop、その他のMCP互換クライアントの詳細なセットアップ手順
• ツールのドキュメント：各ツールのリファレンス。例、パラメーター、ユースケースを掲載
• AIエージェントスキルガイド：ツールの選択パターン、判断ツリー、ベストプラクティスに関するAIエージェント向けガイド

要件

• Node.js：バージョン 20.0.0 以上
• NPM：最新バージョンを推奨（パッケージ管理用）
• TestDino アカウント：Test Runs および／または Test Case Management にアクセスできる有効なアカウント
• Personal Access Token（PAT）：認証に必要です。TestDino Settings → Personal Access Tokens から取得してください

主な機能の説明

debug_testcase による AI 支援デバッグ

debug_testcase ツールは、過去の実行データを分析して、テストが失敗する理由を理解するのに役立ちます。

• 過去の分析：複数のテスト実行からデータを集約し、パターンを特定します
• 失敗パターン：一般的なエラーカテゴリ、メッセージ、発生箇所を特定します
• ブラウザー固有の問題：ブラウザー固有の失敗パターンを検出します
• 不安定なテストの検出：再試行のパターンと不安定さを示す指標を分析します
• AI に適した出力：AI 分析用に事前フォーマットされたデバッグプロンプトを返します
• コードとの関連付け：エラー発生箇所のファイル名と行番号を提示し、AI がソースコードと関連付けられるようにします

ワークフローの例：

1. 「testdino レポートからテストケース 'Verify user login' をデバッグして」と尋ねます
2. AI が projectId と testcase_name を指定して debug_testcase を呼び出します
3. ツールが失敗パターンを含む過去のデータを返します
4. AI がデータを分析し、アクセス可能な場合はテストコードと関連付けます
5. AI がパターンとコード分析に基づいて、具体的な修正案を提示します

サポート

• ドキュメント：ツールの完全なドキュメントについては、docs/TOOLS.md をご覧ください
• インストールのヘルプ：詳細なセットアップ手順については、docs/INSTALLATION.md をご覧ください
• TestDino サポート：[email protected]
• TestDino ドキュメント：https://docs.testdino.com