בניית אפליקציות בתוך הצ'אט: המסע שלי עם MCP Apps

אם עקבתם אחרי עולם ה-AI, בטח שמעתם על MCP (Model Context Protocol). אבל יש חלק חדש ומרגש יותר: MCP Apps. לאחרונה בניתי README Generator כ-MCP App, ואני רוצה לשתף מה למדתי – גם על הפרוטוקול וגם למה "אפליקציות בתוך הצ'אט" זה חזק יותר ממה שזה נשמע.

מה זה MCP?

לפני שנצלול ל-MCP Apps, בואו נבין את היסודות. MCP (Model Context Protocol) הוא תקן פתוח שנוצר על ידי Anthropic שמגדיר איך עוזרי AI מתקשרים עם כלים חיצוניים, מקורות מידע ו-APIs. תחשבו על זה כמחבר אוניברסלי שמאפשר לכל עוזר AI לדבר עם כל מערכת backend באמצעות אותו פרוטוקול.

למה זה חשוב? לפני MCP, לכל עוזר AI היה דרך קניינית משלו להתחבר לכלים. אם בניתם פלאגין ל-ChatGPT, הוא לא היה עובד עם Claude. אם רציתם שהאפליקציה שלכם תעבוד עם מספר עוזרי AI, הייתם צריכים לתחזק אינטגרציות נפרדות לכל אחד. MCP פותר את זה על ידי מתן פרוטוקול סטנדרטי – בנו פעם אחת, עבדו בכל מקום.

Anthropic פרסמה את המפרט כקוד פתוח ומספקת SDKs ב-TypeScript ו-Python. הפרוטוקול מתוכנן סביב ארכיטקטורת client-server שבה עוזר ה-AI (client) מתחבר לשרתי MCP שחושפים כלים, משאבים ו-prompts.

MCP Architecture: AI Assistant connected via MCP to Your tools, data, and APIs

MCP הוא השכבה הסטנדרטית בין ה-AI לכלים/מידע שלכם. פרוטוקול אחד, עוזרים רבים ו-backends רבים.

אם אתם רוצים להעמיק, בדקו את המפרט הרשמי – הסעיפים "Architecture" ו-"Concepts" נותנים לכם את התמונה הכללית הטובה ביותר.

מה שונה ב-MCP Apps?

כאן זה נהיה מעניין. MCP קלאסי עובד ככה: המודל קורא לכלי ומקבל בחזרה טקסט או מידע מובנה. המשתמש רואה הודעה. זהו.

את הרעיון של UI אינטראקטיבי בתוך הצ'אט (MCP Apps) פיתחו ליעד יוסף ועידו סלומון בספריית MCP-UI, לפני שאוחד הסטדרט הרשמי; הם גם היו מעורבים בעבודה עם Anthropic ו-OpenAI.

MCP Apps לוקח את זה צעד קדימה: הכלי יכול להחזיר UI חי – אפליקציה קטנה בתוך iframe, ישירות בתוך הצ'אט. המשתמש מקבל חוויה מרובת שלבים, עם state, בלי לעזוב את השיחה. טפסים, wizards, dashboards – הכל באותו thread.

דוגמה קונקרטית

נניח שאתם בונים README Generator.

בלי MCP Apps:

  • משתמש: "תיצור לי README."
  • מודל: "בטח! מה השם שלך?"
  • משתמש: "ג'ון"
  • מודל: "מה התפקיד שלך?"
  • משתמש: "Engineering Manager"
  • מודל: "מה שעות העבודה שלך?"
  • ...וכך הלאה, הלוך ושוב ל-10+ הודעות.

עם MCP Apps:

  • משתמש: "תיצור לי README."
  • המודל קורא לכלי שלכם → ה-wizard שלכם מופיע בצ'אט
  • המשתמש ממלא שלבים ולוחץ Continue
  • שיחה אחת, מקום אחד, בלי copy-paste

הנה ההבדל הויזואלי:

Classic MCP vs MCP Apps: one-shot answer vs multi-step interactive UI

מה למדתי מהבנייה של זה

בניתי את ה-README Generator בעיקר כדרך להבין MCP Apps בפועל. החלק המעניין לא היה יצירת ה-README עצמו – זה פשוט. מה שרציתי לחקור היה: האם אפשר לקחת חוויית web קיימת ולהביא אותה לצ'אט בלי לשכפל את כל הלוגיקה?

הנה מה שהפך את זה לתרגיל למידה שימושי:

  1. ערוץ הפצה, לא שכתוב מחדש: כבר היה לי wizard של README באתר. במקום לבנות אותו מחדש לצ'אט, רציתי שאותו backend API ישרת את שני הממשקים. משתמשים שמעדיפים את האתר יכולים להשתמש באתר. משתמשים שכבר נמצאים ב-ChatGPT/Claude יכולים להישאר שם. אותו מידע, אותה לוגיקה, אפס שכפול.

  2. ניהול state בין שלבים: טפסי web זה קל – אתם שולטים על כל העמוד. בצ'אט, אתם עובדים בתוך iframe עם tool calls שמתאמים בין שלבים. להבין איך לנהל wizard מרובה שלבים בסביבה המוגבלת הזו היה עקומת הלמידה האמיתית.

  3. הוכחת קונספט לדפוס: ברגע שאתם רואים ש-wizard מרובה שלבים עובד בצ'אט, אתם מתחילים לחשוב על flows אחרים: checklists של onboarding, workflows של אישורים, wizards של קונפיגורציה. ה-README Generator לא מיוחד כשלעצמו – הוא פשוט הוכחה קונקרטית שהדפוס הזה עובד, ועכשיו אני חושב מה עוד יכול להתאים כאן.

התובנה האמיתית: אתם לא בונים "אפליקציות צ'אט" בנפרד מאפליקציות ה-web שלכם. אתם בונים API אחד, ומציגים אותו במספר מקומות. זה ה-unlock.

איך זה בנוי: מבנה ו-Flow

הרשו לי להראות לכם איך החלקים מתחברים.

מבנה המערכת

README Generator System: Next.js App, MCP Apps Server, Supabase, ChatGPT/Claude

למה הארכיטקטורה הזו?

ההחלטה המרכזית הייתה להפריד את שרת ה-MCP מאפליקציית ה-Next.js. הנה החשיבה:

  1. שרת MCP (פורט 3001): זו שכבה דקה שעושה רק שני דברים:

    • חושפת כלי MCP (readme_start, readme_manager_step2, וכו') שה-AI יכול לקרוא להם
    • מגישה את ה-HTML של ה-widget שמרנדר בתוך ה-iframe של הצ'אט

    זה מינימלי בכוונה. בלי לוגיקה עסקית, בלי גישה למסד נתונים, בלי ניהול קונפיגורציה.

  2. אפליקציית Next.js (פורט 3000): כאן הכל בעצם נמצא:

    • ה-UI של האתר למשתמשים שרוצים ליצור READMEs באתר
    • ה-endpoint של /api/readme שגם טפסי האתר וגם ה-widget של MCP קוראים לו
    • כל הלוגיקה העסקית לוולידציה, יצירת README, אחסון

    שרת ה-MCP מעביר את כל העבודה האמיתית ל-API הזה.

  3. מקור אמת יחיד: Supabase שומרת את כל ה-READMEs. בין אם יצרתם אחד דרך web או צ'אט, זה הולך לאותו מסד נתונים עם אותה schema.

למה לא לשים הכל בשרת ה-MCP? כי אז הייתם מתחזקים שתי אפליקציות נפרדות. כל פעם שאתם מעדכנים לוגיקת ולידציה או מוסיפים שדה חדש, הייתם צריכים לעדכן את זה בשני מקומות. ככה, שרת ה-MCP הוא פשוט protocol adapter דק. כל המורכבות נשארת במקום אחד.

User Flow (מהצ'אט למסד הנתונים)

User flow: ChatGPT to MCP Server to Next.js API to DB

מעבר על ה-flow:

  1. התחלה: המשתמש כותב "Create my README" ב-ChatGPT/Claude. המודל מזהה שזה תואם לכלי readme_start וקורא לו.

  2. הזרקת widget: שרת ה-MCP מחזיר תגובה מיוחדת שמכילה את ה-HTML של ה-widget. ה-client של ה-AI מרנדר את זה ב-iframe בתוך בועת הצ'אט.

  3. התקדמות בשלבים: כשהמשתמש ממלא כל שלב ולוחץ Continue, ה-widget עושה קריאות חזרה לשרת ה-MCP (readme_manager_step2, readme_manager_step3, וכו'). כל קריאה כוללת את ה-form data מהשלב הזה.

  4. העברת API: שרת ה-MCP לא מעבד את המידע הזה בעצמו. הוא מעביר אותו ל-endpoint של /api/readme של אפליקציית ה-Next.js. זה אותו endpoint שגרסת ה-web משתמשת בו.

  5. שמירה והתמדה: כשהמשתמש משלים את כל השלבים ולוחץ Save, הכלי הסופי readme_save נקרא. המידע זורם דרך ל-Supabase.

  6. URL לשיתוף: ה-API מחזיר URL לשיתוף (למשל, yourapp.com/readme/abc123). זה מוצג בצ'אט.

הנקודה החשובה: שלבים 4-6 זהים בין אם המשתמש נמצא באתר או בצ'אט. שרת ה-MCP פשוט מתרגם בין פרוטוקול ה-MCP ל-HTTP API הקיים שלכם. בלי לוגיקה כפולה.

החזון הגדול יותר: Workflows מורכבים בצ'אט

העתיד הוא לא רק MCP Apps שאתם בונים – אלא גם MCP Apps שאתם משתמשים בהם. וכאן זה נהיה מעניין לצוותי פיתוח.

תרחיש ריאלי: אתם engineering manager שעושה תכנון שבועי. הנה איך ה-workflow הזה יכול להיראות עם MCP Apps:

  1. בדיקת תקלות on-call: "הצג לי תקלות production מהשבוע שעבר" → שרת ה-MCP של כלי ה-observability שלכם מחזיר widget של dashboard עם מספר תקלות, פירוט חומרה, מדדי MTTR.

  2. יצירת action items: אתם מזהים דפוס. "צור כרטיס tech debt לרפקטור של שירות ה-auth" → כלי ניהול הפרויקטים שלכם (Linear, Jira, וכו') פותח טופס ישירות בצ'אט. אתם ממלאים אותו, מקצים אותו, קובעים עדיפות.

  3. תזמון review: "הוסף 30 דקות של architecture review ליומן שלי ביום חמישי" → אפליקציית Calendar MCP יוצרת את האירוע, מציעה זמן על סמך הזמינות שלכם.

  4. עדכון הצוות: "שלח את זה לערוץ #backend בסלאק" → אפליקציית Slack MCP מפרסמת סיכום עם קישור לכרטיס.

כל זה קורה ב-thread שיחה אחד. בלי החלפת הקשר, בלי העתקת URLs בין טאבים, בלי "תן לי לפתוח את Jira רגע." הצ'אט הופך למרכז הפיקוד שלכם, וכל MCP App הוא כלי ממוקד שעושה דבר אחד טוב.

למפתחים בודדים, תארו לעצמכם debugging: "הצג לי את ה-logs של שירות X" → widget של observability מופיע → "צור כרטיס לשגיאה הזו" → טופס ניהול פרויקטים → "מתי בפעם האחרונה עשינו deploy לשירות הזה?" → היסטוריית deployments → "עשה rollback לגרסה הקודמת" → כלי deployment מאשר את ה-rollback.

הפרוטוקול מאפשר את זה כי כל כלי הוא עצמאי. צוות ה-observability בונה את שרת ה-MCP שלהם, צוות ה-deployment בונה את שלהם, והם מתחברים באופן טבעי בצ'אט שלכם בלי שאף אחד צריך לתאם נקודות אינטגרציה.

למה זה חשוב: כמנהל או מפתח, אתם כבר עושים context-switch בין 10+ כלים כל יום. MCP Apps לא מבטלים את הכלים האלה – הם מביאים אותם למקום שבו אתם כבר מנהלים שיחות על העבודה. הצ'אט שלכם הופך לשכבת האינטגרציה.

הנה דמו מלא של ה-README Generator:

דמו: MCP App Test Host עם README Generator - מילוי שלבים ויצירת README

בקרוב בבלוג – מה הבא:

  • איך חיברתי את האפליקציה ל-ChatGPT ואיך מחברים גם ל-Claude ודומיהם
  • איך עושים טסטים בסביבה מקומית לפני שמעלים לפלטפורמות הצ'אט
  • העלאה כאפליקציה לפרודקשן לשימוש ההמונים

מה ה-MCP App הראשון שהייתם בונים – או הראשון שהייתם רוצים להשתמש בו בתוך הצ'אט שלכם?

לעוד מוצרים וסדנאות מבית Lead By Nature

גלו את כל הסדנאות, הקורסים והליווי האישי שאני מציע למנהלים ולצוותי פיתוח

לעמוד הבית