טעינה עצלה (Lazy Loading) של כלי MCP: מי תומך בזה ואיך
רוב האנשים חושבים שעלויות שרת ה-MCP נמצאות בקוד. הם טועים.
אם אתם בונים שרת MCP, אתם מתמודדים עם שני סוגים של עלויות טוקנים:
- עלות קבועה: הגדרות כלים (Tool definitions) שנטענות לתוך ההקשר (context) בכל תור.
- עלות משתנה: גודל התגובה שכלים מחזירים.
אתם שולטים בעלות המשתנה. אתם יכולים לבצע דפדוף (pagination) לתוצאות או להגביל את גודל הפלט.
אתם לא שולטים בעלות הקבועה. זוהי עבודתו של המארח (the host/client).
אם יש לכם עשרה שרתים עם כלים רבים, אתם עלולים לבזבז 40,000 טוקנים עוד לפני שהמודל בכלל קורא את ההודעה הראשונה שלכם. זה קורה מכיוון שהמארח טוען את כל הגדרות הכלים מראש.
הפתרון הוא טעינה עצלה (lazy loading). המשמעות היא שהמארח טוען רק כלי חיפוש קטן ומושך הגדרות אחרות רק כשצריך.
הבעיה? רוב הלקוחות (clients) עדיין לא תומכים בזה.
סטטוס נוכחי של טעינה עצלה:
- Claude Code: תומך בזה. כלים נטענים לפי דרישה באמצעות כלי חיפוש.
- Cursor, Devin ואחרים: הם לא תומכים בזה. הם טוענים הכל בבת אחת.
אם ההקשר (context) שלכם מתנפח בלקוח שחסר בו מנגנון טעינה עצלה, יש לכם שתי אפשרויות:
שימוש ב-lazy proxy הפנו את המארח שלכם לשרת פרוקסי במקום לשרתים האמיתיים שלכם. הפרוקסי חושף רק שני כלים: search_tools ו-execute_tool. הוא טוען את ההגדרות האמיתיות שלכם רק כשמבקשים אותן. זה מצמצם את ההקשר שלכם אך מסיר שליטה מדויקת בהרשאות.
שימוש בתבנית router אם שרת אחד הופך לגדול מדי, אל תוסיפו עוד כלים. במקום זאת, צרו כלי אחד עם פרמטר פעולה (operation parameter). לדוגמה, השתמשו בכלי "docs" אחד עם פקודות כמו "list", "get" או "search". זה מפחית את מספר הסכמות (schemas) שהמארח חייב לטעון.
סיכום האסטרטגיה:
- 6 עד 15 כלים: אל תעשו כלום. העלות נמוכה מדי מכדי לדאוג.
- הרבה כלים בשרת אחד: השתמשו בתבנית router.
- הרבה שרתים שונים: השתמשו ב-lazy proxy.
בדקו את התנהגות הלקוח שלכם