Skip to main content
Glama
shreyasKaturi2004

test-intelligence-mcp

test-intelligence-mcp

AIコーディングエージェント(Claude Code、Claude Desktop、その他あらゆるMCPクライアント)がPythonリポジトリのテスト健全性(カバレッジ、不安定なテスト、MLベースのプルリクエストリスク予測)を分析できるようにする、MCP(Model Context Protocol)サーバーです。

ステータス: 活発に開発中です。このREADMEはマイルストーンごとに更新されます。現在実際に機能しているものと今後追加予定のものについては、以下のビルドステータスを参照してください。

できること

Pythonリポジトリを指定すると、MCP対応エージェントとの自然言語での会話を通じて、以下のことが可能です。

  • リポジトリのテストスイートをカバレッジ付きで実行し、ファイルごとの実際の数値を取得する(analyze_coverage

  • テストスイートを複数回実行し、実行順序や環境に依存しない、真に不安定なテストを検出する(detect_flaky_tests

  • テスト実行結果をPostgresに保存し、履歴を蓄積する(record_test_run

  • その履歴をクエリして取得する(get_test_history

  • 蓄積された実行履歴を用いて勾配ブースティング分類器を訓練し、プルリクエスト内のどのファイルがテストを壊しそうかを予測する(train_risk_model

  • ブランチをベースブランチと比較し、変更されたファイルごとにランク付けされたリスクスコアを取得する(predict_pr_risk

すべての処理は、実際のサブプロセスによるテスト実行と、coverage.jsonの実際の解析に基づいています。ターミナル出力をスクレイピングしたり、数値を偽装したりするものではありません。

なぜMCPか

MCPは(Anthropicによってオープンソース化され、現在広く採用されている)プロトコルであり、AIエージェントが別のサーバープロセスによって公開されているツールを発見し、標準のJSON-RPCトランスポート(ローカルではstdio、リモートではHTTP/SSE)を介して呼び出すことを可能にします。カスタムAPIを自作してエージェントのシステムプロンプトで教え込む代わりに、型付けされたPython関数を「ツール」として公開します。クライアントはその名前、引数スキーマ、docstringを自動的に発見し、会話の途中で呼び出すことができます。このプロジェクトでは、公式のMCP仕様の上に構築された、人間工学的なPython SDKである**FastMCP**を使用しています。通常の型付けされた関数に@mcp.tool()を付けるだけで、それを公開できます。

技術スタック

項目

選択肢

MCPサーバー

FastMCP

テスト実行

pytest, pytest-cov, coverage.py (coverage.jsonを解析)

データベース

PostgreSQL, 非同期SQLAlchemy 2.0 (AsyncSession), asyncpgドライバ

マイグレーション

Alembic(バージョン管理、create_all()は不使用)

ML

scikit-learn GradientBoostingClassifier

Git操作

GitPython / subprocess

CI

GitHub Actions

ローカルPostgres

Docker + docker-compose

パッケージ管理

uv

リポジトリ構成

test-intelligence-mcp/
  src/test_intelligence/
    server.py       # FastMCP server + tool registration
    config.py        # typed settings, loaded from .env
    safety.py         # repo-path allowlist gate (see Safety below)
    paths.py            # cross-platform file-path normalization
    runners/               # pytest/coverage execution, JUnit + coverage.json parsing
    flaky/                   # multi-run comparison logic, order/seed control
    ml/                        # features.py, synthetic.py, training.py, prediction.py, model_store.py
    db/                        # SQLAlchemy models, session, query helpers
    git/                        # commit/branch metadata (repo_info.py), diff stats (diff.py)
  tests/                       # tests for THIS project's own code
    fixtures/                  # tiny throwaway repos the runner tests execute for real
  scripts/
    ci_report.py         # flaky-check + coverage summary, invoked by CI (see below)
  alembic/             # migration scripts
  .github/workflows/
    ci.yml              # runs on every PR — see Continuous Integration below
  docker-compose.yml  # local Postgres
  pyproject.toml
  .env.example

セットアップ

1. 前提条件

  • Python 3.11+

  • uv — pip + venv + virtualenvに代わる高速でモダンなツールです。ここでは依存関係の管理とコマンドの実行に使用します。 Windowsの場合: winget install -e --id astral-sh.uv

  • Docker Desktop — docker-composeを介してPostgresをローカルで実行するために使用します。マシンにPostgresをインストールする必要はありません。 Windowsの場合: winget install -e --id Docker.DockerDesktop

2. 依存関係のインストール

uv sync

uv syncpyproject.tomlを読み込み、ロックされた依存関係セットを解決し(uv.lockを書き込み/使用)、.venv/を作成します。これは、新しいvirtualenv内でpip install -r requirements.txtを実行するのと同等ですが、より高速で、マシン間で再現可能です。

3. Postgresの起動

docker-compose up -d

これにより、docker-compose.ymlで定義されたPostgres 16コンテナが起動し、localhost:5433で公開されます。認証情報はそのファイルに組み込まれています。(Postgresデフォルトの5432ではなくポート5433を使用することで、既にPostgresがネイティブインストールされている場合の競合を回避します。詳細はdocker-compose.ymlを参照してください。) -dはデタッチモード(バックグラウンド)で実行します。正常に動作しているか確認するには:

docker-compose ps

ステータスがhealthytest-intelligence-postgresが表示されるはずです。

4. 環境設定

cp .env.example .env

.env.exampleのデフォルト値は既にdocker-compose.ymlの認証情報と一致しているため、ローカル開発では通常、TI_ALLOWED_REPO_ROOTS(下記の安全性を参照)以外は変更する必要はありません。

5. データベースマイグレーションの適用

uv run alembic upgrade head

Alembicはalembic/versions/配下の全てのマイグレーションスクリプトを順番に再生し、データベーススキーマを最新バージョンに更新します。SQLAlchemyのBase.metadata.create_all()(現在のモデルコードに一致するテーブルを、過去の状態を記憶せずにその場で作成できるだけ)とは異なり、Alembicはスキーマ履歴を順序付けられたスクリプトのチェーンとして追跡します。そのため、変更はgitでレビュー可能で、元に戻すことができ(alembic downgrade)、開発環境、CI、本番環境で同一に適用されます。

6. MCPクライアントへの登録

Claude Code

claude mcp add test-intelligence -- uv run --directory "C:\path\to\test-intelligence-mcp" test-intelligence-mcp

--directoryを使用することで(後でclaude mcp addを実行した任意のディレクトリに依存するのではなく)、Claude Codeのプロセスが後でサーバーを起動する場所に関係なく、登録が機能するようになります。これは、サーバーが起動時に作業ディレクトリを基準にして.envを読み取るため重要です。

これにより、サーバーがローカルのClaude Code設定にスコープされたstdioトランスポートMCPサーバーとして登録されます。claude mcp listで接続を確認し、新しいClaude Codeセッションを開始して(既に実行中のセッションは、開始後に登録されたサーバーを認識しません)、利用可能なツールの一覧表示を依頼してください。

Claude Desktop

claude_desktop_config.json(Windowsの場合: %APPDATA%\Claude\claude_desktop_config.json)に追加:

{
  "mcpServers": {
    "test-intelligence": {
      "command": "uv",
      "args": ["--directory", "C:\\path\\to\\test-intelligence-mcp", "run", "test-intelligence-mcp"]
    }
  }
}

Claude Desktopを再起動すると、🔨ツールアイコンの下に6つのツールが表示されるはずです。

安全性

これらのツールは、ターゲットリポジトリの実際のテストスイート(つまり任意のPythonコード)をサブプロセスとして実行するため、以下の2つのガードレールが無条件に適用されます。

  • パス許可リスト: 全てのrepo_path引数は絶対パスに解決され、.env内のTI_ALLOWED_REPO_ROOTS(許可されたベースディレクトリのカンマ区切りリスト)と照合チェックされます。許可リスト外のパスは、サブプロセスが実行される前に拒否されます。

  • サブプロセスタイムアウト: 全てのsubprocess呼び出し(pytest実行、gitコマンド)にはハードタイムアウト(.env内のTI_SUBPROCESS_TIMEOUT_SECONDS、デフォルト300秒)が設定されており、ハングアップや無限ループするスイートがサーバーを無期限にブロックするのを防ぎます。

使用例

analyze_coverage

MCP対応エージェントに、例えば次のように依頼します: "Run analyze_coverage on C:\path\to\some-repo"。このツールは、そのリポジトリのテストスイートをカバレッジ付きで実行し(リポジトリが.venv/venvを持っていればそれを使用し、なければこのサーバーのインタプリタにフォールバックします)、以下を返します:

{
  "status": "ok",
  "tests_passed": true,
  "overall_coverage_percent": 87.5,
  "total_statements": 120,
  "total_covered_lines": 105,
  "total_uncovered_lines": 15,
  "files": [
    {
      "file": "pkg/calculator.py",
      "coverage_percent": 80.0,
      "num_statements": 10,
      "covered_lines": 8,
      "uncovered_line_count": 2,
      "uncovered_lines": [12, 13]
    }
  ]
}

filesはカバレッジが低い順にソートされるため、エージェントはすぐにテストが最も必要なファイルを特定できます。ターゲットリポジトリに、解決されたPython環境にpytestpytest-covがインストールされている必要があります。

record_test_run + get_test_history

"Record a test run for C:\path\to\some-repo, then show me the history for pkg/calculator.py" — 最初の呼び出しは、pytestの--junitxml出力を介してスイートを1回実行し(ターゲットリポジトリにはpytestだけで十分で、プラグインは不要です)、Repository/TestRun/TestResultの行セットをPostgresに永続化し、それが実際のgitリポジトリである場合、ターゲットリポジトリの現在のコミットSHAとブランチ(GitPython経由)で実行にタグを付けます:

{
  "status": "ok",
  "run_id": 3,
  "repo_id": 1,
  "commit_sha": "a1b2c3d...",
  "branch": "main",
  "duration_seconds": 0.52,
  "total_tests": 3,
  "passed_count": 1,
  "failed_count": 1,
  "skipped_count": 1
}

get_test_historyは、record_test_runによって既に書き込まれた行のみを読み取ります。それ自体が実行をトリガーすることは決してなく、このサーバーがこれまでに記録した全てのリポジトリを横断してクエリを実行し(repo_path引数はありません)、オプションで1つのfile_pathにフィルタリングできます:

{
  "status": "ok",
  "count": 2,
  "history": [
    {
      "repo_name": "C:\\path\\to\\some-repo",
      "run_id": 3,
      "commit_sha": "a1b2c3d...",
      "branch": "main",
      "started_at": "2026-08-16T00:20:11+00:00",
      "node_id": "tests/test_calculator.py::test_divide",
      "file_path": "tests/test_calculator.py",
      "outcome": "passed",
      "duration_seconds": 0.001,
      "error_message": null
    }
  ]
}

detect_flaky_tests

"Run detect_flaky_tests on C:\path\to\some-repo with 5 runs" — スイートをruns回実行します。この際、既知のテスト順序ランダム化プラグイン(pytest-randomlypytest-random-order)を明示的に無効にするため、テスト順序は毎回同一になります。これにより、テストが実行ごとに自身と矛盾する唯一の説明として、真の非決定性(タイミング、共有状態、テスト対象コード内のシードされていないランダム性)を分離します。順序シャッフルプラグインがあると、順序依存の障害と本当の不安定性を区別できなくなります。大きなスイートで5回以上の連続実行には時間がかかる可能性があるため、進行状況はMCP進行状況通知(対応するクライアントから可視)を介してストリーミングされます:

{
  "status": "ok",
  "repo_id": 2,
  "runs_requested": 5,
  "runs_completed": 5,
  "total_tests_observed": 2,
  "flaky_test_count": 1,
  "flaky_tests": [
    {
      "node_id": "tests/test_flaky.py::test_alternates",
      "runs_observed": 5,
      "inconsistency_count": 2,
      "flakiness_rate": 0.4,
      "outcomes": ["passed", "failed", "passed", "failed", "passed"],
      "majority_outcome": "passed"
    }
  ],
  "run_failures": []
}

検出された不安定なテストもflaky_reportsテーブルに永続化されます。

train_risk_model

"Train the risk model" — ファイルごとに10個の特徴量(チャーン、過去の障害数、現在のカバレッジ、ファイルに触れるテスト数、最終更新からの日数、異なる作成者数、ファイルサイズ、循環的複雑度 — MLモデルのコールドスタート戦略についてはコールドスタート戦略を参照)から、「このファイルが変更された後、テストは失敗するか?」を予測するGradientBoostingClassifierを訓練し、ホールドアウト分割で評価し、正直に報告します:

{
  "status": "ok",
  "model_path": "models/risk_model.joblib",
  "real_sample_count": 0,
  "synthetic_sample_count": 500,
  "total_sample_count": 500,
  "test_set_size": 125,
  "metrics": {
    "accuracy": 0.6,
    "precision": 0.5962,
    "recall": 0.5167,
    "f1": 0.5536
  },
  "caveat": "Only 0 real training example(s) recorded so far (via record_test_run) — this training run is dominated by synthetic, artificially-generated bootstrap data. These metrics describe how well the model fits that synthetic relationship, NOT real predictive power on an actual repository. Keep calling record_test_run on real repos, then retrain, before trusting these numbers for anything beyond confirming the training pipeline itself works."
}

caveatフィールドは、real_sample_countが実際の閾値(30、ml/training.pyを参照)を超えるまで消えません。このツールは、合成データが主流の指標を、現実に対して検証済みであるかのように提示することは決してありません。

(残りのツールはマイルストーンごとに追加されます。詳細はビルドステータスを参照してください。)

MLモデルのコールドスタート戦略

train_risk_modelにはラベル付きの例が必要です — 「ファイル変更に関するこれらの特徴量を与えられたとき、そのファイルに関連するテストはその後失敗したか?」。新しくセットアップされたサーバーでは、実行が0回記録されているため、学習するための履歴がありません。MLコードを書く前に、3つのオプションが検討されました:

  1. 実際のオープンソースリポジトリのgit/CI履歴を再生する。 実際のプロジェクトをクローンし、そのコミットをウォークスルーし、各コミットをチェックアウトし、その時点の履歴に存在していた依存関係をインストールし、スイートを実行し、実際の特徴量と実際のラベルを抽出します。 はるかに現実的なデータですが、確実に構築するにはコストがかかり、脆弱です。依存関係のインストールは何年もの履歴の中で壊れます(非推奨のパッケージ、Pythonバージョンの変動)、全履歴のチェックアウトは遅く、このプロジェクト自身のCIにハードな外部依存関係(特定の時点の特定のリポジトリ)を追加することになり、実行のたびにそれを再現する必要があります。

  2. このプロジェクト自身のコミットを再生する。 同じアイデアですが、範囲が小さくなります。中心となるコスト問題を回避できず、このプロジェクト自身の履歴は、汎用リスクモデルが一般化すべきファイル変更パターンの幅を表現するにはあまりに短く、狭すぎます。

  3. 合成データを生成する(採用)。 尤もらしい分布から特徴ベクトルを抽出し、意図的に設計されたドメイン知識に基づく生成ルール(より多くのチャーン + より多くの過去の障害 + より低いカバレッジ + より高い複雑度 → より高い障害確率、そしてノイズ)からラベルを導出します。これはコインフリップではありません。高速で、完全に再現可能で、外部リポジトリを必要とせず、パイプライン全体(特徴抽出 → 訓練 → 評価)を今日、正直に実行するのに十分です。

正直なトレードオフ: 純粋に合成データのみで訓練されたモデルは、尤もらしいリスク関係の形状を学習したものであり、実際のものではありません。ホールドアウトされた合成データに対するその指標は妥当に見えます(精度~0.6、ROC-AUC ~0.67 — tests/ml/test_synthetic.pyを参照)が、これはパイプラインが機能することを証明するだけであり、実際のリポジトリについて何かを予測することを証明するものではありません。train_risk_modelは、実際の例が存在する瞬間(record_test_runfile_changes行経由 — 下記参照)からそれらをブレンドし、常に実際/合成の分割と、実際のデータが信頼するには薄すぎる場合の明示的な注意事項を報告し、合成データ由来の数値を検証済みとして提示することは決してしません。

実例の出どころ: record_test_run は毎回の実行後に実際のgit差分 (HEAD~1..HEAD) を計算し、変更されたファイルごとに1行の file_changes を書き込みます。tests_failed_after は「この実行で 何らかの テストが失敗したか」で、変更されたすべてのファイルに同じ値が適用されます(ファイルごとの帰属ではありません)。これは意図的な選択です。つまり、失敗を 原因となった特定の ファイルに帰属させるには、カバレッジベースのトレーシング(どのテストがどのソース行を実行したか)が必要になりますが、本プロジェクトではそれを行いません。この粗い信号は、あくまで相関関係(「このファイルは何かを壊したコミットの一部だった」)を示すものであり、因果関係ではありません。完全な理由(ファイルパス文字列マッチのヒューリスティックが見た目ほど正確ではなく、実際にはより狭く、誤解を招くものである理由を含む)については、runners/record_run.py のコメントを参照してください。

履歴特徴量抽出(実際のトレーニング例に使用)は、記録された各実行のタイムスタンプとコミット「時点」のgit履歴を読み取ります。つまり、git log --beforegit show <sha>:<path> を使用し、決してファイルの現在の状態は使いません。これにより、モデルが予測時点でまだ存在していなかった情報を誤って学習することを防ぎます。coverage_percent は、対象のコミットで完全なテストスイートを再実行することなく履歴的に再構築できない唯一の特徴量です(トレーニング例ごとに行うにはコストが高すぎる)。そのため、実際の履歴行では明示的な「不明」センチネルとして保存され、ライブ予測(後述の predict_pr_risk)の場合にのみ新たに計算されます。

predict_pr_risk

「C:\path\to\some-repo の PR リスクを main ブランチに対して予測」base_ref..HEAD の差分を取得し(実際の git diff --numstat)、変更された各ファイルに対してライブな特徴量を抽出します(現在のワーキングツリーの状態、さらに analyze_coverage を新たに実行して現在の実際のカバレッジを取得します。履歴トレーニング行で使用される「不明」センチネルではありません)。そして、トレーニング済みモデルで各ファイルをスコアリングし、リスクの高い順にランク付けします。

{
  "status": "ok",
  "repo_id": 3,
  "base_ref": "0bcbeba860df0457c55ad3c1d3826ed5fd941506",
  "commit_sha": "8306f4598275f92907de89e1161f982772f3aac7",
  "model_trained_at": "2026-08-17T19:03:42.707577+00:00",
  "model_real_sample_count": 0,
  "predictions": [
    { "file": "tests/test_calculator.py", "predicted_risk_probability": 0.0743, "lines_added": 9, "lines_deleted": 1 },
    { "file": "pkg/calculator.py", "predicted_risk_probability": 0.0457, "lines_added": 7, "lines_deleted": 0 }
  ]
}
```</s>

`model_real_sample_count` はモデルのトレーニングメタデータから引き継がれます。これにより、呼び出し元は別途ルックアップすることなく、これらの予測が合成データ主体のモデル([コールドスタート戦略](#cold-start-strategy-for-the-ml-model)を参照)に基づくものかを一目で確認できます。`train_risk_model` が少なくとも1回実行されている必要があります(そうでない場合は `no_trained_model` エラー)。このツールは暗黙的にモデルをトレーニングすることはありません。すべての予測は `risk_predictions` テーブルに保存され、`actual_outcome` は `NULL` のままとなります。これにより、実際のリポジトリの予測を後で実際の結果と照合できます。この評価機能はまだ構築されていませんが、初日からデータを取得しておくことで、スキーマ変更なしで後から追加できるようになっています。</s>

## 継続的インテグレーション (GitHub Actions)</s>

GitHub Actions は GitHub に組み込まれた CI です。**ワークフロー**(1つのYAMLファイル、[.github/workflows/ci.yml](.github/workflows/ci.yml))が、リポジトリイベント(ここでは、プルリクエストの作成/更新、または `main` ブランチへのプッシュ)に応じて自動的に実行される **ジョブ** を記述します。各ジョブは、新しく使い捨ての仮想マシン(「ランナー」)上で実行されます。明示的にキャッシュまたはアップロードされたものを除き、実行間で永続化されるものはありません。ジョブは **ステップ** のシーケンスであり、各ステップはシェルコマンドまたは再利用可能な **アクション**(他の誰かが公開したパッケージ化されたステップで、`actions/checkout@v4` のように参照されます)のいずれかです。</s>

このプロジェクトのワークフローは、プロジェクト自身をエンドツーエンドでテストします。</s>

1. **リポジトリをチェックアウト** し、**`uv` + 依存関係をインストール** します。これはコントリビューターがローカルでインストールするものと同じツールです。</s>
2. **Postgres をサービスコンテナとして起動** します。GitHub Actions がジョブと一緒に実行する2つ目のコンテナで、すべてのステップから `localhost:5433` でアクセス可能です。これはローカルでの `docker-compose up -d` とまったく同じですが、Docker Desktop ではなく GitHub によって管理されます。ジョブのステップは、ヘルスチェックが成功するまで開始されません。手書きの「Postgres を待つ」ポーリングループは不要です。</s>
3. **Alembic マイグレーションを適用** し、**`--cov-fail-under=$COVERAGE_THRESHOLD` を付けてプロジェクト自身のテストスイートを実行** します。pytest-cov の組み込みゲートです。カバレッジがしきい値を下回ると(現在は80%、実際の約93%未満に余裕を持たせて設定)、ビルドは即座に失敗します。</s>
4. **`detect_flaky_tests` をプロジェクト自身のテストに対して実行** します。[scripts/ci\_report.py](scripts/ci_report.py) 経由で実行されます。このスクリプトは、ショートカットではなく、*実際の* MCP レイヤー(`fastmcp.Client` が実際のサーバーオブジェクトと通信)を介してツールを呼び出します。これは情報提供のみであり、ビルドを失敗させることはありません。失敗させるのはカバレッジのみです。</s>
5. **両方のレポートをワークフローアーティファクトとしてアップロード** します(`actions/upload-artifact`)。デフォルトで90日間、ワークフロー実行ページからダウンロード可能です。</s>
6. **ジョブサマリーを書き込み**(`$GITHUB_STEP_SUMMARY`、実行ページにMarkdownとして直接レンダリングされます)、**それを PR コメントとして投稿** します(`actions/github-script`、実行に組み込まれた `GITHUB_TOKEN` を使用。追加のシークレットは不要)。ステップサマリーは常に動作するフォールバックであり、フォークからのPR(コメントを投稿できない読み取り専用トークンが付与される。これはGitHubのセキュリティ制限であり、このワークフローのバグではありません)を含む場合でも機能します。コメントステップは `continue-on-error: true` でラップされているため、この制限はジョブ全体を失敗させるのではなく、グレースフルに低下します。</s>

**これを実際に実行するには**、プロジェクトが実際のGitHubリポジトリに存在し、コミットがプッシュされている必要があります。このローカルビルドプロセスではまだ作成されていません。それが存在すれば、PRを開くだけで、Actionsタブ(およびPR自体、コメントが投稿された後)にライブで実行されている様子が表示されます。</s>

## ビルドステータス</s>

このプロジェクトはマイルストーンごとに構築され、それぞれが次の段階に進む前に動作が確認されています。</s>

* [x] **マイルストーン 1** — プロジェクトスケルトン、docker-compose Postgres、`.env.example`、この README</s>
* [x] **マイルストーン 2** — データベース層 (SQLAlchemy モデル + Alembic)</s>
* [x] **マイルストーン 3** — FastMCP サーバースケルトン (6つのツール登録、プレースホルダーの本体)</s>
* [x] **マイルストーン 4** — `analyze_coverage`</s>
* [x] **マイルストーン 5** — `record_test_run` + `get_test_history`</s>
* [x] **マイルストーン 6** — `detect_flaky_tests`</s>
* [x] **マイルストーン 7** — ML コールドスタート戦略、特徴量抽出、`train_risk_model`</s>
* [x] **マイルストーン 8** — `predict_pr_risk`</s>
* [x] **マイルストーン 9** — GitHub Actions CI (構築 + ローカル検証済み。ライブPR実行は実際のGitHubリポジトリを待つ)</s>
* [ ] **マイルストーン 10** — 最終仕上げ</s>

## このプロジェクト自身のテストの実行</s>

```bash
uv sync --extra dev     # installs pytest-asyncio + ruff on top of the base deps
uv run pytest -v
uv run pytest --cov --cov-report=term-missing   # with coverage
uv run ruff check .                              # lint
```</s>

DB層のテストは、実際の使い捨てのPostgresデータベース (`test_intelligence_test`、自動的に作成および破棄) を使用し、データベースをモックしたり `create_all()` を使用したりする代わりに、実際のAlembicマイグレーションをそれに対して実行します。これはCIがPostgresサービスコンテナ(マイルストーン9)を介して使用するのと同じアプローチです。詳細については `tests/conftest.py` を参照してください。</s>

## データモデル</s>

6つのテーブルがあり、Alembicマイグレーションによって管理されています。</s>

* **repositories** — 追跡対象のリポジトリ(名前 + ローカルパスまたはリモートURL)</s>
* **test\_runs** — `pytest` の呼び出しごとに1行(リポジトリ、コミットSHA、ブランチ、タイムスタンプ、期間、成功/失敗/スキップ数)</s>
* **test\_results** — 実行内のテストノードIDごとに1行(結果、期間、エラーメッセージ)</s>
* **file\_changes** — 実行のファイルごとの差分統計(追加/削除行数、変更後にテストが失敗したかどうか)</s>
* **flaky\_reports** — テストノードごとのフレーキネスサマリー(観測された実行回数、不一致数、検出タイムスタンプ)</s>
* **risk\_predictions** — コミットのファイルごとのMLリスクスコア。実際の結果が判明したらそれも保存されます(モデルのオフライン評価用)</s>

## ライセンス</s>

MIT
-
license - not tested
-
quality - not tested
C
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

  • An MCP server that gives your AI access to the source code and docs of all public github repos

  • Hosted MCP server for structured code review passes on human- and AI-written code. Free tier.

  • MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shreyasKaturi2004/test-intelligence-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server