שיטות מומלצות לשימוש ב-WebMCP

Alexandra Klepper

תאריך פרסום: 18 במאי 2026

ההצהרה על כלי WebMCP צריכה להיות ברורה, בלי שיהיה צורך שמפתחים או סוכנים יבדקו את התוצאות וינסו שוב. בין אם אתם משתמשים ב-Imperative API או ב-Declarative API, כדאי לפעול לפי השיטות המומלצות הבאות:

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

יצירת אסטרטגיית כלים

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

• כל כלי צריך לכלול פונקציה אחת. לדוגמה, כלי אחד יכול להפנות את המשתמש לסוג מסוים של טופס, וכלי אחר יכול להתאים שדות קלט למידע על המשתמש. חשוב להיזהר שלא ליצור כלים חופפים, כי הסוכן עלול להתבלבל ולא לדעת באיזה כלי להשתמש. כדאי לשאול את עצמכם: האם אפשר לבצע כמה משימות באמצעות אותה פונקציה?
• ניהול רישום כלי כדאי לרשום כלים כשהם שימושיים במצב מסוים של הדף, ואז לבטל את הרישום כשהכלי כבר לא שימושי.
  • ‫Imperative API: אתם יכולים לנהל את ההרשמה באופן דינמי באמצעות registerTool ו-unregisterTool.
  • ‫Declarative API: אתם יכולים לנהל את ההרשמה באופן דינמי על ידי הוספה או הסרה של מאפייני הכלי בטופס, באמצעות toolName ו-toolDescription.
• צמצום המורכבות: ברוב האפליקציות, הגישה שמומלצת כברירת מחדל היא רישום סטטי.
• הסוכן יוכל להשלים את המשימה*. במקום לכתוב הוראות נוקשות או שליליות, כדאי להניח שהנציג מסוגל להבין מה נדרש כדי להשלים את המשימה, ולא לצפות שהנציג ינהל רצף מדויק של שלבים.

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

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

שימוש בשפה ברורה ובקוד סמנטי

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

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

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

מזעור של מחשוב קוגניטיבי

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

• קבלת קלט גולמי של משתמשים. לא מומלץ לבקש מהסוכן לבצע חישובים או לשנות את מחרוזות הקלט. לדוגמה, אם משתמש אומר "11:00 עד 15:00", הכלי צריך לקבל את זה כמחרוזת. אל תבקשו מהמודל לחשב את מספר הדקות בין השעות האלה.
• הצהרה על סוגים ספציפיים של פרמטרים, כמו מחרוזת, מספר או enum.
• הסבר למה בחרת באפשרויות מסוימות הבחירה שביצעתם צריכה להיות ברורה. ההסבר עוזר לנציגים לקבל החלטות טובות יותר. לדוגמה, אם יש לכם חנות מסחר אלקטרוני, אתם יכולים להצהיר על סוג המשלוח בשפה טבעית במקום להשתמש במזהה לא ברור: shipping="Express" במקום shipping_id=1.

עדיפות לאמינות

סוכנים ואנשים נהנים מכלים שמתנהגים כמצופה:

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

בדיקה וניפוי באגים של הערכה

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

• הגדרת הבעיה. אפשר להגדיר את הבעיה כמו חוזה API, כולל סוג הקלט, פורמט הפלט ואילוצים נוספים.
• הגדרת בסיס ותוצאה אידיאלית. במיוחד כשמזינים טקסט, חשוב להבין אילו סוגי תוצאות יכולים להניב את הפלט שאתם מצפים לו.
• להחליט איך להעריך את הפלט. סביר להניח שאתם מזהים ומודדים תוצאות סובייקטיביות ואיכותיות על סמך איכות הקלט, התועלת והיכולת לבצע את המשימה הבאה. יש מספר טכניקות שניתן להשתמש בהן כדי להעריך את הפלט, כולל בדיקות מבוססות-קוד לפלטים מבוססי-כללים (מגבלות תווים) וLLM-as-a-judge.

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

אינטראקציה ושיתוף משוב

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

• לקרוא את ההסבר על WebMCP, לשאול שאלות ולהשתתף בדיון.
• אפשר לבדוק את ההטמעה ב-Chrome בסטטוס של Chrome.
• הצטרפות לתוכנית הגישה המוקדמת כדי לקבל הצצה מוקדמת לממשקי API חדשים וגישה לרשימת התפוצה שלנו.
• אם יש לכם משוב על ההטמעה של Chrome, אתם יכולים לדווח על באג ב-Chromium.