המדריך לאפליקציות מקושרות בגוגל (Connected Apps)

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

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

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

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

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

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

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

מה זמין כרגע בחיפוש וב-Gemini

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

ב-Gemini הזמינות משתנה בין אפליקציות, מדינות, שפות ומכשירים. כך זה נראה ברשימת האפליקציות של Gemini: Google: אפליקציות מקושרות ותנאי הזמינות שלהן ב-Gemini

• Instacart ו-Zocdoc מוגבלות לארה״ב.
• Canva ו-Wix מוגדרות לכל המדינות שבהן Gemini והאפליקציה נתמכות, אבל רק באנגלית, צרפתית, הינדית, אינדונזית ופורטוגזית. עברית לא ביניהן.

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

מי שעובד מישראל יכול כבר עכשיו להצטרף לרשימה ולהכין את שרת ה-MCP לפי הדרישות של גוגל. אם לחשבון יש גישה ל-Gemini Developer Mode, אפשר גם לבדוק שם את הכלים.

איך משתמשים באפליקציה מקושרת בחיפוש

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

1. לפתוח את מצב AI בחיפוש. להיכנס לחיפוש גוגל עם חשבון Google ולבחור במצב AI.
2. לבקש פעולה. אפשר לציין שם של אפליקציה או לתאר צורך ולבחור שירות מרשימת האפשרויות הזמינות, אם היא מוצגת.
3. לקשר חשבון כשנדרש. אם צריך לקשר חשבון לשירות והקישור עדיין לא בוצע, גוגל עשויה להציע אפשרות לקישור. כדאי לבדוק איזו גישה מבוקשת לפני אישור הקישור.
4. להשלים את המשימה. חלק מהתוצאה יכול להופיע בחיפוש, ובחלק מהמקרים ממשיכים לשירות עצמו, למשל כדי לשלם.

גם ב-Gemini אפשר להשתמש באפליקציות מקושרות. לפני בדיקה כדאי לבדוק ברשימה של גוגל את המדינה, השפה והמכשיר של האפליקציה הרלוונטית.

מה זה יכול לשנות לאתר של המוצר?

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

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

בקניות במצב AI יש גם מסלול נפרד מאפליקציות מקושרות, שבו חנויות מתאימות בארה״ב מאפשרות תשלום בתוך גוגל. לא כל בקשה או רכישה מסתיימת באותו מקום. Google: קניות ותשלום במצב AI בחיפוש גוגל

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

למפתחים: האם אפשר להשתמש בשרת MCP שכבר קיים?

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

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

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

• כתובת HTTPS ציבורית, כדי שגוגל תוכל להגיע לשרת.
• שימוש ב-Streamable HTTP, שיטת התקשורת שגוגל דורשת במסלול הזה.
• גרסת פרוטוקול נתמכת, ולכן שרת ישן עלול לדרוש עדכון.

צריך גם לוודא שלגוגל יש גישה לשרת ולבדוק איזה סוג הרשאה מתאים לשירות.

החיבור דרך שרת MCP שונה מ-WebMCP, שבו אתר מציע כלים דרך הדפדפן. כתבתי על המסלול הזה במדריך ל-WebMCP. בחיבור של Connected Apps, שרת ה-MCP של השירות מאפשר לגוגל לבקש את הפעולות שהשרת מציע.

יש גם מסלול Android MCP לפעולות בתוך אפליקציה במכשיר Android. הוא מיועד לחוויות Gemini ב-Android, ולכן לא כדאי להניח שהוא מחבר את אותה פעולה גם לחיפוש.

איך מקבלים גישה: מה שואל הטופס של רשימת ההמתנה

הדרך פנימה עוברת בטופס להבעת עניין. עברתי עליו עם חשבון Google שלי, בלי לשלוח אותו. השאלה הראשונה היא אם יש לכם חשבון מפתחים ב-Google Play. google.com: הבעת עניין בפלטפורמת האפליקציות המקושרות

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

לכן כדאי להכין את התשובות האלה מראש:

• שם הארגון או האפליקציה, גודל החברה ומספר המשתמשים היומיים
• מדינת המוצא של החברה, אזורי הפעילות וקטגוריית האפליקציה
• היכולות ותהליכי המשתמש שהאפליקציה מאפשרת
• מסלול החיבור (Server-Side MCP או Android MCP) והמוצר המבוקש (חיפוש או Gemini)
• כתובת שרת ה-MCP, או N/A אם הוא עדיין לא מוכן, והאם הוא ציבורי או פרטי
• הגישה לממשק (MCP בלבד או MCP App עם iframes)
• מועד היעד לזמינות, והאם כבר יש MCP פעיל בפלטפורמות LLM אחרות
• פרטי אבטחה ופרטיות, כמו הרשאות קריאה וכתיבה, OAuth 2.1 ומדיניות פרטיות מפורסמת

בלי גישה, הקונסולה סגורה. כשפתחתי את Connected Console בחשבון שלי, שאין לו גישה, קיבלתי עמוד 404.

איך מכינים שירות לרישום ב-Connected Console

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

Connected Console הוא המקום שבו מפתחים רושמים אפליקציה מקושרת ומגישים אותה לבדיקה. לפני הרישום צריך:

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

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

השלבים הבאים מתייחסים לחיבור של שרת MCP מרוחק. במסלול Android יש שלבי הגדרה אחרים.

1. להכין שרת וחיבור. יחד עם צוות הפיתוח, כדאי לבדוק את הכתובת, הפרוטוקול והרשאות הגישה מול רשימת הדרישות של גוגל. אם השרת מוגבל לפי כתובות IP, צריך לבדוק גם אילו בקשות גוגל יכולה לשלוח אליו.
2. ליצור אפליקציה ולבחור מסלול. כשהגישה זמינה, אפשר ליצור אפליקציה ב-Connected Console ולבחור קטגוריה וסוג חיבור. את הבחירות האלה אי אפשר לשנות אחר כך באותה אפליקציה.
3. לאמת את הדומיין של שרת MCP. אם הדומיין כבר אומת בחשבון, הוא עשוי להופיע כמאומת. אחרת, במסך הגדרת השרת ב-Connected Console יש להזין את כתובת ה-HTTPS המלאה של השרת ולהוריד את קובץ האימות. הצוות שמנהל את השרת צריך לדאוג שתוכן הקובץ יהיה זמין בכתובת https://<your-domain>/.well-known/google-connected-apps, כש-your-domain הוא הדומיין האמיתי של השרת. הכתובת צריכה להיות נגישה לציבור ולהחזיר קוד 200 ללא הפניה. לאחר מכן אפשר לחזור ל-Connected Console ולבחור באימות הדומיין.
4. להגדיר את ההרשאות. אחרי האימות, יש לבחור את אופן הגישה שמתאים לשרת.
5. להכין את פרטי האפליקציה. גוגל מבקשת שם ותיאור של עד 30 מילים, סמל בגודל 512 על 512 פיקסלים, לפחות שלוש יכולות ושלוש בקשות לדוגמה, וגם קישורים לתנאי השימוש ולמדיניות הפרטיות.
6. לבדוק ולהגיש. אפשר להמשיך לפי הוראות הרישום והבדיקה, ואז להגיש לסקירה.

בלי גישה ל-Connected Console אי אפשר להשלים את הרישום במסלול הזה. אפשר עדיין לבדוק את הדרישות ולהכין שרת לבדיקה. בחלק מהחשבונות אפשר לבדוק שרת דרך Gemini Developer Mode, כפי שאסביר בהמשך.

מה לכתוב בתיאור האפליקציה ובהוראות לכלים

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

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

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

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

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

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

איך לבדוק את הכלים לפני הגשה

Gemini Developer Mode הוא סביבת בדיקה לשרת MCP בתוך Gemini. הוא מאפשר למפתחים לבדוק אילו כלים זמינים, לזהות שגיאות בקריאות ולבדוק הרשאה. בדיקה שם אינה מוכיחה שהאפליקציה כבר זמינה בחיפוש או מופיעה לכל משתמש.

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

השלבים מבוססים על התיעוד, ולא הרצתי אותם על שרת אמיתי. אם יש לצוות גישה למצב המפתחים ושרת HTTPS מתאים, אפשר להתחיל בהוראות הבדיקה של גוגל: Google: בדיקת שרת MCP במצב מפתחים של Gemini

1. לפתוח את סביבת המפתחים. להיכנס ל-Gemini בדפדפן ולבחור ב-Gemini Apps Developer Mode דרך Settings, או להשתמש בקישור שבהוראות של גוגל.
2. להזין את כתובת השרת. בחלון בחירת האפליקציה, לבחור + Create new ולהזין ב-MCP Server URL את כתובת ה-HTTPS הציבורית של השרת. אם נדרשים פרטי OAuth שנרשמו מראש, להזין אותם ב-Additional settings ולבחור Next.
3. לבדוק את הרשאות החיבור. לקרוא את חלון הפרטיות והאבטחה ולוודא שהשרת מהימן. אם מסכימים לתנאים, לסמן את אישור הסיכונים ולבחור Connect.
4. לשמור את אפליקציית הבדיקה. לתת לאפליקציה שם ולבדוק שהכלים מופיעים ב-Available actions. לאחר מכן לבחור שוב Connect ולפתוח את לשונית Tool schemas לבדיקת הגדרות הכלים.
5. לבקש פעולה ולבדוק מה קרה. לבקש משימה שהשירות יודע לבצע ולבדוק ב-Event Log איזו קריאה בוצעה ומה חזר. כדאי לבדוק גם בקשה שלא מתאימה לשירות, ולבדוק אם המערכת נמנעה מקריאה לא מתאימה.

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

איך לבדוק אם האפליקציה נמצאת כשלקוח צריך אותה

אחרי שהאפליקציה זמינה לבדיקה במוצר ובחשבון המתאימים, כדאי להכין כמה בקשות סביב משימה אחת אמיתית. בחיפוש זה אומר כרגע ארה״ב ואנגלית, ולכן גם הדוגמאות כאן באנגלית. למשל, אם InsureApp היא אפליקציה זמינה להצעות מחיר לביטוח, אפשר לבדוק את הבקשות „Get a car insurance quote from InsureApp” ו-„How much would car insurance cost for a 2022 Toyota Corolla?”.

InsureApp הוא שם לדוגמה. צריך להחליף אותו בשם האפליקציה ולבקש פעולה שהיא באמת מציעה.

1. לבדוק לפי שם. לכתוב את שם השירות בבקשה או לתייג אותו באמצעות @, אם האפשרות זמינה. לרשום אם השירות הופיע ואם אפשר היה להמשיך איתו.
2. לבדוק לפי צורך. לתאר את הביטוח המבוקש בלי להזכיר את שם השירות. לרשום אילו אפשרויות הוצגו והאם השירות הרלוונטי היה ביניהן.
3. לבדוק את הפעולה. אם השירות הוצג וחובר, לבקש פעולה שהוא באמת מציע ולבדוק אם התקבלה תוצאה. כדאי לרשום בנפרד אם האפליקציה הוצעה, אם הופיע פלט מהכלי ואם הפעולה עצמה הושלמה.
4. לשמור את תנאי הבדיקה. לרשום את התאריך, המוצר של גוגל, החשבון, המדינה, השפה והבקשה המדויקת. אחרי שינוי אפשר לחזור לאותן בקשות ולהשוות את מה שנראה בפועל.

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

מה כדאי לבדוק אחרי שהחיבור עולה לאוויר

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

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

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

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

יש כבר דוגמה לכך ב-Gemini. Zocdoc מסבירה למרפאות שספקים הרשומים אצלה יכולים להיות זמינים להזמנה דרך החיבור שלה, כשיש להם תורים פנויים. Zocdoc גובה על הזמנה כזאת את דמי ההזמנה הרגילים שלה, כי הדמים אצלה תלויים בדרך שבה המטופל מצא את הרופא. zocdoc.com: איך מרפאות ב-Zocdoc זמינות להזמנה דרך Gemini

שימוש אייג’נטי יצמצם את הצורך להגיע לאתר

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

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

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

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

בהצלחה.