Model Context Protocol (MCP) अब stateless हो गया है, और यह बदलाव डेवलपर्स को Cloudflare Workers के फ्री टियर पर छोटे MCP सर्वर चलाने की सुविधा देता है—बशर्ते प्रत्येक रिक्वेस्ट प्लेटफॉर्म की 10 ms CPU लिमिट के भीतर रहे।

यह बदलाव क्यों महत्वपूर्ण है

दो हालिया बदलावों ने इसके लिए रास्ता खोल दिया है। पहला, MCP कोर ने अपने session-based डिज़ाइन को छोड़ दिया है और अब यह बिना handshakes के चलता है; कोड के किसी भी instance द्वारा किसी भी रिक्वेस्ट को हैंडल किया जा सकता है। दूसरा, Cloudflare ने McpAgent class को हटा दिया है और अब नए सर्वरों के लिए plain request handlers की सिफारिश करता है। ये दोनों मिलकर Durable Objects या अन्य stateful storage की आवश्यकता को समाप्त कर देते हैं, जो फ्री प्लान पर MCP चलाने के लिए मुख्य बाधाएं थीं।

फ्री टियर वास्तव में क्या कर सकता है

हमने एक read-only MCP सर्वर बनाया है जो एक static site से Markdown फ़ाइलों को सर्व करता है। सर्वर में दो टूल्स—list_articles और get_article—इस्तेमाल किए गए हैं, जो मेथड्स को रूट करने के लिए एक साधारण switch statement का उपयोग करते हैं। इसमें कोई भारी कैलकुलेशन नहीं है, बस static assets को फेच करना है।

Cloudflare की CPU अकाउंटिंग, कुल रिस्पॉन्स टाइम (total response time) से अलग होती है। CPU टाइम में केवल आपके JavaScript को चलाने में खर्च हुए cycles गिने जाते हैं; नेटवर्क कॉल्स या डिस्क रीड का इंतज़ार करने में लगने वाला समय इसमें शामिल नहीं होता है। यह अंतर महत्वपूर्ण है क्योंकि फ्री टियर प्रति रिक्वेस्ट CPU को 10 ms तक सीमित रखता है, जबकि कुल लेटेंसी (latency) इससे अधिक हो सकती है।

फ्री टियर पर हमारे माप (measurements) कुछ इस प्रकार रहे:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (सबसे बड़ी फ़ाइल): 1-2 ms CPU

सबसे बड़ी आर्टिकल ने भी 10 ms के बजट का एक छोटा सा हिस्सा ही इस्तेमाल किया। क्लाइंट साइड पर दिखने वाली सुस्ती फ़ाइल को पढ़ने के इंतज़ार के कारण थी, न कि कोड के निष्पादन (execution) के कारण।

सीमा कहाँ समस्या पैदा करती है

डेटा एक स्पष्ट पैटर्न की ओर इशारा करता है:

  • Data-serving tools (साधारण रीड, लिस्टिंग) आसानी से लिमिट के भीतर रहते हैं।
  • Compute-heavy tools (parsing, rendering, hashing, या कोई भी एल्गोरिथमिक काम) तेज़ी से 10 ms का बजट खत्म कर सकते हैं।

यदि किसी टूल को मामूली प्रोसेसिंग से अधिक की आवश्यकता है, तो डेवलपर्स को पेड Workers प्लान पर जाना होगा। $5 वाला प्लान लिमिट को प्रति रिक्वेस्ट 30 सेकंड तक बढ़ा देता है।

किसे फायदा होगा, और किसे सावधानी बरतनी होगी

छोटी साइटें जो पहले से ही Markdown फ़ाइलें या RSS फ़ीड होस्ट करती हैं, वे एक नए रूट के साथ MCP endpoint को एक्सपोज़ कर सकती हैं और फ्री प्लान पर ही रह सकती हैं। इसका मतलब है हॉबीइस्ट (hobbyists), डॉक्यूमेंटेशन साइटों या कम ट्रैफिक वाले ब्लॉगों के लिए कम ऑपरेटिंग लागत और कम जटिलता।

यदि किसी टूल को मामूली प्रोसेसिंग से अधिक की आवश्यकता है, तो डेवलपर्स को पेड Workers प्लान पर जाना होगा।

लॉन्च करने से पहले क्या टेस्ट करें

  • अपने टूल को प्रोफाइल करें: कुछ प्रतिनिधि रिक्वेस्ट चलाएं और Cloudflare के डैशबोर्ड में CPU मीटर चेक करें।
  • Static और dynamic पाथ को अलग रखें: स्टैटिक फ़ाइल सर्विंग को फ्री टियर पर रखें, और कंप्यूट-इंटेंसिव कॉल्स को पेड वर्कर या किसी अन्य बैकएंड पर रूट करें।
  • छिपी हुई लेटेंसी पर नज़र रखें: नेटवर्क वेट (network waits) CPU में नहीं गिने जाते, लेकिन वे फिर भी यूजर एक्सपीरियंस को प्रभावित करते हैं। आप जो फ़ाइलें सर्व करते हैं, उनके लिए edge caching पर विचार करें।

विपरीत तर्क: फ्री प्लान असीमित नहीं है

हालांकि stateless कोर से Durable Objects की आवश्यकता समाप्त हो जाती है, लेकिन 10 ms की सीमा एक सख्त सीमा (hard ceiling) बनी हुई है। जो डेवलपर्स मामूली पार्सिंग (जैसे, markdown से HTML कन्वर्जन) की लागत को कम आंकते हैं, वे अप्रत्याशित रूप से इस सीमा तक पहुँच सकते हैं। फ्री टियर "serve-as-is" परिदृश्यों के लिए उपयुक्त है, न कि on-the-fly कंटेंट जनरेशन के लिए।

Cloudflare पर MCP के लिए आगे क्या है

यदि आपकी साइट की सामग्री पहले से ही एक static bucket में है, तो MCP endpoint जोड़ना कोड की कुछ लाइनों और एक सिंगल रूट जितना सरल हो सकता है। यह प्रोटोकॉल अब छोटे सर्वरों की ज़रूरतों के अनुरूप है—एक साधारण HTTP endpoint जिसे मुफ्त में होस्ट किया जा सकता है, जब तक कि आप 10 ms CPU की सीमा के भीतर रहते हैं।