n8n-mcp-tools-expert

n8n MCP ツールエキスパート

ワークフローの構築に n8n-mcp MCP サーバーのツールを使うための総合ガイドです。

---

ツールのカテゴリー

n8n-mcp は、カテゴリー別に整理されたツールを提供します。

1. ノードの検索 → SEARCH_GUIDE.md
2. 設定の検証 → VALIDATION_GUIDE.md
3. ワークフロー管理 → WORKFLOW_GUIDE.md
4. テンプレートライブラリ - 2,700 件以上の実際のワークフローを検索してデプロイします
5. データテーブル - n8n のデータテーブル、行、列を管理します（n8n_manage_datatable）
6. ワークフローフォルダー - フォルダーの CRUD とワークフローの配置（n8n_manage_folders）
7. 認証情報管理 - 認証情報の CRUD とスキーマの検出（n8n_manage_credentials）
8. セキュリティと監査 - カスタムの詳細スキャンによるインスタンスのセキュリティ監査（n8n_audit_instance）
9. ドキュメントとガイド - ツールのドキュメント、AI エージェントガイド、Code ノードガイド
10. エージェント - 永続化された n8n エージェントの作成、設定、検証、実行、公開（n8n_manage_agents、N8N_MCP_ACCESS_TOKEN が必要）
11. ノードリソースの解決 - 実際の認証情報を使って、実行時のドロップダウン／リソースロケーターの値を解決します（n8n_explore_node_resources、N8N_MCP_ACCESS_TOKEN が必要）
12. インスタンスカタログ - プロジェクトとタグを一覧表示します（n8n_list_catalog）

---

クイックリファレンス

使用頻度の高いツール（成功率順）

ツール	使用する場面	速度
search_nodes	キーワードでノードを探す場合	<20ms
get_node	ノードの操作を理解する場合（detail="standard"）	<10ms
validate_node	設定を確認する場合（mode="full"）	<100ms
n8n_create_workflow	ワークフローを作成する場合	100-500ms
n8n_update_partial_workflow	ワークフローを編集する場合（最もよく使用！）	50-200ms
validate_workflow	ワークフロー全体を確認する場合	100-500ms
n8n_deploy_template	n8n インスタンスにテンプレートをデプロイする場合	200-500ms
n8n_manage_datatable	データテーブルと行を管理する場合	50-500ms
n8n_manage_folders	フォルダーの CRUD とワークフローの整理	100-500ms
n8n_manage_credentials	認証情報の CRUD とスキーマの検出	50-500ms
n8n_audit_instance	セキュリティ監査（組み込みスキャン＋カスタムスキャン）	500-5000ms
n8n_autofix_workflow	検証エラーを自動修正する場合	200-1500ms
n8n_manage_agents	永続化された n8n エージェントの CRUD／検証／公開	150-400ms；call アクション：5-60s
n8n_explore_node_resources	実行時の loadOptions／listSearch の値を解決する場合	200 ms - 5 s
n8n_list_catalog	プロジェクトまたはタグを一覧表示する場合	50-300ms

---

ツール選択ガイド

適切なノードを見つける

ワークフロー：

1. search_nodes({query: "keyword"})
2. get_node({nodeType: "nodes-base.name"})
3. [Optional] get_node({nodeType: "nodes-base.name", mode: "docs"})

例：

// Step 1: Search
search_nodes({query: "slack"})
// Returns: nodes-base.slack

// Step 2: Get details
get_node({nodeType: "nodes-base.slack"})
// Returns: operations, properties, examples (standard detail)

// Step 3: Get readable documentation
get_node({nodeType: "nodes-base.slack", mode: "docs"})
// Returns: markdown documentation

一般的なパターン：検索 → get_node（平均 18 秒）

設定を検証する

ワークフロー：

1. validate_node({nodeType, config: {}, mode: "minimal"}) - Check required fields
2. validate_node({nodeType, config, profile: "runtime"}) - Full validation
3. [Repeat] Fix errors, validate again

一般的なパターン：検証 → 修正 → 検証（サイクルあたり、検討に 23 秒、修正に 58 秒）

ワークフローを管理する

ワークフロー：

1. n8n_create_workflow({name, nodes, connections})
2. n8n_validate_workflow({id})
3. n8n_update_partial_workflow({id, operations: [...]})
4. n8n_validate_workflow({id}) again
5. n8n_update_partial_workflow({id, operations: [{type: "activateWorkflow"}]})

一般的なパターン：反復的な更新（編集間の平均 56 秒）

重要：ワークフロー作成時のノード JSON の適切な扱い

生成されたノード JSON に構造上の誤りが 3 つあると、ワークフローの検証に成功しても n8n の UI が壊れます。

1. プレースホルダー ID を含む credentials ブロックは絶対に出力しないでください。 "id": "REPLACE_ME" のような偽の ID を指定すると、n8n の UI で認証情報セレクターが恒久的に無効になり、クリックできなくなります（「認証情報がまだありません」）。その場合、ユーザーはノードを最初から作り直す必要があります。実際の認証情報 ID がわからない場合は、credentials ブロックを完全に省略してください。ブロックがなければ、通常の空のドロップダウンが表示され、ユーザーがクリックできます。まず n8n_manage_credentials({action: "list"}) を使って、実際の認証情報 ID を確認してください。

// ❌ Breaks the credential selector
"credentials": {"httpHeaderAuth": {"id": "REPLACE_ME", "name": "My API Key"}}

// ✅ Unknown ID → omit credentials block; user picks in UI
// ✅ Known ID (from n8n_manage_credentials list) → use the real ID

2. ノードの id には、読みやすい文字列（"http-list-node" など）ではなく、UUID v4 の値を生成してください。n8n のフロントエンドはフォームのバインドと認証情報コンポーネントの初期化にノード ID を使用するため、UUID 以外の ID は、気づきにくい UI の不具合を引き起こします。

3. 各ノードには、現在の typeVersion を使用してください。記憶しているバージョンをそのまま指定せず（例：httpRequest は 4.2 ではなく 4.4 以降です）、get_node で確認してください。

重要：nodeType の形式

ツールによって2種類の異なる形式があります！

形式 1：検索／検証ツール

// Use SHORT prefix
"nodes-base.slack"
"nodes-base.httpRequest"
"nodes-base.webhook"
"nodes-langchain.agent"

この形式を使用するツール：

• search_nodes（この形式を返します）
• get_node
• validate_node
• validate_workflow

形式 2：ワークフローツール

// Use FULL prefix
"n8n-nodes-base.slack"
"n8n-nodes-base.httpRequest"
"n8n-nodes-base.webhook"
"@n8n/n8n-nodes-langchain.agent"

この形式を使用するツール：

• n8n_create_workflow
• n8n_update_partial_workflow

変換

// search_nodes returns BOTH formats
{
  "nodeType": "nodes-base.slack",          // For search/validate tools
  "workflowNodeType": "n8n-nodes-base.slack"  // For workflow tools
}

---

よくある間違い

繰り返し発生する間違いは8つあります。構造が気付かないうちに壊れるため、うち2つは詳しく説明する価値があります。

// nodeType prefix (search/validate tools want the SHORT form)
get_node({nodeType: "slack"})              // ❌ missing prefix → "Node not found"
get_node({nodeType: "n8n-nodes-base.slack"}) // ❌ FULL prefix is for workflow tools
get_node({nodeType: "nodes-base.slack"})     // ✅

// credentials must be nested by type with {id, name} — not a flat string
updates: {credentials: "myApiKey"}                              // ❌
updates: {credentials: {httpHeaderAuth: {id: "abc123", name: "My API Key"}}}  // ✅

#	間違い	修正方法
1	nodeType の形式が間違っている	検索／検証には短い形式の nodes-base.*、ワークフローツールには完全な形式の n8n-nodes-base.* を使用します（上記参照）
2	デフォルトで detail: "full" を使用する	デフォルトの standard で95％のケースをカバーできます。full の代わりに docs／search_properties を使用してください
3	検証プロファイルを指定しない	明示的に profile: "runtime" を渡してください（他の段階では minimal／ai-friendly／strict を使用します）
4	自動サニタイズを無視する	どの更新でも、すべてのノードがサニタイズされます（オペレーター構造、IF／Switch メタデータ）。ただし、壊れた接続や分岐数の不一致は修正できません
5	スマートパラメーターを使用しない	脆弱な sourceIndex の計算ではなく、branch: "true"／case: 0 を使用してください
6	intent を省略する	より適切な応答を得るため、n8n_update_partial_workflow には必ず intent を含めてください
7	updates ではなく parameters を使用する	updateNode が受け取るのは parameters: {...} ではなく updates: {...} です
8	認証情報の形式が間違っている	型ごとに {id, name} をネストします（上記参照）

各項目の完全な誤り例／正しい例については、VALIDATION_GUIDE.md → よくある間違いを参照してください。

---

ツールの使用パターン

実際の使用では、3つのパターンが主流です。それぞれの手順を追った詳しい例は、各リファレンスガイドに掲載されています。

• パターン 1 — ノードの検出（ステップ間の平均18秒）：search_nodes({query}) → get_node({nodeType, includeExamples: true})。SEARCH_GUIDE.mdを参照してください。
• パターン 2 — 検証ループ（検討に23秒、修正に58秒）：validate_node({profile: "runtime"}) → errors を確認 → 設定を修正 → エラーがなくなるまで再検証。VALIDATION_GUIDE.mdを参照してください。
• パターン 3 — ワークフローの編集（成功率99.0％、編集間の平均56秒）：n8n_update_partial_workflow（intent を含む）を繰り返し実行 → n8n_validate_workflow → 最後に activateWorkflow。一度にまとめて作成するのではなく、反復的に構築してください。WORKFLOW_GUIDE.mdを参照してください。

---

詳細ガイド

ノード検出ツール

SEARCH_GUIDE.mdでは、次の項目について説明しています。

• search_nodes
• 詳細レベル（minimal、standard、full）を指定した get_node
• get_node のモード（info、docs、search_properties、versions）

検証ツール

VALIDATION_GUIDE.mdでは、次の項目について説明しています。

• 検証プロファイルの解説
• モード（minimal、full）を指定した validate_node
• validate_workflow の完全な構造
• 自動サニタイズシステム
• 検証エラーへの対処

ワークフロー管理

WORKFLOW_GUIDE.mdでは、次の項目について説明しています。

• n8n_create_workflow
• n8n_update_partial_workflow（patchNodeField、setNodeGroups、moveToFolder を含む21種類の操作）
• スマートパラメーター（branch、case）
• AI 接続タイプ（8種類）
• ワークフローの有効化（activateWorkflow/deactivateWorkflow）
• n8n_deploy_template
• n8n_workflow_versions
• n8n_manage_folders（フォルダーの CRUD とワークフローの配置）
• n8n_manage_credentials（認証情報の CRUD とスキーマの検出）
• n8n_audit_instance（セキュリティ監査）

テンプレート、データテーブル、セルフヘルプ

OPERATIONS_GUIDE.mdでは、次の項目について説明しています。

• search_templates / get_template / n8n_deploy_template の例
• n8n_manage_datatable（全アクション、フィルター条件、例）
• tools_documentation、ai_agents_guide、n8n_health_check

テンプレートの使用

2,700 件以上のテンプレートライブラリには、3 つのツールがあります。search_templates（モードは query／by_nodes／by_task／by_metadata）、get_template（モードは structure／full）、n8n_deploy_template（autoFix／autoUpgradeVersions を使ってインスタンスにデプロイし、ワークフロー ID、必要な認証情報、適用した修正を返します）。

検索／取得／デプロイの詳しい例は、OPERATIONS_GUIDE.md をご覧ください。

---

ワークフローの実行

n8n_test_workflow に必須パラメーターは 1 つ（workflowId）あり、実行経路は method で選択します。

method	バックエンド	処理内容
auto（デフォルト）	Public API	Webhook／フォーム／チャットのトリガーを検出し、HTTP 経由で実行します。ワークフローはアクティブである必要があります。該当するトリガーがない場合は、ワークフローを実行できないことを報告し、以下の方法を示します。auto が n8n の MCP サーバー経由で何かを実行することはありません。
trigger	Public API	同じ HTTP 経路を明示的に指定します。
prepare	n8n の MCP サーバー	読み取り専用です。ピン留めデータが必要なノードを一覧表示します。
pinned	n8n の MCP サーバー	トリガー、認証情報を使うノード、HTTP Request ノードの代わりに pinData を使用してワークフローを実行し、完了を待ちます。それ以外のすべてのノードは実行されます。実行が error／crashed／canceled で終了すると、executionId を含む EXECUTION_FAILED が返されます。
direct	n8n の MCP サーバー	実行を開始し、開始後すぐに戻ります。何もピン留めされないため、すべてのノードが実行されます。message または data／headers は入力としてトリガーに転送されます。

• 最後の 3 つの方法には N8N_MCP_ACCESS_TOKEN（n8n 2.34 以降）と、ワークフローの「Available in MCP」設定が必要です。
• pinData のキーはノードの名前で、すべての値は {"json": {...}} でラップされたアイテムの配列です。例：{"Webhook": [{"json": {"id": "123"}}]。フラットなオブジェクトは指定できません。空であってはなりません。
• triggerNodeName は、実行を開始するトリガーノードを指定します（デフォルトでは検出されたノードです。入力が指定されている場合、n8n では必須です）。
• どちらの実行方法でも、ワークフローのノードが実際に実行されます。 direct はすべてのノードを実行します。pinned がピン留めするのはトリガーノード、認証情報を使うノード、HTTP Request ノードのみです。そのため、Code、Set、If、認証情報を必要としない I/O（Execute Command、ファイルの読み取り／書き込み）も実行されます。ワークフローを実行する前に、どこかに書き込みを行う場合はユーザーに確認してください。
• executionMode は direct に適用されます。manual（デフォルト）または production を指定できます。これは実行コンテキストを変更するもので、実行による副作用の有無を変えるものではありません。production 実行は本番実行経路を通り、実行履歴として記録されます。ユーザーから指定された場合にのみ渡してください。
• timeoutMs は公式呼び出しに対するクライアント側の期限です（5000～600000。デフォルトは prepare で 30000、pinned／direct で 300000）。
• direct は実行開始後すぐに戻るため、実行が最終的にどうなったかにかかわらず、executionId とともに成功を報告します。結果を確認するには、n8n_executions({action: "get", id: executionId}) をポーリングしてください。n8n がディスパッチを明示的に拒否した場合は、EXECUTION_FAILED ではなく OFFICIAL_MCP_ERROR が返されます。
• ワークフローの「Available in MCP」設定がオフの場合は WORKFLOW_NOT_EXPOSED が返されます。exposeToMcp: true を指定すると設定が有効になり、1 回再試行されます。これはユーザーに見える永続的な変更です。先にユーザーへ確認してください。また、この設定を有効にすること自体がワークフローの更新であるため、同時に行われた UI 上の編集が上書きされる可能性があることを伝えてください。

成功時とルーティング時のレスポンスには method と backend（public-api または official-mcp）が含まれます。引数の検証で拒否されたエンベロープには、どちらも含まれない場合があります。

各方法の実行可能な例は、WORKFLOW_GUIDE.md をご覧ください。

---

バージョン履歴

n8n_workflow_versions は、source で選択する2つの独立した履歴を読み取ります。

• source: "local"（デフォルト）— ワークフローを変更する前に n8n-mcp が取得するスナップショットです。n8n のバージョンを問わず、トークンは不要で、ID は数値です。n8n UI で行われた編集は反映されません。delete と prune に対応する唯一のソースです。
• source: "native" — n8n 独自のワークフロー履歴で、ユーザーによる編集を含む、UI に表示されるものと同じ一覧です。N8N_MCP_ACCESS_TOKEN が必要です（n8n 2.34 以降。ネイティブの diff には 2.36 が必要で、get_workflow_versions_diff が追加されています）。また、ワークフローの「Available in MCP」設定も必要です。ID は不透明な文字列です。list は offset を指定しても上限が50件です。n8n が保持期間を管理するため、delete と prune は MODE_NOT_SUPPORTED_FOR_SOURCE で拒否されます。ネイティブのロールバックは事前検証されません。validateBefore は受け付けられますが、無視されます。

mode: "diff" は、2つのバージョン（versionId と toVersionId。どちらも同じソース、同じワークフローのもの）を比較します。ローカルの差分（data.format: "n8n-mcp"）では、追加／削除／変更されたノードがノードの ID として報告されます。ネイティブの差分（data.format: "n8n"）は n8n 独自のペイロードで、フィールド単位の変更前／変更後の値を含みます。フィールド名を決めつけず、data.format に応じて処理を分けてください。

ネイティブモードには、ルーティングされた実行メソッドと同じ同意ゲートが適用されます。「Available in MCP」設定がオフのワークフローは WORKFLOW_NOT_EXPOSED を返します。exposeToMcp: true を指定して再実行すると、その設定がオンになり、1回だけ再試行されます（その場合、レスポンスには exposedToMcp: true が含まれます）。これはワークフローに対する、ユーザーに見える永続的な変更です。指定する前にユーザーに確認してください。timeoutMs（5000～600000）は、ネイティブ呼び出しに対するクライアント側の期限です。

両方のソースについて、実行可能な例を含むすべてのモードは、WORKFLOW_GUIDE.md を参照してください。

---

データテーブルの管理

n8n_manage_datatable は、ワークフローの外部からデータテーブルと行を管理する MCP ツールです（テーブル操作は createTable／listTables／getTable／updateTable／deleteTable、行操作は getRows／insertRows／updateRows／upsertRows／deleteRows で、フィルタリング、ページネーション、dryRun に対応します）。ワークフロー内で使用する nodes-base.dataTable ノードと混同しないでください。このノードは実行中に行を読み書きします（n8n-node-configuration → OPERATION_PATTERNS.md を参照）。目安として、テーブルの初期設定には MCP ツールを、実行のたびに行を読み書きするにはワークフローノードを使います。deleteRows にはフィルターが必須です。一括変更の前には dryRun: true を使用してください。

列の操作 — addColumn、deleteColumn、renameColumn — は既存のテーブルの列を変更します。Public API では実行できない操作であり、n8n の MCP サーバー経由で実行するため、N8N_MCP_ACCESS_TOKEN が必要です（n8n 2.34 以降）。addColumn では column: {name, type} を指定します（名前は英字で始まり、英字／数字／アンダースコアのみを使用でき、最大63文字です。型は string、number、boolean、date のいずれかです）。deleteColumn／renameColumn では getTable で取得した columnId を指定し、renameColumn では新しい列名を name に指定します。これらの操作ではプロジェクトを指定してテーブルを特定します。アクセス可能なプロジェクトが1つだけの場合、projectId は自動的に解決されます。それ以外の場合は呼び出しが PROJECT_REQUIRED を返し、候補を一覧表示します。解決を省略するには、projectId（n8n_list_catalog({kind: "projects"}) から取得）を渡してください。テーブルの名前変更は列の操作ではありません。Public API の updateTable を使用してください。

deleteColumn を実行すると、列とともにその列の値も削除され、元に戻すことはできません。 特に注意が必要なのは、列の型は作成後に変更できない点です。そのため、「この列を数値にする」には、実際には削除して作り直す必要があり、列内のデータはすべて失われます。データが必要であれば、先に getRows で値を読み取ってください。また、データが入った列を削除する前に、ユーザーに確認してください。

すべての操作、フィルター条件、例については、OPERATIONS_GUIDE.md を参照してください。

---

ワークフローフォルダー

n8n_manage_folders はワークフローをフォルダーに整理します（アクションは create／list／get／rename／move／delete、n8n 2.19 以降、無料の Community ティア以上で登録可能）。projectId のデフォルト値は 'personal' です。ワークフローの配置は ワークフロー ツールで行います。n8n_create_workflow の parentFolderId、または n8n_update_partial_workflow の moveToFolder 操作を使用します（いずれも n8n 2.32 以降。null はプロジェクトのルートを意味します）。次の 2 点を把握しておいてください。n8n の API では、ワークフローのフォルダーは書き込み専用です（配置を確認するには、ワークフローを読み取るのではなく、フォルダーの get で件数を確認してください）。また、transferToFolderId を指定せずに delete すると、フォルダー内のワークフローはアーカイブされます（transferToFolderId: "0" を指定すると、ワークフローはアクティブなままプロジェクトのルートに移動します）。

すべてのアクション、リストのフィルター／件数、削除の動作については、WORKFLOW_GUIDE.md を参照してください。

---

認証情報の管理

n8n_manage_credentials は、認証情報を管理する統合ツールです。アクションは list、get、create、update、delete、getSchema です。シークレットは返されません。get／create／update では data フィールドが除外されます。必須フィールドを確認するには、create の前に getSchema を使用してください。オプションの includeUsage: true フラグ（list／get で使用）を指定すると、ワークフローを逆方向にスキャンし、usedIn: [{id, name, active}] と usageCount を追加します。認証情報を削除またはローテーションする前に、どの処理に影響するかを確認するために使用してください（クライアント側で全件スキャンが実行され、対象は最大 5000 件のワークフローです。アーカイブ済みのワークフローは除外され、失敗時は usageScanError フィールドにエラーが設定されます）。

すべてのアクション、includeUsage の形式、セキュリティに関する注意事項、安全な削除／ローテーションのワークフローについては、WORKFLOW_GUIDE.md を参照してください。

---

エージェント

このセクションの3つのツールは、n8n のインスタンスレベル MCP サーバー（Public API とは別のエンドポイント）専用です。n8n_manage_agents と n8n_explore_node_resources には N8N_MCP_ACCESS_TOKEN が必要です。n8n_list_catalog はトークンなしで動作し、チームプロジェクトへのフォールバック時にのみトークンを使用します。その他のツールも、各自のセクションに記載のとおり、同じサーバーを通じて個別の操作を実行します。たとえば、n8n_test_workflow の prepare／pinned／direct、n8n_workflow_versions の source: "native"、n8n_manage_datatable の列操作です。詳しくは、下記の「ツールの利用可否」を参照してください。

• n8n_manage_agents — 永続化された n8n エージェント（モデル、指示、ツール、スキル、タスク、メモリ、チャネルを備えた独立したアシスタント成果物。AI Agent ワークフローノードではありません）の作成、設定、検証、実行、公開を行います。アクション：reference、search、get、create、mutate、validate、call、publish、unpublish、revert、versions、delete、discover_assets、verify_mcp_server、update_integration。まず action: "reference" を実行し、次に discover_assets → create → mutate（一度に1つのリソースを変更し、常に最新のハッシュを使用します。n8n はこれを configHash として返し、args.baseConfigHash として受け取ります。古いハッシュを渡すと STALE_CONFIG が返されます）→ validate の順に進めます。publish は明示的に要求された場合にのみ実行します。call は実際の認証情報とツールを使ってエージェントを実行し、人間が判断するための approvals[] を返す場合があります。timeoutMs はトップレベルのパラメーターです（デフォルトは30000、call の場合は180000）。args の一部ではありません。エージェントモジュールを備えた n8n 2.34+ が必要です。2.36.x では、エージェントのランタイムが azureOpenAiApi／aws の認証情報を拒否します。エンベロープのエラーコード：NOT_CONFIGURED、INVALID_ARGS、STALE_CONFIG、AGENT_NOT_RUNNABLE、AGENT_TOOL_ERROR（コンパイルに失敗したカスタムツール、または不明な agentId）、および共通の OFFICIAL_MCP_* ファミリー（AUTH_FAILED、NOT_ENABLED、RATE_LIMITED、TOOL_UNAVAILABLE、URL_REJECTED、TIMEOUT、TRANSPORT_ERROR、ERROR）。ワークフロー全体については、n8n-agents スキルの「永続化された n8n エージェント」セクションを参照してください。
• n8n_explore_node_resources — ノードの loadOptions ドロップダウンやリソースロケーターの listSearch（Slack のチャンネル、Google Sheets のタブ、モデル一覧など）の実際の値を、ID を推測せずに、実際の認証情報を使って取得します。get_node（standard 詳細）で、プロパティに dynamicOptions: {methodName, methodType, dependsOn} が表示された場合に使用します。6つのパラメーターが必須で、いずれも自動推定されません。nodeType（LONG 形式）、メソッドが属するノードの version（typeVersion）、dynamicOptions からそのままコピーした methodName と methodType、および n8n_manage_credentials({action: "list"}) で取得したその種類の credentialType と credentialId です。メソッドの dependsOn に指定されているものはすべて currentNodeParameters に含めます。リソースロケーターの値は {__rl: true, mode: "id", value: "…"} の形式を維持します。各結果の value がワークフローパラメーターに設定する値です。name は表示用のテキストにすぎません。
• n8n_list_catalog — インスタンスレベルの projects（個人プロジェクトとしてマークされたもの。n8n_manage_agents／n8n_manage_datatable 用の projectId が含まれます）または tags を一覧表示します。Public API 経由ならトークンなしで動作します。トークンが設定されている場合は、Public API がライセンス制限により拒否した際に、チームプロジェクトについて公式 MCP サーバーにフォールバックします（teamProjectsEnabled で有効かどうかが報告されます）。

セキュリティと監査

n8n_audit_instance は、n8n 組み込みの監査（カテゴリ credentials／database／nodes／instance／filesystem）と、カスタムの詳細スキャン（hardcoded_secrets、unauthenticated_webhooks、error_handling、data_retention）を組み合わせます。すべてのパラメーターは省略可能です：categories、includeCustomScan（デフォルトは true）、customChecks、daysAbandonedWorkflow。検出されたシークレットはマスキングされます（先頭 6 文字と末尾 4 文字）。出力は実行可能な Markdown レポートです。サマリーテーブル、ワークフローごとの検出結果、自動修正可能／レビューが必要／ユーザーの操作が必要に分かれた修正プレイブックが含まれます。

2 つのスキャン方法、例、修正の種類の詳細については、WORKFLOW_GUIDE.md を参照してください。

---

セルフヘルプツール

• tools_documentation() — すべてのツールの概要（n8n-mcp 2.97.0 以降では、ネイティブ優先のノード選択手順から始まります）。特定のツールについては tools_documentation({topic, depth: "full"}) を使用します。expression_helpers（2.97.0 以降）には、{{ }} のヘルパーメソッド（.pluck()、.sum()、.unique()、.diffTo()、$ifEmpty()）が一覧表示されます。1 行の変換処理のために Code ノードを記述する前に確認してください。Code ノードガイドは、トピック javascript_code_node_guide／python_code_node_guide から利用できます。
• AI エージェントガイド — tools_documentation({topic: "ai_agents_guide", depth: "full"})（独立したツールはありません）。アーキテクチャ、接続、ツール、検証、ベストプラクティスを返します。
• n8n_health_check() — 簡易チェックです。n8n_health_check({mode: "diagnostic"}) は、ステータス、環境変数、ツールの状態、API の接続状況を返します。どちらのモードでも officialMcp ブロック（{configured, endpoint, reachable, toolCount, agentTools}）も返されます。これは、N8N_MCP_ACCESS_TOKEN が必要なすべての機能、つまりエージェントツール、n8n_test_workflow のルーティングされたメソッド、ネイティブのバージョン履歴、データテーブルの列操作を利用する前の事前確認に使えます。タスクの途中で NOT_CONFIGURED のエンベロープを受け取って問題に気付くのではなく、これらの機能を使う前に一度確認してください。

例については、OPERATIONS_GUIDE.md を参照してください。

---

ツールの利用可否

常に利用可能（n8n API は不要）：

• search_nodes、get_node
• validate_node、validate_workflow
• search_templates、get_template
• tools_documentation（ai_agents_guide と、2.97.0 以降は expression_helpers のトピックを含む）

n8n API が必要（N8N_API_URL + N8N_API_KEY）：

• n8n_create_workflow
• n8n_update_partial_workflow、n8n_update_full_workflow
• n8n_validate_workflow（ID 指定）
• n8n_list_workflows、n8n_get_workflow、n8n_delete_workflow
• n8n_test_workflow
• n8n_executions
• n8n_evaluations（読み取り：n8n 2.30 以降で、2.30 以降に作成された API キーが必要です。実行／キャンセル：n8n 2.32 以降で、2.32 以降に作成されたキーが必要です。古いキーには testRun スコープがありません）
• n8n_deploy_template
• n8n_workflow_versions
• n8n_autofix_workflow
• n8n_manage_datatable
• n8n_manage_folders（フォルダーの CRUD：n8n 2.19 以降、登録済みの Community ティア以上。parentFolderId／moveToFolder によるワークフローの配置：n8n 2.32 以降）
• n8n_manage_credentials
• n8n_audit_instance
• n8n_list_catalog（トークンなしで動作します。チームプロジェクトへのフォールバック時のみトークンが必要です）

N8N_MCP_ACCESS_TOKEN が必要（上記の Public API 認証情報に加え、n8n の Settings → Instance-level MCP から取得する別のトークン）：

• n8n_manage_agents
• n8n_explore_node_resources
• method: "prepare"／"pinned"／"direct" を指定した n8n_test_workflow（ワークフローの「Available in MCP」設定も必要です）
• source: "native" を指定した n8n_workflow_versions（ワークフローの「Available in MCP」設定も必要です）
• addColumn／deleteColumn／renameColumn を指定した n8n_manage_datatable

API ツールを利用できない場合は、テンプレートと検証のみのワークフローを使用してください。

---

統合ツールリファレンス

• get_node — 詳細レベル（minimal 約200トークン／standard 約1～2K、推奨／full 約3～8K、必要な場合のみ）とモード（info がデフォルト、docs、search_properties ＋ propertyQuery、versions、compare、breaking、migrations）を指定できます。詳しくは SEARCH_GUIDE.md をご覧ください。
• validate_node — モードは full（デフォルト。エラー／警告／提案を表示）と minimal（必須フィールドのチェック）です。プロファイルは minimal／runtime（デフォルト、推奨）／ai-friendly／strict です。詳しくは VALIDATION_GUIDE.md をご覧ください。

---

パフォーマンス特性

ツール	応答時間	ペイロードサイズ
search_nodes	<20ms	小
get_node (standard)	<10ms	約1～2KB
get_node (full)	<100ms	3～8KB
validate_node (minimal)	<50ms	小
validate_node (full)	<100ms	中
validate_workflow	100-500ms	中
n8n_manage_folders	100-500ms	小
n8n_manage_credentials	50-500ms	小～中
n8n_audit_instance	500-5000ms	大
n8n_create_workflow	100-500ms	中
n8n_update_partial_workflow	50-200ms	小
n8n_deploy_template	200-500ms	中

---

ベストプラクティス

推奨事項

• シンプルなワークフロー（ノード数が5以下）では、MCP ツールを直接使用し、調査を過度に複雑化しないでください
• Code ノードの内容をピンポイントで編集する場合は、ノード全体を置き換えるのではなく patchNodeField を使用してください
• ほとんどのユースケースでは get_node({detail: "standard"}) を使用してください
• 検証プロファイルを明示的に指定してください（profile: "runtime"）
• 明確さを高めるため、スマートパラメーター（branch、case）を使用してください
• ワークフローの更新には intent パラメーターを含めてください
• 検索 → get_node → ワークフローの検証、の順に進めてください
• ワークフローは反復して改善してください（編集間隔は平均56秒です）
• 重要な変更を行うたびに検証してください
• 実際の設定を確認するには includeExamples: true を使用してください
• 手早く開始するには n8n_deploy_template を使用してください

禁止事項

• 必要な場合を除き detail: "full" を使用しないでください（トークンを無駄に消費します）
• nodeType のプレフィックス（nodes-base.*）を忘れないでください
• 検証プロファイルを省略しないでください
• ワークフローを一度で完成させようとしないでください（反復してください！）
• 自動サニタイズの動作を無視しないでください
• 検索／検証ツールで完全なプレフィックス（n8n-nodes-base.*）を使用しないでください
• 作成後にワークフローを有効化し忘れないでください

---

概要

最も重要な点：

1. get_node では detail: "standard"（デフォルト）を使用します。ユースケースの95％をカバーできます
2. nodeType の形式は異なります。nodes-base.*（検索／検証）と n8n-nodes-base.*（ワークフロー）があります
3. 検証プロファイルを指定します（runtime を推奨）
4. スマートパラメーターを使用します（branch="true"、case=0）
5. ワークフローを更新する際は intent パラメーターを含めます
6. 更新時には、すべてのノードで自動サニタイズが実行されます
7. ワークフローは API 経由で有効化できます（activateWorkflow 操作）
8. ワークフローは反復的に作成されます（編集間の平均時間は56秒）
9. データテーブルは n8n_manage_datatable で管理します（CRUD＋フィルタリング）
10. フォルダーは n8n_manage_folders で管理します。ワークフローの配置は書き込み専用のため、ワークフロー自体ではなくフォルダーの件数で確認してください
11. 認証情報は n8n_manage_credentials で管理します（CRUD＋スキーマの検出）
12. セキュリティ監査は n8n_audit_instance で実行します（組み込みスキャン＋カスタムの詳細スキャン）
13. AI エージェントガイドは tools_documentation({topic: "ai_agents_guide", depth: "full"}) から利用できます

一般的なワークフロー：

1. search_nodes → ノードを検索
2. get_node → 設定を確認
3. validate_node → 設定をチェック
4. n8n_create_workflow → 作成
5. n8n_validate_workflow → 検証
6. n8n_update_partial_workflow → 反復
7. activateWorkflow → 運用開始！

詳細については、以下を参照してください：

• SEARCH_GUIDE.md - ノードの検出
• VALIDATION_GUIDE.md - 設定の検証＋よくある間違い
• WORKFLOW_GUIDE.md - ワークフローの管理
• OPERATIONS_GUIDE.md - テンプレート、データテーブル、セルフヘルプツール

---

関連スキル：

• n8n Expression Syntax - ワークフローのフィールドに式を記述する
• n8n Workflow Patterns - テンプレートに基づくアーキテクチャパターン
• n8n Validation Expert - 検証エラーを解釈する
• n8n Node Configuration - 操作ごとの要件
• n8n Code JavaScript - Code ノードに JavaScript を記述する
• n8n Code Python - Code ノードに Python を記述する