n8n MCP連携｜Claude Code・Desktop・Cursorから自分のワークフローを呼ぶ全手順【2026年版】

n8n MCP連携｜ワークフロー1本と設定1回で、AIから呼べる道具になる
n8n MCPとは？ ── n8nで使うための最小知識
- Webhookで済むのに、なぜわざわざMCPにするのか
n8n × MCP、連携は2方向ある（先に全体地図）
パターン1：n8nをMCPサーバーにする（MCP Server Trigger）
- MCP Server Triggerノードの設定
- Transportの選択：SSE（レガシー）vs Streamable HTTP（推奨）
クライアント別の繋ぎ方：Claude Code / Claude Desktop / Cursor
実践レシピ：Slack通知をn8n MCP経由で呼ぶ（30分・4ステップ）
パターン2：n8nがMCPクライアントになる（AI Agent × MCP Client Tool）
- AI Agentノード × MCP Client Toolの組み合わせ
混同しやすい3つの整理：公式ノード / コミュニティ / n8n-mcp
Instance-level MCP（Beta）と、本番運用の安全策
- Instance-level MCP：1接続で複数ワークフロー。ただしスコープ分離は未実装
- セキュリティ3点：認証 / nginx / Cloudflare Tunnel・IP制限
まとめ：ワークフローを増やす＝AIにできることが増える
- n8nシリーズの他の記事
- AI・自動化の関連記事
Git/Claude Code 使い込んでる人ほど、止まりがちです。

n8n MCP連携｜ワークフロー1本と設定1回で、AIから呼べる道具になる

n8n を MCP サーバーにするのに必要なのは、ワークフロー1本と、クライアント側の設定1回だけです。ワークフローに MCP Server Trigger ノードを足して Activate し、Claude Code なら claude mcp add をターミナルで1発打つ。これで最初の1本が30分以内に、自分の n8n ワークフローが Claude Code / Claude Desktop / Cursor から「AIが自分で見つけて呼べる道具」に変わります。

この記事では、その手順を3クライアント横断で、コピペで動く形で載せます。あわせて、つまずきの定番——公式ノード／コミュニティノード／n8n-mcp という名前の似た3つの混同、Claude Desktop だけ mcp-remote を噛ませる理由、nginx で SSE が詰まる3行——を先回りで潰します。2026年5月時点・n8n v2 系（私の環境は v2.8.3）の記録です。

タイムラインや Zenn で「n8n を MCP サーバーにして Claude から呼ぶ」投稿を見て、すごいと思いつつ手が止まっていませんか。設定例を探すと Claude Desktop（GUI）の話ばかりで、毎日叩いている Claude Code（CLI）からの繋ぎ方が出てこない——半年前の私もそうでした。でも詰まりの正体は技術の難しさではなく、情報が散らばっていて CLI の例が見当たらないことでした。だから n8n MCP連携の手順を網羅するのではなく、「迷わない一本道」として書きます。

前提として、この記事はn8nをDocker Composeでセルフホストする手順で建てた環境（n8n v2系・2026年5月時点）を想定しています。まだn8n自体を触ったことがない方は、先にn8nの基本的な使い方と概要を読んでおくと、ノード名で迷いません。

n8n MCPとは？ ── n8nで使うための最小知識

深い仕様は不要です。n8n MCPを動かすために知っておくべきことだけ書きます。

MCP（Model Context Protocol）は、AIアプリと外部ツールをつなぐ共通プロトコルです。Anthropicが2024年11月に発表しました。よく「AIのUSB-C」と例えられます。

覚えるのは2つの役割だけです。

MCPサーバー：ツール（機能）を公開する側。今回の主役、n8nがこれです
MCPクライアント：ツールを呼ぶ側。Claude Code / Claude Desktop / Cursorがこれです

MCPそのものが「結局なにに役立つのか」がまだピンと来ていない方は、MCPが結局なにに役立つのかを先に読むと、この後の話が立体的になります。

Webhookで済むのに、なぜわざわざMCPにするのか

ここ、私も最初に引っかかりました。「n8nにはWebhookがあるじゃん。MCPにする意味あるの？」と。

違いは一言、「ツールの発見」です。

Webhookは「このURLにこのJSONを投げて」と、こちらがURLを丸暗記して指定する方式です。AIに使わせるなら、プロンプトに毎回URLとパラメータの形式を書いておく必要があります。

MCPは違います。クライアント（Claude Codeなど）がサーバー（n8n）に「何ができる？」と聞き、ワークフロー一覧を自動で取得します。そのうえで、ユーザーの指示に合うワークフローをAIが自分で選んで呼びます。URLを覚える必要はありません。「Slackに投げて」と書けば、AIが「あ、Slack通知のツールがあるな」と気づいて使う。この発見の自動化が決定的に違います。

とはいえ、Webhookが不要になるわけではありません。決まったタイミングで決まった処理を確実に叩くなら、Webhookのほうがシンプルで速いです。「AIに自由に選ばせたい」ときがMCPの出番。用途で使い分けるのが正解です。

n8n × MCP、連携は2方向ある（先に全体地図）

迷子になる最大の原因は、連携に方向が2つあることを知らないまま記事を読み始めることです。先に地図を渡します。

パターン	n8nの役割	用途
パターン1（メイン）	MCPサーバー	Claude Code / Claude Desktop / Cursorからn8nワークフローを呼ぶ
パターン2（後半で補足）	MCPクライアント	n8nのAI Agentノードから外部MCPサーバーを呼ぶ

本記事のメインはパターン1（n8nをサーバーにする）です。これが「自分のワークフローをAIに使わせる」の本体。パターン2（n8nがクライアントになる）は逆方向で、後半でまとめて触れます。

パターン1：n8nをMCPサーバーにする（MCP Server Trigger）

MCP Server Triggerノードの設定

n8n mcp server 化の心臓は、MCP Server Triggerノードです。v1.88.0（2025年4月）で追加され、現行のv2系でも問題なく動作しています（私の環境はv2.8.3です）。これ1つで、ワークフローがそのままn8n MCPサーバーになります。設定項目の正式な仕様はn8n公式ドキュメント（MCP Server Trigger）に整理されているので、迷ったら一次情報を当たってください。

設定はシンプルで、5ステップです。

ワークフローを新規作成する
トリガーとして MCP Server Trigger を追加する
認証方式を選択する（本番では Bearer Token 推奨）
MCP Server Triggerにツールノードを接続する
ワークフローを Activate（公開）する

MCP Server Triggerノードの設定項目は、次の3つを押さえれば十分です。

Path：MCPエンドポイントのパス（ランダム生成、カスタマイズ可）
Authentication：None / Bearer Token / Header Auth
Transport：SSE（レガシー） / Streamable HTTP（推奨）

ここで一番大事なのは、MCP Server Triggerに接続したツールノードだけがMCPツールとして公開されるという仕組みです。ワークフロー全体がまるごと公開されるわけではありません。接続したSlackノードだけが「AIから呼べるツール」になる。逆に言えば、公開したくないノードは繋がなければいい。これは安全側に倒れていて、私は安心しました。

Transportの選択：SSE（レガシー）vs Streamable HTTP（推奨）

n8nは2つのトランスポートをサポートしています。

SSE（Server-Sent Events）：初期からの方式。長時間接続を維持する。現在は非推奨
Streamable HTTP：新しい推奨方式。SSEの後継で、より効率的

ぶっちゃけ、Claude Desktop接続では後述のmcp-remote経由になるので体感差はほぼありません。ただ、公式がStreamable HTTPを推奨しているので、新規構築なら素直に従っておくのが無難です。私もそうしました。

クライアント別の繋ぎ方：Claude Code / Claude Desktop / Cursor

ここが、私がこの記事で一番書きたかったところです。多くの解説がClaude Desktop（GUI）前提で、毎日Claude Code（CLI）を叩いている人間からすると「で、自分はどう繋ぐの？」が抜けている。CLI派が置いていかれている。その穴を、3クライアント横断で埋めます。

そもそもなぜクライアントごとに繋ぎ方が違うのか。背景はClaude Code（CLI）とClaude Desktopの違いに詳しいですが、要点は「対応しているトランスポートが違う」ことです。

3クライアント接続方式の比較表（直結できる / mcp-remoteで噛ませる）

クライアント	n8n MCPへの繋ぎ方	mcp-remote	設定場所
Claude Code（CLI）	SSE / HTTPに直結	不要	`claude mcp add` コマンド
Cursor	SSEに直結	不要	`.cursor/mcp.json`
Claude Desktop（GUI）	STDIOしか喋れない	必要（噛ませる）	`claude_desktop_config.json`

表の通り、Claude CodeとCursorは直結、Claude Desktopだけがmcp-remoteでブリッジが必要です。この1行が頭に入っていれば、もう迷いません。順に見ていきます。

① Claude Code（CLI）から接続する（n8n claude code 連携の本命）

「n8n claude code」で検索しても断片的な情報しか出てこない、と感じていた方。ここが本命です。Claude Code（CLI）はリモートのSSE / HTTPサーバーに直接繋がります。mcp-remoteのような橋渡しは要りません。設定ファイルを手で開く必要すらなく、ターミナルからコマンド1発です。

n8nのMCP Server TriggerがSSEの場合は、こうです。

bash

claude mcp add --transport sse n8n-workflows \
  https://your-n8n-domain.com/mcp/your-mcp-path/sse \
  --header "Authorization: Bearer your-token-here"

Streamable HTTPで公開しているなら、--transportをhttpに変えるだけです。

bash

claude mcp add --transport http n8n-workflows \
  https://your-n8n-domain.com/mcp/your-mcp-path/mcp \
  --header "Authorization: Bearer your-token-here"

追加できたか確認するには、次のコマンドです。

bash

claude mcp list

一覧にn8n-workflowsが出れば成功です。なお、デフォルトでは追加したMCPサーバーは「local」スコープ（そのプロジェクト限定・自分専用）になります。どのプロジェクトからでも呼びたいなら--scope userを付けてください。設定は~/.claude.jsonに保存されます。

bash

claude mcp add --transport http n8n-workflows --scope user \
  https://your-n8n-domain.com/mcp/your-mcp-path/mcp \
  --header "Authorization: Bearer your-token-here"

正直、CLIから繋ぐ場合がいちばん楽でした。JSONを手で書かない分、カッコの閉じ忘れもない。n8n claude code 連携を探していたCLI派の方は、ここが一本道です。

② Claude Desktop：STDIOしか喋れないのでmcp-remoteで噛ませる

ここが最大のハマりポイントです。私もここで時間を溶かしました。

Claude Desktop（GUI）は、STDIOトランスポートしかネイティブサポートしていません。つまり、n8nのSSE / Streamable HTTPベースのMCPサーバーに直接は繋がらないのです。「設定例の通りにURLを書いたのに認識されない」のほとんどは、これが原因です。

解決策はmcp-remoteです。STDIOとSSE / HTTPをブリッジしてくれるnpmパッケージで、これを間に挟むと接続が通ります。claude_desktop_config.jsonを編集します。

macOS：~/Library/Application Support/Claude/claude_desktop_config.json

Windows：C:\Users\USERNAME\AppData\Roaming\Claude\claude_desktop_config.json

json

{
  "mcpServers": {
    "n8n-workflows": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "https://your-n8n-domain.com/mcp/your-mcp-path/sse",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "ここにn8nで設定したBearerトークンを入れる"
      }
    }
  }
}

URLの形式はhttps://your-n8n-domain.com/mcp/{path}/sseです。{path}はMCP Server Triggerノードの設定画面で確認できます。設定後、Claude Desktopを再起動してください。ツール一覧にn8nのワークフローが表示されれば成功です。

③ Cursor：SSE直結（.cursor/mcp.json）

CursorはSSEへの直接接続をサポートしています。Claude Codeと同じくmcp-remoteは不要です。プロジェクトルートの.cursor/mcp.jsonに次を追加します。

json

{
  "mcpServers": {
    "n8n-workflows": {
      "url": "https://your-n8n-domain.com/mcp/your-mcp-path/sse",
      "headers": {
        "Authorization": "Bearer your-token-here"
      }
    }
  }
}

Cursorの Settings > MCP からGUIで追加することもできます。お好みで。

実践レシピ：Slack通知をn8n MCP経由で呼ぶ（30分・4ステップ）

知識はここまでで十分です。手を動かしましょう。Slack通知ワークフローをMCPツールにして、自分のクライアントから呼べるようにします。所要30分。

Step 1：ワークフローを作る

n8nで新規ワークフローを作成し、次の2ノードを配置します。

MCP Server Trigger — 認証：Bearer Token
Slack – Send Message — MCP Server Triggerのツールコネクタに接続

Slackノードの設定で、チャンネルとメッセージを「入力パラメータ」として受け取るようにします。MCP Server Triggerに接続されたSlackノードは、クライアントが渡すパラメータ（channel、message）をそのまま受け取れます。

Step 2：ワークフローを公開する

右上の Activate を押します。これでProduction URLが有効になります。MCP Server Triggerノードをクリックすると、Production URLが表示されます。この中の/mcp/{path}/sse部分をメモしてください。後でクライアント側に貼ります。

Step 3：自分のクライアントから接続する

前章の比較表に従って、自分の使っているクライアントで繋ぎます。Claude Code派なら、これだけです。

bash

claude mcp add --transport sse n8n-slack \
  https://your-n8n-domain.com/mcp/your-mcp-path/sse \
  --header "Authorization: Bearer your-bearer-token"

Claude Desktop派なら、claude_desktop_config.jsonにmcp-remote経由の設定を書いて再起動します。

json

{
  "mcpServers": {
    "n8n-slack": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "https://your-n8n-domain.com/mcp/your-mcp-path/sse",
        "--header",
        "Authorization: Bearer ${N8N_MCP_TOKEN}"
      ],
      "env": {
        "N8N_MCP_TOKEN": "your-bearer-token"
      }
    }
  }
}

Step 4：動作確認

クライアントで、自然文で頼んでみます。

Slackの#generalチャンネルに「MCP連携テスト成功！」と送って

クライアントがn8n MCPサーバーのSlackツールを検出し、確認ダイアログが表示されます。許可すると、n8nのワークフローが実行されてSlackにメッセージが届きます。

ここまで、30分もかかりません。私が初めて通したときの「声が出た」瞬間が、たぶんこのStep 4です。

動かないときの最初の一手：mcp-remoteとnginxを疑う

もしツール一覧に出てこなかったら、原因はだいたい2つに絞れます。Claude Desktopならmcp-remoteを挟み忘れていないか。セルフホストでリバースプロキシを通しているなら、nginxの設定（後述）でSSEが詰まっていないか。この2つを先に疑うと、無駄に検索タブを増やさずに済みます。

パターン2：n8nがMCPクライアントになる（AI Agent × MCP Client Tool）

逆方向の連携です。今度はn8n側がMCPクライアントになり、外部のMCPサーバーを呼びます。

AI Agentノード × MCP Client Toolの組み合わせ

n8nには MCP Client Tool ノードがあります。これをAI Agentノードのツールとして接続すると、外部MCPサーバーのツールをLLMが動的に発見・呼び出しできます。設定手順です。

AI Agentノードを配置する
AI Agentのツールコネクタに MCP Client Tool を接続する
MCP Client Toolに外部MCPサーバーのSSE / Streamable HTTPエンドポイントを設定する
認証情報を設定する（Bearer Token / Header Auth / OAuth2）

これで、n8nのワークフロー内でLLMが外部MCPサーバーのツールを使えるようになります。n8nとDifyをAI Agent文脈で比較した記事でも触れた「AIエージェント」の機能が、MCPでさらに拡張される形です。

ちなみに、AI Agentノードを経由しない MCP Client（スタンドアロン） ノードもあります。List Tools（ツール一覧取得）とExecute Tool（ツール実行）の2つのオペレーションで、ワークフロー内の任意のステップから直接MCPサーバーを呼べます。AI Agentを介さずに呼びたい場面では、こちらのほうが軽量です。

混同しやすい3つの整理：公式ノード / コミュニティ / n8n-mcp

ここ、まじで混同しやすいので表で一発整理します。私が検索タブを増やした最大の原因が、この3つの名前の似かたでした。

名前	種類	機能
MCP Server Trigger / MCP Client Tool	n8n公式ノード	ワークフローのMCPサーバー化 / MCPクライアント
n8n-nodes-mcp	コミュニティノード	STDIOトランスポート対応のMCPクライアント（公式はSSE / Streamable HTTPのみ）
n8n-mcp	外部npmパッケージ	n8n APIを操作してワークフローを自然言語で作成・管理する

日本語の解説記事でも、この3つを混同しているものが少なくありません。この記事で解説しているのは 公式ノード です。とくにn8n-mcpはワークフローを「実行する」のではなく「作成・管理する」ためのツールなので、目的が根本から違います。名前が似ているだけで、別物だと割り切ってください。

Instance-level MCP（Beta）と、本番運用の安全策

Instance-level MCP：1接続で複数ワークフロー。ただしスコープ分離は未実装

n8n v1.120以降では、インスタンス全体を1つのMCPサーバーとして公開できる Instance-level MCP 機能がベータ提供されています。ワークフローごとにMCP Server Triggerを設定しなくても、単一の接続で複数ワークフローをまとめて公開できます。

便利ですが、率直に制約も書きます。まず、ベータ段階なので仕様変更の可能性があります。そして、接続クライアント間のスコープ分離が未実装です（全クライアントが同じワークフロー群を参照する）。私の感覚では、自分専用の検証環境なら快適ですが、本番でクライアントごとに見せるツールを分けたい用途には、まだ早い。本番導入は慎重に判断してください。

セキュリティ3点：認証 / nginx / Cloudflare Tunnel・IP制限

VPSでn8nをセルフホストしてMCPエンドポイントを外部公開するなら、セキュリティ対策は必須です。「公開して大丈夫か」という不安は、ここを押さえれば消えます。

① 認証は必ず設定する。 当たり前ですが、本番でAuthentication: Noneは絶対にダメです。Bearer Tokenを設定し、トークンは環境変数で管理してください。定期的なローテーションも忘れずに。

② nginxリバースプロキシの設定。 SSE / Streamable HTTPを通すには、nginx側に注意が必要です。

nginx

location /mcp/ {
  proxy_pass http://localhost:5678;
  proxy_http_version 1.1;
  proxy_buffering off;
  gzip off;
  chunked_transfer_encoding off;
  proxy_set_header Connection '';
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_read_timeout 86400s;
  proxy_send_timeout 86400s;
}

proxy_buffering off、gzip off、chunked_transfer_encoding off の3つが揃っていないと、SSEが正常に動きません。ここでハマる人、本当に多いです（私も含めて）。「クライアント側は正しいのに繋がらない」ときは、まずこの3行を確認してください。

③ Cloudflare Tunnel・IP制限。 ポートを開放せずに公開したいなら、Cloudflare Tunnel + Zero Trustが有効です。UIとMCPエンドポイントでサブドメインを分ければ、それぞれ別のセキュリティポリシーを当てられます。自分しか使わないなら、ファイアウォールで接続元IPを制限するのが最もシンプルです。n8nの建て方やリバースプロキシ周りはn8nをDocker Composeでセルフホストする手順にまとめてあります。

まとめ：ワークフローを増やす＝AIにできることが増える

n8nをMCPサーバーにする。やってみて分かったのは、これが単なる技術連携ではないということでした。

1本通ると、発想が変わります。それまでは「AIに何をさせるか」を考えていました。今は「n8nでどんなワークフローを作るか」を考えるようになりました。ワークフローを1つ足すたびに、Claude Code / Claude Desktop / Cursorから呼べる道具が1つ増える。Slack通知、カレンダー登録、データベース更新——n8nで自動化できるものは、全部AIの手足になります。

冒頭で書いた「乗り遅れている気がする」焦り。あれは、技術が難しかったからではなく、情報が散らばっていて、自分のクライアント（CLI）の例が見つからなかったから生まれていたものです。一本道さえ通れば、「今日1本やればいい」に変わります。

まずは一番よく使うワークフロー1本を、MCP Server Triggerで公開してみてください。そして自分のクライアントから呼んでみる。「これ全部つながるのか」という感覚は、手を動かさないと得られません。

n8nのUIを日本語化する方法がまだの方は、ノード名が見やすくなるので先に済ませておくのもおすすめです。

n8n以外も含めて自動化ツールの全体像を整理したい方は、n8n以外も含めたAI自動化ツールの全体像で、各ツールの設計思想と用途別の選び方をまとめています。「次に何を選ぶか」で迷ったら、こちらへどうぞ。

参考になれば幸いです。