Model Context Protocol (MCP) اب stateless ہو گیا ہے، اور یہ تبدیلی ڈویلپرز کو Cloudflare Workers کے فری ٹیر پر چھوٹے MCP سرورز چلانے کی اجازت دیتی ہے—بشرطیکہ ہر درخواست (request) پلیٹ فارم کی 10 ms کی CPU حد کے اندر رہے۔

یہ تبدیلی کیوں اہم ہے

دو حالیہ اقدامات نے اس کے دروازے کھول دیے ہیں۔ پہلا یہ کہ MCP کور نے اپنا سیشن پر مبنی ڈیزائن ختم کر دیا ہے اور اب یہ ہینڈ شیکس (handshakes) کے بغیر چلتا ہے؛ کسی بھی درخواست کو کوڈ کے کسی بھی انسٹنس (instance) کے ذریعے ہینڈل کیا جا سکتا ہے۔ دوسرا یہ کہ Cloudflare نے McpAgent کلاس کو ختم کر دیا ہے اور اب نئے سرورز کے لیے سادہ ریکوئسٹ ہینڈلرز (request handlers) کی سفارش کرتا ہے۔ یہ دونوں مل کر Durable Objects یا دیگر اسٹیٹ فل (stateful) اسٹوریج کی ضرورت کو ختم کر دیتے ہیں، جو فری پلان پر MCP چلانے میں سب سے بڑی رکاوٹیں تھیں۔

فری ٹیر اصل میں کیا کر سکتا ہے

ہم نے ایک ریڈ اونلی (read-only) MCP سرور بنایا ہے جو ایک اسٹیٹک سائٹ سے Markdown فائلیں فراہم کرتا ہے۔ یہ سرور میتھڈز کو روٹ کرنے کے لیے ایک سادہ switch سٹیٹمنٹ کا استعمال کرتے ہوئے دو ٹولز—list_articles اور get_article—کو نافذ کرتا ہے۔ کوئی بھاری حساب کتاب نہیں، صرف اسٹیٹک اثاثوں (assets) کو حاصل کرنا۔

Cloudflare کا CPU اکاؤنٹنگ کل ٹوٹل ریسپانس ٹائم سے مختلف ہے۔ CPU ٹائم میں صرف آپ کے JavaScript کو چلانے میں صرف ہونے والے سائیکلز شمار ہوتے ہیں؛ نیٹ ورک کالز یا ڈسک ریڈز کے انتظار میں گزارا گیا وقت اس میں شامل نہیں ہوتا۔ یہ فرق اہم ہے کیونکہ فری ٹیر فی درخواست CPU کو 10 ms تک محدود رکھتا ہے، جبکہ کل لیٹنسی (latency) اس سے زیادہ ہو سکتی ہے۔

فری ٹیر پر ہمارے پیمائش کے نتائج کچھ اس طرح تھے:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (سب سے بڑی فائل): 1-2 ms CPU

سب سے بڑی آرٹیکل نے بھی 10 ms کے بجٹ کا ایک چھوٹا سا حصہ استعمال کیا۔ کلائنٹ سائیڈ پر نظر آنے والی سست رفتاری فائل کے پڑھے جانے کے انتظار کی وجہ سے تھی، نہ کہ کوڈ کے چلنے (execution) کی وجہ سے۔

حد کہاں رکاوٹ بنتی ہے

ڈیٹا ایک واضح پیٹرن کی طرف اشارہ کرتا ہے:

  • ڈیٹا فراہم کرنے والے ٹولز (سادہ ریڈز، لسٹنگ) آسانی سے حد کے اندر رہتے ہیں۔
  • کمپیوٹیشن کے لحاظ سے بھاری ٹولز (پارسنگ، رینڈرنگ، ہیشنگ، یا کوئی بھی الگورتھمک کام) تیزی سے 10 ms کے بجٹ کو ختم کر سکتے ہیں۔

اگر کسی ٹول کو معمولی سے زیادہ پروسیسنگ کی ضرورت ہے، تو ڈویلپرز کو پیڈ (paid) Workers پلان پر منتقل ہونا پڑے گا۔ $5 والا پلان فی درخواست کی حد کو بڑھا کر 30 سیکنڈ کر دیتا ہے۔

کون فائدہ اٹھائے گا، اور کون وقت کا محتاط رہے گا

چھوٹی ویب سائٹس جو پہلے سے ہی Markdown فائلیں یا RSS فیڈ ہوسٹ کرتی ہیں، وہ ایک نئے روٹ کے ساتھ MCP اینڈ پوائنٹ (endpoint) فراہم کر سکتی ہیں اور فری پلان پر رہ سکتی ہیں۔ اس کا مطلب ہے کہ شوقین افراد (hobbyists)، ڈاکومنٹیشن سائٹس، یا کم ٹریفک والے بلاگز کے لیے کم آپریشنل اخراجات اور کم پیچیدگیاں۔

اگر کسی ٹول کو معمولی سے زیادہ پروسیسنگ کی ضرورت ہے، تو ڈویلپرز کو پیڈ (paid) Workers پلان پر منتقل ہونا پڑے گا۔

لانچ کرنے سے پہلے کیا ٹیسٹ کریں

  • اپنے ٹول کا پروفائل بنائیں: چند نمائندہ درخواستیں چلائیں اور Cloudflare کے ڈیش بورڈ میں CPU میٹر چیک کریں۔
  • اسٹیٹک اور ڈائنامک راستوں کو الگ کریں: اسٹیٹک فائل سرونگ کو فری ٹیر پر رکھیں، اور کمپیوٹیشن کے لحاظ سے بھاری کالز کو پیڈ ورکر یا کسی دوسرے بیک اینڈ پر روٹ کریں۔
  • چھپی ہوئی لیٹنسی پر نظر رکھیں: نیٹ ورک کا انتظار CPU کے خلاف شمار نہیں ہوتا، لیکن یہ پھر بھی صارف کے تجربے (user experience) پر اثر انداز ہوتا ہے۔ ان فائلوں کے لیے ایج کیشنگ (edge caching) پر غور کریں۔

ایک دوسرا پہلو: فری پلان لامحدود نہیں ہے

اگرچہ اسٹیٹ لیس (stateless) کور Durable Objects کی ضرورت کو ختم کر دیتا ہے، لیکن 10 ms کی حد ایک سخت حد (hard ceiling) کے طور پر برقرار ہے۔ وہ ڈویلپرز جو معمولی سی پارسنگ (مثلاً markdown سے HTML میں تبدیلی) کی لاگت کو کم سمجھتے ہیں، وہ غیر متوقع طور پر اس حد تک پہنچ سکتے ہیں۔ فری ٹیر "جیسا ہے ویسا ہی فراہم کرنے" (serve-as-is) والے منظرناموں کے لیے موزوں ہے، نہ کہ آن دی فلائی (on-the-fly) مواد کی تخلیق کے لیے۔

Cloudflare پر MCP کے لیے آگے کیا ہے

اگر آپ کی سائٹ کا مواد پہلے سے ہی ایک اسٹیٹک بکٹ (static bucket) میں موجود ہے، تو MCP اینڈ پوائنٹ شامل کرنا محض چند لائنوں کے کوڈ اور ایک روٹ جتنا آسان ہو سکتا ہے۔ یہ پروٹوکول اب چھوٹے سرورز کی ضروریات کے مطابق ہے—ایک سادہ HTTP اینڈ پوائنٹ جسے مفت میں ہوسٹ کیا جا سکتا ہے، جب تک کہ آپ 10 ms کی CPU حد کے اندر رہیں۔