n8n + Claude Code: 5 projektów, które agent wygenerował i wdrożył za Ciebie 

Najpierw kilka słów o tym, czym to właściwie jest, bo nazwa bywa myląca. n8n to narzędzie do budowania automatyzacji: łączysz w nim kroki (webhook, baza danych, e-mail, model językowy) w jeden przepływ, który sam się odpala. Claude Code to asystent programistyczny, który pisze i poprawia kod. MCP (Model Context Protocol) to standardowy „wtyk”, przez który jeden program rozmawia z drugim. Po podłączeniu Claude Code widzi Twoje instancje n8n: może przeczytać workflow, zmienić węzeł, sprawdzić konfigurację i wdrożyć zmianę.

To jest realna możliwość, nie hasło z konferencji. Niżej pięć projektów, które dały się zbudować i wdrożyć przez agenta, z konkretnymi opisami przepływu, kosztem i miejscami, w których trzeba było uważać. Opisuję je tak, żeby dało się je powtórzyć.

Co właściwie łączy Claude Code z n8n

Są dwa niezależne serwery MCP dla n8n i warto wiedzieć, który wybierasz.

Pierwszy jest wbudowany w n8n. Działa od wersji 2.18.3 i jest dostępny w każdym planie, łącznie z darmową wersją Community. Włączasz go w ustawieniach instancji, a potem zaznaczasz, które workflow mają być widoczne dla klientów MCP. Ważne ograniczenie: dostęp nie jest automatyczny. Nie wystawia całej instancji, tylko te przepływy, które sam włączysz, i tylko takie, które mają wyzwalacz (webhook, formularz, harmonogram albo czat).

Drugi to n8n-mcp od Macieja Czlonkowskiego: open source, licencja MIT. Ten ma dwa zestawy narzędzi, łącznie 28, w tym 21 do zarządzania instancją. W praktyce jego przewagą jest katalog wiedzy, nie liczba przycisków.

Co dostajesz	Wbudowany w n8n	n8n-mcp (community)
Narzędzia	pełna lista nie jest udokumentowana w artykułach, które sprawdzałem; wzmiankowane są search_workflows i execute_workflow	28 narzędzi: 7 podstawowych plus 21 zarządczych po podaniu klucza API
Katalog węzłów	brak	2 864 węzły n8n (836 core i 2 028 community), dane z repozytorium projektu
Szablony	zestaw wbudowanych w n8n	2 352 szablony plus 156 wzorców wyciągniętych z popularnych konfiguracji
Instalacja	włączone w panelu n8n	npm install -g n8n-mcp albo obraz Dockera

Liczby węzłów różnią się między źródłami i to nie jest błąd, tylko migawka. Strona kursu podaje 2 616 unikalnych węzłów, starsza dokumentacja wdrożeniowa wciąż mówi o 500+. Baza węzłów odświeża się po każdym wydaniu n8n, więc traktuj to jako rząd wielkości, a nie pomiar.

Projekt 1: od eventu klienta do insightu na Slacku

To pierwszy przepływ, który warto zbudować, bo działa na istniejących danych i niczego nie psuje. Zespół dostaje zdarzenie, system sam dokłada kontekst i propozycję reakcji.

Przepływ ma sześć kroków: webhook na zdarzenie z klienta, pobranie kontekstu konta przez narzędzie MCP, wyszukanie w bazie wiedzy podobnych klientów, wygenerowanie spersonalizowanych wniosków przez model językowy, przekierowanie opiekuna klienta na Slacku i zapis zdarzenia w panelu analitycznym. Tak właśnie wygląda to u zespołu, który opisał swoje wdrożenie w amarsohail.com.

Co tam jest naprawdę interesujące, to decyzja o parametrach. Klasyfikacja klienta idzie z limitem 1 024 tokenów, a wygenerowanie wniosków z limitem 2 048, z dokładaniem 3 najbliższych dokumentów z indeksu. Nie jest to detal, tylko sposób na kontrolę kosztu. Przy produkcyjnym wolumenie różnica między rozsądnym limitem a domyślnym jest pierwszą pozycją na rachunku.

Co zrobił tu agent: wygenerował plik workflow, sprawdził konfigurację węzłów i wdrożył go na instancji. Opis ekipy, który przeszedł na n8n, brzmi konkretnie: skrypt orkiestracji, który wcześniej zajmował 2 000 linii Pythona, rozpadł się na wizualny przepływ i sześć warstw integracji sprowadzonych do jednego serwera MCP. Ich zdaniem przepływ jest wtedy sam dokumentacją.

Projekt 2: asystent account managera odpalany webhookiem

Drugi projekt jest bliższy promptowi niż dokumentacji, bo cała logika mieści się w jednym poleceniu. Opis brzmi tak:

Zbuduj przepływ n8n, który: odpala się na webhooku, gdy w ciele JSON przyjdzie „company_name"; wyszukuje firmę w naszym CRM przez węzeł HTTP Request; jeśli znajdzie, pobiera 5 ostatnich zgłoszeń wsparcia; streszcza je węzłem Anthropic; wysyła streszczenie na kanał #account-management w Slacku; zwraca odpowiedź 200 z tekstem.

To gotowy prompt testowy z agenticvessel.com. Claude Code generuje JSON workflow, waliduje konfigurację węzłów i wdraża ją na instancji. W tym miejscu warto zatrzymać się na chwilę, bo to jest sedno całej metody: opisujesz zachowanie słowami, a nie klikaniem.

Ich wniosek z praktyki brzmi: przepływ, który wcześniej zajmował dzień pracy, powstaje w godzinę, a przy 40 węzłach nie łączysz ich ręcznie. Druga część jest ważniejsza: agent potrafi uruchomić przepływ, przeczytać wynik, wskazać awarię i poprawić konfigurację. Oszczędza się wtedy nie samo budowanie, tylko debugowanie.

Przy czym dokładna skala tej oszczędności zależy od tego, co jest zautomatyzowane. Zespoły opisujące to podejście mówią o spadku czasu budowy z godzin do minut, ale to deklaracja autorów, nie niezależny pomiar. Ja traktuję to jako argument, nie jako obietnicę.

Projekt 3: audyt instancji i sprzątanie porzuconych workflowów

To projekt, który nie buduje niczego nowego, tylko porządkuje to, co już jest. Prompt wygląda krótko: „Przejrzyj moją instancję n8n pod kątem problemów bezpieczeństwa i porzuconych przepływów starszych niż 60 dni”.

Agent z n8n-mcp ma do tego odpowiednie narzędzia, między innymi listę credentiali ze wskazaniem, które przepływy z nich korzystają i które nie są używane nigdzie. Ten drugi wariant jest częściej doceniany niż sam audyt: niepozostawione, zbędne klucze API to realne ryzyko, a nikt o nich nie pamięta.

Druga rzecz, o której warto wspomnieć, wynika z praktyki, nie z dokumentacji. Jeśli wywożysz eksport przepływów do repozytorium git, twarde tokeny w JSON-ach zostają w historii wersji. Zmienna w stylu „secrets w kodzie” ma tu bardzo konkretny odpowiednik: bearer token w pliku workflow.

Jeśli pracujesz dopiero nad pierwszym takim przepływem i nie masz jeszcze działającej instancji, pierwsza automatyzacja w n8n krok po kroku prowadzi od podstaw.

Projekt 4: agent sam debuguje zepsute uruchomienie

Czwarty projekt oszczędza najwięcej czasu, bo dotyczy momentu, kiedy coś już nie działa. Prompt: „To uruchomienie się nie powiodło: adres. Powiedz, co się zepsuło, dlaczego i jaki dane wejściowe to spowodowało. Zaproponuj poprawkę, ale niczego nie stosuj, dopóki nie potwierdzę”.

Agent wyciąga z adresu identyfikatory przepływu i uruchomienia, więc wchodzi od razu w diagnozę, zamiast prosić cię o kopiowanie logów. Kluczowe jest to ostatnie zdanie promptu: „zaproponuj, ale nie stosuj”. Bez tego agent wprowadza poprawkę, która jest logicznie spójna i zupełnie nie pasuje do tego, co chciałeś.

Warto wiedzieć, jak wygląda rozkład błędów w praktyce. Analiza 29 218 zdarzeń walidacji z 9 021 instancji, zebrana w repozytorium projektu, podaje sukces za pierwszym razem na poziomie około 77%, a po ponowieniu na poziomie 100%. Około 75% błędów mieści się w trzech obszarach: struktura przepływu (26% wszystkich błędów), połączenia między węzłami (14%) i pola wymagane, których nikt nie zaznaczył (8%). Najczęściej wywalały się węzły webhook i trigger, Slack, agent AI oraz HTTP Request.

To daje konkretną prognozę. Jeśli pierwszy przebieg czegoś nie zadziała, to nie musi oznaczać, że prompt był zły. W 26% przypadków problem leży w samej strukturze JSON-a, który wygenerował model, a nie w Twojej specyfikacji.

Projekt 5: biblioteka opisów zamiast biblioteki węzłów

Piąty projekt jest inny w naturze. Nie chodzi o pojedynczy przepływ, tylko o sposób przechowywania wiedzy o procesach.

Zamiast budować i utrzymywać kilkadziesiąt przepływów, trzymasz ich opisy w repozytorium jako prompty. Zmiana zachowania to zmiana opisu i regeneracja, a nie ręczna edycja wdrożonego przepływu. W praktyce agencja trzyma w ten sposób bibliotekę szablonów opisanych po ludzku, które Claude Code instancjuje i dostosowuje dla kolejnych klientów.

Warto to rozumieć tak: Twoja własność intelektualna jest w opisie procesu, a nie w kliknięciach przy budowie węzłów. Jeśli kiedyś zmieniasz dostawcę bazy albo przenosisz projekt do innej osoby, zostaje Ci opis, z którego przepływ da się odtworzyć.

Praktyczna wskazówka z tych samych materiałów: sub-agent z tańszym modelem, ograniczony do odczytu przepływów i wykonania, porządkuje duże instancje znacznie taniej niż sesja główna. Przy kilkuset przepływach na produkcji różnica w rachunku jest zauważalna.

Ile to kosztuje: subskrypcja, okna, n8n

Zacznijmy od tego, czego nie da się pominąć. Claude Code nie ma planu darmowego. Dostęp jest w planach Pro i wyżej, ceny z marca 2026, stan na 24 marca 2026:

Plan	Cena	Limit w oknie 5 godzin	Dla kogo
Pro	20 USD miesięcznie albo 17 USD przy płatności rocznej	około 44 tys. tokenów	pojedynczy projekt, praca dorywcza
Max 5x	100 USD miesięcznie	około 88 tys. tokenów	praca nad n8n cały dzień, wiele sesji
Max 20x	200 USD miesięcznie	około 220 tys. tokenów	agencja, praca zespołowa

Limity działają w przesuwających się oknach pięciogodzinnych, a nie dziennie ani miesięcznie. To zmienia sposób planowania pracy: przerwa nie znosi limitu, tylko przesuwa okno, więc rozłożenie sesji ma znaczenie.

Dla zespołów jest haczyk, który widać dopiero przy zakupie. Plan Standard kosztuje 20 USD za miejsce, ale Claude Code jest w nim niedostępny. Wersja Premium z dostępem to 100 USD za miejsce, minimum pięć osób. Sama wartość liczby miejsc nie wystarczy.

Jeśli pierwsze zastosowanie jest szersze niż n8n, to plany Team i API opisuję w osobnym tekście przy porównaniu Claude i ChatGPT w zespole oraz przy koszcie 1 000 zadań automatyzacji. Sam n8n jest tu darmowy: wbudowany serwer MCP działa w każdym planie, łącznie z Community, a n8n-mcp jest na licencji MIT i można go uruchomić lokalnie przez Node.js 16+ albo Dockera. Do testów wystarczy darmowa instancja z 14-dniowym okresem próbnym.

Skąd bierze się oszczędność 41× na edycji

To liczba, która przekonuje najbardziej, bo dotyczy realnego kosztu pracy poza pierwszym uruchomieniem. Autorzy n8n-mcp podają z produkcji medianę 41× mniej tokenów na jedną edycję, przy 99,77% skuteczności na 2 milionach wywołań w 90 dni.

Mechanizm jest prosty i warto go zrozumieć, bo zmienia sposób zamawiania pracy. Zamiast „przepisz ten przepływ”, mówisz „w węźle Pobierz klienta zmień ścieżkę z /v1 na /v2 i zrób najmniejszą możliwą zmianę”. Narzędzie wkleja pojedynczy fragment zamiast całego węzła. Przy długim węźle Code albo szablonie HTML to różnica między kilkuset znakami a ponad 5 tysiącami tokenów.

Ta sama dokumentacja podaje, że użytkownicy modyfikują istniejące przepływy częściej niż tworzą nowe, w stosunku 6,21 do 1. To ważniejszy wniosek niż sama oszczędność: większość roboty to poprawki, więc optymalizacja edycji bije optymalizację generowania.

Praktyczna wskazówka na co dzień: szablony n8n to 2 352 pozycje, a sam n8n deklaruje ponad 10 tysięcy gotowych przepływów. Zanim opiszesz nowy przepływ od zera, sprawdź, czy ktoś nie zbudował już podobnego. Porównanie platform automatyzacji zaczyna się od tego samego pytania: czy to zadanie w ogóle wymaga nowego narzędzia.

Cztery ścieżki połączenia i ta, którą wybieram

Połączenie można zrobić na cztery sposoby i wybór ma realne konsekwencje operacyjne.

Wbudowany serwer MCP w n8n, przez HTTP. Włączasz dostęp w panelu, kopiujesz adres serwera kończący się na /mcp-server/http i rejestrujesz go w Claude Code poleceniem claude mcp add --transport http. Obsługa klienta jest oficjalna, a dokumentacja n8n prowadzi osobno przez klientów CLI, webowych i IDE. To ścieżka, którą wybieram w pierwszej kolejności dla klienta, bo nie wymaga dodatkowego serwera do utrzymania.

n8n-mcp lokalnie, przez stdio. Instalacja przez npm install -g n8n-mcp albo npx n8n-mcp, konfiguracja w pliku z adresem instancji i kluczem API. Działa tylko na tej samej maszynie i nie wymaga uwierzytelniania. Wygodne do nauki i do pracy na własnym środowisku.

n8n-mcp jako zdalny serwer HTTP. Kontener z tokenem, limit 20 prób autoryzacji na 15 minut i adres dla klienta przez mcp-remote. Wymaga własnego utrzymania i twardego tokenu, minimum 32 znaki. Sensowne, kiedy kilka osób ma korzystać z jednego połączenia.

Odwrotna kolejność: n8n jako serwer MCP. Węzeł MCP Server Trigger wystawia adres dla klientów MCP, ale nie obsługuje transportu stdio, więc wybór jest tylko między SSE a streamable HTTP. To opcja dla zupełnie innego scenariusza, w którym to n8n udostępnia narzędzia, a nie odwrotnie.

Dwie rzeczy, które psują połączenie najczęściej i warto je znać przed szukaniem błędu. Przy odwrotnym proxy trzeba wyłączyć buforowanie odpowiedzi dla ścieżki /mcp, a n8n musi przepuszczać w polityce CORS trzy nagłówki wysyłane przez klientów MCP. Jeśli instancja ma więcej niż jedną replikę webhooków, wszystkie żądania /mcp muszą trafić do jednej, wydzielonej replikacji.

Granice uprawnień: co agent zobaczy, a czego nie

Tu najczęściej pojawia się fałszywe rozumienie, więc warto to powiedzieć wprost. Wbudowany serwer MCP nie daje dostępu do wszystkich przepływów. Włączasz go na poziomie instancji, a potem każdy przepływ osobno. Wyjątkiem jest search_workflows, który przeszukuje wszystko, do czego masz uprawnienia, ale zwraca tylko podglądy, nie pełną definicję.

Druga granica jest mniej oczywista: uprawnienia nie są dzielone na klientów. Jeśli podepniesz Claude Code i ChatGPT, oba widzą wszystkie przepływy, które włączyłeś dla MCP. Nie da się powiedzieć, że ChatGPT ma dostęp do jednego, a Claude do drugiego.

Trzecia sprawa to sposób na tryb tylko-do-odczytu. n8n-mcp ma listę zmiennych środowiskowych, którymi wyłączasz narzędzia zapisujące: tworzenie, edycję pełną i częściową, usuwanie, wdrażanie szablonów, testowanie oraz zarządzanie credentialami i tablicami danych. Działa to na poziomie poszczególnych operacji, więc z narzędzia testowania zostaje wariant przygotowujący, a wyzwalający i pilnowany odpadają.

Autorzy projektu zalecają podwójną warstwę: klucz API n8n z zakresem tylko do odczytu plus wyłączone narzędzia po stronie MCP. Ich zdaniem warstwa MCP jest wygodną dźwignią, a uprawnienia w API n8n są właściwą granicą egzekwowania. Zgadzam się z tym rozróżnieniem.

Osobno ostrzeżenie, którego nie chcę pominąć. Z oficjalnej dokumentacji Claude Code: serwery pobierające treści z zewnątrz narażają Cię na ryzyko prompt injection. W praktyce oznacza to, że przepływ, który pobiera dane z zewnętrznego źródła, może przynieść treść, która wygląda jak instrukcja dla agenta. Dlatego twórcy n8n-mcp wprost zalecają: nigdy nie edytuj produkcyjnych przepływów bezpośrednio przez AI, rób kopię, testuj na środowisku deweloperskim i eksportuj kopie zapasowe.

Co psuje się najpierw - 29 tysięcy walidacji

Warto tu wrócić do danych, bo oszczędza godziny zgadywania. Rozkład najczęstszych awarii w n8n-mcp wygląda następująco:

• Struktura przepływu: 26% błędów, zazwyczaj zniekształcony JSON wygenerowany przez model.
• Połączenia między węzłami: 14% błędów. Węzeł IF ma dwa wyjścia, prawidłowe i nieprawidłowe, i bez wskazania gałęzi oba połączenia mogą trafić tam, gdzie nic nie powinno.
• Pola wymagane: 8% błędów, bo nie są oznaczone z góry.

Dwie rzeczy praktyczne. Po pierwsze, operacja dodająca połączenie wymaga czterech osobnych parametrów tekstowych, więc typowa pomyłka daje komunikat błędu, który nie mówi, co konkretnie jest nie tak. Po drugie, funkcja łagodnej poprawki celowo nie naprawia wszystkiego: konserwatywnie podchodzi do zmian, które mogłyby coś zepsuć. Niepobrana odpowiedź „brak automatycznych poprawek” często znaczy, że funkcja już je zastosowała przy wdrożeniu szablonu.

Jest też pułapka związana z samą funkcją patchowania pojedynczego pola: indeks spoza zakresu jest odrzucany, a nie dopisywany na końcu listy. Nie dodasz w ten sposób nowego elementu tablicy, musisz podać całą tablicę.

Checklista przed podpięciem do produkcji

Uporządkuję to w kolejności, w której samo sprawdzenie nic nie kosztuje, a potem dopiero działania.

Najpierw środowisko. Kopia przepływu, eksport do pliku, osobna instancja deweloperska. Autorzy danych o walidacjach wprost radzą nie ćwiczyć na produkcji: darmowa instancja albo projekt deweloperski wystarczą.

Potem dostęp. Klucz API z zakresem tylko do odczytu na start, wyłączone narzędzia zapisujące, dopiero później rozszerzanie uprawnień o to, czego faktycznie używasz.

Następnie test pojedynczego uruchomienia z payloadem, który znasz. Prompt „wyślij taki test i przejdź węzeł po węźle, a jeśli coś padnie, napraw i puść ponownie” robi więcej niż dziesięć rund walidacji bez danych.

Na końcu audyt i rotacja. Lista credentiali z odpowiedziami, które przepływy ich używają, oraz usunięcie tokenów, które zostały zapisane w repozytorium. Wersje przepływów warto przeglądać raz w miesiącu, bo n8n traktuje wdrożenie jako zwykłą aktualizację: świeżo utworzony przepływ nie ma jeszcze żadnej wersji, więc nie ma dokąd wrócić, jeśli pierwszy deploy był zły.

To wszystko działa bez pisania kodu. Jeśli chcesz policzyć, ile godzin w tygodniu zjada proces, który chcesz tu oddać agentowi, zacznij od prostego rachunku zwrotu z automatyzacji - wtedy będziesz wiedział, czy warto budować od największego kłopotu, czy od najczęstszego.