Посібник з n8n MCP server: безпечно підключаємо AI-клієнт до ваших workflow
Практичний посібник з n8n MCP server: відкрийте workflow AI-клієнту через MCP Server Trigger або MCP на рівні інстансу та захистіть їх на корпоративному інстансі.
Перевірено за документацією n8n .
Мета й передумови для n8n MCP server
У цьому посібнику ви налаштуєте n8n MCP server, щоб AI-клієнт міг знаходити й запускати ваші workflow як інструменти, і збережете безпеку на спільному корпоративному інстансі. Кроки спираються на офіційну документацію n8n станом на 2026-09-16. Ми не перевіряли їх самі, а меню змінюються від версії до версії, тож звіряйте кожен крок зі своєю версією n8n.
n8n пропонує два способи. Варіант A використовує вузол MCP Server Trigger: один workflow стає окремим MCP-сервером, і клієнт бачить лише інструменти, додані в цей workflow. Варіант B — MCP на рівні інстансу (instance-level MCP), який відкриває наявні workflow з усього інстансу. Наша порада (це редакційна рекомендація, а не офіційне правило): починайте практику з варіанта A, бо один workflow тримає доступ у вузьких межах.
Перед початком вам потрібен інстанс n8n, до якого може дістатися ваш AI-клієнт. Для варіанта B також потрібна роль owner або admin, бо лише вони можуть увімкнути цю функцію. Посібник не охоплює вузол MCP client у n8n: він працює у зворотному напрямку й дає n8n змогу викликати зовнішні MCP-сервери. Тут n8n завжди виступає сервером.
Варіант A: створюємо workflow з n8n MCP Server Trigger
Створіть новий workflow і додайте вузол MCP Server Trigger. Він з'єднується лише з вузлами-інструментами, тому під'єднайте ті інструменти, якими має користуватися клієнт. Щоб запропонувати окремий workflow як інструмент, під'єднайте його через вузол Custom n8n Workflow Tool. Налаштування цього вузла тут не розглядаються, тож дотримуйтеся документації n8n щодо Custom n8n Workflow Tool.
Далі оберіть у тригері метод автентифікації: bearer auth, header auth або None. Документація не рекомендує жодного з них. Ми радимо не використовувати None ніде, крім тимчасової локальної пісочниці.
Тригер має дві URL-адреси. Під час розробки користуйтеся тестовою URL. Production URL починає працювати лише після публікації workflow. Дані production-викликів не відображаються в редакторі, тому перевіряйте їх на вкладці Executions.
Варіант B: вмикаємо n8n MCP на рівні інстансу
Щоб використовувати n8n MCP server на рівні інстансу, увійдіть як owner або admin, відкрийте Settings, потім Instance-level MCP, і ввімкніть доступ MCP. Згідно з документацією, такий вигляд налаштувань є починаючи з n8n 2.33.0. У старіших версіях екран простіший.
Далі оберіть, які workflow відкрити. Підходять лише опубліковані workflow з тригером webhook, form, schedule або chat. Їх можна вмикати поодинці, а в n8n 2.24.0 і новіших — також за проєктом або папкою. Редакційна порада: відкривайте лише ті workflow, які справді потрібні конкретному клієнту.
Sources: S2
Підключаємо AI-клієнт через OAuth або токен
У варіанті A клієнт викликає URL тригера й надсилає налаштований вами bearer-токен або заголовок. У варіанті B клієнти можуть підключатися через OAuth, який рекомендує n8n, або через API-ключ. Від себе (цього немає в документації n8n) радимо тримати набір відкритих для MCP workflow невеликим — лише ті, що справді потрібні клієнту.
Ми не наводимо тут фрагменти налаштувань для конкретних клієнтів. Налаштування відрізняються від клієнта до клієнта, тому для свого інструмента скористайтеся сторінкою n8n з прикладами підключення MCP-клієнтів.
Очікуваний результат: що клієнт бачить і може запускати
У варіанті A клієнт має показувати лише інструменти, під'єднані до вашого workflow із тригером. У варіанті B він має могти запускати ввімкнені вами workflow.
На одну деталь варто звернути увагу. У MCP на рівні інстансу інструмент search_workflows може показати всі workflow, до яких має доступ підключений користувач, зокрема й ті, що не позначені як доступні в MCP. Він повертає лише попередній перегляд. Щоб запустити чи змінити workflow, для нього все одно має бути ввімкнений доступ MCP. Проте, як редакційне застереження: попередній перегляд може розкрити сам факт існування workflow, який ви, можливо, не хочете показувати клієнту.
Чекліст безпеки для корпоративного інстансу
Рекомендовані перевірки для будь-якого n8n MCP server на корпоративному інстансі — це редакційна порада, а не офіційний чекліст: вмикайте автентифікацію для кожного MCP Server Trigger. Для MCP на рівні інстансу надавайте перевагу OAuth. Вмикайте лише ті workflow, які потрібні клієнту. Підключайте MCP-клієнти через облікові записи з обмеженим доступом, бо search_workflows показує все, до чого має доступ цей користувач. Перед публікацією тестуйте на тестовій URL, а потім переглядайте production-запуски на вкладці Executions.
Посібник не охоплює ротацію токенів, відкликання доступу клієнтів, обмеження OAuth callback URL чи повне вимкнення MCP. Усе це описано в документації n8n, тож прочитайте її, перш ніж розгортати це для команди.
Усунення проблем: reverse proxy, буферизація й доступ
Якщо n8n працює за reverse proxy, наприклад nginx, можуть виникати проблеми з підключенням. У такому разі вимкніть буферизацію проксі для ендпоінта MCP. На тій самій сторінці документації йдеться також про стиснення, chunked encoding, заголовки з'єднання та queue mode з кількома репліками webhook. Прочитайте її, якщо у вашому середовищі використовується щось із цього.
Якщо у варіанті B якогось workflow не видно, перевірте, чи він опублікований, чи має підтримуваний тригер і чи ввімкнено для нього доступ MCP. Якщо екран Settings відрізняється від описаного, перевірте версію n8n. Якщо production-виклик нібито нічого не робить, шукайте його на вкладці Executions, а не в редакторі.
