Claude Media
n8nのMCP Server TriggerでワークフローをMCPサーバー化する方法
MCPClaude CodeClaude連携チュートリアル

n8nのMCP Server TriggerでワークフローをMCPサーバー化する方法

n8nのMCP Server Triggerノードでワークフローを外部公開し、Claude CodeやClaude Desktopからツールとして呼び出す設定手順を扱います。

読了目安 約11分

n8nの「MCP Server Trigger」ノードを使うと、n8nワークフローをMCP(Model Context Protocol)サーバーとして外部公開できます。ClaudeはMCPクライアントとして、公開されたワークフローをツールの一つとして直接呼び出せるようになります。ノード追加からClaude Code・Claude Desktopでの接続設定、実運用でつまずきやすい制限事項まで順に扱います。

n8n自身をMCPサーバー化する方法は本記事の範囲です。逆にn8nのワークフローから既存のMCPサーバーを呼び出す方法は、おすすめMCPサーバー10選で扱っているツール選定とは別の設定になるので、両者は混同しないでください。

MCP Server Triggerノードとは何か

MCP Server Triggerは、n8nをMCPサーバーとして動かし、URLを公開してMCPクライアントに接続させるトリガーノードです。通常のトリガーノードがイベントに応じて次のノードへ処理を渡すのに対し、このノードはツールノードへの接続と実行だけを行います。

接続したMCPクライアントは、n8n側に定義したツール一覧を取得し、個々のツールを呼び出して処理を実行させます。ワークフロー自体をツールとして公開するには、Custom n8n Workflow ToolノードをMCP Server Triggerに接続します。対応トランスポートはServer-Sent Events(SSE)とstreamable HTTPの2つで、標準入出力(stdio)には対応していません。

n8nには逆方向のMCP Client Toolノードもあり、こちらはn8nのAIエージェントが外部のMCPサーバーを呼び出す側です。今回扱うMCP Server Triggerとは役割が逆になるので、どちらを追加すべきか迷ったら「n8nをサーバーにするか、クライアントにするか」で判断します。

MCP Server Triggerノードの設定手順

設定するパラメーターは3つだけです。ワークフローにノードを追加したら、この順に埋めていきます。

  1. Path: MCP URLのパス部分です。既定では他のMCP Server Triggerノードと衝突しないランダムな値が入りますが、APIのプロトタイプ用途などで固定URLが必要なときは手動指定できます。ルートパラメーターの追加にも対応します。
  2. Authentication: None / Bearer auth / Header authの3方式から選びます。詳細は次の節で扱います。
  3. 接続先ツール: Custom n8n Workflow Toolノードをこのノードに接続し、外部公開したいワークフローをツールとして登録します。

ノードパネルの上部にはTest URLとProduction URLの2種類のMCP URLが表示され、トグルで切り替えられます。Test URLは「Listen for Test Event」の実行時か、ワークフローが未アクティブな状態でExecute workflowを実行したときに登録され、呼び出すとワークフロー画面上にデータが表示されます。Production URLはワークフローを公開(Activate)した時点で登録され、実行データはワークフロー画面には出ず、Executionsタブから個別の実行結果を確認する形になります。検証中はTest URL、公開後はProduction URLと使い分けます。

認証方式の使い分け

3つの認証方式は用途に応じて選びます。いずれもHTTP Requestクレデンシャルの設定を流用します。

認証方式向いている用途注意点
None向いている用途ローカル検証・信頼できる閉域ネットワーク内での利用注意点claude.aiのカスタムコネクタはAuthentication=Noneでもサインインを要求してくる(後述)
Bearer auth向いている用途APIキー1本で認証するシンプルな外部公開注意点Authorizationヘッダーにトークンを載せる構成にクライアント側を合わせる
Header auth向いている用途独自ヘッダー名で認証したいカスタムAPI注意点クライアント側の設定でヘッダー名・値を正確に一致させる

外部に公開するワークフローでNoneを選ぶ運用は避け、Bearer authかHeader authでトークンを要求する構成にします。誰でも呼び出せる状態は避けたいところです。

Claude Codeから呼び出す設定

Claude Codeではclaude mcp addコマンドでMCP Server TriggerのURLを登録します。トランスポートはhttpを指定するのが基本です。

# 基本構文
claude mcp add --transport http <サーバー名> <MCP URL>
 
# 認証ヘッダーを付ける場合
claude mcp add --transport http n8n-workflow https://your-n8n-instance.example.com/mcp/xxxx \
  --header "Authorization: Bearer your-token"

Claude CodeはまずHTTPトランスポートで接続を試み、サーバーが受け付けない場合にSSEへ自動的に切り替えます。この自動切り替えにはClaude Code v2.1.265以降が必要です。それより前のバージョン、またはSSEで直接接続したい場合は--transport sseを明示します。ただし公式ドキュメントはSSEトランスポート自体を非推奨としており、HTTPが使えるならHTTPを選ぶ方針です。設定後は/mcpコマンドでサーバーの接続状態を確認できます。

Claude Desktop・claude.aiから呼び出す設定

claude.aiやClaude Desktopでは、「Customize > Connectors」からMCP URLを直接追加する方法が公式手順として案内されています。認証が必要な場合は、n8n側で生成したトークンをコネクタ設定の認証情報に入力します。

n8nの公式ドキュメントでは、これとは別にmcp-remoteを経由してClaude Desktopの設定ファイルに直接エンドポイントを書き込む方法も示されています。

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<n8nのMCP URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<n8nで発行したトークン>"
      }
    }
  }
}

<n8nのMCP URL>と<n8nで発行したトークン>は、MCP Server Triggerノードのパラメーターとクレデンシャルから取得した実際の値に置き換えます。設定ファイルを直接編集する方法なので、記述を誤るとClaude Desktop起動時にエラーになる点に注意します。

トランスポートとツール実行結果のサイズ制限

MCP Server TriggerはSSEとstreamable HTTPのみに対応し、stdioには対応していません。Claude側もStreamable HTTPとレガシーのHTTP+SSEトランスポートの両方をサポートしていますが、レガシーHTTP+SSEはStreamable HTTPへの移行が進んでおり非推奨扱いです。n8nインスタンスをこれから構築するなら、streamable HTTPで接続できる構成を優先する方が長期的に安定します。

ツール実行結果のサイズにも上限があります。claude.ai・Claude Desktopではツール結果1件あたり約150,000文字、1回のツール呼び出しにつき240秒(4分)のタイムアウトが設定されています。Claude Codeでは既定25,000トークンで、MAX_MCP_OUTPUT_TOKENS環境変数で変更できます。n8nワークフローが大きなJSONやファイル内容をそのまま返す設計だと、この上限に引っかかって結果が切り詰められることがあるため、ツール化するワークフロー側で返却データを要約・ページング分割しておくと安全です。特にファイル添付やAPIレスポンスをそのまま返すワークフローは注意します。

よくあるつまずき

n8n公式ドキュメントが挙げている制限事項は3つです。いずれも見落とすと接続自体が不安定になるか、想定外の挙動につながります。運用に入る前に一通り目を通しておくと安心です。

Webhookレプリカを複数動かしている環境で接続が不安定になる

MCP Server TriggerはSSEかstreamable HTTPで永続接続を維持するため、同じサーバーインスタンスが接続を処理し続ける必要があります。queueモードでWebhookレプリカが1台なら問題ありませんが、複数レプリカで動かす場合は/mcp*宛のリクエストをすべて1台の専用レプリカへルーティングする構成に変更しないと、SSEとstreamable HTTPの接続が頻繁に切れたり、イベント配信が失敗したりします。

claude.aiがAuthentication=Noneでもサインインを要求する

claude.aiのカスタムコネクタは、MCP Server Trigger側のAuthenticationをNoneに設定していてもn8nへのサインインを求めてきます。n8nインスタンスが他のトリガーでn8nユーザー認証を提供している場合、claude.aiはドメイン内のすべてのMCPエンドポイントが同じ認証方式を使うと仮定するためです。n8n公式ドキュメントは、この挙動を示すクライアントはclaude.aiだけだと明記しています。

リバースプロキシ経由だとSSE・streamable HTTPが機能しない

nginxなどのリバースプロキシ配下でn8nを動かす場合、MCP用のエンドポイントでプロキシバッファリングを無効化しないと接続が失敗します。あわせてgzip圧縮の無効化(n8n側で処理済みのため)、チャンク転送エンコーディングの無効化、Connectionヘッダーを空文字にして転送ヘッダーから除去する設定も必要です。

location /mcp/ {
    proxy_http_version          1.1;
    proxy_buffering             off;
    gzip                        off;
    chunked_transfer_encoding   off;
 
    proxy_set_header            Connection '';
}

まとめ

n8nをMCPサーバーとして外部公開する仕組み自体は、ノードを追加してPath・Authentication・接続先ツールを設定するだけで完成します。手間がかかるのはむしろ接続後の運用面で、複数Webhookレプリカでのルーティング、claude.ai特有のサインイン要求、リバースプロキシ配下でのバッファリング設定の3点は事前に把握しておくと、公開後のトラブルシューティングを避けられます。Claude Code側の接続コマンドとMCPサーバーの自作方法はOpenAPI仕様からMCPサーバーを自動生成する3つの方法、公開したサーバーをMCP Registryへ登録する手順はMCP Registryへのリモートサーバー公開手順も参考にしてください。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →