数分でMCPサーバーをテストする方法

Model Context Protocol (MCP) は、LLMアプリケーションを外部データやツールに接続するためのオープンスタンダードとして登場しました。MCPサーバーを構築または統合する際、MCPサーバーをテストし、ツール、プロンプト、リソースが期待通りに動作することを確認する信頼性の高い方法が必要です。Apidog MCPクライアントは、まさにそのための組み込みのプロフェッショナルな環境を提供し、Apidogを今日利用できる最も効果的なMCPサーバーテストツールの1つにしています。

このガイドでは、Apidogを使用してMCPサーバーをステップバイステップでテストする方法を説明します。MCPクライアントの作成方法、STDIOまたはHTTP経由での接続方法、ツールとプロンプトのデバッグ方法、およびMCP統合を堅牢で保守可能に保つためのベストプラクティスを学びます。

ボタン

MCPサーバーのテストにApidog MCPクライアントを使用する理由

適切なMCPサーバーテスト環境を選択することは、どれだけ迅速にイテレーションできるか、そして統合にどれだけ自信を持てるかに影響します。Apidogの組み込みMCPクライアントは、個別のツールをやりくりするのではなく、単一の統合されたワークフローに適合するように設計されています。

利点	あなたにとっての意味
単一のワークスペース	HTTPプロジェクト内でMCPクライアントを作成し、アプリを切り替えることなくAPIとMCPのデバッグを切り替えられます。
完全なプロトコルサポート	単一のインターフェースから、MCPの3つのコア機能であるツール、プロンプト、リソースをデバッグできます。
デュアルトランスポート	STDIO経由でローカルサーバーをテストし、HTTP（Streamable HTTP）経由でリモートサーバーを認証を含めてテストできます。
再利用とコラボレーション	設定済みのMCPクライアントをプロジェクトに保存し、チームと共有できます。

Apidogは、サーバーアドレス、環境値、ヘッダー、パラメーターにおける変数もサポートしているため、設定を再入力することなく環境（例：開発環境と本番環境）を切り替えることができます。すでにAPI設計とテストにApidogを使用しているチームにとって、MCPサーバーテストを追加することで、コンテキスト切り替えが減り、ドキュメントと動作が一箇所にまとまります。

MCPサーバーをテストする前に必要なもの

ApidogでMCPサーバーのテストを開始する前に、以下のものが準備されていることを確認してください。

Apidogアカウントとプロジェクト — MCPクライアントを追加するHTTPプロジェクトを作成または開きます。
MCPサーバーの詳細 — STDIOの場合はコマンド (例: npx -y @modelcontextprotocol/server-everything)、またはHTTPの場合はURL (例: https://example-server.modelcontextprotocol.io/mcp)。
STDIOのランタイム — ローカルコマンドを使用する場合、必要なランタイム (例: Node.js) がインストールされており、PATHが通っている必要があります。
認証 (HTTPの場合) — サーバーがOAuth 2.0、APIキー、Bearerトークン、その他の認証を使用する場合、資格情報または設定を準備しておきます。ApidogはサポートされているサーバーのOAuth 2.0設定を自動的にフェッチできます。

追加のプラグインや個別のMCPテストツールは不要です。ApidogのMCPクライアントは組み込みで、すぐに使用できます。

Apidogを使ったMCPサーバーのステップバイステップテスト方法

ステップ1：ApidogでMCPクライアントを作成する

ApidogでHTTPプロジェクトを開きます。
新しいエンドポイントを作成し、タイプとしてMCPを選択します。
MCPクライアント設定画面が表示され、サーバーアドレスを入力するか、設定ファイルを貼り付けることができます。

これにより、プロジェクト内に専用のMCPクライアントエンドポイントが作成され、他のAPIアセットと一緒にMCPサーバーをテストできます。

ステップ2：MCPサーバーに接続する

サーバーアドレスを入力

Apidogは複数の入力スタイルを受け入れ、貼り付けた内容からトランスポートを推測します。

ターミナルコマンドを貼り付け → プロトコルがSTDIOに切り替わります。
例: npx -y @modelcontextprotocol/server-everything
URLを貼り付け → プロトコルがHTTPに切り替わります。
例: https://example-server.modelcontextprotocol.io/mcp

また、MCP設定ファイルを貼り付けることもできます。Apidogはこれを解析し、サーバー名、コマンドまたはURL、環境変数、および関連フィールドに入力します。ファイルに複数のサーバーがリストされている場合、最初の一つが使用されます。

MCPサーバーファイル例 (STDIO):

{

  "mcpServers": {

    "Everything Server": {

      "command": "npx",

      "args": ["-y", "@modelcontextprotocol/server-everything"],

      "env": {}

    }

  }

}

MCPサーバーエントリ例 (HTTP):

{

  "type": "streamable-http",

  "url": "https://example-server.modelcontextprotocol.io/mcp"

}

接続を確立

接続をクリックします。
STDIO: Apidogはローカルプロセスを実行する前にセキュリティ確認を表示する場合があります。確認後、プロセスを開始して接続します。
HTTP: ApidogはURLに接続リクエストを送信します。OAuth 2.0の場合、認証設定を取得し、認証ウィンドウを表示できます。APIキー、Bearerトークン、Basic認証などの場合、認証タブで設定します。

接続が成功すると、ディレクトリツリーにサーバーのツール、プロンプト、リソースが表示されます。これで、ApidogをこのサーバーのメインのMCPサーバーテストツールとして使用できます。

ステップ3：ツール、プロンプト、リソースをデバッグする

ツール — 実行可能なサーバーサイド関数。ツールを選択し、フォームまたはJSONエディターでパラメーターを設定し、実行をクリックします。結果は応答エリアに表示されます。

プロンプト — 事前定義されたプロンプトテンプレート。プロンプトを選択し、任意のパラメーターを入力して実行をクリックすると、生成されたプロンプトテキストが得られます。

リソース — サーバーによって公開されるデータリソース。リソースを選択し、実行をクリックしてコンテンツをフェッチします。

これら3つすべて（ツール、プロンプト、リソース）を実行することで、MCPサーバーをテストする際に完全に網羅し、何も設定ミスや破損がないことを確認できます。

ステップ4：環境、認証、ヘッダーを設定する

環境 (STDIOのみ): 環境セクションで、MCPサーバープロセス用の環境変数 (例: ACCESS_TOKEN, NODE_ENV) を設定します。
認証 (HTTPのみ): 認証タブを使用して、APIキー、Bearerトークン、JWT Bearer、Basic認証、Digest認証、またはOAuth 2.0を設定します。OAuth 2.0対応サーバーの場合、Apidogは認証設定を自動取得して入力できます。

ヘッダー (HTTPのみ): MCPサーバーに必要なカスタムHTTPヘッダーを追加します。

変数 {{variable_name}} は、サーバーアドレス/コマンド、環境値、ヘッダー、認証、およびパラメーター値でサポートされているため、環境間で設定を再利用できます。

ステップ5：応答を表示して設定を保存する

応答エリアには2つのタブがあります。

メッセージ — ユーザー駆動型イベント: 接続/切断、リクエスト/レスポンス。
通知 — サーバー駆動型メッセージ (例: 通知、ツールリストの更新)。

メッセージをクリックすると、詳細 (タイプ、コンテンツ、タイムスタンプ) が表示されます。「エンベロープ付き」に切り替えると、完全なJSON-RPCペイロードを表示できます。

MCPクライアントをプロジェクトに保存して、再利用やチームコラボレーションを可能にします。ディレクトリツリー (ツール、プロンプト、リソースのリスト) は接続ごとに更新され、ローカルに保存されます。

MCPサーバーテストのベストプラクティス

単一のトランスポートから開始する — ローカル開発にはSTDIOを、リモートまたは本番環境に近いテストにはHTTPを使用し、両方のパスが機能することを確認します。
3つのインターフェースすべてをテストする — 少なくとも1つのツール、1つのプロンプト、1つのリソースを実行して、サーバーのエンドツーエンドを検証します。
変数を使用する — サーバーURL、トークン、環境値を変数に格納することで、クライアントを毎回編集することなく環境を切り替えられます。
通知タブを確認する — 接続後にディレクトリツリーが空の場合、通知タブを開いて、サーバーがツール/リストの更新やエラーを送信したかどうかを確認します。
パラメーターの型を検証する — フォームモードではApidogが型を検証します。JSONエディターモードでは、パラメーターの型の不一致を防ぐために、数値を引用符で囲まず、ブール値にはtrue/falseを使用します。

一般的なMCPサーバーテストの問題のトラブルシューティング

問題	対処法
STDIO: 「command not found」	必要なランタイム（例：Node.js）をインストールし、コマンドパスが正しいことを確認してください。
HTTP: 401	ApidogにOAuth 2.0の自動設定を試させてください。失敗した場合は、認証タブで手動で認証を設定してください。
接続されたがツリーが空	サーバー構成を確認し、サーバーからのツール/リスト応答について通知タブをチェックしてください。
パラメーターの型の不一致	検証にはフォームモードを使用するか、JSONでは数値に引用符を付けず、ブール値にはtrue/falseを使用してください。

結論

単一で高機能なMCPサーバーテストツールを使用すれば、MCPサーバーのテストは簡単です。Apidogの組み込みMCPクライアントは、HTTPプロジェクト内でMCPエンドポイントを作成し、STDIOまたはHTTP経由で接続し、Apidogを離れることなくツール、プロンプト、リソースをデバッグすることを可能にします。設定の貼り付け、環境変数、認証（OAuth 2.0の自動設定を含む）、および変数のサポートにより、セットアップは迅速かつ繰り返し可能になります。プロジェクトにクライアントを保存することで、再利用とチームコラボレーションがサポートされ、メッセージタブと通知タブによりプロトコルの動作が明確に可視化されます。

すでにAPIワークフローに適合するツールでMCPサーバーテストを深く掘り下げてください。個別のインストールも、コンテキスト切り替えも不要です。RESTまたはHTTP APIとModel Context Protocolサーバーの両方に単一のワークスペースを提供するため、チームは別のMCPサーバーテストアプリをスタックに追加することなくMCPを採用できます。既存のMCP設定ファイルを貼り付けるだけでApidogが接続詳細を自動入力する機能はセットアップ時間を短縮し、変数のサポートにより、開発、ステージング、本番のサーバーアドレスと資格情報を簡単に管理できます。問題が発生した場合、メッセージ（ユーザーの操作）と通知（サーバー駆動の更新）の区別により、問題がクライアント側にあるのかサーバー側にあるのかを簡単に特定できます。

サードパーティのMCPサーバーを統合する場合でも、自社のサーバーを検証する場合でも、このガイドに従うことで、自信を持ってMCPサーバーをテストし、LLMとツールの統合を信頼性の高いものに保つことができます。次のMCPプロジェクトでApidog MCPクライアントを試して、MCPサーバーのエンドツーエンドテスト方法を効率化してください。Apidogにサインアップして、APIの設計、テスト、ドキュメント作成を行うのと同じプラットフォームにMCPサーバーテストを取り込みましょう。

ボタン