MCP הוא חוזה, לא קסם

דרך מעשית לראות את הרעיון

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

צלילה טכנית: עקבו אחרי המערכת, לא אחרי הסיסמה

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

מעבדת קוד: מעטפת נצפית

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

ALLOWED_TOOLS = {"weather.read", "calendar.find_free"}

def authorize(call, user_grant):
    if call["tool"] not in ALLOWED_TOOLS:
        return False, "tool not allowed"
    if call["tool"] not in user_grant:
        return False, "missing user grant"
    if call.get("writes_data"):
        return False, "proposal only"
    return True, "scoped read"

מבחן בעולם האמיתי

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

הניתוח של ג׳ק

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

מה הדוגמה אינה מוכיחה

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

שאלות שכדאי לשאול בבדיקה

• איזו טענה נתמכת בדיוק במקור?
• היכן עלול להיכנס הקשר מיושן או עוין?
• איזה שלב יקר או קשה לביטול?
• אילו ראיות נשמרות לביקורת?
• מי יכול לעצור את הפעולה וכמה מהר?