MCP, WebMCP ו-A2A: כשסוכן AI לא רק קורא את האתר, אלא מפעיל אותו

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

זה גם החלק שבו הציון של קלאודפלייר עובר מ-80 ל-100. בנינו אותו באתר שלנו באותו לילה, ונספר בדיוק מה זה כלל ומה זה לא.

מה תלמדו מהפוסט הזה

• מה זה MCP, למה קוראים לו “USB-C של ה-AI”, ומה זה “כרטיס שרת”
• מה ההבדל בין MCP, WebMCP ו-A2A, בטבלה אחת
• מה סוכן יכול לעשות בפועל באתר של קוסמטיקאית, של משרד עורכי דין, של חנות
• מה זה OAuth, מה בנינו ממנו בפועל, ומה ההבדל בין “הרשאות” לבין “זהות” לסוכן
• מה אנחנו מתכננים לבנות, ומה זה יכול לתת ללקוחות שלנו

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

המונח הראשון: MCP

MCP הוא ראשי תיבות של Model Context Protocol. אנתרופיק (החברה שמאחורי Claude) פרסמה אותו כתקן פתוח בנובמבר 2024, ובתוך שנה אימצו אותו OpenAI, גוגל, מיקרוסופט ורוב הכלים בתחום. היום הוא הדרך המקובלת שבה סוכן AI מדבר עם שירות חיצוני.

הבעיה שהוא פותר: לפני MCP, כל שירות שרצה ש-AI יוכל להשתמש בו היה צריך להמציא דרך משלו. חיבור ליומן גוגל בדרך אחת, ל-CRM בדרך אחרת, למערכת המלאי בדרך שלישית. כמו מגירה של כבלי טעינה, כל אחד למכשיר אחר.

MCP אומר: יש שקע אחד. השירות מפרסם “הנה הכלים שלי” בפורמט אחיד: שם הכלי, מה הוא עושה, אילו פרטים הוא צריך לקבל. הסוכן קורא את הרשימה ויודע להפעיל כל כלי בלי שמישהו כתב לו קוד מיוחד. לכן הדימוי שחוזר בכל מקום: ה-USB-C של ה-AI.

דוגמה קונקרטית. נניח שלקליניקה יש שרת MCP עם שני כלים:

• check_availability - מקבל תאריך וסוג טיפול, מחזיר שעות פנויות
• book_appointment - מקבל שעה, שם וטלפון, קובע תור

לקוחה אומרת לסוכן שלה: “תקבעי לי טיפול פנים ביום חמישי אחר הצהריים”. הסוכן מגלה את השרת, מפעיל את הכלי הראשון, מקבל רשימת שעות, בוחר (או שואל אותה), מפעיל את השני. הקליניקה קיבלה תור. אף אחד לא דיבר בטלפון ואף אחד לא מילא טופס.

כרטיס שרת MCP

איך הסוכן מגלה שיש שרת כזה? דרך כרטיס שרת (MCP Server Card): קובץ JSON קטן בכתובת /.well-known/mcp/server-card.json. הוא אומר: “יש כאן שרת MCP, הנה הכתובת שלו, הנה הכלים, ככה מזדהים”. זה כרטיס ביקור.

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

המונח השני: WebMCP

WebMCP הוא אח צעיר ושונה. במקום שרת מחוץ לדף, זה קוד בתוך הדף. כמה שורות JavaScript שרצות כשהעמוד נטען ואומרות לדפדפן: “הנה פעולות שאפשר לעשות כאן”. התקן מקודם על ידי גוגל ומיקרוסופט במסגרת W3C, וזמין ב-Chrome בתצוגה מקדימה למפתחים.

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

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

ההבדל בעלות עצום: WebMCP הוא שעה של עבודה. שרת MCP הוא פרויקט.

המונח השלישי: A2A

A2A (Agent-to-Agent) הוא פרוטוקול שגוגל פרסמה באפריל 2025 והעבירה לקרן הלינוקס. הרעיון: סוכן מדבר עם סוכן, ולא עם אתר. הסוכן של הלקוח פונה לסוכן של העסק, מציג משימה, והשניים מנהלים משא ומתן.

הביטוי באתר: כרטיס סוכן (Agent Card) בכתובת /.well-known/agent-card.json, שמציג את העסק כסוכן: מה הוא יודע לעשות, איך פונים אליו, איך מזדהים. כמו כרטיס ה-MCP, גם הוא דורש שרת חי מאחוריו.

בפועל, היום, MCP ו-A2A חופפים בהרבה. אותו שרת יכול להציג שני “פנים”: כלים ב-MCP, ויכולות ב-A2A. מי שבונה אחד יכול להוסיף את השני בעלות קטנה.

המונח הרביעי: OAuth, ומה בנינו ממנו

OAuth הוא התקן שבו אתם “מתחברים עם גוגל” לאתר זר. בעולם הסוכנים, הוא אומר: “כדי לגשת למידע מוגן (ההזמנות של הלקוח, החשבון שלו), הסוכן צריך לבקש הרשאה, וזה איפה שמבקשים”. שני קבצים ב-.well-known מכריזים על זה, ושניהם נספרים בציון.

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

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

• רישום אנונימי (תקן RFC 7591): סוכן שולח בקשה אחת ומקבל מזהה וסוד. בלי אישור אנושי, בלי מייל, בלי חשבון, בלי גישה לשום נתון של אף אחד.
• החלפה לטוקן: עם המזהה והסוד הסוכן מקבל טוקן חתום שתקף ל-15 דקות. המפתח הציבורי לאימות החתימה מפורסם בכתובת ידועה (jwks.json), כך שכל אחד יכול לוודא שהטוקן באמת שלנו.
• שימוש: הסוכן מצרף את הטוקן לקריאות ל-MCP. אצלנו זה רשות ולא חובה, כי הכלים ממילא ציבוריים וקוראים בלבד. הטוקן הוא כרטיס ביקור מנומס, לא שער.

מה זה נותן לנו בפועל: אם מחר נרצה כלי שכן דורש זהות (למשל “בדוק סטטוס של הצעת מחיר”), התשתית קיימת. ומה זה לא: זו לא מערכת משתמשים, אין בה בני אדם, ואין בה סיסמאות של אף אחד. הכלל שלנו ללקוחות נשאר: OAuth מלא, עם התחברות של בני אדם, בונים רק כשיש חשבונות אמיתיים להגן עליהם. את הגרסה האנונימית אפשר לתת לכל אתר, כי היא לא פותחת שום דלת שלא הייתה פתוחה.

מה סוכן יכול לעשות בפועל, לפי סוג עסק

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

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

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

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

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

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

מה אנחנו מתכננים

נהיה שקופים, כי זו הסדרה שבה הבטחנו לא למכור באזוורדים.

מה כבר חי אצלנו: כל שלוש המדרגות. שרת MCP בכתובת primestack.co.il/mcp עם שלושה כלים (חיפוש באתר, קריאת עמוד כ-markdown, רשימת השירותים ואיפה המחירים שלהם), כרטיס MCP וכרטיס A2A שמצביעים עליו, רישום אנונימי וטוקנים כמו שתואר למעלה, וקובץ auth.md שמסביר את כל זה לסוכן. רמה 5 בסורק (Agent-Native), 14 מתוך 15 בדיקות. הבדיקה האחרונה, DNS-AID, דורשת חתימת DNSSEC על הדומיין, ואת זה עושים אצל רשם הדומיינים.

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

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

ומה שמתחיל קודם: בדיקת Agent Readiness נכנסת לדוח הבריאות הדיגיטלי שלנו, לצד מהירות, SEO ונראות ב-AI. כי לפני שבונים שרת למישהו, כדאי שהוא יראה איפה הוא עומד היום. רוב הסיכויים: רמה 1, כמו שהיינו.

מה זה לא (תזכורת אחרונה)

• ציון 100 בסורק לא אומר שלקוחות יגיעו דרך סוכנים. הוא אומר שכשיגיעו, הדלת פתוחה.
• שרת MCP לא מחליף אתר טוב, תוכן טוב או שאלות ותשובות מסודרות. הוא בנוי עליהם.
• כל התקנים כאן צעירים. MCP יציב יחסית; WebMCP ו-A2A עדיין משתנים. מי שבונה היום צריך להיות מוכן לעדכן.

מונחון

• MCP - Model Context Protocol. תקן אחיד לסוכן להפעיל כלים של שירות.
• כרטיס שרת (Server Card) - קובץ JSON ב-.well-known שמכריז על שרת MCP.
• WebMCP - פעולות שמוגדרות בתוך דף, לסוכן שגולש בדפדפן.
• A2A - Agent-to-Agent. פרוטוקול של גוגל לדיבור בין סוכנים.
• כרטיס סוכן (Agent Card) - קובץ JSON שמציג עסק כסוכן A2A.
• OAuth - תקן הרשאות: איך סוכן מבקש גישה למידע מוגן.
• כלי (Tool) - פעולה אחת שסוכן יכול להפעיל: שם, תיאור, ומה צריך לתת לה.

לסיכום

הסדרה הזאת התחילה ב-20 מתוך 100 ומספר שלא הבנו. היא נגמרת בהבנה פשוטה: סוכן AI צריך שלושה דברים מאתר. לדעת מה מותר לו, לקרוא בקלות, ולדעת מה הוא יכול להפעיל. את שני הראשונים כל אתר יכול לתת ביום עבודה. את השלישי כדאי לתת רק כשיש באמת מה להפעיל, ואז זה לא “ציון” אלא ערוץ מכירה.

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

אפילוג: הגענו ל-100

כתבנו את כל הסדרה הזאת בזמן שהבדיקה האחרונה עדיין תלויה: רשומת ה-DNSSEC שסוגרת את בדיקת ה-DNS-AID הייתה צריכה להתפרסם אצל רשם הדומיין, ותהליך כזה יכול לקחת בין כמה שעות ליממה. היא התפרסמה, ומריצה נוספת של הבדיקה נותנת ציון 100 מתוך 100, רמה 5 מתוך 5, Agent-Native.

זה לא שינה שום דבר בקוד. זה בדיוק הנקודה שחזרה בכל שלושת הפוסטים: 93 מתוך 100 היה כבר תשובה כנה ומלאה לכל שאלה שסוכן AI שואל אתר. ה-100 הגיע מרשומת DNS אחת שממתינה לרשם, לא מעבודה נוספת.

אם קראתם עד לכאן ורוצים לדעת איפה האתר שלכם עומד היום, לא רק ב-Agent Readiness אלא במהירות, ב-SEO ובנראות ב-AI, זה בדיוק מה שדוח הבריאות הדיגיטלי שלנו נותן: תמונת מצב אמיתית, במחיר של 99 ש”ח. אפשר לרכוש אחד בעמוד דוח הבריאות.