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

n8nの「MCP Server Trigger」ノードを使うと、n8nワークフローをMCP(Model Context Protocol)サーバーとして外部公開できます。ClaudeはMCPクライアントとして、公開されたワークフローをツールの一つとして直接呼び出せます。

設定そのものはノードを置いてパラメーターを3つ埋めるだけです。時間がかかるのは接続後で、Claude側のタイムアウトや結果サイズの上限、レプリカ構成、リバースプロキシの設定が詰まりどころになります。

n8nをサーバーにするかクライアントにするか

MCP関連のノードは2種類あり、役割が逆です。どちらを置くか迷ったら、MCPの接続を受ける側か、接続しに行く側かで決めます。

MCP Server Triggerは、通常のトリガーノードとは動きが違います。イベントを受けて次のノードへ出力を渡すのではなく、接続されたツールノードを公開して実行するだけです。ワークフロー全体を公開したいときは、Custom n8n Workflow ToolノードをMCP Server Triggerにつなぎます。

対応するトランスポートはServer-Sent Events(SSE)とstreamable HTTPです。標準入出力(stdio)には対応しません。この制約が、後でClaude Desktopに接続するときの設定に効いてきます。

公開までの3ステップ

ノードを追加したら、次の順に進めます。

ノードパネルの上部には、Test URLとProduction URLの2つが表示され、切り替えて使います。Test URLは「Listen for Test Event」を選んだとき、またはワークフローが未公開の状態でExecute workflowを実行したときに登録されます。呼び出すと、ワークフロー画面にそのデータが表示されます。

Production URLはワークフローを公開した時点で登録されます。こちらの実行はワークフロー画面に出ません。結果を見たいときは、ワークフローのExecutionsタブから個別の実行を開きます。Claudeに登録するURLは、検証中はTest URL、運用ではProduction URLと使い分けます。

認証方式の選び方

3つの認証方式は、公開範囲で選びます。

インターネットに出すワークフローをNoneのまま置くと、URLを知っている相手なら誰でもツールを実行できます。外部公開ではBearer authかHeader authを選ぶ構成が基本になります。

Claude Codeから呼び出す設定

Claude Codeではclaude mcp addでMCP URLを登録します。トランスポートはhttpを指定します。

claude mcp add --transport http n8n-workflow https://your-n8n.example.com/mcp/xxxx \
  --header "Authorization: Bearer your-token"

トークンをコマンドにそのまま書くと、シェルの履歴に残ります。プロジェクトで共有する設定ファイルへ保存するなら、トークンを環境変数にして${N8N_MCP_TOKEN}の形で参照します。Claude Code v2.1.289で、--scope projectを付けて追加した結果が次のとおりです。

claude mcp add --transport http --scope project n8n-workflow \
  https://n8n.example.com/mcp/xxxx \
  --header 'Authorization: Bearer ${N8N_MCP_TOKEN}'

Added HTTP MCP server n8n-workflow with URL: https://n8n.example.com/mcp/xxxx to project config
Headers: {
  "Authorization": "[REDACTED]"
}
File modified: /path/to/project/.mcp.json

画面ではヘッダーの値が[REDACTED]と伏せられます。作成された.mcp.jsonには${N8N_MCP_TOKEN}が展開されないまま入っていました。

{
  "mcpServers": {
    "n8n-workflow": {
      "type": "http",
      "url": "https://n8n.example.com/mcp/xxxx",
      "headers": {
        "Authorization": "Bearer ${N8N_MCP_TOKEN}"
      }
    }
  }
}

--scopeの既定はlocalで、自分のそのプロジェクトだけに効きます。projectはこの.mcp.jsonに書いてチームで共有し、userは全プロジェクトで使います。

このファイルはGitに入れても、トークン本体は含まれません。ただし環境変数名には罠があります。リモートサーバーのurlやheadersでは、ANTHROPIC_AUTH_TOKENやNPM_TOKENのような認証情報の変数は、設定の有無にかかわらず空として読まれます。Bearer ${ANTHROPIC_AUTH_TOKEN}と書くとBearer だけが送られ、n8n側は401で拒否します。N8N_MCP_TOKENのように、専用の名前を付けておきます。

接続の仕方にも注意点があります。Claude CodeはまずHTTPで接続し、サーバーが受け付けなければSSEへ自動で切り替えます。この自動切り替えにはv2.1.265以降が必要です。それより古いバージョン、またはSSEで直接つなぎたいときは--transport sseを指定します。SSEトランスポート自体は非推奨で、HTTPが使えるならHTTPを選びます。登録後は/mcpでサーバーの接続状態を見られます。

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

claude.aiとClaude Desktopでは、コネクタ設定でカスタムコネクタとしてMCP URLを追加します。n8nの認証はOAuthではなくBearerトークンです。組織のOwnerがコネクタ追加時にリクエストヘッダーとして入力する静的認証情報(ベータ、一部の組織のみ)を使います。この欄がない環境では、次のmcp-remote構成を使います。

もう一つの方法が、設定ファイルに書く形です。MCP Server Triggerはstdioに対応しないので、n8nのドキュメントはmcp-remoteというゲートウェイでSSEのメッセージをstdioのサーバーに見せる構成を示しています。

{
  "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ノードのパラメーターとクレデンシャルの実際の値に置き換えます。貼り付けたあとは、JSONの構文を先に確かめておきます。

長いワークフローはどこで切れるか

ワークフローの実行が長い、または戻り値が大きいと、n8nの外側で打ち切られます。上限は接続する面によって違います。

n8nがファイルの中身やAPIレスポンスをそのまま返す設計だと、この上限に当たります。ツール化するワークフローの側で、返す項目を絞るか、ページ単位に分けて返す形にしておきます。Claude Codeには、出力が10,000トークンを超えると警告を出す仕組みもあります。この閾値は固定で、変えられるのは上限の25,000トークンだけです。

Claude Codeは、時間のかかる呼び出しを3つのタイマーで管理しています。

数分かかるn8nワークフローをClaude Codeから呼ぶなら、2分でバックグラウンドへ回る点が実運用に効きます。claude.aiとClaude Desktopでは240秒で打ち切られるので、それより長い処理は、ワークフロー側で受付だけ返して別ツールで結果を取る構成に分けます。

トランスポートの選び方

Claude側はStreamable HTTPと、レガシーのHTTP+SSEの両方を扱います。ただしレガシーのHTTP+SSEは、Streamable HTTPへ置き換えられていく途中の非推奨の方式です。これから構築するなら、streamable HTTPでつながる構成を前提にします。

よくあるつまずき

n8nのドキュメントが挙げている制限は3つで、症状から原因をたどれます。

接続が頻繁に切れる、イベントが届かない

MCP Server TriggerはSSEかstreamable HTTPで永続接続を保つため、同じサーバーインスタンスが接続を受け続ける必要があります。queueモードでWebhookレプリカが1台なら問題ありません。

複数レプリカを動かすなら、/mcp*宛のリクエストをすべて専用の1台へ流します。MCP用にWebhookコンテナが1つだけのレプリカセットを作り、IngressやロードバランサーでMCPのトラフィックをそこへ向けます。振り分けないと、接続が頻繁に切れるか、イベントが確実に届かなくなります。

Noneにしたのにclaude.aiがサインインを求める

claude.aiのカスタムコネクタは、AuthenticationをNoneにしていてもn8nへのサインインを求めます。n8nインスタンスが他のトリガーでn8nのユーザー認証を提供していると、claude.aiはドメイン上のすべてのMCPエンドポイントが同じ認証を使うものと見なすためです。n8nのドキュメントによれば、こうした挙動が知られているクライアントはclaude.aiだけです。

リバースプロキシ配下で接続に失敗する

nginxなどの背後でn8nを動かすときは、MCPのエンドポイントでプロキシのバッファリングを無効にします。gzip圧縮の無効化(n8nが自前で処理するため)、チャンク転送エンコーディングの無効化、Connectionヘッダーを空文字にして転送ヘッダーから外す設定も候補です。MCPのエンドポイントで明示しておくと、他の場所の設定を引き継いでしまうことがありません。

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

まとめ

n8nのMCPサーバー化は、ノードを置いて3つの項目を埋めれば形になります。公開前に決めておきたいのは、認証方式、Claudeの面ごとのタイムアウトに収まる処理時間、複数レプリカやリバースプロキシの構成の3点です。Claude Code側の接続コマンドとMCPサーバーの自作はOpenAPI仕様からMCPサーバーを自動生成する3つの方法、公開したサーバーをMCP Registryへ載せる流れはMCP Registryへのリモートサーバー公開手順が参考になります。