מפתחים המשתמשים במודלי שפה גדולים (LLMs) מקומיים מגלים ששרת Multi-Channel-Protocol (MCP) בודד יכול לצרוך את כל חלון ההקשר (context window) עוד לפני שהמשתמש הקליד הנחיה (prompt) כלשהי. הם נאלצים לבחור בין תיאורי כלים מוגבלים לבין זרימת שיחה משובשת.

למה ניפוח טוקנים (token bloat) משנה עבור LLMs מקומיים

MCP מאפשר ל-LLM לקרוא לכלים חיצוניים — APIs, סקריפטים או כלי מערכת קבצים — על ידי הזנת תיאור של כל כלי למודל. מודלים המאוחסנים בענן עם חלונות של 128k טוקנים יכולים להכיל הגדרות רבות של כלים ועדיין להשאיר מקום לדיאלוג עם המשתמש. מודל של 7 מיליארד פרמטרים הרץ באופן מקומי עם חלון של 8k טוקנים נגמר לו המקום לאחר טעינת מספר קטן של כלים בלבד. הטרייד-אוף (trade-off) הוא בולט: תיאורים קצרים וזולים גורמים לניתוב שגוי של קריאות; תיאורים ארוכים ומפורטים צורכים את התקציב הדרוש לצ'אט.

שרשרת האירועים שהובילה לכך

MCP נבנה כדי להחליף קוד אינטגרציה מותאם אישית בממשק יחיד מונחה-מודל למקורות נתונים רבים. רוב שרתי ה-MCP פועלים כמעטפת (wrapper) דקה סביב נקודות קצה (endpoints) של REST המיועדות למפעילים אנושיים, לא למכונות. כאשר המעטפות הללו נכנסות לסשן של LLM מקומי, המודל חייב לקרוא את השם, הפרמטרים והערות השימוש של כל כלי לפני שיוכל להחליט באיזה מהם להשתמש. חלונות הקשר קטנים הופכים את "עומס התיאור" (description overhead) הזה לצוואר בקבוק מבני.

מי מרוויח ומי מפסיד

  • מפתחים הבונים עוזרים המופעלים על המכשיר (on-device assistants) מפסידים גמישות. הם נאלצים או לצמצם את קטלוג הכלים, מה שמסכן כשלים תכופים, או לקבל פרומפט מנופח שחותך את קלט המשתמש.
  • משתמשי קצה חווים התנהגות לא יציבה כאשר העוזר בוחר בכלי הלא נכון או מסרב לפעול כי ההקשר מלא.
  • ספקי כלים מרוויחים נקודת כניסה אחידה.

המחיר אינו רק חוויה דלה יותר; הוא מעלה חששות אבטחה. כאשר סוכן MCP יכול לקרוא כל קובץ מקומי, מודל ההרשאות קורס לשיטת "הכל או כלום". ללא סנדבוקס (sandbox), כלי שאינו מוגדר כהלכה עלול לחשוף את כל מערכת הקבצים.

מה מפתחים עושים בנידון

שלושה פתרונות מעקף שולטים בקהילה:

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

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

סיכוני אבטחה הנובעים מבעיית הטוקנים

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

עיצוב כלים למודלים קטנים

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

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

נקודת מבט נגדית: לפרוטוקול עדיין יש ערך

למרות החיכוך, MCP נותר אטרקטיבי מכיוון שהוא מבצע הפשטה (abstracts away) של קוד boilerplate. ממשק יחיד מונחה-מודל יכול להתחבר לעשרות שירותים מבלי לכתוב מתאמים (adapters) מותאמים אישית לכל אחד. צוותים שיכולים להרשות לעצמם מודלים בקנה מידה של ענן רואים בניפוח הטוקנים בעיה שאינה קיימת, והנוחות עולה על עומס התיאור. האתגר הוא לתרגם את הנוחות הזו לעולם המוגבל של LLMs המופעלים על המכשיר.

שורה תחתונה

אם אתם בונים עוזר המופעל על המכשיר (on-device assistant), התייחסו לתיאורי כלי MCP כמשאב מוגבל. צמצמו, טענו באופן דינמי, ותכננו כלים בעלי היקף מוגדר כדי לשמור על חלון ההקשר (context window) פנוי עבור השיחה עצמה. במקביל, הגנו מפני מודל אבטחה משתמע של "גישה מלאה" על ידי הוספת שכבת הרשאות, גם אם זה עולה בכמה טוקנים נוספים. האיזון שתשיגו יקבע אם ה-LLM המקומי שלכם ירגיש כמו בן לוויה מועיל או כמו צ'אטבוט תקול.