mcpField
M
mcp-release-qa

mcp-release-qa

github.com/xgent-aiテスト・品質164 回インストール今日更新
リポジトリ

mcp-release-qa について

mcp-release-qaは、ソースや単体テストの確認にとどまらず、ユーザーが実行するMCPサーバーを検証するスキルです。プロトコルセッション、実行時の機能検出、公開契約、トランスポート、インストール、再現可能なリリース証跡を確認します。

主な機能

  1. 01候補版から起動した新規プロセスをテスト
  2. 02初期化・機能検出・呼び出しを実行
  3. 03ソース・実行時・メタデータ・文書を照合
  4. 04ツール・リソース・プロンプトの契約を確認
  5. 05プロトコルと入力の失敗経路を検証
  6. 06公開されたインストール手順を確認

活用シーン

  1. 01MCPサーバーのリリース証跡の準備
  2. 02実行時機能とドキュメントの差異検出
  3. 03トランスポートと不正リクエスト処理の確認
  4. 04ソースツリー外でのインストール済み成果物の検証

MCP 対応

MCPサーバーのQA手順を定め、MCPクライアントまたは統合テスト環境から初期化、機能検出、呼び出しを実行します。ツール、リソース、テンプレート、プロンプト、トランスポートの動作を確認します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/xgent-ai/skills --skill mcp-release-qa

インストール後、Claude Code で/mcp-release-qaを入力して読み込まれたか確認します。

詳細

MCP リリース QA

ユーザーが実行するサーバーをテストします。スキーマのレビューやユニットテストの合格は、実行時の証拠にはなりません。

このスキルはセキュリティレビューを補完するものです。プロトコルの動作、公開されている契約とのずれ、トランスポートの正確性、再現可能なリリース証拠に焦点を当てます。

ルール

  • 候補リビジョンからビルドした、新しいサーバープロセスに対してチェックを実行します。
  • initialize、notifications/initialized、ディスカバリー、呼び出しは、同じセッション内で行います。新しいプロセスは新しい STDIO セッションです。
  • ソースコード上の登録内容を実装の正とし、公開ドキュメントはそれに一致すべき契約として扱います。
  • 正確なコマンドと未加工の応答を記録します。不足している証拠を「問題なさそうです」で置き換えないでください。
  • 本番データに対して、変更を伴う可能性のあるツールを呼び出さないでください。フィクスチャまたはサンドボックスを使用するか、安全なテスト環境がない場合は作業を中止し、その旨を明記します。
  • 実行のたびに、候補ソースから期待される機能の一覧を導き出します。

1. リリース対象を確認する

以下を特定します。

  • 候補コミットとビルドコマンド
  • サーバーのエントリーポイントとトランスポート:STDIO、Streamable HTTP、または SSE
  • サポートされている MCP プロトコルのバージョン
  • ツール、リソース、リソーステンプレート、プロンプトを登録するソースファイル
  • 生成されるカタログ、マニフェスト、README の表、インストール手順
  • 既存のプロトコル、統合、スモークテストのコマンド

テストハーネスを独自に作成する前に、リポジトリ標準のコマンドを優先します。package.json、pyproject.toml、Makefile、CI ワークフロー、コントリビューター向けの手順を確認してください。

2. クリーンなサーバーを起動する

候補をビルドし、テストに安全な設定で、ドキュメントに記載されたエントリーポイントを起動します。以下を記録します。

  • 正確なコマンド
  • コミット SHA
  • 環境変数名(値は伏せて記載)
  • 標準出力、標準エラー出力、終了ステータス
  • クライアントが使用するエンドポイントまたは子プロセスのトランスポート

STDIO の場合、標準出力にはプロトコルデータのみを出力します。ログ、バナー、スタックトレースは標準エラー出力に出力します。HTTP トランスポートの場合は、認証情報を表示せずにステータス、関連する MCP ヘッダー、セッション識別子の処理を記録します。

ドキュメントに記載された手順でサーバーを起動できない場合は、リリース失敗として報告し、起動エラーを一字一句そのまま保存します。

3. 完全なセッションを1回実行する

実際の MCP クライアント、またはリポジトリの統合テストハーネスを通じて、次の手順を実行します。

  1. サーバーがサポートするとするプロトコルバージョンを指定して initialize を実行します。
  2. ネゴシエートされたバージョンと、通知された機能を確認します。
  3. notifications/initialized を送信します。
  4. ping を呼び出します。
  5. サポートされる各ディスカバリーメソッドを呼び出します。
    • tools/list
    • resources/list
    • resources/templates/list
    • prompts/list
  6. 通知された各機能クラスから、代表的な読み取り専用の項目を少なくとも1つ実行します。
  7. リストメソッドがページ分割される場合は、カーソルがなくなるまでページを取得します。

初期化後のリクエストを、それぞれ別の単発プロセス経由で送信しないでください。これは、1つの有効なセッションではなく、複数の不完全なセッションを誤ってテストすることになります。

4. 一覧の一致を証明する

現在の証拠から、次の4つの一覧を作成します。

対象証拠
ソース登録されたツール、リソース、テンプレート、プロンプトの定義
実行時実行中のディスカバリーメソッドの結果
生成メタデータカタログ、マニフェスト、生成されたインデックス
ドキュメントREADME、リファレンスページ、インストール時の出力

安定した識別子を基準に比較し、次の内容を報告します。

  • 実行時に存在しないソースの項目
  • メタデータまたはドキュメントに存在しない実行時の項目
  • 古い名前、説明、引数、URI、プロンプトパラメーター
  • 候補サーバーを起動できない、ドキュメント記載のインストールコマンド

リポジトリ標準のビルドコマンドを使って派生ファイルを再生成し、その後も説明のつかない生成差分が作業ツリーに残っている場合は失敗とします。

5. 公開されている契約を確認する

検出された各項目について、実行時の定義がソースと一致していることを確認します。

ツール
  • 名前と説明は安定しており、具体的です。
  • inputSchema では、必要に応じて型、必須フィールド、列挙値、範囲を定義します。
  • ツールの契約が閉じている場合、未知のプロパティは拒否されます。
  • 変更、べき等性、読み取り専用、オープンワールドの注釈は、実際の動作と一致しています。
  • 成功した呼び出しは、公開されている場合、outputSchema に準拠します。
  • エラーはプロトコルエラーまたは構造化されたツールの失敗として返され、スタックトレースを漏らしません。
リソースとテンプレート
  • URI と MIME タイプは、登録済みの定義と一致しています。
  • 静的リソースは読み取り可能です。
  • テンプレートのパラメーターは、解決前に検証されます。
  • 存在しない、またはアクセスが禁止されているリソースは、明示的に失敗します。
プロンプト
  • 必須引数と任意引数は、検出結果と一致しています。
  • prompts/get は、有効な引数に対して使用可能なメッセージを返します。
  • 必須引数の欠落と未知のプロンプト名は、明示的に失敗します。

6. 失敗経路をテストする

最低限、次の項目を確認します。

  • 初期化が完了する前のリクエスト。
  • 不正な JSON、または無効な JSON-RPC エンベロープ。
  • 未知のメソッド。
  • サポートされていないプロトコルバージョン。
  • 初期化の繰り返し。
  • 未知のツール名、リソース名、プロンプト名。
  • 引数の欠落、余分な引数、型の誤り、範囲外の値。
  • 文書化されているトランスポートサイズ上限に一致するリクエストと、それを超えるリクエスト。
  • 認証情報とスタックトレースを伏せた、制御可能な内部エラー。

各レスポンスのリクエスト ID が正しいこと、有用なエラーメッセージが含まれていること、成功時の副作用が発生しないことを確認します。STDIO では、さらに、すべての標準出力行が完全なプロトコルメッセージであり、サーバーが診断出力を明示的に文書化している場合を除き、正常なセッション中に標準エラー出力が空であることも確認します。

7. インストールをスモークテストする

プロジェクトがインストールコマンドを公開している場合:

  1. ソースチェックアウトの外部に、一時的なインストール先を作成します。
  2. 公開されているインストールコマンドを、文書どおりに実行します。
  3. ソースツリー内のファイルに依存せず、インストール済みの成果物を起動します。
  4. 初期化、検出、読み取り専用の呼び出しを1回行う手順を繰り返します。
  5. コマンドの出力を保存してから、一時的なインストール先を削除します。

確認しただけのインストール文字列は、検証済みではありません。

8. 証拠を報告する

次の形式を使用します。

# MCP Release QA

Candidate: [commit]
Transport: [STDIO | Streamable HTTP | SSE]
Verdict: PASS | PASS WITH CAVEATS | FAIL

## Commands and results
- `[exact command]` — [exit status and result]

## Session transcript
- initialize: [result]
- discovery: [result]
- representative calls: [result]
- negative paths: [result]

## Parity
| Identifier | Source | Runtime | Metadata | Docs | Result |
|---|---|---|---|---|---|

## Findings
| Severity | Evidence | Impact | Narrowest fix |
|---|---|---|---|

## Missing evidence
- [check that could not run and why]

有効なセッションを完了できない、トランスポートを解析可能な状態に保てない、または無効な入力を安全に拒否できないサーバーには FAIL を使用します。危険な機能を誤解させない範囲に限られた、文書またはメタデータとの不一致にのみ PASS WITH CAVEATS を使用します。それ以外の場合は PASS を使用します。

コメント