n8nとMCPをつなぐ前に、n8nが外部ツールを呼ぶ側なのか、外部AIへworkflowを公開する側なのかを決めます。接続が成功したことと、どの操作を許可するかは別に確認します。
呼び出す側と、公開する側を分ける
| 構成 | 最初に決めること |
|---|---|
| n8nから外部MCPを使う | 接続先、呼ぶツール、送る引数とデータ |
| n8nの処理をMCPへ公開する | 公開するworkflow、呼べる利用者、許す操作 |
| AI Agentがツールを選ぶ | 選べるツールの範囲と、操作前の確認 |
外部ツールを使いたいだけなのに、すべてのworkflowを外部へ公開する構成を選ばないようにします。通常のworkflowのステップで外部ツールを呼ぶならMCP Client、AI Agentに選ばせるならMCP Client Toolが対応する部品です。公開する側のMCP Server Triggerとは役割が違います。
最初に公開する操作は、小さな読み取りにする
試験用の登録状況をIDで読むなど、影響を限定した操作から始めます。任意URLの取得や任意ファイルの読取を一つのツールとして公開するより、対象と操作を固定した形にします。
{
"operation": "read_test_status",
"request_id": "demo-001"
}これは入力の設計例です。公開するツールは、この値を受け取った後も、呼び出す人の権限と対象IDを照合します。説明文へ禁止事項を書くだけで、実行側の制限を代用しないようにします。
更新・送信は、確認された対象と版へ限定する
投稿作成や通知送信を許す場合は、下書き作成までか、公開までかを分けます。承認の対象は、ツール名だけでなく、実際の引数・送信先・本文の版です。
外部文書の文章からAIが新しい引数を作った場合も、許可範囲を再確認します。読ませるデータと実行を許す設定を混ぜないことは、外部入力を扱う設計と同じです。
再接続と再試行で、操作が重ならないか見る
接続切れ、時間切れ、同じ依頼の再実行を試します。AI側が失敗と見なしても、n8n側では外部登録が完了している場合があります。依頼ID、実行ID、外部結果IDを対応させて照合できる形にします。
まず公開する操作を一つに絞り、誰が呼べて何が返るかを記録してください。自動化を広げる前に、許可した操作と実際に起きた結果の対応を読めるようにします。