n8n MCP: wybierz drogę i przetestuj jedno zadanie w CRM

n8n MCP może oznaczać klienta AI wywołującego n8n albo workflow n8n wywołujący narzędzia innej aplikacji. Do wyszukania klienta w Customermates i utworzenia zadania wewnętrznego pasuje drugi kierunek: przetestowany przykład poniżej używa samodzielnego węzła MCP Client z n8n, bez modelu.

Krótko: n8n może być zarówno serwerem MCP, jak i klientem. Jako serwer udostępnia klientom AI swoje workflow (MCP na poziomie instancji albo węzeł MCP Server Trigger). Jako klient wywołuje narzędzia innych aplikacji (MCP Client Tool w agencie albo samodzielny węzeł MCP Client). Tabela niżej pokazuje, który z tych wariantów pasuje do Twojego zadania.

MCP, czyli Model Context Protocol, to protokół połączenia, a n8n to aplikacja do workflow. Zacznij od kierunku wywołania, a potem wybierz węzeł lub serwer. Poradnik n8n dla początkujących omawia edytor wizualny; ten tekst omawia wybór drogi MCP i jedną opisaną datą, naprawdę wykonaną trasę.

Która droga n8n MCP pasuje do Twojego zadania?

Tabela oddziela osobę utrzymującą komponent od osoby, której poświadczenia autoryzują pracę. Znajoma nazwa produktu nie wystarcza do rozpoznania połączenia.

Oficjalna dokumentacja serwera n8n MCP na poziomie instancji odróżnia dostęp do instancji od Server Trigger pojedynczego workflow. Włączenie MCP nie wystawia wszystkich workflow. Widoczność zależy od dostępu użytkownika i ustawień ekspozycji MCP. Opis narzędzi obejmuje tworzenie i edycję workflow oraz tabel danych. Opisywanie dzisiejszego oficjalnego serwera jako służącego tylko do wykonywania jest niepełne.

Opis MCP Server Trigger przedstawia punkt wejścia serwera. Opis MCP Client Tool przedstawia zewnętrzne narzędzia agenta. Opis samodzielnego MCP Client obejmuje jawne wywołania w zwykłym workflow.

Niezależne repozytorium n8n-mcp pomaga budować workflow. To osobny projekt, a nie nazwa każdej natywnej funkcji MCP. Nie musisz go instalować, żeby wykonać poniższy przepis z samodzielnym klientem.

Jak włączyć dostęp MCP w n8n i podłączyć klienta AI?

To pierwszy wiersz tabeli: klient AI łączy się z Twoją instancją n8n i może szukać oraz uruchamiać workflow, a od wersji 2.13.0 także je budować i zmieniać. Tego scenariusza nie wykonywaliśmy w teście opisanym niżej; poniższe kroki opieramy na oficjalnej dokumentacji serwera n8n MCP na poziomie instancji, więc dokładne nazwy opcji sprawdź w niej dla swojej wersji.

1. Włącz dostęp MCP na poziomie instancji. Dokumentacja opisuje to dla n8n Cloud i dla instancji self-hosted; układ ustawień zmienił się w wersji 2.33.0. Administrator własnej instancji może MCP także całkowicie wyłączyć.
2. Połącz klienta. Zalecane jest OAuth: klient przeprowadza Cię przez logowanie do n8n i działa jako ten użytkownik. Alternatywą jest token dostępu MCP, który wklejasz do konfiguracji klienta; traktuj go jak hasło i nie zapisuj w plikach, które trafiają do repozytorium.
3. Wskaż workflow, które klient ma widzieć. Włączenie MCP nie wystawia wszystkich workflow. Udostępniasz je jawnie i dodajesz opis, żeby klient wiedział, do czego służą.
4. Sprawdź uprawnienia. Klient widzi i zmienia tyle, ile użytkownik n8n, jako którego działa. Zacznij od konta z najmniejszym potrzebnym dostępem.

Budowanie i zmiana workflow z klienta AI

Skoro opis narzędzi obejmuje tworzenie i edycję workflow, klient AI może przygotować szkic, który potem poprawiasz w edytorze. Traktuj taki szkic jak cudzy pull request: przejrzyj każdy węzeł, sprawdź, które poświadczenia wykorzystuje, uruchom ręcznie na danych testowych i dopiero wtedy opublikuj. Nie pozwalaj klientowi publikować ani zmieniać produkcyjnych workflow bez przeglądu. Podstawy budowania workflow w samym edytorze opisuje poradnik n8n dla początkujących.

n8n Cloud czy własna instancja: co się zmienia przy MCP?

• Dostępność. Dokumentacja n8n opisuje dostęp MCP zarówno dla n8n Cloud, jak i dla instancji self-hosted. Nasz test uruchomiono na własnej instancji z obrazu Dockera; n8n Cloud i OAuth nie były w nim testowane.
• Adres instancji. Klient działający w chmurze nie dotrze do instancji pod localhost. Dla klienta, który nie działa na Twoim komputerze, potrzebujesz publicznego adresu HTTPS albo klienta uruchomionego lokalnie obok instancji.
• Węzły społeczności. n8n Cloud instaluje tylko zweryfikowane węzły społeczności, więc węzeł @customermates/n8n-nodes-crm ze wzmianki niżej wymaga własnej instancji, a w Cloud pozostaje węzeł HTTP Request.
• Utrzymanie. Na własnej instancji sam odpowiadasz za aktualizacje, kopie zapasowe i zabezpieczenia; wersję n8n przypnij, jak w naszym teście.

Co dokładnie uruchomiono i na jakich wersjach?

Wykonano 28 października 2026, od 23:10:03 do 23:10:15 UTC: ręczny workflow na n8n 2.45.5 z @n8n/n8n-nodes-langchain.mcpClient typeVersion 1.1. Obraz przypięto do tego skrótu (digest):

docker.n8n.io/n8nio/n8n@sha256:9f6d0a5987ab5a297c4b0b38fbf1a22285dd1364551478e93f03d506908fa74c

Źródłem Customermates było 86212781f845d0ccdc1dfa3ddd78fa38fa2b8912. Wszystkie rekordy były fikcyjne i znajdowały się w odizolowanej lokalnej bazie danych. Przekaźnik dostępny tylko na pętli zwrotnej (loopback) podawał w pamięci jednorazowy klucz API do /api/v1/mcp. Nie użyto żadnego zewnętrznego konta, wywołania modelu ani wysyłki wiadomości.

To przepis na dokładnie tę przetestowaną drogę i składnię, sprawdzony 5 listopada 2026. Nie jest to nowe wykonanie n8n z tej daty. Konfiguracja uwierzytelniania przekaźnika, stałe identyfikatory danych testowych i rewizja schematu są specyficzne dla testu. Nie testowano OAuth, n8n Cloud, harmonogramów, Server Trigger ani wyboru narzędzi przez AI Agent.

Jak złożyć ręczny workflow z pięcioma wywołaniami?

Utwórz węzeł Manual Trigger, a po nim pięć węzłów MCP Client w wersji samodzielnej, połączonych zwykłymi wyjściami. Zostaw workflow nieopublikowany, dopóki sprawdzasz zadanie wewnętrzne w jednorazowym obszarze roboczym. Diagram pokazuje wykonaną sekwencję, z celowo zduplikowanym żądaniem:

Manual Trigger
  → get_workspace_context
  → get_record_model
  → query_crm_records
  → mutate_crm_record
  → mutate_crm_record (identical payload and key)

W zachowanym workflow każdy węzeł klienta miał taki układ parametrów. To historyczny adres lokalnego przekaźnika, a nie publiczny endpoint ani konfiguracja CRM bez uwierzytelniania:

{
  "serverTransport": "httpStreamable",
  "endpointUrl": "http://127.0.0.1:4053/mcp",
  "authentication": "none",
  "tool": {
    "__rl": true,
    "value": "get_workspace_context",
    "mode": "id"
  },
  "inputMode": "json",
  "jsonInput": {},
  "options": {
    "timeout": 60000,
    "convertToBinary": false
  }
}

W każdym kolejnym węźle zmień tool.value i jsonInput zgodnie z krokami poniżej; zachowaj Streamable HTTP, wejście JSON i 60-sekundowy limit czasu. Stała sekwencja nie mapuje dynamicznie wyników wykrywania do kolejnych węzłów.

1. Potwierdź obszar roboczy. Wywołaj get_workspace_context z {}. Sprawdź zwróconego użytkownika i obszar roboczy, zanim dopuścisz zapis.
2. Odczytaj schemat. Wywołaj get_record_model z {}. Zestaw testowy rozpoznał typy Task i Organization, pola główne i relację wychodzącą, zanim zbudowano workflow. Zapisana mutacja użyła rewizji konfiguracji 2.
3. Znajdź klienta. Wywołaj query_crm_records z zapisanym poniżej JSON. W swoim obszarze roboczym rozpoznaj identyfikatory od nowa i sprawdź wynik, zanim wybierzesz klienta. Znane odwołanie do rekordu z danych testowych ustalono w następnym węźle; nie był to test automatycznego dopasowywania encji.

{
  "typeId": "51d5e8d2-9468-8718-852d-aad6d1964282",
  "fields": [
    "b8b511f4-5de8-81ce-887f-880d80b0062c"
  ],
  "search": "Example organization",
  "page": 1,
  "pageSize": 25
}

4. Utwórz zadanie wewnętrzne. Wywołaj mutate_crm_record z dokładnie tym zapisanym ładunkiem. Każdy UUID to identyfikator danych testowych, także przypisany użytkownik. Relacja łączy zadanie z fikcyjną organizacją; niczego do niej nie wysyła.

{
  "expectedRevision": 2,
  "idempotencyKey": "seo-run340-n8n-mcp-manual-next-task-v1",
  "mutation": {
    "action": "create",
    "typeId": "0d70aff9-0fa9-8ce2-8e75-8bdddf0fdfd1",
    "assignedUserIds": [
      "eed148ca-b816-4db2-acac-186ca6f03043"
    ],
    "fields": [
      {
        "fieldId": "02960cb0-8976-81b2-82ce-6194a5bc90e3",
        "value": {
          "kind": "text",
          "value": "Fictional n8n manual proof: check the handover field list"
        }
      }
    ],
    "links": [
      {
        "relationId": "2f82adb2-ca57-8190-85ae-230cde69ff06",
        "direction": "outgoing",
        "record": {
          "typeId": "51d5e8d2-9468-8718-852d-aad6d1964282",
          "recordId": "16d88ab1-a440-4e42-b698-99a284940191"
        }
      }
    ]
  }
}

5. Powtórz identyczne żądanie. Ostatni węzeł użył tych samych argumentów mutate_crm_record, równoważnego bajt po bajcie JSON i tego samego klucza idempotentności. Ponowienie dla tego samego zdarzenia biznesowego musi zachować i ładunek, i klucz. Zmienione zdarzenie lub ładunek wymaga nowego klucza.

Oryginalny test zaimportował workflow o identyfikatorze seoRun340McpProof i wykonał go po identyfikatorze w przypiętym środowisku:

n8n import:workflow --input /proof/workflow.json
n8n execute --id seoRun340McpProof --rawOutput

Te polecenia zakładają, że zachowany workflow i przekaźnik już istnieją. Wcześniejsza próba execute --file zakończyła się kodem zero, choć workflow się nie wykonał. Test ją odrzucił, bo nie było żadnych wywołań narzędzi. Sam kod wyjścia ani importowalny plik JSON nie są dowodem działającego połączenia.

Jaki wynik sprawdzić, zanim to dostosujesz?

Poprawiony przebieg zapisał pięć faktycznych wywołań narzędzi z n8n: trzy odczyty i dwie identyczne mutacje. Import i wykonanie zakończyły się powodzeniem. Potem osobny odczyt kontrolny przez SDK potwierdził zadanie 8f3bd9eb-0696-4505-9c09-e12620648cc1 w wersji 1, z nienaruszonym przypisanym właścicielem i powiązaniem z klientem. Zestaw testowy powtórzył też mutację przez SDK. Odczyt kontrolny odbył się poza workflow z pięcioma węzłami.

Osobny test produktu z 5 listopada 2026 na źródle 111f8a2e33f39975955e8f49d3f7c898fbbd3d05 obejmował odczyty i zapisy REST oraz MCP, idempotentne powtórzenie i odmowę uprawnień. Jego klientem MCP było SDK 1.24.0, a nie n8n. Wspiera te bieżące obserwacje produktu, ale nie aktualizuje datowanego wyniku zgodności z n8n.

Czym różnią się poświadczenia i konfiguracja produkcyjna?

Przy bezpośrednim połączeniu z Customermates użyj <BASE_URL>/api/v1/mcp i poświadczenia Header Auth w n8n z nazwą nagłówka x-api-key. Przechowuj klucz w poświadczeniach, nigdy w wyeksportowanym JSON workflow. Przewodnik po kluczach API Customermates wyjaśnia powiązanie z obszarem roboczym i dziedziczone uprawnienia użytkownika. Bezpośrednie Header Auth to udokumentowana konfiguracja; zachowane uruchomienie n8n użyło przekaźnika.

Aktualne narzędzia i schematy sprawdzisz w kontrakcie MCP Customermates. Zastąp identyfikatory z danych testowych i rewizję wartościami ze swojego obszaru roboczego, dodaj kontrolę, że dopasowanie klienta jest jednoznaczne, i odczytaj utworzone zadanie. Sprawdzaj błędy narzędzi, a nie tylko status workflow. Nie zamieniaj nieudanego zapisu na nowy klucz idempotentności, dopóki nie rozumiesz jego wyniku.

Zewnętrzny klient MCP działa jako połączony z nim użytkownik. Instrukcje, by pytać przed wysłaniem lub usunięciem, to wskazówki dla klienta, a nie wymuszana przez serwer bramka zatwierdzenia. Wdróż własną granicę przeglądu dla działań o poważnych skutkach. Polityka zatwierdzeń Mate jest osobna; ten workflow ani nie wywołuje Mate, ani nie dowodzi procesu zatwierdzania.

Jeśli Twoje zadanie to stała synchronizacja CRM, prostszy może być przewodnik po integracji Customermates z n8n: osobny węzeł społeczności @customermates/n8n-nodes-crm w wersji 2 korzysta z ogólnego API rekordów. Jego workflow w wersji 1 celują w usunięte endpointy. Opcjami są też REST i webhooki; porównaj kontrakty w MCP vs API.

Samodzielnie hostowany Customermates udostępnia rdzeń CRM Starter, REST i zewnętrzny dostęp MCP. Mate hostowany przez Customermates i skrzynka odbiorcza w chmurze nie są w nim zawarte. Customermates nie zawiera środowiska ani subskrypcji n8n, darmowego hostowanego n8n ani wychodzących sekwencji. Jeśli chcesz tylko połączyć istniejący CRM, Customermates nie jest wymaganym pośrednikiem.

Taki workflow tworzy następny krok. Druga połowa to odpowiedź do klienta: gdy LinkedIn i e-mail są podłączone w Customermates Cloud od planu Pro, rozmowa leży na rekordzie klienta, a Mate albo Twój własny agent AI przygotowuje szkic odpowiedzi do przejrzenia i wysłania. Żeby zobaczyć oba elementy razem, zacznij okres próbny: 14 dni planu Pro bez karty kredytowej.

Najczęstsze pytania

Dokumentację podmiotów zewnętrznych sprawdzono 5 listopada 2026 w oficjalnych opisach n8n i repozytorium społeczności, do których odsyłają linki powyżej. Wykonany przykład n8n pozostaje datowany na 28 października 2026.