Model Context Protocol (MCP) ने आपला 'session state' काढून टाकला आहे आणि त्याऐवजी 'receipt-style' विनंत्या (requests) आणि नवीन server/discover कमांड आणली आहे. आता डेव्हलपर्स AWS Lambda सारख्या 'serverless' प्लॅटफॉर्मवर MCP चालवू शकतात आणि "single waiter" सारख्या अडथळ्यांपासून वाचू शकतात, ज्यामुळे दीर्घकाळ विश्वासार्हतेवर परिणाम होत होता.

जुने मॉडेल का महत्त्वाचे होते

मूळतः MCP साठी विशिष्ट सर्व्हरशी सतत (persistent) कनेक्शन असणे आवश्यक होते. सर्व्हरकडे वापरकर्त्याचा "table number" असे काहीतरी असायचे—एक गुप्त 'session' जो संदर्भ (context), नियम आणि प्रलंबित कृती साठवून ठेवत असे. जेव्हा तो सर्व्हर क्रॅश व्हायचा, तेव्हा तो 'session' नाहीसा व्हायचा आणि क्लायंटला पुन्हा सुरुवातीपासून सुरुवात करावी लागायची.

या अपडेटमध्ये काय वेगळे आहे

  • No sessions – प्रत्येक विनंतीमध्ये सर्व्हरला आवश्यक असलेली सर्व माहिती असते, जसे की रेस्टॉरंटमधील पावती जी कोणताही कॅशियर वाचू शकतो. "initialize" हँडशेक (handshake) आता नाहीसा झाला आहे.
  • Receipt model – प्रत्येक विनंतीच्या सुरुवातीला एक छोटा 'meta block' असतो, ज्यामध्ये व्हर्जन माहिती आणि आवश्यक पॅरामीटर्स असतात. सर्व्हर ही विनंती स्वतंत्रपणे (in isolation) प्रक्रिया करतो आणि त्यानंतर resultType, ttlMs (मिलीसेकंदमध्ये 'time-to-live') आणि cacheScope सह निकाल परत करतो. या फील्ड्समुळे क्लायंट सुरक्षितपणे उत्तर कॅश (cache) करू शकतो आणि ते कधी संपेल हे जाणून घेऊ शकतो.
  • Server/discover – एक नवीन कमांड क्लायंटला सर्व्हरच्या सध्याच्या क्षमतांबद्दल विचारण्यास (query) अनुमती देते. याचे उत्तर त्वरित मिळते आणि ते आधीच्या संवादावर अवलंबून नसते.
  • Subscriptions/listen – हे एका बजरप्रमाणे काम करते: क्लायंट अपडेट्ससाठी सबस्क्राईब करतो आणि जेव्हा काही बदल होते तेव्हाच त्याला सूचित केले जाते, ज्यामुळे 'polling traffic' कमी होतो.
  • Input_required flow – जर सर्व्हरला अधिक माहितीची आवश्यकता असेल, तर तो क्लायंटकडे परत न जाता input_required प्रतिसाद देतो. त्यानंतर क्लायंट पुढील विनंतीमध्ये (follow-up request) ती गहाळ माहिती पुरवतो.

सर्व्हर आता 'state' साठवून ठेवत नसल्यामुळे, कोणताही 'stateless compute environment' MCP एंडपॉइंट्स होस्ट करू शकतो. मागणीनुसार सुरू होणारे (spin up), थांबणारे (pause) किंवा विविध झोनमध्ये स्थलांतरित (migrate) होणारे फंक्शन्स, संभाषण न तोडता ट्रॅफिक हाताळू शकतात.

कोणाचा फायदा, कोणाची चिंता

AI front-ends बनवणारे डेव्हलपर्स – त्यांना अधिक सोपे आणि विश्वासार्ह बॅक-एंड्स मिळतील. इन्फ्रास्ट्रक्चर टीम्स – स्वस्त आणि ऑटो-स्केलिंग सेवांवर MCP तैनात (provision) करू शकतात. MCP सर्व्हर मेंटेनर्स – ttlMs, cacheScope पाठवण्यासाठी आणि server/discover कराराचे पालन करण्यासाठी हँडलर्स पुन्हा लिहावे लागतील. ज्या कोडमध्ये 'persistent session' वर अवलंबून होते, त्याचे रिफॅक्टरिंग (refactoring) करावे लागेल. कडक नियमावली (compliance) पाळणाऱ्या संस्था – डेटा-लाईफसायकलच्या स्पष्ट नियंत्रणामुळे त्यांना फायदा होईल.

लपलेला तपशील: व्हर्जन नेगोशिएशन

प्रत्येक पावतीमध्ये एक छोटा 'meta block' असतो जो क्लायंटला अपेक्षित असलेल्या प्रोटोकॉल व्हर्जनची माहिती देतो.

अजूनही काय अनिश्चित आहे

पुढे काय पाहावे

निष्कर्ष

'session state' काढून टाकून आणि प्रत्येक संवाद एका स्वतंत्र पावतीमध्ये रूपांतरित करून, MCP आता 'serverless' इकोसिस्टममध्ये नैसर्गिकरित्या बसते. या बदलामुळे MCP अधिक स्थिर आणि स्केलेबल (scalable) झाले आहे, ज्यामुळे सर्व्हर कुठेही चालवता येतात आणि कोणत्याही सामान्य वेब सेवेप्रमाणे स्केल होऊ शकतात.