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

Alexandra Klepper

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

סרטון הסבר	פיתוח אתרים	תוספים	הסטטוס של Chrome	הרציונל
GitHub	גרסת מקור לניסיון		תצוגה	הבעת עניין בהשתתפות בניסוי

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

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

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

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

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

• כל כלי צריך לכלול פונקציה אחת. לדוגמה, כלי אחד יכול להפנות את המשתמש לסוג טופס מסוים, וכלי אחר יכול להתאים שדות קלט למידע על המשתמש. חשוב להיזהר ולא ליצור כלים חופפים, כי הסוכן עלול להתבלבל ולא לדעת באיזה כלי להשתמש. כדאי לשאול את עצמכם: האם אפשר לבצע כמה משימות באמצעות אותה פונקציה?
• ניהול רישום כלי. כדאי לרשום כלים כשהם שימושיים במצב מסוים של הדף, ואז לבטל את הרישום כשהכלי כבר לא שימושי.
  • ‫Imperative API: אתם יכולים לנהל את ההרשמה באופן דינמי באמצעות registerTool.
  • ‫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.