using-n8n-mcp-skills

n8n-mcp スキルの使い方

これはルーターであり、リファレンスではありません。これから行う作業のルールをどのスキルが管理しているかを示します。実際のガイダンスはスキル本体に記載されています。Skill ツールで呼び出してください。迷ったら、スキルを少なく読み込むのではなく、多めに読み込んでください。

コミュニティの n8n-mcp サーバーと n8n 自体は、どのモデルの学習データのカットオフよりも速く変化します。ツール名、パラメーター、ノードの typeVersion、デフォルトの動作は、リリースごとに変わります。差異に気づいた場合（スキルに記載されたツールが存在しない、パラメーターの形式が get_node の返却内容と一致しない、動作がスキルの説明と異なるなど）は、現在のツールを信頼し、ユーザーに伝えたうえで、パックとインスタンスの更新を提案してください。

絶対に守ること

例外のない3つのルールです。それぞれ、本番環境で問題が起きる、一見正しそうなワークフローを防ぎます。

1. n8n の操作を行う前に、該当するスキルを必ず呼び出してください。MCP の呼び出しの前だけではありません。 式の記述、ノードの設定、ワークフローの設計、接続の配線、Code の記述を行う前に、該当するスキルを呼び出してください。PreToolUse フックは影響の大きいツール呼び出しの前に通知しますが、利用できるのは Claude Code プラグインをインストールした場合のみです。それ以外の場所（Claude.ai のスキルアップロードや、このパックを Agent Plugin として読み込むクライアント（Codex、Cursor、Copilot など））では、通知はありません。すべて自分の責任です。このセッションでフックが動作するのを確認していない限り、フックは設定されていないものと考えてください。
2. 有効化する前に、検証と確認の両方を行ってください。 有効化する前に validate_workflow（または ID を指定して n8n_validate_workflow）を実行し、作成または更新のたびに n8n_get_workflow を呼び出して connections オブジェクトを確認してください。検証だけでは、接続線が通知なく削除されたケース、Merge のインデックスが1つずれているケース、エラー出力が未接続のケースを見落とします。検証に合格したということは、JSON の形式が正しいというだけであり、ワークフローが正しいという意味ではありません。テストが成功しても証明にはなりません。{{ }} 内の JS エラーは通知なく null に解決されるためです（条件が壊れた Filter はすべてのアイテムを破棄しても、成功と表示されます）。そのため、出力値を確認してください。n8n-expression-syntax を参照してください。
3. シークレットをテキストフィールドに入力しないでください。 トークン、API キー、パスワードは、必ず n8n の認証情報システムを通じて設定してください。ネイティブノードがない場合は、公式の認証情報タイプを使って HTTP Request ノードを使用してください。{{ $json.token }} で参照するトークンを保持する Set ノードは、手順を増やして情報を漏えいさせているにすぎません。n8n-mcp-tools-expert を参照してください。

学習データではなく、スキルを頼りにする

n8n は常に変化しています。「記憶している」パラメーター名は、気づかないうちに誤っていることがよくあります。通常の文字列として検証は通るものの、実行時には何もしないことがあります。記憶より、スキルと現在のツール（get_node、search_nodes、tools_documentation）を信頼してください。スキルと記憶が矛盾する場合は、スキルを信頼してください。get_node とスキルが矛盾する場合は、ツールを信頼し、その差異を報告してください。

基本の方針

各スキルには例外が記載されています。以下は基本の方針です。

• Code ノードは最後の手段です。 まず式を試し、次に Edit Fields 内のアロー関数を試してください。どちらでも実現できない場合に限り、Code ノードを使用します。n8n-code-javascript を参照してください。
• 1つ以下のノードに値を渡す Set ノードは、ほとんどの場合、誤りです。 代わりに、受け取り側のノードに式を直接記述してください。n8n-expression-syntax を参照してください。
• アイテムごとの反復処理は自動で行われます。 デフォルトのアイテムごとの実行で処理できる場合、「ループさせる」ために Loop Over Items ノードを追加しないでください。
• 設定には、記憶ではなく現在のスキーマを使用してください。 パラメーターを設定する前に get_node を実行してください。n8n-node-configuration を参照してください。

危険信号：「これから ___ しよう」→ ___ を呼び出す

次のようなことを考えたら、いったん止めて、まず指定されたスキルを呼び出してください。

考えたこと	呼び出すスキル
「このワークフローは簡単だから、そのまま作ろう」	n8n-workflow-patterns — 「簡単な」フローの大半は、完成するとノードが10個以上になります
「フィールドをマッピングするために Set ノードを追加しよう」	n8n-expression-syntax — Set の出力先が1つ以下の場合は、最もよくあるアンチパターンです
「Code ノードを使えば簡単だから、そうしよう」	n8n-code-javascript — 求められる基準は高く、多くの場合、必要なのは式か Edit Fields です
「ユーザーがデータに言及したから、Python を書こう」	n8n-code-javascript — デフォルトは JS です。Python（n8n-code-python）を使うのは、明示的に求められた場合に限ります
「AI エージェントが呼び出すコードを書いている」	n8n-code-tool — Code ノードとは実行時の契約が異なります
「日付の計算には DateTime ノードを入れよう」	n8n-expression-syntax — ほとんどの場合、Luxon をインラインで使うのが適切です
「3つのソースを Merge でつなごう」	n8n-node-configuration — Merge のデフォルト入力数は2つで、3つ目の入力は警告なく破棄されます
「検証に通ったので、有効化しよう」	n8n-validation-expert + n8n-workflow-patterns — アンチパターンのチェックを実行してください
「検証で理解できないエラーが出た」	n8n-validation-expert — 各エラーや警告の意味と、必ず修正すべきものとベストプラクティスに関する助言の違いを確認してください
「ここで $json.x を参照しよう」	n8n-expression-syntax — 分岐のあるワークフローでは、$('Node').item.json.x を優先してください
「この Webhook／スケジュール実行フローは正常系しか考慮していない」	n8n-error-handling — エラーが起こりうるすべてのノードにエラーブランチをつないでください。4xx は呼び出し元の問題、5xx はあなた側の問題です
「このファイル／画像を JSON として渡そう」	n8n-binary-and-data — ファイルの内容は $binary に格納され、エージェントとツールの間では受け渡せません
「AI エージェントをつないで、モデルにいくつかツールを渡そう」	n8n-agents — ツール名と説明がプロンプトそのものです。メモリ、構造化出力、トポロジーには落とし穴があります
「このロジックを別のワークフローにコピーしよう」／「大きくなってきた」	n8n-subworkflows — 再利用可能なサブワークフローに切り出してください。作成する前に検索してください
「その認証情報を作成しよう／そのワークフローを開こう」（アカウントに複数のインスタンスがある場合）	n8n-multi-instance — 呼び出しごとに instance: "<name>" を指定して対象を明示してください。名前を省略すると、他のチャットが変更する可能性のあるデフォルトに呼び出しが向けられ、読み取り先も警告なく誤ります

スキル一覧

スキル	使用する場面
using-n8n-mcp-skills	このルーターです（自動読み込み）。タスクを担当するスキルを示します。
n8n-mcp-tools-expert	n8n-mcp ツールの選択や呼び出し、ノードの検索、認証情報、データテーブル、セキュリティ監査、テンプレートを扱う場合
n8n-workflow-patterns	ワークフローの設計や構築、アーキテクチャ（Webhook／HTTP API／データベース／AI エージェント／スケジュール実行／バッチ処理）の選択
n8n-node-configuration	ノードの設定、操作に応じた必須フィールド、プロパティの依存関係、対象を絞ったフィールド編集
n8n-expression-syntax	{{ }}、$json／$node／$now の記述、ノード間のデータマッピング、変換の要所、Set ノードの適切な使用
n8n-validation-expert	検証エラー／警告、誤検知、検証ループ、自動修正、既存ワークフローのレビューの解釈
n8n-code-javascript	JavaScript を使う Code ノード、データアクセス、this.helpers、DateTime、SplitInBatches のループパターン
n8n-code-python	Python が明示的に指定された Code ノード。ネイティブランタイム（_items／_item のみ、インポートはデフォルトでブロック、従来の _input コードは動作しません）
n8n-code-tool	AI エージェントから呼び出し可能な Custom Code Tool（toolCode）。文字列を返し、$fromAI／$input は使用しません
n8n-error-handling	Webhook／API または無人実行ワークフロー、エラー出力の接続、再試行、4xx／5xx のレスポンス形式、サイレントエラー
n8n-binary-and-data	ファイル、画像、PDF、添付ファイル、アップロード／ダウンロード、ビジョン、エージェントツールへの／からのファイルの受け渡し
n8n-subworkflows	再利用可能な構築／複数ステップの構築、Execute Workflow、共通ロジックの抽出、Define-Below の入力、全体単位と各項目単位、エージェントツールとしてのワークフローの公開
n8n-agents	AI Agent／ツールを使う LLM／Text Classifier、ツール設計と $fromAI、システムプロンプト、構造化出力、メモリ、RAG、人によるレビュー、チャットボット
n8n-multi-instance	複数のインスタンスを持つアカウント（n8n_instances ツールが存在する場合）、呼び出しごとの instance 引数、1 つの接続上での並列エージェント、switch によるデフォルト設定、認証情報の書き込み、予期しない NOT_FOUND、誤った／空の読み取り、INSTANCE_NOT_FOUND、INSTANCE_AMBIGUOUS からの復旧
n8n-self-hosting	ワークフロー構築ではなくデプロイ — VM への n8n のセルフホスト／インストール／デプロイ（Docker Compose + Caddy、シングルモードとキューモードの比較）、または更新／バックアップ／セキュリティ強化。単独で該当し、上記の構築フローには含まれません。

n8n-mcp ツール — 初回ターンから活用できる基礎知識

修飾名は mcp__<server>__<tool> の形式です（<server> は通常 n8n-mcp）。これにより、ツールの完全な説明が初回使用まで読み込まれない場合の不足を解消します。

2 つの階層と、利用中の階層を見分ける方法。 以下のドキュメントツールと検証ツールはオフラインで動作し、常に利用できます。n8n_* 管理ツールは稼働中の n8n インスタンスと通信し、インスタンスが接続されると表示されます。表示されない場合も、問題が発生したわけではなく、再試行する必要もありません。その旨を明確に伝え、利用環境に合った解決方法を案内してください。

• ホステッド（https://api.n8n-mcp.com/mcp） — 初回使用時にクライアントに表示される OAuth プロンプトからサインインし、ダッシュボードで n8n インスタンスを接続します。環境変数は不要で、API キーを設定ファイルに貼り付ける必要もありません。
• セルフホスト（npx n8n-mcp、Docker） — クライアントの起動前にエクスポートされるよう、サーバーの環境に N8N_API_URL と N8N_API_KEY が必要です。

n8n_health_check は接続が機能していることを確認し、解決されたインスタンスを返します。 検出とドキュメント

• tools_documentation — すべてのツールに関するメタドキュメント。エージェントガイドには {topic:"ai_agents_guide", depth:"full"} を指定します。
• search_nodes — キーワードでノードを検索します。
• get_node — ノード情報を取得します。単一の 短縮形 の nodeType（nodes-base.httpRequest、nodes-langchain.agent）と、detail（minimal/standard/full）、mode（info/docs/search_properties/versions）を指定します。
• validate_node — 単一ノードの設定を個別に検証します（プロファイル：minimal/runtime/ai-friendly/strict）。
• search_templates / get_template — テンプレートライブラリ（キーワード、ノード、タスク、メタデータで検索）。

構築と編集

• n8n_create_workflow — 完全なワークフロー JSON から作成します。
• n8n_update_partial_workflow — 差分操作で段階的に更新します（{id, operations:[…]}）：addNode、updateNode、patchNodeField、addConnection、setNodeGroups、activateWorkflow など。編集にはこちらを推奨します。
• キャンバスグループ（n8n 2.28+）は、編集で管理しなくても維持されます。削除したノードがグループに属していた場合はそのグループから取り除かれ、n8n がグループを受け入れられなくなった場合はグループ解除されるため、編集は適用されます。ノードと接続は変更されず、各調整は details.warnings に報告されます。グループを作成または変更するには、setNodeGroups op（全置換。[] はすべてのグループを解除）を使用してください。n8n-mcp-tools-expert を参照してください。
• n8n_update_full_workflow — 全体を置き換えます。
• n8n_autofix_workflow — よくある問題を自動修正します。
• n8n_deploy_template — インスタンスにテンプレートをデプロイします。

検証（必要ですが、それだけでは不十分です。必ずアンチパターンのスキャンも行ってください）

• validate_workflow — 完全な JSON を受け取り、エラー／警告／修正内容を返します。ここでのノードタイプは 完全形（n8n-nodes-base.set）です。
• n8n_validate_workflow — {id} でデプロイ済みのワークフローを検証します（検査するノード JSON はありません）。

確認とライフサイクル

• n8n_get_workflow — ワークフローを取得します（full / structure / active / filtered / minimal）。編集後に connections を確認するために使用します。mode="filtered" と nodeNames を指定すると、ワークフロー全体を取得してクライアント側で切り詰められることなく、負荷の高いノード（長い Code ソースなど）を 1 つ読み取れます。
• n8n_list_workflows — ワークフローを一覧表示／フィルタリングします（ロジックを複製する前に検索してください）。
• n8n_delete_workflow、n8n_workflow_versions（履歴／ロールバック／差分。source: "local" は n8n-mcp 独自のスナップショット、source: "native" は UI で行われた編集を含む n8n 独自の履歴です。n8n-mcp-tools-expert を参照してください）、n8n_instances（マルチインスタンスアカウントのみ：インスタンスの一覧表示とデフォルトの切り替え。ここでの各 n8n ツールには、呼び出しごとに指定できる省略可能な instance 名もあります。n8n-multi-instance を参照してください）、n8n_health_check（解決された instanceName と、以下のインスタンスレベルの MCP サーバーが設定済みで到達可能かどうかを示す officialMcp ブロックを返します）。

テストと実行

• n8n_test_workflow — 実際のノードを実行します（Code、HTTP、DB 書き込み、送信などがすべて実行されます）。副作用がある場合は、実行前にユーザーに確認してください。method で実行経路を選択します。auto（デフォルト）と trigger は、アクティブなワークフローの webhook/form/chat トリガーを HTTP 経由で実行します。prepare/pinned/direct は n8n 独自の MCP サーバー経由で実行するため、HTTP トリガーがないワークフロー（Manual、Schedule、サブワークフロー）も実行できます。n8n-mcp-tools-expert を参照してください。
• n8n_executions — 実行を一覧表示／確認します。execute_workflow ツールはありません。
• n8n_evaluations — 評価テスト実行：実行一覧、集計メトリクス、ケースごとの結果（n8n ≥ 2.30）に加え、実行の開始または停止を行う run/cancel（n8n ≥ 2.32）を提供します。run はデータセット全体に対してワークフローを実行します。実際のノードが実行されるため、最初にユーザーに確認してください。403 は、API キーがアクションの最低バージョンより前に作成されている（テスト用に testRun スコープで再作成してください）、プランで評価機能がライセンスされていない、またはキーの所有者がワークフローにアクセスできないことを示す場合があります。run/cancel には、特に workflow:execute スコープが必要です。 データ、フォルダー、認証情報、監査
• n8n_manage_datatable — データテーブルの CRUD、フィルタリング、ドライラン。addColumn／deleteColumn／renameColumn は、n8n の MCP サーバーを通じて既存テーブルの列を変更します（Public API ではできません）。deleteColumn は列の値も削除します。
• n8n_manage_folders — ワークフローのフォルダー CRUD とコンテンツ数（n8n ≥ 2.19、Community ティア以上で登録済み。projectId のデフォルトは personal）。n8n_create_workflow の parentFolderId または moveToFolder オペレーション（n8n ≥ 2.32）でワークフローを配置します。配置は書き込み専用です。ワークフローを読み取って確認するのではなく、フォルダーの get で件数を確認してください。transferToFolderId を指定せずに delete すると、フォルダー内のワークフローはプロジェクトのルートに移動され、アーカイブされます。ワークフロー自体は残りますが、無効化されます（transferToFolderId: "0" は、アーカイブせずにプロジェクトのルートへ移動します）。
• n8n_manage_credentials — 認証情報の CRUD と getSchema による検出。
• n8n_audit_instance — セキュリティ監査（ハードコードされたシークレット、認証されていない Webhook、エラー処理の不備）。

インスタンスレベルの MCP サーバー — Public API と並ぶ 2 つ目のエンドポイントです。N8N_MCP_ACCESS_TOKEN で保護されています（n8n 2.34 以降）。n8n_health_check で到達可能かどうかを確認できます。設定されていない場合、呼び出しは原因の分かりにくいエラーではなく NOT_CONFIGURED を返します。

• n8n_manage_agents — 永続化された n8n Agents：独自のライフサイクル（モデル、指示、スキル、タスク、メモリ、チャネル）を持つスタンドアロンのアシスタント成果物であり、AI Agent ワークフローノードではありません。call は実際の認証情報を使ってライブ実行し、approvals[] を返す場合があります。publish はユーザーが求めた場合にのみ実行してください。n8n-agents を参照してください。
• n8n_explore_node_resources — ID を推測する代わりに、実際の認証情報を通じてノードのライブドロップダウン／リソースロケーターの値を解決します。n8n-node-configuration を参照してください。
• n8n_list_catalog — projectId を取得するための projects、または tags を一覧表示します。ここでトークンなしでも動作する唯一のツールです。
• 同じサーバーは、n8n_test_workflow の prepare／pinned／direct、n8n_workflow_versions の source: "native"、および n8n_manage_datatable の列操作も支えています。これらはさらに、ワークフローごとの「Available in MCP」設定によって制御されます。拒否された場合は WORKFLOW_NOT_EXPOSED が返ります。設定をオンにする（exposeToMcp: true）と、変更が可視となり永続化されます。まずユーザーに確認してください。

ノードタイプの形式に関する注意点： get_node／validate_node は SHORT 形式（nodes-base.set）を受け取ります。 validate_workflow／n8n_create_workflow 内のワークフロー JSON では LONG 形式 （n8n-nodes-base.set）を使います。両者を混同するのは、よくある見逃しやすいミスです。n8n-mcp-tools-expert を参照してください。

プロトコルの手順

1. インデックスから該当するスキルを見つけ、最初の MCP 呼び出しの前に実行します。
2. 不明な点があれば、セッションごとに 1 回 tools_documentation に目を通し、利用可能なツールを再確認します。
3. ノードを設定する前に必ず get_node を呼び出し、ライブスキーマを読み取ります。推測しないでください。
4. 構築／編集した後、有効化する前に**validate_workflow を実行し、その後n8n_get_workflow で** connections を確認します。
5. 気づいた差異（ツールの欠落、パラメーターの変更、動作の相違）を伝えます。

判断に迷ったとき

• ユーザーが UI で作成したワークフローが見つからない場合： 最もよくある原因は、ワークフローごとの MCP アクセスがオフになっていることです。n8n でワークフローを開き、Settings に移動して MCP アクセスを有効にするよう依頼してください。
• ユーザーが動かないと言った場合： その申告を信頼してください。get_node と照らし合わせてパラメーターを再確認し、データ参照を追跡し、実行内容を調べてください。n8n-validation-expert を参照してください。
• 該当するスキルがなく、タスクが単純でない場合： 推測する前に確認してください。

これらは推奨されるベストプラクティスであり、絶対的なルールではありません。判断に異議がありますか？ すべて Markdown なので、スキルを編集してください。