MCP в n8n: подключение инструментов к воркфлоу

MCP в n8n решает узкую задачу: дать агентной ноде инструменты, которых нет среди готовых нод. Всё остальное лучше делать обычными нодами.

Зачем это в n8n

У n8n большой каталог интеграций, и напрашивается вопрос, зачем ещё один способ подключать внешние системы. Разница в том, кто решает.

Нода - это решение, принятое вами при сборке. Выполняется всегда, в заданном порядке.

MCP-инструмент - это возможность, из которой агент выбирает по ходу. Он может вызвать её, а может не вызвать, в зависимости от того, что обнаружил на предыдущем шаге.

Отсюда простой критерий: если вы знаете порядок действий заранее, MCP не нужен. Нужны ноды: дешевле, предсказуемее, видно в истории выполнений.

Второй мотив - переиспользование. Сервер, написанный для доступа к вашей внутренней системе, работает и в n8n, и в терминальном агенте, и в собственном коде. Одна интеграция вместо трёх.

Подключение

Общая схема: агентная нода получает подключение к MCP-серверу, забирает у него список инструментов и дальше вызывает их так же, как остальные свои инструменты.

Что нужно учесть при self-hosted установке:

Локальный сервер запускается в среде n8n, а не в вашей оболочке. В контейнере это означает, что нужная программа должна быть внутри образа. Самая частая ошибка - сервер, который работает у вас на машине и не работает в n8n именно поэтому.

Удалённый сервер должен быть доступен из контейнера n8n. Сетевые ограничения и адреса внутри Docker - см. n8n в Docker.

Секреты идут в креденшелы или переменные окружения, а не в поле ноды: экспорт воркфлоу видят все, у кого есть доступ к интерфейсу.

Порядок настройки самих серверов и разбор ошибок подключения - в статье про настройку MCP.

Сценарии применения

Доступ к внутренней системе. Учётная система, самописная админка, внутренний API. Готовой ноды не будет, а сервер пишется один раз - см. обёртку своего API.

Данные по требованию. Агент обрабатывает обращение и при необходимости смотрит в базу. Если бы вы делали это нодой, запрос выполнялся бы всегда, включая случаи, где он не нужен.

Общий инструментарий. Один сервер обслуживает несколько воркфлоу и несколько агентов. Изменение логики доступа происходит в одном месте.

Чего делать не стоит: подключать MCP там, где хватает HTTP-ноды. Вызов, известный заранее, дешевле сделать напрямую.

Ограничения

Расход контекста. Описания всех инструментов попадают в каждый запрос агента. Несколько серверов заметно увеличивают стоимость шага.

Недетерминированность. Агент может не вызвать нужный инструмент или вызвать не тот. Если действие обязательно, оно должно быть нодой после агента, а не инструментом внутри него.

Отладка. История выполнений n8n показывает, что вошло в агентную ноду и что вышло, но происходящее внутри цикла видно хуже, чем обычная цепочка нод. Это аргумент держать агентную часть небольшой.

Права. Инструмент MCP выполняет реальное действие. Сервер с правами на запись сделает то, что решит агент, - см. безопасность MCP.

Что должно оставаться нодами: отправка сообщений, запись в системы, известная маршрутизация, обработка ошибок. Подробнее об этой границе - в агентных сценариях.

Общая картина по протоколу - гид по MCP. Обзор n8n - гид.