Model Context Protocol (MCP) ने अपने session state को हटा दिया है, और उसकी जगह receipt-style requests और एक नए server/discover command को शामिल किया है। डेवलपर्स अब AWS Lambda जैसे serverless platforms पर MCP चला सकते हैं और उस “single waiter” bottleneck से बच सकते हैं जिसने लंबे समय से reliability को प्रभावित किया है।

पुराना मॉडल क्यों महत्वपूर्ण था

मूल रूप से MCP के लिए एक विशिष्ट server के साथ persistent connection की आवश्यकता होती थी। Server यूजर का “table number” रखता था—एक छिपा हुआ session जो context, rules और लंबित (pending) actions को स्टोर करता था। जब वह server क्रैश हो जाता था, तो session गायब हो जाता था और client को फिर से शुरुआत करनी पड़ती थी।

अपडेट में क्या अलग है

  • No sessions – प्रत्येक request में वह सब कुछ होता है जिसकी server को आवश्यकता है, जैसे कि एक रेस्टोरेंट की receipt जिसे कोई भी कैशियर पढ़ सकता है। “initialize” handshake अब खत्म हो गया है।
  • Receipt model – प्रत्येक request की शुरुआत में एक छोटा meta block होता है जिसमें version info और आवश्यक parameters शामिल होते हैं। Server request को अलग से (in isolation) प्रोसेस करता है, और फिर resultType, ttlMs (milliseconds में time-to-live), और cacheScope के साथ परिणाम वापस करता है। ये fields client को उत्तर को सुरक्षित रूप से cache करने और यह जानने में मदद करते हैं कि यह कब समाप्त (expire) होगा।
  • Server/discover – एक नया command client को server की वर्तमान क्षमताओं (capabilities) के बारे में पूछने की अनुमति देता है। इसका response तुरंत मिलता है और यह पिछले किसी भी interaction पर निर्भर नहीं करता है।
  • Subscriptions/listen – यह एक buzzer की तरह काम करता है: client updates के लिए subscribe करता है और उसे केवल तभी सूचित किया जाता है जब कुछ बदलता है, जिससे polling traffic कम हो जाता है।
  • Input_required flow – यदि server को अधिक जानकारी की आवश्यकता होती है, तो वह client से दोबारा संपर्क करने के बजाय input_required response वापस करता है। इसके बाद client एक follow-up request में छूटी हुई जानकारी प्रदान करता है।

चूंकि server अब state को स्टोर नहीं करता है, इसलिए कोई भी stateless compute environment MCP endpoints को host कर सकता है। वे functions जो मांग पर (on demand) शुरू होते हैं, pause होते हैं, या zones के बीच migrate होते हैं, वे बातचीत को तोड़े बिना traffic को संभाल सकते हैं।

किसे फायदा होगा, किसे चिंता होगी

AI front-ends बनाने वाले developers – उन्हें सरल और अधिक विश्वसनीय back-ends मिलते हैं। Infrastructure teams – सस्ते, auto-scaling services पर MCP provision कर सकती हैं। MCP server maintainers – उन्हें ttlMs, cacheScope भेजने के लिए और server/discover contract का पालन करने के लिए handlers को फिर से लिखना होगा। वह code जो persistent session पर निर्भर था, उसे refactoring की आवश्यकता होगी। सख्त compliance वाले Enterprises – उन्हें डेटा-लाइफसाइकिल के स्पष्ट नियंत्रण से लाभ होगा।

छिपा हुआ विवरण: version negotiation

प्रत्येक receipt में एक छोटा meta block शामिल होता है जो उस protocol version की जानकारी देता है जिसकी client अपेक्षा करता है।

क्या अभी भी अनिश्चित है

आगे क्या देखना है

निष्कर्ष

session state को हटाकर और प्रत्येक interaction को एक self-contained receipt में बदलकर, MCP अब serverless ecosystems में स्वाभाविक रूप से फिट हो जाता है। यह बदलाव MCP को अधिक stable और scalable बनाता है, जिससे servers कहीं भी चल सकते हैं और किसी भी सामान्य web service की तरह scale हो सकते हैं।