mcp-zuul

mcp-zuul

Web UIをクリックして回る代わりに、質問するだけでビルドの失敗をデバッグできます。Zuul CI 用の MCP サーバーです。

mcp-zuulでデバッグの手間が省けたら、⭐ スターを付けて、ほかの人にも見つけてもらいましょう。

インストール不要、コマンド1つで実行：

claude mcp add zuul -e ZUUL_URL=https://your-zuul.example.com -- uvx mcp-zuul

ビルド、ログ、パイプライン、ジョブ、インフラストラクチャ、リアルタイムステータスに対応する48個のツール、5個のプロンプト、3個のリソースを備えています。Claude Code、Claude Desktop、Cursor、Codex、Windsurf、およびMCP互換のあらゆるクライアントで動作します。

mcp-zuulを選ぶ理由

	mcp-zuul	Zuul APIを直接使用	Zuul Web UI
失敗の分析	構造化された情報 — タスク、ホスト、エラー、rc	生のJSON。解析は自分で行う必要があります	ログページをクリックして移動
ログ検索	正規表現＋前後のコンテキスト行＋行範囲	利用できません	ブラウザーのCtrl+F
不安定なテストの検出	合否統計を自動算出	手動でクエリして計算	利用できません
テスト結果	失敗の詳細を含む解析済みJUnit XML	利用できません	外部リンク
異常検出	LogJuicerによる機械学習ベース	利用できません	利用できません
リアルタイムステータス	ジョブの進捗、完了予定時刻、失敗前アラート	APIのポーリング	手動更新
複数インスタンス	Zuulごとに設定を1つ登録	異なるベースURL	異なるブラウザータブ

クイックスタート

uvx（インストール不要、推奨）：

claude mcp add zuul \
               -e ZUUL_URL=https://softwarefactory-project.io/zuul \
               -e ZUUL_DEFAULT_TENANT=rdoproject.org \
               -- uvx mcp-zuul

pip：

pip install mcp-zuul

Docker：

docker build -t mcp-zuul .

LobeHub — これをAIエージェントに送信します：

Read https://lobehub.com/mcp/imatza-rh-mcp-zuul/skill.md and follow the instructions to install the MCP server.

Kerberosや複数インスタンスを含む設定オプションの全容については、セットアップを参照してください。

機能

構造化された失敗分析 — get_build_failures は Zuul の job-output.json を解析し、どの Ansible タスクがどのホストで失敗したのかを、エラーメッセージ、戻りコード、stderr とともに正確に返します。ログを延々とスクロールする必要はありません。

任意のログファイルの読み取り — get_build_log は job-output.txt に限定されません。log_name を指定すると、ビルドのログディレクトリにある任意のファイル（ci_script のログ、ansible.log、デプロイログなど）を、grep、tail、行範囲の指定機能をすべて使って読み取れます。

ログの正確な位置への移動 — start_line／end_line を指定して、正確な行範囲に移動できます。6148 行目でエラーを見つけたら、200 行単位のログをスクロールする代わりに、6130～6160 行を読み取れます。

スマートな grep — コンテキスト行付きで正規表現検索ができます。一般的なシェルの grep の \| 構文を Python の正規表現の | に自動変換するため、error\|failed\|timeout のようなパターンをそのまま使えます。

パイプラインのリアルタイム把握 — get_change_status は、経過時間、完了予測、失敗前の検出（pre_fail フィールド）を含む、ジョブの進捗状況をリアルタイムで返します。変更がパイプラインにない場合は、最新の完了済みビルドセットを自動的に取得します。

ツールのフィルタリング — ZUUL_ENABLED_TOOLS または ZUUL_DISABLED_TOOLS を使って、LLM のツール選択時のノイズを減らせます。ワークフローに必要なツールだけを公開し、残りはサーバーから完全に削除します。

URL による入力 — Zuul のビルド URL を直接貼り付けられます。https://zuul.example.com/t/tenant/build/abc123 のような URL から、ツールがテナントと UUID を自動解析するため、手動で抽出する必要はありません。

不安定なジョブの検出 — find_flaky_jobs は、最近のビルド履歴を分析して成功／失敗の統計を算出し、断続的な失敗を自動的に特定します。

ジョブの依存関係グラフ — get_freeze_jobs は、パイプライン／プロジェクト／ブランチの完全に解決されたジョブグラフを返します。継承の解決後に、依存関係を含むすべてのジョブを確認できます。

Kerberos／SPNEGO 認証 — OIDC と Kerberos を使用する Zuul インスタンスを標準でサポートします。SPNEGO のリダイレクトチェーン全体を自動的に処理します。セッション Cookie は保持され、有効期限が切れると透過的に再認証されます。

ストリーミング可能な HTTP トランスポート — リモート／共有環境へのデプロイでは、MCP_TRANSPORT=streamable-http を指定して、常駐型の HTTP サーバーとして実行できます。stdio（デフォルト）、SSE、streamable-http をサポートします。

書き込み操作 — 変更のキューへの追加／キューからの削除／優先処理、およびビルドセットの再キューイングができます。パイプラインに影響するツールはデフォルトで無効（ZUUL_READ_ONLY=true）になり、サーバーから完全に削除されるため、LLM からも見えません。Autohold の管理（作成／削除）は実行中のパイプラインに影響しないため、常に利用できます。

LogJuicer との連携 — get_build_anomalies は、ML ベースのログ分析を使って、失敗したログを成功時のベースラインと比較し、通常とは異なる行を見つけます。オプション機能です。利用には LOGJUICER_URL が必要です。

トークン効率の高い出力 — すべての応答で None 値を取り除き、コンパクトなフォーマッターを使用します。tail_build_log は最後の N 行だけを返すため、ビルドが失敗した理由を確認する最速の方法です。

エラー処理 — すべてのツールは、エラーも含めて JSON を返します。ネットワーク障害、認証の問題、無効なパラメーターが発生した場合は、{"error": "説明的なメッセージ"} を返します。ツールが未処理の例外を発生させることはありません。

ツール

ビルドと失敗

ツール	機能
list_builds	プロジェクト、パイプライン、ジョブ、変更、結果でビルドを検索します。相互参照用の buildset_uuid が含まれます。
get_build	ビルドの詳細情報をすべて取得します。ノードセット、ログ URL、アーティファクト、エラーの詳細が含まれます。url または uuid を指定します。
get_build_failures	失敗の調査はここから始めてください。 job-output.json のタスクレベルの構造化データ（失敗したプレイ、タスク、ホスト、msg、rc、stderr/stdout）を取得します。url または uuid を指定します。
diagnose_build	1 回の呼び出しで失敗を診断します。 job-output.json の構造化された失敗情報と、対象を絞ったログのコンテキスト（job-output.txt の致命的エラー行／FAILED 行とその前後のコンテキスト）を組み合わせます。get_build_failures と get_build_log を別々に呼び出す代わりに使用してください。url または uuid を指定します。
get_build_log	ログファイルを読み取り、検索します。モードは summary（末尾とエラー行）、full（ページ分割）、grep（正規表現とコンテキスト）、start_line／end_line（正確な範囲）です。任意のファイルに log_name を指定できます。url または uuid を指定します。
tail_build_log	最速で失敗を確認できます。 ログの末尾から N 行を取得します（デフォルトは 50 行、最大 500 行）。get_build_log の summary モードよりトークン効率に優れています。url または uuid を指定します。
browse_build_logs	ログディレクトリの内容を一覧表示するか、特定のファイル（インベントリー、アーティファクト、must-gather）を取得します。ファイルごとの最大サイズは 512KB です。url または uuid を指定します。
stream_build_console	実行中ビルドのライブコンソールです。 Zuul WebSocket に接続し、末尾から N 行を返します。完了済みビルドには tail_build_log を使用してください。オプション機能です。利用するには pip install mcp-zuul[console] が必要です。

ビルドセット

ツール	機能
list_buildsets	ビルドセットを検索します。ビルドの詳細情報をインラインで含めるには、include_builds=true を使用します（呼び出し回数を削減できます）。
get_buildset	すべてのビルドとイベントを含む、ビルドセットの詳細情報を取得します。url または uuid を指定します。

パイプラインとステータス

ツール	機能
get_status	パイプラインのライブステータスを取得します。キューに入っているものや実行中のものを、ジョブの進捗と予定時間とともに確認できます。パイプラインとプロジェクトで絞り込めます。
get_change_status	変更／PR／MR のステータスを取得します。パイプライン内にある場合は、経過時間付きで実行中のジョブを表示します。パイプライン内にない場合は、最新の完了済みビルドセットを自動取得します。url または change を指定します。
list_pipelines	トリガーの種類とともに、すべてのパイプラインを一覧表示します。

ジョブとプロジェクト

ツール	機能
list_tenants	すべてのテナントとプロジェクト数を一覧表示します。
list_jobs	オプションの名前フィルターを指定して、ジョブを一覧表示します。
get_job	ジョブの設定を取得します。親、ノードセット、タイムアウト、バリアント、ソースプロジェクトが含まれます。
get_project	プロジェクトに設定されているパイプラインとジョブを確認します。
list_projects	オプションの名前フィルターを指定して、テナント内のすべてのプロジェクトを一覧表示します。
get_config_errors	ジョブが実行されない場合は、これを確認してください。 設定エラー、参照先の欠落、破損した設定を確認します。プロジェクトで絞り込めます。
get_freeze_jobs	パイプライン／プロジェクト／ブランチに対して解決済みのジョブ依存関係グラフを取得します。継承が解決された状態で、実行されるジョブを正確に確認できます。
get_freeze_job	継承を解決した後のジョブ設定です。 特定のジョブについて、最終的に統合されたノードセット、プレイブック、変数、タイムアウトを取得します。「このジョブは実際に何をするのか」という疑問に答えます。
find_flaky_jobs	最近のビルド履歴を分析し、断続的な失敗を検出します。合格率／失敗率を算出し、結果にばらつきがある状態で失敗率が 20% を超えるジョブに、不安定であるというフラグを付けます。
get_build_times	ビルド所要時間の傾向と、平均／最小／最大の統計情報を取得します。パフォーマンスの低下やタイムアウトしやすいジョブを検出できます。
get_job_durations	1 回の呼び出しで複数のジョブの平均／最小／最大所要時間をまとめて取得します。N 回に分けて呼び出すことなく、パイプラインチェーン全体を監視できるように設計されています。
check_health	API への接続、認証ステータス、設定をテストします。Kerberos セッションの有効期限が切れている場合は、自動的に再認証します。
get_tenant_info	テナントの機能（認証レルム、ジョブ履歴のサポート、WebSocket URL）を取得します。

インフラストラクチャ

ツール	機能
list_nodes	状態（ready、in-use、building）、プロバイダー、ラベルを含むNodepoolノードの一覧です。状態の概要も含まれます。
list_labels	利用可能なNodepoolラベルの一覧です。ジョブがリクエストできるノードタイプを確認できます。
list_semaphores	現在の保持者と最大容量を含むリソースロックの一覧です。ジョブが予期せず待機しているときに確認してください。
list_autoholds	アクティブなautoholdリクエストの一覧です。デバッグのため、失敗後に保持されているノードを確認できます。
get_autohold	特定のautoholdリクエストの詳細情報です。保持されたノード、タイミング、プロジェクト、ジョブを確認できます。
list_providers	フレーバー（VMサイズ）、イメージ、ラベルを含むNodepoolクラウドプロバイダーの一覧です。
list_images	ビルド状態とプロバイダーへのアップロード状態を含むNodepoolディスクイメージの一覧です。
list_system_events	設定の更新、再設定、パイプラインの変更などのシステムイベントです。「ジョブが実行されなくなったのはなぜか？」を調べるのに役立ちます。
get_badge	プロジェクトのCIステータスバッジURL（SVG）です。Markdownスニペットを使ってREADMEに埋め込めます。
get_connections	設定済みのソース接続です。ドライバーとホスト名を含むGerrit、GitHub、GitLabのインスタンスを確認できます。
get_components	スケジューラー、エグゼキューター、マージャー、ウェブサーバーなどのシステムコンポーネントです。状態とバージョンを確認できます。

書き込み操作

パイプラインに影響する操作は、デフォルトで無効になっています（ZUUL_READ_ONLY=true）。有効にするには、ZUUL_READ_ONLY=falseを設定してください。認証トークンまたはKerberosが必要です。autoholdの管理（作成／削除）は実行中のパイプラインに影響しないため、常に利用できます。

ツール	機能
enqueue	変更またはrefをパイプラインに登録します。変更ベース（check/gate）とrefベース（periodic）の両方の登録に対応しています。
promote	変更をパイプラインキューの先頭に移動します。gateのキューが長い場合に、緊急の修正に使用してください。
reenqueue_buildset	ビルドセットを再登録します。以前のビルドセットからプロジェクト／パイプライン／refを読み取り、再度登録します。
dequeue	変更またはrefをパイプラインから削除します。破壊的な操作です。
autohold_create	autoholdリクエストを作成し、デバッグのため失敗後にノードを保持します。ZUUL_READ_ONLYによる制限はありません。
autohold_delete	autoholdリクエストを削除します。ZUUL_READ_ONLYによる制限はありません。

テスト結果とログ分析

ツール	機能
get_build_test_results	JUnit XMLテスト結果を解析します。 zuul-manifest.jsonを使ってテストファイルを検出し、失敗の詳細とともに、成功／失敗／スキップの件数を構造化して返します。tempest、tobiko、およびあらゆるJUnit XML出力に対応しています。
get_build_anomalies	LogJuicerによるMLベースのログ異常検出です。失敗したログを成功時のベースラインと比較します。LOGJUICER_URLが必要です。

プロンプト

コンテキストを事前に読み込み、分析をガイドする、事前作成済みのプロンプトテンプレートです。

プロンプト	機能
debug_build	ビルドの詳細と構造化された失敗情報を取得し、最近の履歴から不安定な兆候を確認して、根本原因分析をガイドします。
compare_builds	2つのビルドを失敗データとともに並べて読み込み、差分分析を行います。「なぜ失敗するようになったのか？」を調べられます。
check_change	変更の現在のパイプライン状態または最新の結果を確認し、適切な次の手順を提示します。
tenant_health	コンポーネント、設定エラー、ノードプールの状態をひと目で確認し、テナント全体の健全性を評価します。
diagnose_queue_delay	ジョブがキューに入ったまま、または遅延している理由を診断します。ノード、セマフォ、システム状態を確認します。

リソース

ツール呼び出しなしで、クライアントが会話に添付できる、参照可能なコンテキストです。

リソース	URIパターン
ビルドの詳細	zuul://{tenant}/build/{uuid}
ジョブ設定	zuul://{tenant}/job/{name}
プロジェクト設定	zuul://{tenant}/project/{org}/{repo}

セットアップ

MCP クライアントの設定

すべてのクライアントで同じ JSON 構造を使用します。クライアントの MCP 設定ファイルに追加してください。

Claude Code（~/.claude.json → mcpServers）：

{
  "mcpServers": {
    "zuul": {
      "command": "uvx",
      "args": ["mcp-zuul"],
      "env": {
        "ZUUL_URL": "https://softwarefactory-project.io/zuul",
        "ZUUL_DEFAULT_TENANT": "rdoproject.org"
      }
    }
  }
}

Claude Desktop（claude_desktop_config.json）、Cursor（.cursor/mcp.json）、その他の MCP クライアントでも同じ形式を使用します。GUI ベースのクライアントはシェルの PATH を継承しないため、uvx のフルパスを使用してください（which uvx を実行すると確認できます）。

または CLI から：

claude mcp add zuul \
               -e ZUUL_URL=https://softwarefactory-project.io/zuul \
               -e ZUUL_DEFAULT_TENANT=rdoproject.org \
               -- uvx mcp-zuul

環境変数

変数	必須	デフォルト	説明
ZUUL_URL	はい	—	Zuul のベース URL（例：https://softwarefactory-project.io/zuul）
ZUUL_DEFAULT_TENANT	いいえ	—	デフォルトのテナント（呼び出しごとに tenant を渡す手間を省きます）
ZUUL_AUTH_TOKEN	いいえ	—	認証が必要なインスタンス用の Bearer トークン
ZUUL_USE_KERBEROS	いいえ	false	Kerberos/SPNEGO 認証を有効にします
ZUUL_TIMEOUT	いいえ	30	HTTP タイムアウト（秒）
ZUUL_VERIFY_SSL	いいえ	true	SSL 証明書の検証
MCP_TRANSPORT	いいえ	stdio	トランスポート：stdio、sse、または streamable-http
MCP_HOST	いいえ	127.0.0.1	HTTP サーバーのバインドアドレス（stdio 以外のトランスポート）
MCP_PORT	いいえ	8000	HTTP サーバーのポート（stdio 以外のトランスポート）
ZUUL_ENABLED_TOOLS	いいえ	—	有効にするツールのカンマ区切りリスト（それ以外のツールはすべて無効になります）
ZUUL_DISABLED_TOOLS	いいえ	—	無効にするツールのカンマ区切りリスト（上記と併用できません）
ZUUL_READ_ONLY	いいえ	true	false に設定すると、パイプラインに影響する書き込み操作（enqueue、promote、dequeue、reenqueue_buildset）が有効になります。Autohold の管理（作成／削除）は常に利用できます。
LOGJUICER_URL	いいえ	—	ML ベースのログ異常検出に使用する LogJuicer のベース URL

トークン認証

ホスト環境経由で ZUUL_AUTH_TOKEN を渡してください。設定ファイルにトークンをハードコードしないでください（ps の出力に表示されます）。

export ZUUL_AUTH_TOKEN=<your-token>

Docker の場合、値を指定せずに転送してホストから継承します。

"args": ["run", "-i", "--rm", "-e", "ZUUL_AUTH_TOKEN", "mcp-zuul"]

Kerberos / SPNEGO

OIDC + Kerberos の背後にある Zuul 用です。有効な Kerberos チケット（kinit）と gssapi パッケージが必要です。

Linux の前提条件 - gssapi にはビルド済みの Linux ホイールがないため、ソースからコンパイルする必要があります。

# Fedora/RHEL/CentOS
sudo dnf install krb5-devel python3-devel gcc

# Debian/Ubuntu
sudo apt install libkrb5-dev python3-dev gcc

macOS と Windows にはビルド済みのホイールがあるため、追加パッケージは不要です。

次に、Kerberos サポートを有効にしてインストールします。

pip install mcp-zuul[kerberos]    # or: uvx --with "mcp-zuul[kerberos]" mcp-zuul

CLI から：

claude mcp add -s user zuul-internal \
               -e ZUUL_URL=https://internal-zuul.example.com/zuul \
               -e ZUUL_DEFAULT_TENANT=my-tenant \
               -e ZUUL_USE_KERBEROS=true \
               -e ZUUL_VERIFY_SSL=false \
               -- uvx --with "mcp-zuul[kerberos]" mcp-zuul

または JSON 設定から：

{
  "zuul-internal": {
    "command": "uvx",
    "args": ["--with", "mcp-zuul[kerberos]", "mcp-zuul"],
    "env": {
      "ZUUL_URL": "https://internal-zuul.example.com/zuul",
      "ZUUL_USE_KERBEROS": "true",
      "ZUUL_VERIFY_SSL": "false"
    }
  }
}

Docker の場合、Kerberos チケットキャッシュをマウントします。

docker run -i --rm \
  -v /etc/krb5.conf:/etc/krb5.conf:ro \
  -v /tmp/krb5cc_$(id -u):/tmp/krb5cc_$(id -u):ro \
  -e KRB5CCNAME=/tmp/krb5cc_$(id -u) \
  -e ZUUL_URL=https://internal-zuul.example.com/zuul \
  -e ZUUL_USE_KERBEROS=true \
  mcp-zuul

複数のインスタンス

Zuul インスタンスごとに個別のエントリを追加します。

{
  "mcpServers": {
    "zuul-rdo": {
      "command": "uvx", "args": ["mcp-zuul"],
      "env": { "ZUUL_URL": "https://softwarefactory-project.io/zuul", "ZUUL_DEFAULT_TENANT": "rdoproject.org" }
    },
    "zuul-internal": {
      "command": "mcp-zuul",
      "env": { "ZUUL_URL": "https://internal.example.com/zuul", "ZUUL_USE_KERBEROS": "true" }
    }
  }
}

トラブルシューティング

Linux で mcp-zuul[kerberos] をインストールする際に krb5-config: not found または Python.h: No such file と表示される場合：

gssapi にはビルド済みの Linux ホイールがないため、ソースからコンパイルされます。まずシステムパッケージをインストールしてください。

# Fedora/RHEL/CentOS
sudo dnf install krb5-devel python3-devel gcc

# Debian/Ubuntu
sudo apt install libkrb5-dev python3-dev gcc

Cursor または Claude Desktop で uvx: command not found と表示される場合：

GUI ベースの MCP クライアントはシェルの PATH を継承しません。uvx のフルパスを使用してください。

which uvx    # find the path, e.g. /usr/bin/uvx or ~/.local/bin/uvx

次に、その絶対パスを MCP 設定の command として使用します。

"command": "/usr/bin/uvx"

~/.local/share/uv/ で権限エラーが発生する場合：

以前に sudo で uv を実行していた場合、キャッシュディレクトリの所有者が root になっていることがあります。

sudo chown -R $(whoami) ~/.local/share/uv/

使用例

ビルド失敗をデバッグする

"Why did the latest build of my-project fail?"

→ list_builds(project="my-project", result="FAILURE", limit=1) → get_build_failures(uuid="...") → タスク名、エラー、戻りコードを含む根本原因。

ログを詳しく調べる

"The structured data says 'non-zero return code' but no error detail.
 Check the ci_script logs."

→ browse_build_logs(uuid="...", path="controller/ci-framework-data/logs/") → ci_script_008_run.log を見つける → get_build_log(uuid="...", log_name="controller/ci-framework-data/logs/ci_script_008_run.log", grep="error|timed out|Error 1", context=2) → 前後のコンテキストを含む正確なエラー。

特定のエラーに移動する

"Show me lines 6478-6484 of the job output"

→ get_build_log(uuid="...", start_line=6478, end_line=6484) → 指定した 7 行をそのまま表示します。

パイプラインの現在のステータスを確認する

"Is change 54321 in any pipeline?"

→ get_change_status(change="54321") → 経過時間と ETA を含む実行中のジョブ、またはパイプラインにない場合は最新の完了済みビルドセット。

パイプライン間でビルド結果を比較する

"Show me all builds from the latest buildset"

→ list_builds で buildset_uuid を取得 → get_buildset(uuid="...") → 結果と所要時間を含む、同じビルドセット内のすべてのビルド。

Zuul の URL を直接貼り付ける

"What went wrong with this build?
 https://zuul.example.com/t/tenant/build/abc123def"

→ get_build_failures(url="https://zuul.example.com/t/tenant/build/abc123def") → テナントと UUID が自動的に抽出されます。

ジョブが実行されない理由を調べる

"My project's check pipeline seems broken — jobs aren't triggering"

→ get_config_errors(project="org/my-project") → 設定エラー、参照の欠落、またはリポジトリへのアクセスに関する問題を確認できます。

ノードの空き状況を確認する

"Jobs are stuck in queue — are there nodes available?"

→ list_nodes() → 状態ごとの概要を含むノードの状態 → list_labels() → 利用可能なノードタイプ。

不安定なジョブを検出する

"Is this job flaky? It keeps failing intermittently"

→ find_flaky_jobs(job_name="my-deploy-job", limit=30) → 成功・失敗の統計、失敗率、flaky=true/false。

プロジェクトで実行されるジョブを確認する

"What jobs are configured for openstack-operator in the check pipeline?"

→ get_freeze_jobs(pipeline="check", project="openstack-k8s-operators/openstack-operator") → 依存関係を含む、解決済みのジョブグラフ。

ログの末尾をすばやく確認する

"Show me the last 30 lines of the build log"

→ tail_build_log(uuid="...", lines=30) → ログの末尾のみを取得し、トークンを最小限に抑えます。

継承後にジョブが使用するノードセットを確認する

"What nodeset and playbooks will deploy-job actually use?"

→ get_freeze_job(pipeline="check", project="org/repo", job_name="deploy-job") → すべての親からの継承後の、解決済みノードセット、プレイブック、変数、タイムアウト。

開発

git clone https://github.com/imatza-rh/mcp-zuul.git
cd mcp-zuul
uv sync --extra dev

# Run locally
ZUUL_URL=https://softwarefactory-project.io/zuul uv run mcp-zuul

# Run tests
uv run pytest tests/ -v

# Lint and format
uv run ruff check src/ tests/
uv run ruff format --check src/ tests/

# Type check
uv run mypy src/mcp_zuul/

# Build Docker image
docker build -t mcp-zuul .

アーキテクチャ

MCP Client (Claude Code, Cursor, etc.)
    │
    ▼
┌──────────────────────────────────────────────────┐
│  src/mcp_zuul/                                   │
│                                                  │
│  server.py       MCPServer instance               │
│  config.py       env vars, transport, filtering  │
│  auth.py         Kerberos/SPNEGO + OIDC          │
│  errors.py       @handle_errors decorator        │
├──────────────────────────────────────────────────┤
│  tools/          48 tools across 8 submodules    │
│  prompts.py      5 prompt templates              │
│  resources.py    3 zuul:// resources             │
├──────────────────────────────────────────────────┤
│  helpers.py      API client, URL parsing         │
│  formatters.py   token-efficient output          │
│  parsers.py      Ansible/JUnit/log parsing       │
│  classifier.py   failure classification          │
├──────────────────────────────────────────────────┤
│  httpx clients   API (auth) + logs (no auth)     │
└────────┬─────────────────────────┬───────────────┘
         ▼                         ▼
    Zuul REST API           Log file hosts

アーキテクチャの詳細については、CLAUDE.md を参照してください。

掲載先

• PyPI — pip install mcp-zuul
• Glama — 品質：A/A/A
• Conare — マーケットプレイスへの掲載
• PulseMCP — サーバーディレクトリ
• LobeHub — エージェントのインストールに対応した MCP マーケットプレイス
• HiFriendBot — AI ツールディレクトリ
• pepy.tech — ダウンロード統計
• Docker — ghcr.io/imatza-rh/mcp-zuul

コントリビューション

コントリビューションを歓迎します。大きな変更については、まず issue を作成して相談してください。

# Fork, clone, and install dev dependencies
uv sync --extra dev

# Make changes, then verify
uv run pytest tests/ -v
uv run ruff check src/ tests/
uv run ruff format src/ tests/
uv run mypy src/mcp_zuul/

ライセンス

Apache-2.0