Insomnia MCPクライアントの使い方 — 自作MCPサーバーを検証する
InsomniaのMCPクライアント機能で外部MCPサーバーに接続し、ツール・プロンプト・リソースを発見して呼び出す手順と、認証の仕組み・MCP Inspectorとの違いを扱います。
Insomniaには、外部のMCPサーバーに接続してツール・プロンプト・リソースを発見し、その場で呼び出せる「MCPクライアント」機能が搭載されています。自作したMCPサーバーをClaude Codeにつなぐ前の動作確認に使えるほか、認証フローの成否をリクエスト・レスポンス単位で確認できる点が特徴です。
MCPサーバー自体の作り方はMCPサーバー自作ガイド、Claude Code側での接続構文はClaude Code MCP設定ガイド、MCPの概念整理はMCPクライアント概念ガイドが扱っています。
InsomniaのMCPクライアントとは
InsomniaのMCPクライアントとは、HTTP JSON-RPCで公開されたMCPサーバーのツール・プロンプト・リソースを発見し、パラメータを設定して直接呼び出せるInsomniaの機能です。MCPクライアントはプロジェクト単位のリソースで、1つのワークスペースに複数作成できます。
保存先はGitプロジェクト・クラウドプロジェクト・ローカルプロジェクトのいずれかで、他のプロジェクトリソースと同じようにバージョン管理・同期・共有ができます。
MCPサーバーが公開する要素は3種類に分かれます。
| 要素 | 内容 |
|---|---|
| Tools | 内容実行可能なサーバー側の関数 |
| Prompts | 内容再利用可能なプロンプトのテンプレート |
| Resources | 内容構造化された文脈データ |
InsomniaのMCPクライアントはこの3種類を発見し、アプリ内から直接呼び出し・照会・テストできるようにします。
クライアントを作成して接続する
手順は次のとおりです。
- Insomniaの左ペインで「MCP Clients」をクリックする
- 「Name」欄にクライアント名を入力する
- 「Create」をクリックする
- 「MCP Server URL」欄にサーバーのエンドポイントを入力する(例:
https://mcp.deepwiki.com/mcp) - 「Connect」をクリックして接続する
- サーバーが認証を要求する場合は、MCP Auth Flowに従ってサインインまたはトークンを入力する
- 接続後、左ペインに発見されたツール・プロンプト・リソースが表示されることを確認する
各ペインの役割
接続後の画面には、発見した操作の実行や結果確認に使う複数のペインが並びます。
| ペイン | 役割 |
|---|---|
| Params | 役割選択した操作の入力パラメータを編集する |
| Auth | 役割認証情報を設定する |
| Headers(リクエスト側) | 役割カスタムヘッダーの追加・上書き |
| Roots | 役割接続先サーバーが公開するエンドポイントやツールの一覧。選ぶとParamsタブに読み込まれる |
| Events | 役割発見の更新や認証状態の変化などリアルタイムのサーバーイベント |
| Notifications | 役割サーバーやInsomniaランタイムからの情報・エラーメッセージ |
| Headers(レスポンス側) | 役割サーバーから返るレスポンスヘッダー。ステータスやコンテンツタイプの確認に使う |
| Console | 役割生のリクエスト・レスポンスのログ。トラブルシューティング用 |
認証の仕組み(MCP Auth Flow)
MCPサーバーが認証を要求する場合、Insomniaは次の順序で対応します。
- サーバーが401 Unauthorizedを返し、有効なメタデータを含んでいれば、Insomniaが対応するOAuth認可サーバーを自動的に発見する
- 現在の認証方式が「OAuth 2.0 > MCP Auth Flow」で有効になっていれば、その方式でトークンを要求する
- 選択されていなければ、発見した認証フローへの切り替えをInsomniaが提案する
認可サーバーがDynamic Client Registration(DCR)に対応していない場合は、Personal Access Token(PAT、GitHub Copilot MCPサーバーなどが該当)を使うか、自分でOAuthアプリケーションを登録してClient IDとSecretをInsomniaに入力します。
Elicitation — サーバーが追加情報を求める仕組み
Elicitationは、リクエスト処理中にサーバーがクライアントへ追加情報を求める機能です。処理の流れは次の3ステップです。
- MCPサーバーが操作の処理中にElicitationリクエストを返す
- Insomniaがリクエストで定義されたフィールドをもとに、レスポンスペインにElicitationフォームを表示する
- ユーザーが必要な情報を入力すると、InsomniaがElicitationレスポンスとしてサーバーに送り返し、サーバーが元のリクエストの処理を続行する
サーバー側が追加の文脈や特定のフィールド値を必要とするワークフローで、この往復をInsomniaがフォーム表示・入力収集・レスポンス送信までまとめて処理します。
Sampling — サーバーがモデル応答を求める仕組み
Samplingは、MCPサーバーがInsomnia側のAI統合を使ってモデル応答を生成させる仕組みです。
{
"method": "sampling/createMessage"
}サーバーがこのリクエストを送ると、Insomniaはレスポンスペインに内容を表示してユーザーの確認を求めます。承認するとInsomnia AIが使っているモデルに転送され、返ってきた出力も表示・修正した上でサーバーへ返します。対応するサーバーであれば、この往復を複数ターンにわたって続けられます。
トークン上限を設定する
既定では、1リクエストがモデルの上限いっぱいまでトークンを消費できます。コストを抑えたい場合は次の手順で上限を設定します。
- 「Preferences」>「AI Settings」>「Activate an LLM」を開く
- 「LLM URL」を選択し、
https://api.openai.com/v1のようなプロバイダーのURLか自前のURLを入力する - 「API Token」欄にトークンを入力する
- 「Advanced Options」をクリックする
- 「Max Tokens」欄に1リクエストあたりの上限を入力する
Claude Codeへつなぐ前に確認すること
自作MCPサーバーをClaude Codeのmcp addで接続する前にInsomniaで検証しておくと、Claude Code側のエラーメッセージだけでは切り分けにくい失敗を先に潰せます。Claude Code側で「接続に失敗しました」としか出ない事象の大半は、下表のいずれかをInsomniaで先に確認すれば原因が特定できます。
| 確認項目 | Insomniaで見る場所 | Claude Code側での典型的な症状 |
|---|---|---|
| サーバーがHTTP JSON-RPCで正しく応答するか | Insomniaで見る場所Console(生のリクエスト・レスポンス) | Claude Code側での典型的な症状mcp add後に接続タイムアウトになる |
| Tools/Prompts/Resourcesが期待どおり公開されているか | Insomniaで見る場所左ペインの発見結果 | Claude Code側での典型的な症状ツールが一覧に出ない・呼び出せない |
| 401後にOAuthメタデータを正しく返しているか | Insomniaで見る場所MCP Auth Flow(Authタブ) | Claude Code側での典型的な症状認証ループ・トークンが通らない |
| レスポンスヘッダーやステータスが仕様どおりか | Insomniaで見る場所Headers(レスポンス側) | Claude Code側での典型的な症状断続的に成功・失敗を繰り返す |
この4項目をInsomniaでひととおり通してから接続すると、Claude Code側で発生する不具合が「サーバー実装側の問題」か「Claude Code側の設定の問題」かを切り分けやすくなります。
MCP Inspectorとの違い
自作MCPサーバーの動作確認という用途ではMCP Inspectorも選択肢になりますが、性格が異なります。MCP Inspectorはデバッグに特化した単機能ツールで、サーバー単体を素早く検査するのに向きます。InsomniaのMCPクライアントは、既存のAPIクライアント機能(リクエスト管理・環境変数・Gitプロジェクト連携)の上にMCP検査機能が乗る形なので、REST APIの開発と同じワークフローの中でMCPサーバーも扱いたいチームに向きます。チーム開発でAPIとMCPサーバーの両方をInsomniaのGitプロジェクトで一元管理しているなら、単発ツールのMCP Inspectorを別途導入する理由は薄くなります。
よくあるつまずき
401 Unauthorizedが出て発見が止まる
多くのMCPサーバーは、クライアントが先に認可サーバーを発見することを前提にしています。典型的な流れは「クライアントがサーバーに接続 → サーバーが401とメタデータを返す → クライアントがメタデータをたどってOAuthエンドポイントを取得する」という順序です。DCRに対応していないサーバーでは、事前登録済みのクライアントかPATを使います。
アップグレード後にMCPクライアントが表示されない
Insomnia 12.3より前のバージョンでクローンまたは開いたGit・クラウドプロジェクトにMCPクライアントのファイルが含まれている場合、アップグレード後にそのまま開いても表示されないことがあります。プロジェクトを再クローンすると、MCPクライアントのリソースが正しく読み込まれます。
サーバー側の操作一覧を更新したい
「MCP Servers」の左ペインで「Resync」をクリックすると、接続中のサーバーからツール・プロンプト・リソースを再取得できます。
実行に時間がかかっているMCPリクエストを止めたい
「Events」タブで、実行中のリクエストの横にあるキャンセルアイコンをクリックします。現在のMCPタスクが終了し、操作がアプリに戻ります。
よくある質問
Personal Access Tokenだけで認証できますか
できます。「Auth」タブで「Bearer Token」を選び、「Token」欄にPATを入力すれば、OAuthフローを経由せずに認証できます。
OAuth 2.0の一覧に「MCP Auth Flow」が出てきません
サーバーのメタデータに有効な認可エンドポイントが含まれていない場合、この選択肢は表示されません。代わりにPersonal Access TokenかBasic Authを使います。
MCPサーバーに接続できません
MCPサーバーはHTTP JSON-RPCトランスポートに対応している必要があります。接続に失敗する、あるいは何も発見されない場合は、サーバーが有効なMCPエンドポイントを公開しておりオンラインであることを確認します。サーバーが一時的に応答しない状態でも、Insomniaは次回の同期が成功するまでキャッシュされたリソースを表示し続けます。
認証をやり直したいときはどうしますか
「Authentication」タブを開き、サーバーとの接続を解除してから、現在のアクセストークンの値を削除し、再接続するかリクエストを送ってフローを再度トリガーします。MCP Auth Flowが再始動するのはサーバーが401 Unauthorizedを返したときだけで、個々のMCP Auth呼び出しを部分的にやり直すことはできず、フロー全体をやり直す形になります。
まとめ
InsomniaのMCPクライアントは、既存のAPIクライアントの延長として、外部MCPサーバーのツール・プロンプト・リソースを発見しその場で呼び出せる機能です。認証はサーバーが返す401とメタデータから自動的にOAuthフローへ誘導される設計で、DCR非対応のサーバーではPATかOAuthアプリの手動登録に切り替えます。ElicitationとSamplingという2つの拡張機能は、単なるリクエスト・レスポンスを超えたMCPサーバーの挙動を確認したいときに重要です。単発のデバッグならMCP Inspector、API開発の一連の流れの中でMCPサーバーも検証したいならInsomniaのMCPクライアント、という使い分けが妥当です。