לתת לAI לבנות אוטומציות דטרמיניסטיות עם n8n וMCP

כבר שנים שאני עוסק באוטומציות, ומי שקורא אותי יודע שאני אוהב שתהליכים ירוצו לבד, בלי שאצטרך לזכור אותם. פעם זה היה עם כלים כמו Integromat וZapier, ובסוף תמיד מצאתי את עצמי כותב עוד קצת קוד, נלחם בAuth ונתקל במגבלות של התוכנית החינמית (כתבתי על כל ההרפתקה הזאת פה).

עכשיו יש AI, וכולם רצים לבקש ממנו ״תכתוב לי סקריפט״ או בונים לו ״סקיל״, כלומר קובץ markdown עם הוראות. זה עובד נהדר בהדגמה, ואז שבוע אחרי זה הAI ממציא פונקציה שלא קיימת, או שהAPI השתנה, או שפשוט בריצה הבאה הוא החליט לעשות את אותו הדבר אחרת. ואין לך מושג למה, כי אין לוג, אין שלבים, אין כלום.

אז הגעתי לגישה אחרת: במקום לתת לAI להיות האוטומציה, אני נותן לו לבנות את האוטומציה בכלי שנבנה בדיוק בשביל זה, n8n.

ההתקנה: n8n וAI שמדבר איתו דרך MCP

הבסיס פשוט להפליא: מריצים את n8n, ומחברים אליו AI דרך MCP. MCP הוא הפרוטוקול שנותן לAI גישה מתועדת לכלים חיצוניים, ובמקרה הזה הכלי הוא n8n עצמו. ברגע שAI יכול לדבר עם n8n, הפוטנציאל כמעט בלתי מוגבל: כל מה שאתה יכול לתאר במילים, הAI יכול לבנות בתור workflow.

את n8n אני מריץ אצלי בתור קונטיינר, כחלק מהשרת הביתי. את הAI אפשר לחבר מאיפה שרוצים, כי בסוף הוא רק צריך גישה לMCP: זה יכול לרוץ על אותה מכונה, אבל גם מרחוק. אני אישית משתמש בClaude Code, ויש גם אלטרנטיבה נחמדה בקוד פתוח, OpenHands.

היעילות: הAI לא חוקר APIs, הוא מתזמר

נניח שאני מבקש מהסוכן ״כשמגיע מייל עם חשבונית, תשמור אותה בPaperless ותשלח לי הודעה בטלגרם״. אם הוא היה כותב קוד, הוא היה צריך ללמוד את הAPI של Gmail, להתעסק עם OAuth, למצוא ספרייה לטלגרם, לטפל בrate limits... וכל זה עוד לפני שבכלל התחלנו לפתור את הבעיה האמיתית.

בn8n כל זה כבר פתור. יש מאות אינטגרציות מוכנות, והAuth מוגדר פעם אחת בממשק. הסוכן לא צריך לחקור כלום, הוא רק צריך לתזמר: לקחת את הnode של Gmail, לחבר אותו לnode של Paperless, ולסיים בnode של טלגרם. זה כל ההבדל בין ״תכתוב לי אינטגרציה״ לבין ״תחבר את הקוביות שכבר קיימות״. במקום לבזבז טוקנים על מחקר, הAI מוציא אותם על מה שבאמת חשוב: ההיגיון של התהליך.

ואיך הסוכן יודע לעשות את זה טוב? פה נכנסים שני רכיבים, במקרה שניהם מאותו בנאדם (czlonkowski):

• הידיים: שרת n8n-mcp, שהוא MCP, שנותן לסוכן גישה מתועדת לn8n: לחפש nodes, לבדוק אילו פרמטרים הם מקבלים, ולבנות ולתקף workflows. גם אותו אני מריץ בתור קונטיינר ליד n8n.
• הידע: אוסף הסקילים n8n-skills, שמלמדים את הסוכן את הקונבנציות של n8n: איך לכתוב expression, איך מגדירים node, ואילו שגיאות validation הן אמיתיות ואילו סתם רעש. אני מסנכרן אותם אוטומטית עם סקריפט קטן.

הצירוף הזה, ידיים שיודעות לגעת בn8n וידע איך לגעת בו נכון, הוא מה שהופך את הסוכן ממישהו ש״מנחש איך n8n עובד״ למישהו שבונה workflow תקין כבר מהפעם הראשונה.

האמינות: פלט דטרמיניסטי שאפשר לתעד, לנטר ולשפר

וזה מביא אותי לחלק שהכי חשוב לי. workflow בn8n הוא דטרמיניסטי: אותו קלט עובר באותו מסלול, דרך אותם nodes, ומוציא אותו פלט. אין פה ״הפעם הAI החליט אחרת״.

וכל ריצה נשמרת. אני נכנס לn8n ורואה execution אחרי execution: איזה node רץ, מה נכנס אליו, מה יצא ממנו, ואיפה בדיוק זה נפל. כשמשהו נשבר אני לא מנחש, אלא פותח את הריצה הכושלת ורואה את השגיאה האמיתית. (זה היה אחד הדברים הכי נוחים כשבניתי את הRAG לבלוג: ממש רואים את כל התהליך מול הכלים והזכרון.)

עכשיו תשוו את זה ל״סקיל״ שהוא קובץ markdown, או לprompt חד-פעמי:

• אין לוג. משהו לא עבד? בהצלחה לשחזר מה קרה שם.
• אין דטרמיניזם. אותה בקשה בדיוק יכולה להניב שלוש תוצאות שונות בשלוש ריצות.
• אין על מה להשתפר. אי אפשר לתקן באג שאתה בכלל לא רואה.

הworkflow, לעומת זאת, הוא נכס: בונים אותו פעם אחת, והוא רץ אלף פעם אותו דבר. וכשהוא כן נכשל (והוא ייכשל, כי APIs משתנים והעולם זז), יש לי כשל קונקרטי עם לוג, ואני יכול פשוט להחזיר את הסוכן ולהגיד לו ״תראה את הריצה הזאת, תתקן את הnode הזה״. הסוכן קורא בדיוק את אותו לוג שאני קורא, ומתקן את המקום הספציפי. ככה האוטומציה משתפרת לפי כשלונות אמיתיים, לא לפי ניחושים.

זה גם מתחבר מצוין לדרך שאני אוהב לעבוד: מתחילים מPOC מהיר, ואם משהו באמת שורד ונהיה חלק מהשגרה, משקיעים בו, מנטרים אותו, ומשפרים אותו לאט לאט. (בדיוק כמו שעשיתי עם MCP מול Actual Budget, שם חיברתי AI לנתונים האמיתיים שלי דרך n8n.)

רוצים לנסות בעצמכם?

אמרתי שבסוף זה שני קונטיינרים, אז הנה זה בפועל. גרסה מינימלית של מה שרץ אצלי בשרת: n8n עצמו, וn8n-mcp שחושף אותו לAI.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - '5678:5678'
    environment:
      - GENERIC_TIMEZONE=Asia/Jerusalem
      - N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true
    volumes:
      - n8n-data:/home/node/.n8n

  n8n-mcp:
    image: ghcr.io/czlonkowski/n8n-mcp:latest
    restart: unless-stopped
    ports:
      - '3100:3100'
    environment:
      - MCP_MODE=http
      - PORT=3100
      - N8N_API_URL=http://n8n:5678
      - N8N_API_KEY=${N8N_API_KEY}
      - AUTH_TOKEN=${AUTH_TOKEN}
    depends_on:
      - n8n

volumes:
  n8n-data:

ומכאן זה כמה צעדים:

1. מרימים את הכל. מייצרים טוקן לMCP עם openssl rand -base64 32, שמים אותו בקובץ .env ליד הcompose בתור AUTH_TOKEN, ומריצים docker compose up -d. n8n עולה על http://localhost:5678.

2. מחברים את הMCP לn8n. בתוך n8n, בהגדרות תחת ״n8n API״, יוצרים API key. מוסיפים אותו ל.env בתור N8N_API_KEY, ומריצים שוב docker compose up -d כדי שהMCP ירים אותו.

3. מחברים את סוכן הקוד. בClaude Code זו שורה אחת:

claude mcp add --transport http n8n-mcp http://localhost:3100/mcp \
  --header "Authorization: Bearer $AUTH_TOKEN"

אם הסוכן רץ על אותה מכונה ולא בא לכם להתעסק בHTTP, יש גם מצב stdio פשוט יותר בלי טוקן, ראו את התיעוד של n8n-mcp.

4. נותנים לסוכן את הידע. מתקינים את הסקילים של czlonkowski כדי שהסוכן יכיר את הקונבנציות של n8n מבפנים:

npx skills add https://github.com/czlonkowski/n8n-skills --skill '*' -a claude-code -y

5. מבקשים. עכשיו פשוט אומרים לו ״תבנה workflow ש...״, והוא יחפש nodes, יחבר אותם, ויתקף את הworkflow מול הMCP לפני שיגיד שסיים. מכאן זה אתם והדמיון שלכם.

שורה תחתונה

השינוי בתפיסה פשוט: במקום לבקש מAI להיות האוטומציה, אני מבקש ממנו לבנות אותה בכלי שנבנה בדיוק בשביל זה. הסוכן כותב פעם אחת, n8n מריץ לנצח (וגם דטרמיניסטית), ושנינו (גם אני וגם הסוכן) מתקנים מתוך לוגים אמיתיים ולא מתוך הזיות.

זה לא אומר שלא צריך AI חכם. להפך, צריך אותו בדיוק במקום הנכון: בתכנון ובתיקון, לא בתור מנוע ריצה שמתפלל בכל בוקר שיעבוד.

אתם מחברים AI לכלי אוטומציה? אשמח לשמוע בתגובות איך אתם סוגרים את הלולאה בין הAI לבין משהו שבאמת רץ.