mcp-tester

MCP ツールテスター

現在の Claude Code セッションで利用可能な MCP（Model Context Protocol）サーバーのツールをテスト、評価するための包括的なスキルです。

使用するタイミング

以下の場合にこのスキルを使用します：

• MCP サーバーの構成を監査する
• ツールの品質と説明を検証する
• MCP ツールのテストケースを生成する
• ツールの命名規則とパラメーターの効率性を確認する
• サーバー間のツールの重複を分析する
• 応答の品質と形式の効率性を評価する
• MCP 統合の問題をデバッグする

前提条件

MCP サーバーを Claude Code の設定で構成しておく必要があります。ユーザーが存在しないツールのテストを依頼した場合は、MCP サーバーを設定に追加するよう案内してください。

ワークフロー

包括的なテストを行うため、以下のフェーズを順に実行します：

フェーズ 1：検出

現在のセッションで利用可能な MCP ツールをすべて特定します。

手順：

1. mcp__ プレフィックスが付いたツールをすべて一覧表示する
2. サーバーごとにグループ化する（2つ目の __ より前の名前空間を使用）
3. インベントリ表を生成する

出力形式：

## Tool Inventory

| Server | Tool Name | Required Params | Optional Params | Description Preview |
|--------|-----------|-----------------|-----------------|---------------------|
| context7 | resolve-library-id | libraryName, query | - | Resolves package to Context7 ID... |
| context7 | query-docs | libraryId, query | - | Retrieves documentation... |

報告する指標：

• サーバーの合計数：[数]
• ツールの合計数：[数]
• サーバーごとのツール内訳

フェーズ 2：品質分析

各ツールの設計品質を評価します。

命名規則の分析

以下を確認します：

• ケバブケースの一貫性：getUser や get_user ではなく get-user を使用しているか
• 動詞を先頭にした命名：create-item、list-users、delete-record
• 明確さ：名前だけで目的を理解できるか
• 名前空間の衝突：サーバー間で類似した名前がないか

説明の品質スコア

スコア	基準
優秀	目的、使用場面、例、入力／出力の想定が明確
良好	目的が明確で、ある程度の背景情報と基本的な想定がある
普通	目的は示されているが、背景情報や例が不足している
不十分	説明が曖昧、欠落、または誤解を招く

以下を評価します：

• ツールが何をするのか説明されているか
• いつ使用するのか説明されているか
• 使用例があるか
• エッジケースが記載されているか

パラメーター効率の分析

以下を確認します：

• 必須と任意のバランス：必須パラメーターは本当に必要か
• 型の具体性：該当する場合、汎用の string より enum を使用しているか
• デフォルト値：適切なデフォルト値が設定されているか
• 命名の明確さ：名前からパラメーターの目的を理解できるか
• トークンコスト：説明の長さがコンテキストに与える影響を推定する

トークン効率の計算式：

Efficiency = (Useful information conveyed) / (Token count)

説明が複雑さに比べて冗長なツールにフラグを付けます。

重大度の指標

検出事項には、以下の指標を使用します：

• 🔴 重大：説明がない、目的が不明確、スキーマが壊れている
• 🟡 警告：説明が過度に冗長、パラメータースキーマが非効率、命名が不明確
• 🔵 提案：軽微な命名の改善、任意の機能強化
• ✅ 良好：設計が優れており、明確で効率的

分析の出力形式：

### Tool: `mcp__server__tool-name`

**Naming**: ✅ Clear verb-first naming
**Description**: 🟡 Warning - Verbose (450 tokens), could be reduced to ~200
**Parameters**: 🔵 Suggestion - Consider enum for `format` param

**Detailed Findings:**
- [Specific observations]

**Recommendations:**
- [Actionable improvements]

フェーズ 3：テスト設計

AAA（Arrange-Act-Assert）パターンを使用して、各ツールのテストケースを生成します。

テストカテゴリ

1. 有効な入力（正常系）

• 必須パラメーターのみ
• すべてのパラメーターに有効な値を指定
• 有効範囲の限界値（最大長の文字列、境界値の数値）

2. 無効な入力（エラー処理）

• 必須パラメーターの欠落
• パラメーターの型が不正（数値が必要な箇所に文字列を指定）
• 無効な値（負の ID、不正な形式の URL）
• 不正なデータ構造

3. エッジケース

• 空文字列 ""
• 非常に長い文字列（1000文字以上）
• 特殊文字と Unicode
• null に類する概念（null、undefined、None）
• 境界値（0、-1、MAX_INT）
• 空白文字のみの文字列

テストケースのテンプレート

### Test: [Tool Name] - [Scenario Name]

**Category**: Valid / Invalid / Edge Case

**Arrange**:
- Context: [What setup is needed]
- Preconditions: [What must be true]

**Act**:
```json
{
  "param1": "value1",
  "param2": "value2"
}

アサート：

• 期待される動作：[どうなるべきか]
• 期待される応答形式：[構造]
• 期待されるエラー（無効な場合）：[エラーの種類／メッセージ]

#### Test Generation Guidelines

For each tool, generate at minimum:
1. 1 happy path test with minimal params
2. 1 happy path test with all params
3. 1 missing required param test
4. 1 wrong type test
5. 1 edge case test (empty/boundary)

### Phase 4: Test Execution

Execute generated tests and capture results.

#### Read-Only Tools
Execute immediately without confirmation:
- Tools that fetch/query data
- Tools that list/search resources
- Tools that analyze/inspect

#### Mutating Tools
**ALWAYS ask for confirmation before testing:**

```markdown
⚠️ **Mutating Tool Detected**

Tool: `mcp__server__create-item`
Operation: Creates new item in external system

**Test Parameters:**
```json
{
  "name": "test-item-12345",
  "type": "test"
}

想定される影響：

• 外部システムに新しいアイテムが作成されます
• Webhook や通知がトリガーされる可能性があります
• アイテムを手動でクリーンアップする必要がある場合があります

このテストを実行しますか？（はい／いいえ／スキップ）

Mutating operations include:
- `create`, `write`, `post`, `add`, `insert`
- `update`, `edit`, `modify`, `patch`, `put`
- `delete`, `remove`, `destroy`, `clear`
- `send`, `publish`, `trigger`, `execute`

#### Response Capture

For each test, capture:
- Full response content (truncate if > 2000 chars)
- Response time (if perceivable delay)
- Error messages and codes
- Unexpected warnings or notices

### Phase 5: Rating & Feedback

Rate each tool's test results and provide actionable feedback.

#### Rating Criteria

| Rating | Symbol | Criteria |
|--------|--------|----------|
| **Worked** | ✅ | Response matches expected format, no errors, useful output |
| **Partially Worked** | 🟡 | Response returned but incomplete, warnings present, or unexpected format |
| **Failed** | ❌ | Error returned, timeout, or completely wrong behavior |

#### Quality Assessment Dimensions

1. **Response Completeness** (High/Medium/Low)
   - Does it return all expected data?
   - Are there missing fields?

2. **Response Efficiency** (High/Medium/Low)
   - Token usage vs. value provided
   - Unnecessary verbosity in response?

3. **Error Handling** (Clear/Vague/Missing)
   - Are error messages helpful?
   - Do they indicate how to fix the issue?

4. **Format Consistency** (Consistent/Inconsistent)
   - Does response format match description?
   - Is format consistent across calls?

#### Feedback Template

```markdown
## Tool: `mcp__server__tool-name`

### Test Results Summary
| Test | Category | Rating | Notes |
|------|----------|--------|-------|
| Minimal params | Valid | ✅ Worked | Response in 200ms |
| All params | Valid | ✅ Worked | - |
| Missing required | Invalid | 🟡 Partial | Error unclear |
| Wrong type | Invalid | ❌ Failed | No error, silent fail |
| Empty string | Edge | ✅ Worked | Handled gracefully |

### Overall Rating: 🟡 Partially Worked (4/5 tests passed)

### Quality Assessment
- **Completeness**: High - Returns all documented fields
- **Efficiency**: Medium - Response includes redundant metadata
- **Error Handling**: Vague - Errors don't indicate fix
- **Consistency**: Consistent

### Critical Issues
🔴 Silent failure on wrong type - should return validation error

### Improvement Suggestions
1. Add input validation with descriptive error messages
2. Remove redundant `metadata.internal_id` from response (saves ~50 tokens)
3. Consider pagination for list responses

フェーズ 6：ツール横断分析

ツールセット全体を分析します。

冗長性の検出

以下を確認します。

• 機能が重複するツール
• 異なるサーバー間で類似した操作
• 名前が異なる重複機能

出力形式：

## Redundancy Findings

| Tool A | Tool B | Overlap | Recommendation |
|--------|--------|---------|----------------|
| mcp__a__get-user | mcp__b__fetch-user | 90% same function | Consolidate to single tool |
| mcp__a__list-all | mcp__a__search | Search can replace list | Deprecate list-all |

統合の機会

以下が可能なツールを特定します。

• 統合：類似したツールをモードパラメーター付きの1つのツールにまとめる
• 一括処理：個別の操作を一括操作にまとめる
• 簡素化：複雑なツールを、焦点を絞った複数のツールに分割する

不足している機能

ツールのカバレッジにおける不足を記録します。

• CRUD 操作が不完全（作成はできるが削除はできない）
• フィルタリングのない読み取り操作
• 個別操作に対する一括処理の代替手段がない

効率化に関する推奨事項

## Efficiency Recommendations

### High Impact
1. **Reduce description verbosity** - 3 tools have descriptions >500 tokens
   - Potential savings: ~800 tokens total

### Medium Impact
2. **Add enum constraints** - 5 parameters accept free text but have limited valid values
   - Improves: Validation, documentation, autocomplete

### Low Impact
3. **Standardize naming** - Mix of `get-X` and `fetch-X` patterns
   - Improves: Consistency, discoverability

出力レポートのテンプレート

すべてのフェーズの完了後に、このレポートを生成します。

# MCP Tool Test Report

**Generated**: [timestamp]
**Session ID**: [if available]

---

## Executive Summary

| Metric | Value |
|--------|-------|
| Servers Tested | [N] |
| Tools Tested | [N] |
| Tests Executed | [N] |
| Pass Rate | [X]% |

### Results Overview
- ✅ **Passed**: [X] tools
- 🟡 **Partial**: [Y] tools
- ❌ **Failed**: [Z] tools

### Key Findings
- 🔴 [N] critical issues requiring immediate attention
- 🟡 [N] warnings to address
- 🔵 [N] suggestions for improvement

---

## Tool Inventory

[Phase 1 output]

---

## Quality Analysis

[Phase 2 output for each tool]

---

## Test Results

[Phase 5 output for each tool]

---

## Cross-Tool Analysis

[Phase 6 output]

---

## Recommendations

### 🔴 Critical (Must Address)
1. [Issue] - [Tool] - [Impact] - [Fix]

### 🟡 Warning (Should Address)
1. [Issue] - [Tool] - [Impact] - [Fix]

### 🔵 Suggestions (Consider)
1. [Improvement] - [Tool] - [Benefit]

---

*Report generated by mcp-tester skill*

よくある落とし穴

このセクションでは、MCP ツールのテスト時に遭遇した実際の失敗パターンとアンチパターンを記載します。こうした注意点は気づきにくく、何度も試行錯誤する中で発覚することがよくあります。

テストカバレッジの不足（エッジケースとエラーパスの見落とし）

問題： 正常系の入力ではテストが成功しても、本番環境ではエッジケースやエラー条件で失敗します。エラーパスのテストが不足すると、ツールの信頼性に盲点が生じます。

避けるべきアンチパターン：

• ❌ 必須パラメーターを最小限にしてテストするだけでは不十分です。ツールはオプションパラメーターがあると動作しなくなる可能性があります
• ❌ 成功パスだけをテストしてはいけません。エラー処理も同様に重要です
• ❌ 現実的なデータだけを使用してはいけません。非現実的な値によってスキーマ検証の不足が明らかになります
• ❌ 境界条件（最大長の文字列、ゼロ、負の数、空のコレクション）をテストしない
• ❌ Unicode や特殊文字のテストを省略しないでください。エンコーディングの問題が明らかになることがよくあります

パターン：包括的なテストマトリックス

For each tool, test:
✅ Happy path: minimal params
✅ Happy path: all params  
✅ Missing required param (each required param tested separately)
✅ Wrong param type (string to number, number to boolean, etc.)
✅ Invalid enum value (param expects ['active', 'inactive'], test 'disabled')
✅ Empty string / null-like values
✅ Very long strings (1000+ chars, 10K+ chars)
✅ Special characters: !@#$%^&*()_+-={}[]|:;"'<>?,./~`
✅ Unicode: emoji, CJK, RTL text
✅ Boundary values: 0, -1, MAX_INT, Float edge cases
✅ Malformed data: incomplete JSON, null objects, circular references

影響： テストカバレッジが不十分だと、実際のデータで使用した際にツールが失敗します

---

モックした依存関係の動作が不適切（非現実的なテストデータ）

問題： モックデータを使ったテストは成功しても、実際の MCP サーバーへの呼び出しでは失敗します。モックの動作が実際のサーバーの動作（タイムアウト、エラー形式、レスポンスサイズなど）と一致しません。

避けるべきアンチパターン：

• ❌ 小さすぎるレスポンスをモックする（モックは10件を返すが、実際の API は1000件以上を返す）
• ❌ 標準と異なる形式のエラーレスポンスをモックする（実際のサーバーは異なる形式のエラーを返す）
• ❌ モックでは即座にレスポンスが返ると想定する（実際のサーバーにはレイテンシーがあります）
• ❌ 実際のサーバーでは認証が必要なのに、成功をモックする
• ❌ モックの動作でレート制限を考慮しない
• ❌ 実際のサーバーが検証エラーを返すのに、null や空のレスポンスをモックする

パターン：現実的なモックの動作

When mocking MCP tool responses:
✅ Return realistic response sizes (don't shrink large responses to 1-2 items)
✅ Match actual error response format (test against real API error docs)
✅ Add realistic latency (~100-500ms for network calls)
✅ Include rate limit headers/indicators in mock
✅ Mock pagination correctly (include next_page token, limits)
✅ Match response schema exactly, including optional fields that are usually present
✅ Test against actual MCP server output when possible (don't guess schema)

不一致の例：

// ❌ Mock (too clean)
{ "users": [{ "id": 1, "name": "Alice" }] }

// ✅ Real API (includes metadata, nulls, pagination)
{
  "data": [{ "id": 1, "name": "Alice", "email": null, "tags": [] }],
  "meta": { "total": 5000, "page": 1, "limit": 50, "next": "cursor-xyz" },
  "timing": { "ms": 234 }
}

影響： モックを使えばローカルではテストが成功しても、実際の MCP サーバーに対しては失敗します

---

非同期処理のタイミング問題（競合状態とタイムアウト）

問題： テストを個別に実行すると成功するのに、並列実行すると断続的に失敗します。セットアップやティアダウンの競合状態、実際には成立しないタイムアウトの想定、または予測不能な順序で完了する非同期処理が原因です。

避けるべきアンチパターン：

• ❌ ツールが一定のタイムアウト内に応答すると想定する（例：「すべてのツールが1秒未満で応答する」）
• ❌ 適切な分離を行わずにテストを並列実行する
• ❌ アサーションの前に非同期処理の完了を待たない
• ❌ 適切にリセットせずに、テスト間で MCP サーバー接続を再利用する
• ❌ 並行するテスト実行で特定の実行順序を想定する
• ❌ 実際のレイテンシーに対するテストをせず、任意のタイムアウト値を設定する
• ❌ サーバーのウォームアップ時間を考慮しない（最初のリクエストは後続のリクエストより遅くなります）

パターン：堅牢な非同期テスト

✅ Set timeouts per tool (measure real response times first)
✅ Use proper async/await or .then() chains — no unhandled promises
✅ Isolate tests: each test gets fresh MCP server connection if possible
✅ Add explicit setup/teardown phases with proper waiting
✅ For concurrent tests: use semaphores/locks to prevent interference
✅ Test with real latency: add 100-500ms overhead to account for network
✅ Run tests multiple times to catch intermittent failures
✅ Use flake detection: run failing tests 5x to confirm it's not timing

競合状態の例：

// ❌ No await - assertion runs before operation completes
const test = () => {
  callMCPTool({ param: "value" });
  assert(responseReceived); // Fails! Call still pending
};

// ✅ Proper await
const test = async () => {
  const response = await callMCPTool({ param: "value" });
  assert(response.success); // Now it's safe to assert
};

影響： テスト結果への信頼性が低く、ときどき成功し、ときどき失敗する不安定なテストになります

---

ツールスキーマの検証不足（無効なパラメーターが受け入れられる）

問題： ツールが、スキーマ検証で拒否されるべき無効なパラメーター値を受け入れます。MCP スキーマ検証が不完全なため、不正な入力がサーバーに渡り、下流で原因の分かりにくいエラーが発生します。

避けるべきアンチパターン：

• ❌ 必須パラメーターの検証をテストしない（必須パラメーターがない場合はエラーになるべきです）
• ❌ 列挙型の検証が機能すると決めつける（無効な列挙値が拒否されることをテストしてください）
• ❌ 型変換を確認しない（数値の 123 が必要なときに、ツールが文字列の "123" を受け入れる可能性があります）
• ❌ 長さやパターンの検証を省略する（文字列は 1 文字でも 10K 文字でもよいのでしょうか？）
• ❌ ネストされたオブジェクトのスキーマをテストしない（サブオブジェクト内の必須フィールド）
• ❌ 拒否されるべき null が拒否されると決めつける（またはその逆）
• ❌ 相互排他制約を確認しない（パラメーター A と B は同時に指定できません）

パターン：包括的なスキーマテスト

For each parameter:
✅ Test missing (should fail if required)
✅ Test wrong type (if expects number, pass string)
✅ Test enum validation (if expects ['a','b','c'], test 'd')
✅ Test length constraints (min/max length for strings)
✅ Test pattern/format validation (regex patterns, URLs, emails)
✅ Test numeric bounds (min/max for numbers, negative values)
✅ Test nested object structure (all required fields present?)
✅ Test null vs undefined behavior
✅ Test special characters in string params
✅ Validate response schema (returned data matches documented format)

検証不足の例：

// Tool spec says: name (required, string, max 255 chars)
// Test reveals:
callMCPTool({ name: 123 }) // ❌ Accepted! Should reject (not a string)
callMCPTool({ name: "a".repeat(1000) }) // ❌ Accepted! Should reject (>255 chars)
callMCPTool({ }) // ❌ Accepted! Should reject (required param missing)

影響： 無効なリクエストがツールに受け入れられる → MCP サーバーから分かりにくいエラーが返され、根本原因のデバッグが困難になります

---

統合テストの失敗（サーバーとクライアントの不一致）

問題： ツールはモックを使ったユニットテストでは動作しますが、実際の MCP サーバーに対する統合テストでは失敗します。ツールのスキーマがサーバーの想定と一致しない、レスポンス形式が異なる、またはエンドポイントが変更されています。

避けるべきアンチパターン：

• ❌ モックを使ったユニットテストのみを実施し、統合テストを省略する
• ❌ 実際の MCP サーバーを呼び出さずに、ツールを単独でテストする
• ❌ MCP サーバーの API が変更されたときにテストを更新しない
• ❌ 後方互換性があると決めつける（新しいサーバーバージョンでは古いテストデータが失敗します）
• ❌ 統合テストで認証・認可をテストしない
• ❌ 権限・スコープの検証を省略する（ツールの仕様で権限 X が必要とされている場合）
• ❌ 統合テストで成功ケースのみをテストし、エラーケースをテストしない

パターン：統合テスト

Separate unit tests (mocks) from integration tests (real server):

✅ Unit tests: test schema validation, parameter handling, response parsing
✅ Integration tests: call actual MCP server with real credentials/permissions
✅ Version your integration tests: document which server version they test
✅ Test error paths in integration: wrong credentials, missing permissions, server errors
✅ Validate response against schema in integration tests
✅ Test server downtime handling (timeouts, retries)
✅ Test against multiple server versions if applicable
✅ Use test fixtures: real-world data from actual server responses

不一致の例：

// Unit test passes
callMCPTool({ userId: 123 }) // ✅ Mock returns { user: { id: 123 } }

// Integration test fails  
callMCPTool({ userId: 123 }) // ❌ Real server expects { user_id: 123 } (different key!)

影響： ローカルではテストが通っても、CI／本番環境で実際の MCP サーバーに対して実行すると失敗します

---

予防策

ツールのテストを確定する前に、次のチェックリストを使用してください。

• すべてのパラメーターをテスト済み：必須、オプション、型違い、無効な値、境界値
• エッジケースを網羅：空、大容量、Unicode、特殊文字
• エラーパスをテスト済み：考えられるすべてのエラー条件
• モックが実際の動作と一致：レスポンスサイズ、形式、レイテンシ、エラー
• 非同期処理を適切に待機：競合状態がない
• タイムアウトが妥当：推測ではなく実測値に基づいている
• スキーマ検証をテスト済み：無効な入力を適切に拒否する
• 統合テストを含む：実際の MCP サーバーに対するテスト
• バージョン互換性を確認済み：現在のサーバーバージョンでツールが動作する
• テストを複数回実行済み：不安定さやタイミングの問題がないことを確認

---

例

例 1：利用可能なすべてのツールをテスト

ユーザー：「すべての MCP ツールをテストして」

応答の流れ：

1. 合計 8 個のツールを持つ 3 台のサーバーを検出
2. 確認用に一覧表を提示
3. 品質を分析（警告 2 件、提案 1 件を発見）
4. 40 件のテストケースを生成（ツールごとに 5 件）
5. 状態を変更するツールを 2 個特定し、確認を求める
6. テストを実行し、結果を記録
7. 評価：成功 6 件、一部成功 1 件、失敗 1 件
8. ツール間を分析：重複を 1 件発見
9. 完全なレポートを生成

例 2：特定のサーバーをテスト

ユーザー：「context7 の MCP ツールだけをテストして」

応答の流れ：

1. context7 サーバーに絞り込み（ツール 2 個）
2. 両方のツールを詳細に分析
3. 10 件のテストケースを生成
4. 状態を変更するツールはないため、すべて実行
5. 対象を絞ったレポートを生成

例 3：品質監査のみ

ユーザー：「テストを実行せずに、MCP ツールの説明を監査して」

応答の流れ：

1. 検出フェーズ
2. 完全な品質分析
3. テスト実行を省略
4. 改善の提案を含む、品質に焦点を当てたレポートを提供

例 4：MCP サーバーが見つからない

ユーザー：「notion MCP ツールをテストしてください」

応答：

I don't see any Notion MCP tools in the current session.

To add a Notion MCP server:

1. Install the server:
   ```bash
   npm install -g @notionhq/notion-mcp-server

2. Claude Code の MCP 設定に追加します（~/.claude/mcp_settings.json）：

   {
     "mcpServers": {
       "notion": {
         "command": "notion-mcp-server",
         "env": {
           "NOTION_API_KEY": "your-api-key"
         }
       }
     }
   }
   

3. 新しいサーバーを読み込むため、Claude Code を再起動します

設定をお手伝いしましょうか？

## Error Recovery

If a test fails or times out:
1. Log the failure with available details
2. Continue testing remaining tools
3. Include failure in final report
4. Suggest debugging steps for failed tools

## MCP Inspector: Standalone Testing

For testing outside of Claude Code sessions, use the MCP Inspector:

```bash
# Launch MCP Inspector UI (browser-based)
npx @modelcontextprotocol/inspector

# Test a specific stdio server
npx @modelcontextprotocol/inspector stdio node /path/to/server.js

# Test a specific HTTP server
npx @modelcontextprotocol/inspector http http://localhost:3000/mcp

# With environment variables
MCP_API_KEY=your-key npx @modelcontextprotocol/inspector stdio node server.js

MCP Inspector では、次のことができます。

• 対話型のツール呼び出し UI
• スキーマ検証の表示
• リクエスト／レスポンスの検査
• サーバー機能の検出

MCP 接続の問題のデバッグ

# Check if MCP server process starts correctly
node dist/index.js  # Should hang waiting for input (stdio) or log port (HTTP)

# Test stdio protocol manually
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' | node dist/index.js

# Check server logs (stderr for stdio servers)
node dist/index.js 2>server.log &
# Then interact, then cat server.log

# For HTTP servers
curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

制限事項

• 現在のセッションで設定されていない MCP ツールはテストできません
• MCP サーバーの URL への HTTP リクエストは直接行いません
• フローの途中で対話型認証が必要なツールはテストできません
• 応答時間の測定値は概算です（体感の遅延に基づきます）
• サーバーの起動に関する問題やプロトコルへの準拠をテストするには、MCP Inspector が必要です