Model Context Protocol (MCP) आता stateless झाला आहे, आणि या बदलामुळे डेव्हलपर्सना Cloudflare Workers च्या फ्री टियरवर (free tier) लहान MCP सर्व्हर्स सुरू करणे शक्य झाले आहे—जर प्रत्येक रिक्वेस्ट प्लॅटफॉर्मच्या १० ms CPU मर्यादेच्या आत राहिली तर.

हा बदल का महत्त्वाचा आहे

दोन अलीकडील घडामोडींमुळे हे मार्ग खुले झाले आहेत. पहिले म्हणजे, MCP कोअरने त्याचे session-based डिझाइन सोडून दिले असून आता ते handshakes शिवाय चालते; कोडच्या कोणत्याही इन्स्टन्सद्वारे (instance) कोणतीही रिक्वेस्ट हाताळली जाऊ शकते. दुसरे म्हणजे, Cloudflare ने McpAgent क्लास बंद केला असून आता नवीन सर्व्हर्ससाठी साध्या request handlers ची शिफारस केली आहे. या दोन्ही गोष्टींमुळे Durable Objects किंवा इतर stateful स्टोरेजची गरज उरली नाही, जे फ्री प्लॅनवर MCP चालवण्यासाठी मुख्य अडथळे होते.

फ्री टियरमध्ये प्रत्यक्षात काय करता येते

आम्ही एक read-only MCP सर्व्हर तयार केला आहे जो स्टॅटिक साइटमधून Markdown फाइल्स सर्व्ह करतो. हा सर्व्हर list_articles आणि get_article ही दोन टूल्स—पद्धतींना (methods) राउट करण्यासाठी साध्या switch statement चा वापर करून कार्यान्वित करतो. यात कोणतेही जड कॅल्क्युलेशन नाही, फक्त स्टॅटिक ॲसेट्स (static assets) मिळवणे इतकेच काम आहे.

Cloudflare चे CPU अकाउंटिंग एकूण रिस्पॉन्स टाइमपेक्षा (total response time) वेगळे आहे. CPU वेळामध्ये फक्त तुमच्या JavaScript च्या एक्झिक्यूशनमध्ये खर्च झालेले सायकल मोजले जातात; नेटवर्क कॉल्स किंवा डिस्क रीड्सची वाट पाहण्यात घालवलेला वेळ यात समाविष्ट नसतो. हा फरक महत्त्वाचा आहे कारण फ्री टियरमध्ये प्रति रिक्वेस्ट CPU मर्यादा १० ms आहे, तर एकूण लॅटन्सी (latency) त्यापेक्षा जास्त असू शकते.

फ्री टियरवरील आमचे मोजमाप खालीलप्रमाणे होते:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (सर्वात मोठी फाईल): 1-2 ms CPU

सर्वात मोठ्या आर्टिकलने देखील १० ms च्या बजेटचा केवळ एक छोटा भाग वापरला. क्लायंट बाजूला जाणारा संथपणा फाईल वाचण्याची वाट पाहण्यामुळे होता, कोड एक्झिक्यूशनमुळे नाही.

मर्यादा कुठे अडथळा ठरू शकते

डेटा एका स्पष्ट पॅटर्नकडे निर्देश करतो:

  • Data-serving tools (साधे रीड्स, लिस्टिंग) सहजपणे मर्यादेच्या आत राहतात.
  • Compute-heavy tools (parsing, rendering, hashing, किंवा कोणतेही अल्गोरिदमिक काम) १० ms चे बजेट वेगाने संपवू शकतात.

जर एखाद्या टूलला साध्या प्रक्रियेपेक्षा जास्त प्रोसेसिंगची गरज असेल, तर डेव्हलपर्सना पेड (paid) Workers प्लॅनवर जावे लागेल. $5 च्या प्लॅनमध्ये ही मर्यादा प्रति रिक्वेस्ट ३० सेकंदपर्यंत वाढते.

कोणाचा फायदा होईल आणि कोणाला काळजी घ्यावी लागेल

ज्या लहान साइट्स आधीच Markdown फाइल्स किंवा RSS फीड होस्ट करतात, त्या एका नवीन राउटद्वारे MCP एंडपॉइंट (endpoint) उपलब्ध करून देऊन फ्री प्लॅनवर राहू शकतात. याचा अर्थ छंद जोपासणाऱ्यांसाठी (hobbyists), डॉक्युमेंटेशन साइट्स किंवा कमी ट्रॅफिक असलेल्या ब्लॉग्ससाठी कमी ऑपरेटिंग खर्च आणि कमी गुंतागुंत असेल.

जर एखाद्या टूलला साध्या प्रक्रियेपेक्षा जास्त प्रोसेसिंगची गरज असेल, तर डेव्हलपर्सना पेड Workers प्लॅनवर जावे लागेल.

लाँच करण्यापूर्वी काय तपासावे

  • तुमच्या टूलचे प्रोफाईलिंग करा: काही प्रतिनिधीत्व करणाऱ्या (representative) रिक्वेस्ट्स चालवून Cloudflare च्या डॅशबोर्डमधील CPU मीटर तपासा.
  • स्टॅटिक आणि डायनॅमिक पाथ वेगळे ठेवा: स्टॅटिक फाईल सर्व्हिंग फ्री टियरवर ठेवा आणि जास्त कॉम्प्युट लागणाऱ्या कॉल्स एखाद्या पेड वर्करकडे किंवा दुसऱ्या बॅकएंडकडे राउट करा.
  • लपलेल्या लॅटन्सीवर लक्ष ठेवा: नेटवर्क वेट्स (waits) CPU मध्ये मोजले जात नाहीत, तरीही ते युजर एक्सपिरियन्सवर परिणाम करतात. तुम्ही सर्व्ह करत असलेल्या फाइल्ससाठी edge caching चा विचार करा.

प्रतिवाद: फ्री प्लॅन अमर्याद नाही

जरी stateless कोअरमुळे Durable Objects ची गरज उरली नसली, तरी १० ms ची मर्यादा ही एक कडक मर्यादा (hard ceiling) आहे. जे डेव्हलपर्स अगदी साध्या पार्सिंगचा (उदा. markdown चे HTML मध्ये रूपांतर) खर्च कमी समजतात, त्यांना अनपेक्षितपणे या मर्यादेचा सामना करावा लागू शकतो. फ्री टियर "serve-as-is" (जसे आहे तसे सर्व्ह करणे) परिस्थितीसाठी योग्य आहे, ऑन-द-फ्लाई (on-the-fly) कंटेंट जनरेशनसाठी नाही.

Cloudflare वरील MCP साठी पुढे काय?

जर तुमच्या साइटवरील कंटेंट आधीच स्टॅटिक बकेटमध्ये असेल, तर MCP एंडपॉइंट जोडणे केवळ काही ओळींचा कोड आणि एका नवीन राउटइतके सोपे असू शकते. जोपर्यंत तुम्ही १० ms च्या CPU मर्यादेच्या आत राहता, तोपर्यंत हा प्रोटोकॉल आता लहान सर्व्हर्सच्या गरजांशी सुसंगत आहे—एक साधा HTTP एंडपॉइंट जो मोफत होस्ट केला जाऊ शकतो.