פרוטוקול ה-Model Context (MCP) הפך זה עתה ל-stateless, ושינוי זה מאפשר למפתחים להקים שרתי MCP זעירים במסלול החינמי של Cloudflare Workers — בתנאי שכל בקשה נשארת מתחת למגבלת ה-10 מילי-שניות (ms) של ה-CPU בפלטפורמה.

למה השינוי הזה חשוב

שני מהלכים אחרונים פתחו את הדלת. ראשית, ליבת ה-MCP זנחה את העיצוב מבוסס ה-session וכעת היא פועלת ללא handshakes; כל בקשה יכולה להיות מטופלת על ידי כל מופע (instance) של הקוד. שנית, Cloudflare ביטלה את מחלקת ה-McpAgent וכעת ממליצה על request handlers פשוטים עבור שרתים חדשים. יחד, הם מבטלים את הצורך ב-Durable Objects או באחסון stateful אחר, שהיו החסמים העיקריים להרצת MCP במסלול החינמי.

מה המסלול החינמי יכול לעשות בפועל

בנינו שרת MCP לקריאה בלבד המגיש קבצי Markdown מאתר סטטי. השרת מממש שני כלים—list_articles ו-get_article—תוך שימוש ב-switch statement פשוט לניתוב המתודות. ללא חישובים כבדים, רק שליפת נכסים (assets) סטטיים.

חישוב ה-CPU של Cloudflare שונה מזמן התגובה הכולל. זמן ה-CPU סופר רק את המחזורים (cycles) שהושקעו בהרצת ה-JavaScript שלכם; זמן המוקדש להמתנה לקריאות רשת או לקריאות דיסק אינו נכלל. ההבחנה הזו חשובה מכיוון שהמסלול החינמי מגביל את ה-CPU ל-10 מילי-שניות לכל בקשה, בעוד שזמן השיהוי (latency) הכולל יכול להיות גבוה יותר.

המדדים שלנו במסלול החינמי נראו כך:

  • server/discover: 0-1 מילי-שניות CPU
  • tools/list: 0 מילי-שניות CPU
  • get_article (הקובץ הגדול ביותר): 1-2 מילי-שניות CPU

אפילו המאמר הגדול ביותר השתמש רק בחלק קטן מתקציב ה-10 מילי-שניות. ההאטה הניכרת בצד הלקוח נבעה מהמתנה לקריאת הקובץ, ולא מהרצת הקוד.

איפה המגבלה מכה

הנתונים מצביעים על דפוס ברור:

  • כלים להגשת נתונים (קריאות פשוטות, רשימות) נשארים בנוחות מתחת למגבלה.
  • כלים עתירי חישוב (parsing, rendering, hashing, או כל עבודה אלגוריתמית) עלולים להכריע במהירות את תקציב ה-10 מילי-שניות.

אם כלי זקוק ליותר מעיבוד בסיסי, מפתחים יצטרכו לעבור למסלול Workers בתשלום. המסלול ב-$5 מעלה את המגבלה ל-30 שניות לכל בקשה.

מי מרוויח, ומי צריכה לשים לב לשעון

אתרים קטנים שכבר מארחים קבצי Markdown או RSS feed יכולים לחשוף endpoint של MCP באמצעות נתיב (route) חדש אחד ולהישאר במסלול החינמי. המשמעות היא עלויות תפעול נמוכות יותר ופחות חלקים נעים עבור חובבים, אתרי תיעוד או בלוגים עם תעבורה נמוכה.

אם כלי זקוק ליותר מעיבוד בסיסי, מפתחים יצטרכו לעבור למסלול Workers בתשלום.

מה לבדוק לפני ההשקה

  • בצעו profiling לכלי שלכם: הריצו מספר בקשות מייצגות ובדקו את מד ה-CPU בלוח הבקרה (dashboard) של Cloudflare.
  • הפרידו בין נתיבים סטטיים לדינמיים: שמרו על הגשת קבצים סטטיים במסלול החינמי, ונתבו קריאות עתירות חישוב ל-worker בתשלום או ל-backend אחר.
  • שימו לב לשיהוי (latency) נסתר: המתנה לרשת אינה נספרת כחלק מה-CPU, אך היא עדיין משפיעה על חווית המשתמש. שקלו שימוש ב-edge caching עבור הקבצים שאתם מגישים.

נקודת מבט נגדית: המסלול החינמי אינו חסר גבולות

בעוד שהליבה ה-stateless מסירה את הצורך ב-Durable Objects, מגבלת ה-10 מילי-שניות נותרת תקרה קשיחה. מפתחים שמעריכים בחסר את העלות של אפילו עיבוד parsing צנוע (למשל, המרת markdown ל-HTML) עלולים להגיע למגבלה באופן בלתי צפוי. המסלול החינמי מתאים לתרחישים של "הגשה כפי שהם" (serve-as-is), ולא ליצירת תוכן בזמן אמת (on-the-fly).

מה הלאה עבור MCP ב-Cloudflare

אם לאתר שלכם כבר יש את התוכן שלו ב-static bucket, הוספת endpoint של MCP יכולה להיות פשוטה כמו כמה שורות קוד ונתיב אחד. הפרוטוקול מתכתב כעת עם הצרכים של שרתים קטנים — endpoint HTTP פשוט שניתן לארח בחינם, כל עוד נשארים מתחת לתקרת ה-10 מילי-שניות של ה-CPU.