Stateless MCP सर्व्हर म्हणजे काय आणि त्यात काय बदल झाले?

Stateless MCP सर्व्हर म्हणजे काय

Stateless MCP सर्व्हर विनंत्यांच्या दरम्यान क्लायंटची कोणतीही स्थिती (state) राखून ठेवत नाही. प्रत्येक विनंतीमध्ये प्रोटोकॉल आवृत्ती, क्लायंटची क्षमता आणि सर्व्हरला उत्तर देण्यासाठी आवश्यक असलेली क्रेडेन्शियल्स असतात, त्यामुळे कोणत्याही मशीनवरील कोणतीही प्रक्रिया कोणत्याही विनंतीचे उत्तर देऊ शकते. MCP (Model Context Protocol, ज्या वायर फॉरमॅटचा वापर एजंट्स टूल्सपर्यंत पोहोचण्यासाठी करतात) ने 2026-07-28 आवृत्तीमध्ये याला एक नियम बनवले आहे, ज्याने initialize हँडशेक आणि त्याखालील HTTP सत्र काढून टाकले आहे.

हाच संपूर्ण ऑपरेशनल उद्देश आहे. जो सर्व्हर क्लायंटनुसार काहीही साठवत नाही, तो कोणत्याही सेशन ॲफिनिटीशिवाय सामान्य लोड बॅलन्सरच्या मागे राहू शकतो, डिप्लॉयमेंट दरम्यान क्लायंटला व्यत्यय न आणता रीस्टार्ट केला जाऊ शकतो आणि एकाऐवजी चार समान प्रक्रिया म्हणून चालू शकतो. सेशन-ओरिएंटेड सर्व्हर अतिरिक्त यंत्रणेशिवाय यापैकी काहीही करू शकत नाही.

Model Context Protocol हा एक stateless प्रोटोकॉल आहे: विनंतीवर प्रक्रिया करण्यासाठी आवश्यक असलेली सर्व माहिती त्या विनंतीमध्येच समाविष्ट असते. सर्व्हर प्रत्येक विनंतीवर स्वतंत्रपणे प्रक्रिया करतो; मागील विनंत्यांवरून कोणतीही स्थिती गृहीत धरली जाऊ नये, अगदी त्याच कनेक्शन किंवा स्ट्रीमवरील विनंत्यांकडूनही नाही.

Stateless म्हणजे तुमचा सर्व्हर काहीही साठवत नाही असा अर्थ होत नाही. तुमचा डेटाबेस, तुमची रांग (queue) आणि तुमची कॅशे (cache) हे सर्व तिथेच असतात. याचा अर्थ असा की प्रोटोकॉल कनेक्शनवर कोणतीही स्थिती वाहून नेत नाही, त्यामुळे सर्व्हरने कनेक्शन, प्रक्रिया किंवा ओपन सॉकेटला "हा क्लायंट, संभाषणाच्या मध्यभागी आहे" असे मानू नये.

2026-07-28 च्या आवृत्तीमध्ये काय काढून टाकले आहे

2026-07-28 ही ऑगस्ट 2026 पर्यंतची स्पेसिफिकेशनची सध्याची आवृत्ती आहे. 2025-11-25 च्या तुलनेत, यामध्ये सत्रांना (sessions) सपोर्ट करण्यासाठी अस्तित्वात असलेल्या पाच गोष्टी काढून टाकल्या आहेत.

• initialize विनंती आणि notifications/initialized सूचना. आता कोणताही हँडशेक (handshake) अस्तित्वात नाही (SEP-2575).
• Mcp-Session-Id हेडर आणि HTTP DELETE द्वारे सत्र समाप्ती (SEP-2567).
• स्वतंत्र HTTP GET स्ट्रीम, ज्यावर सर्व्हर्स सूचना पाठवत असत. त्याऐवजी आता subscriptions/listen वापरले जाते, जी एक सामान्य POST विनंती आहे आणि तिचा प्रतिसाद एक दीर्घकाळ चालणारा स्ट्रीम असतो.
• SSE (server-sent events) स्ट्रीमची पुन्हा सुरू होण्याची क्षमता (resumability). Last-Event-ID हेडर आणि प्रति-इव्हेंट ID आता काढून टाकले आहेत, त्यामुळे स्ट्रीम खंडित झाल्यास चालू असलेली विनंती गमावली जाते आणि क्लायंटला ती नवीन विनंती ID सह पुन्हा करावी लागते.
• ping, logging/setLevel आणि notifications/roots/list_changed. लॉग लेव्हल आता प्रति-विनंती फील्ड आहे, जे _meta मधील io.modelcontextprotocol/logLevel मध्ये समाविष्ट आहे.

एक नवीन पद्धत जोडली गेली आहे आणि प्रत्येक सर्व्हरने ती लागू करणे अनिवार्य आहे. server/discover सर्व्हरच्या समर्थित प्रोटोकॉल आवृत्त्या, क्षमता आणि ओळख एकाच कॉलमध्ये परत करते. हे हँडशेकच्या सर्वात जवळचे उरलेले घटक आहे आणि क्लायंटसाठी ते कॉल करणे ऐच्छिक आहे.

प्रॉडक्शनमध्ये सेशन ट्रान्सपोर्ट चालवणे कठीण का होते

2025-11-25 आणि त्यापूर्वीच्या आवृत्त्यांमध्ये, सर्व्हर इनिशियलायझेशनच्या वेळी एक सेशन ID तयार करू शकत असे आणि तो InitializeResult वर Mcp-Session-Id हेडरमध्ये परत पाठवत असे. त्यानंतर क्लायंटला प्रत्येक पुढील विनंतीवर तो हेडर पाठवणे अनिवार्य होते. वाटाघाटी केलेली प्रोटोकॉल आवृत्ती आणि क्लायंटची क्षमता सर्व्हरच्या मेमरीमध्ये त्या ID द्वारे साठवलेली असायची. या प्रत्येक निवडीचा एक ऑपरेशनल खर्च असतो.

• सर्व्हर रीस्टार्ट केल्यावर सेशन टेबल नष्ट होत असे. स्पेसिफिकेशननुसार, मृत सेशन ID असलेल्या कोणत्याही विनंतीला सर्व्हरने 404 Not Found ने उत्तर देणे आवश्यक होते आणि क्लायंटने नवीन InitializeRequest सह पुन्हा सुरुवात करणे आवश्यक होते. प्रत्येक डिप्लॉयमेंट हे प्रत्येक कनेक्टेड क्लायंटसाठी पुन्हा कनेक्ट होण्याचे कारण बनत असे.
• दुसऱ्या रेप्लिकाला पहिल्या रेप्लिकाची सत्रे (sessions) माहित नसत. स्केलिंग आउट करण्यासाठी लोड बॅलन्सरवर स्टिकी राउटिंग किंवा प्रत्येक रेप्लिकाने प्रत्येक विनंतीवर वाचले असे सामायिक सेशन स्टोअर वापरणे आवश्यक होते.
• सेशन टेबल ही अशी मेमरी होती जी निष्क्रिय क्लायंटच्या संख्येनुसार वाढत असे. DELETE ऐच्छिक होते आणि जे क्लायंट ते न पाठवता बंद होत, त्यांच्या नोंदी मेमरीमध्ये तशाच राहत.
• लिस्ट रिझल्ट्स प्रत्येक कनेक्शननुसार बदलू शकत होते, त्यामुळे सर्व्हरच्या समोर कॅशिंग करणे असुरक्षित होते.

सेशन काढून टाकल्यामुळे या चारही समस्या एकाच वेळी दूर होतात. कोणत्याही कॉन्फिगरेशनला हात लावण्यापूर्वी हा बदल समजून घेणे महत्त्वाचे आहे.

प्रत्येक विनंतीमध्ये आता काय समाविष्ट असते

MCP एंडपॉईंटवर केलेली प्रत्येक POST विनंती स्वतंत्र असते. प्रोटोकॉल आवृत्ती आणि क्लायंटच्या क्षमता विनंतीच्या बॉडीमध्ये _meta अंतर्गत पाठवल्या जातात. काही निवडक फील्ड्स HTTP हेडर्समध्ये देखील समाविष्ट केल्या जातात, जेणेकरून मध्यस्थ प्रणाली (intermediary) JSON पार्स न करता विनंती योग्य ठिकाणी पाठवू शकेल.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {"location": "Seattle, WA"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

प्रत्येक विनंतीमध्ये io.modelcontextprotocol/protocolVersion आणि io.modelcontextprotocol/clientCapabilities असणे अनिवार्य आहे. clientInfo अनिवार्य नसले तरी, क्लायंटने ते पाठवणे अपेक्षित आहे. आवश्यक फील्ड नसलेली विनंती सदोष (malformed) मानली जाते, त्यामुळे सर्व्हरने ती JSON-RPC त्रुटी -32602 आणि HTTP 400 Bad Request सह नाकारली पाहिजे.

प्रत्येक विनंतीमध्ये Mcp-Method हेडर असणे अनिवार्य आहे. tools/call, resources/read आणि prompts/get साठी Mcp-Name आवश्यक आहे. हेडरचे मूल्य बॉडीमधील मूल्याशी जुळले पाहिजे. जर सर्व्हरने बॉडीवर प्रक्रिया केली आणि त्यात तफावत आढळली, तर त्याने ती विनंती 400 Bad Request आणि त्रुटी कोड -32020, HeaderMismatch सह नाकारली पाहिजे. हा नियम यासाठी आहे कारण हेडर्सवर आधारित राउटिंग करणारा लोड बॅलन्सर आणि बॉडीवर प्रक्रिया करणारा सर्व्हर हे सत्यतेचे दोन भिन्न स्रोत असू शकतात. जर तुम्ही या हेडर्सवर आधारित राउटिंग किंवा रेट-लिमिटिंग करत असाल, तर आधी MCP-Protocol-Version तपासा: जुन्या आवृत्त्यांमध्ये हेडर आणि बॉडीची पडताळणी केली जात नसे, त्यामुळे त्या आवृत्त्यांमधील हेडर मूल्ये विश्वासार्ह नाहीत.

आवृत्तीमधील विसंगती आता हँडशेक अयशस्वी होण्याऐवजी विनंती-स्तरीय त्रुटी मानली जाते. ज्या सर्व्हरला विनंती केलेली आवृत्ती सपोर्टेड नाही, तो सर्व्हर 400 Bad Request सह त्रुटी -32022, UnsupportedProtocolVersion देतो आणि data.supported मध्ये तो कोणत्या आवृत्त्यांना सपोर्ट करतो याची यादी देतो. क्लायंट त्या यादीतून एक आवृत्ती निवडून पुन्हा प्रयत्न करतो.

स्टेट कुठे गेली: टोकन्स, कर्सर्स आणि सबस्क्रिप्शन्स

स्टेट गायब झालेली नाही. ती अशा ठिकाणी हलली आहे जिथे तुम्ही ती पाहू शकता आणि लॉग करू शकता.

क्रेडेंशियल्स प्रत्येक विनंतीमध्ये (request) समाविष्ट असतात. ओळख जोडण्यासाठी कोणतेही सेशन नसल्यामुळे, ॲक्सेस टोकन प्रत्येक HTTP कॉलसोबत पाठवले जाते आणि प्रत्येक वेळी त्याची पडताळणी केली जाते. तपशील खालील ऑथेंटिकेशन विभागात दिले आहेत.

कर्सर्सना त्यांची स्वतःची स्थिती स्वतःच वाहून न्यावी लागते. tools/list, resources/list, prompts/list आणि resources/templates/list वरील पेजिनेशन एक अपारदर्शक (opaque) कर्सर स्ट्रिंग वापरते आणि क्लायंटने त्याचे विश्लेषण किंवा बदल करू नयेत. सिंगल-प्रोसेस सर्व्हरवर सेशनद्वारे की (key) वापरून मेमरीमध्ये ऑफसेट ठेवणे सामान्य होते. आता कोणतेही सेशन नसल्यामुळे, कोणत्याही रिप्लिकाने लिस्टिंग पुन्हा सुरू करण्यासाठी कर्सर पुरेसा असावा लागतो. म्हणून, कर्सरमध्ये स्थिती एन्कोड करून त्यावर सही (sign) करा, किंवा सर्व रिप्लिका सामायिक करत असलेल्या स्टोरेजमध्ये ती ठेवा. अवैध कर्सरसाठी -32602 त्रुटी परत केली पाहिजे. कर्सरवर सही करा, कारण अपारदर्शक कर्सर हे क्लायंटने दिलेले इनपुट असते, जे तुमचा कोड डिकोड करतो आणि त्यावर विश्वास ठेवतो.

सबस्क्रिप्शन्स कनेक्शनशी नाही, तर विनंतीशी संबंधित असतात. ज्या क्लायंटला बदलांच्या सूचना हव्या आहेत, तो subscriptions/listen पाठवतो आणि त्यात त्याला हवे असलेल्या प्रकारांचे फिल्टर नमूद करतो: toolsListChanged, promptsListChanged, resourcesListChanged आणि resourceSubscriptions. सर्व्हर notifications/subscriptions/acknowledged सह उत्तर देतो आणि तो रिस्पॉन्स स्ट्रीम खुला ठेवतो. जर स्ट्रीम खंडित झाला, तर सर्व्हर काहीही साठवून ठेवत नाही आणि क्लायंट तो पुन्हा मिळवण्यासाठी subscriptions/listen पुन्हा पाठवतो.

क्रॉस-कॉल ॲप्लिकेशन स्टेट एक स्पष्ट हँडल बनते. जेव्हा सर्व्हरला दोन कॉल्सच्या दरम्यान काहीतरी लक्षात ठेवणे खरोखर आवश्यक असते, तेव्हा स्पेसिफिकेशनचे उत्तर म्हणजे सर्व्हरने तयार केलेला एक आयडेंटिफायर, जो सामान्य टूल आर्ग्युमेंट म्हणून परत पाठवला जातो. तो टूल स्कीमामध्ये दिसतो, तो लॉग केला जाऊ शकतो आणि तो कनेक्शनद्वारे कधीही सूचित केला जात नाही. ज्या सर्व्हरच्या मागे वापरकर्त्याचा प्रत्यक्ष डेटा असतो, जसे की स्वतः होस्ट केलेला MCP ईमेल सर्व्हर, तो सेशनऐवजी हे पॅटर्न वापरतो: मेलबॉक्स किंवा ड्राफ्ट आयडेंटिफायर हे एक टूल आर्ग्युमेंट असते, त्यामुळे कोणताही रिप्लिका पुढचा कॉल घेऊ शकतो. अनेक टूल्सना हँडलची अजिबात गरज नसते: तुमच्या स्वतःच्या SearXNG इन्स्टन्सद्वारे समर्थित सर्च टूल एक क्वेरी घेते आणि निकाल परत करते. यामध्ये पुढच्या कॉलसाठी काहीही राखून ठेवण्याची गरज नसते आणि कोणत्या रिप्लिकाने उत्तर दिले, याची काळजी करण्याचीही गरज नसते.

Deployment: reverse proxy, timeouts, health checks

MCP endpoint हा एक असा मार्ग आहे जो POST विनंत्या स्वीकारतो. बहुतेक ट्रॅफिक हे लहान विनंत्या आणि JSON प्रतिसादांचे असते, जे कोणताही प्रॉक्सी सहज हाताळू शकतो. अपवाद म्हणजे स्ट्रीमिंग प्रतिसाद, जिथे प्रॉक्सीची डीफॉल्ट सेटिंग्ज तुमच्या विरोधात काम करतात. जेव्हा तुम्ही लॅपटॉपवरील डेमोवरून VPS वर चालणाऱ्या MCP सर्व्हरवर जाता, तेव्हा हा भाग बदलतो.

location /mcp {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 1h;
    proxy_send_timeout 1h;
}

proxy_buffering off महत्त्वाचे आहे कारण nginx डीफॉल्टनुसार प्रॉक्सी केलेल्या प्रतिसादांचे बफरिंग करते. यामुळे SSE इव्हेंट्स बफर भरेपर्यंत किंवा प्रतिसाद संपेपर्यंत थांबवून ठेवले जातात. स्पेसिफिकेशननुसार सर्व्हरने SSE प्रतिसादांवर X-Accel-Buffering: no पाठवणे अपेक्षित आहे आणि nginx या हेडरचा आदर करते, त्यामुळे एक योग्य सर्व्हर तुमच्या प्रॉक्सीला स्वतःहून योग्य सूचना देतो. ही डायरेक्टिव्ह सेट करा, कारण हा तुमच्या नियंत्रणातील भाग आहे.

proxy_read_timeout डीफॉल्टनुसार 60 सेकंद असते. जर एखादा subscriptions/listen स्ट्रीम त्यापेक्षा जास्त काळ शांत राहिला, तर तो तुमच्या सर्व्हरद्वारे नाही, तर nginx द्वारे बंद केला जातो. त्यामुळे तुमच्या लॉग्समध्ये प्रक्रिया व्यवस्थित दिसते, पण क्लायंटच्या बाजूला स्ट्रीम तुटल्याचे दिसते. हे फक्त MCP लोकेशनवर वाढवा, संपूर्ण सर्व्हरवर नको. शांत कालावधीत कनेक्शन जिवंत ठेवण्यासाठी सर्व्हरने SSE कमेंट लाईन (कोलनने सुरू होणारी ओळ) पाठवावी, असे सुचवले जाते; यामुळे मध्यस्थ यंत्रणा स्ट्रीम बंद करत नाहीत.

Caddy ला कमी सेटिंग्जची गरज असते. वायर कार्यक्षमतेसाठी ते डीफॉल्टनुसार अंशतः बफरिंग करते आणि जेव्हा प्रतिसादात Content-Type: text/event-stream असते तेव्हा ते त्वरित फ्लश करते, त्यामुळे अतिरिक्त डायरेक्टिव्हशिवाय स्ट्रीमिंग काम करते.

mcp.example.com {
	reverse_proxy 127.0.0.1:8080 {
		health_uri /healthz
		health_interval 10s
	}
}

हेल्थ चेक कशाकडे निर्देश करतो ते लक्षात घ्या. MCP endpoint वर GET वापरून ॲक्टिव्ह चेक करू नका, कारण केवळ या रिव्हिजनची अंमलबजावणी करणारा सर्व्हर GET आणि DELETE ला 405 Method Not Allowed असे उत्तर देतो, तर Caddy ची डीफॉल्ट हेल्थ मेथड GET असते. यामुळे प्रॉक्सी पूर्णपणे निरोगी बॅकएंडला 'डाउन' म्हणून चिन्हांकित करेल. प्रॉक्सीसाठी /healthz सारखा साधा मार्ग वापरा आणि प्रोटोकॉलची तपासणी स्वतंत्रपणे POST द्वारे करा.

curl -sS https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

supportedVersions यादी असलेला 200 म्हणजे प्रक्रिया सुरू आहे आणि प्रोटोकॉलशी संवाद साधत आहे. JSON-RPC एरर -32601 असलेला 404 म्हणजे प्रक्रिया सुरू आहे, पण ती server/discover सर्व्ह करत नाही, जे प्रत्येक 2026-07-28 सर्व्हरने लागू करणे आवश्यक आहे. -32022 असलेला 400 म्हणजे तुमच्या चेकरने अशा व्हर्जनची मागणी केली आहे जे या बिल्डमध्ये सपोर्टेड नाही; डिपेंडन्सी अपग्रेडनंतर तुम्हाला नेमके हेच शोधायचे असते. ओपन सोर्स nginx मध्ये ॲक्टिव्ह हेल्थ चेक नसतात, त्यामुळे अपस्ट्रीमवर पॅसिव्ह max_fails आणि fail_timeout वापरा आणि प्रोटोकॉल चेक तुमच्या मॉनिटरिंगमधून चालवा.

रोलिंग रीस्टार्टमुळे आता फक्त चालू असलेल्या विनंत्यांचे नुकसान होते, इतर काहीही नाही. सर्व्हर ड्रेन करा, चालू असलेले POST पूर्ण होऊ द्या, नवीन प्रक्रिया सुरू करा आणि अयशस्वी झालेल्या विनंत्या क्लायंट पुन्हा पाठवतील. तुम्ही अजूनही जे गमावता ते म्हणजे कोणताही उघडा subscriptions/listen स्ट्रीम, कारण तो स्ट्रीम एका विशिष्ट प्रक्रियेशी थेट जोडलेला असतो. स्टेटलेसनेसने सेशन ॲफिनिटी काढून टाकली आहे, पण सध्या उघड्या असलेल्या स्ट्रीमसाठी कनेक्शन ॲफिनिटी काढलेली नाही आणि कोणताही राउटिंग नियम हे दुरुस्त करू शकत नाही. क्लायंटमधील फरक ओळखू शकतो: जो स्ट्रीम रिकाम्या subscriptions/listen रिझल्टसह संपतो तो व्यवस्थित बंद झाला आहे, आणि जो त्याशिवाय संपतो तो तुटला आहे, ज्याला क्लायंट पुन्हा कनेक्ट करण्याचे कारण मानू शकतो.

कॅशिंग आता पहिल्यांदाच शक्य होते. लिस्ट मेथड्सचे रिझल्ट आता ttlMs आणि cacheScope सोबत येतात आणि cacheScope: "public" हे सामायिक मध्यस्थांना सांगते की ते प्रतिसाद कॅश करू शकतात. हे सुरक्षित आहे कारण लिस्ट रिझल्ट आता प्रत्येक कनेक्शननुसार बदलत नाहीत, जे सेशन काढून टाकल्याचा थेट परिणाम आहे.

सत्र (session) नसताना ऑथेंटिकेशन का बदलते

सत्र असताना, initialize वर एकदा ऑथेंटिकेट करणे आणि त्यानंतर सत्र ID ला सर्व गोष्टींसाठी पुरावा मानणे सोपे होते. अशा प्रकारे वापरलेला सत्र ID हा एक 'bearer credential' असतो, ज्याला कोणताही प्रेक्षक (audience), कालबाह्यता (expiry) किंवा रद्द करण्याचा मार्ग (revocation path) नसतो आणि तो तुमच्या स्वतःच्या सर्व्हरद्वारे तयार केलेला असतो. सत्रे काढून टाकल्यामुळे तो शॉर्टकट निघून जातो आणि त्याची जागा घेणारी पद्धत अधिक कडक असते.

एक सुरक्षित MCP सर्व्हर OAuth 2.1 रिसोर्स सर्व्हर म्हणून काम करतो. क्लायंटकडून येणाऱ्या प्रत्येक HTTP विनंतीमध्ये Authorization: Bearer <access token> असणे आवश्यक आहे आणि सर्व्हर प्रत्येक विनंतीवर टोकनची पडताळणी करतो. पडताळणीमध्ये प्रेक्षकांचा (audience) समावेश असतो: RFC 8707 (Resource Indicators for OAuth 2.0) नुसार, सर्व्हरने हे निश्चित केले पाहिजे की टोकन विशेषतः त्याच्यासाठीच जारी केले गेले आहे आणि इतर कशासाठीही असलेले टोकन स्वीकारू किंवा पुढे पाठवू नये. क्लायंट सर्व्हरच्या कॅनोनिकल URI सह resource पॅरामीटर पाठवून योग्य प्रेक्षकाची विनंती करतात.

डिस्कव्हरी एका चॅलेंजद्वारे चालते. जेव्हा कोणतीही वापरण्यायोग्य टोकन नसलेली विनंती येते, तेव्हा सर्व्हर 401 Unauthorized ने उत्तर देतो.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

क्लायंट resource_metadata वाचतो, तो दस्तऐवज (RFC 9728, OAuth 2.0 Protected Resource Metadata, जे MCP सर्व्हरने लागू करणे आवश्यक आहे) मिळवतो, ऑथरायझेशन सर्व्हर शोधतो आणि फ्लो चालवतो. खूप कमी परवानग्या असलेले वैध टोकन 403 Forbidden सह error="insufficient_scope" आणि त्या ऑपरेशनसाठी आवश्यक असलेले स्कोप (scopes) मिळवते.

तुम्ही ते कसे चालवता याचे दोन परिणाम होतात. टोकन पडताळणी आता प्रत्येक सत्रात एकदा करण्याऐवजी प्रत्येक विनंतीवर होते, त्यामुळे प्रति कॉल एक नेटवर्क राउंड ट्रिप तुमच्या लॅन्सीमध्ये (latency) दिसून येईल: स्वाक्षरी, प्रेक्षक आणि कालबाह्यतेच्या आधारे स्थानिक पातळीवर पडताळणी करता येणारी टोकन्स वापरा किंवा टोकनद्वारे की (key) केलेले पडताळणी निकाल थोड्या काळासाठी कॅशे (cache) करा. आणि ओळख जपणारे सत्र नसल्यामुळे, प्रत्येक कॉलवर टोकनवरून ऑथरायझेशनची गणना करणे आवश्यक आहे. हे सत्र मॉडेलपेक्षा अधिक पारदर्शक आहे आणि ते एजंट प्रक्रियेतून क्रेडेंशियल्स बाहेर ठेवण्याच्या व्यापक पद्धतीशी जुळते, ज्याबद्दल AI एजंटपासून सिक्रेट्स दूर ठेवणे मध्ये माहिती दिली आहे.

या आवृत्तीबद्दल काय सत्य आहे आणि काय नाही

वर दिलेली सर्व माहिती 2026-07-28 आवृत्तीचे वर्णन करते. हे MCP चे कायमस्वरूपी वर्णन नाही आणि तुम्ही गेल्या वर्षी तैनात केलेल्या सर्व्हरचेही हे वर्णन नाही.

2025-11-25 आणि त्यापूर्वीचे क्लायंट आणि सर्व्हर अजूनही हँडशेक मॉडेल वापरतात. तांत्रिक तपशील (specification) अशा आवृत्त्यांना 'लेगसी' (legacy) मानतो आणि प्रति-विनंती-मेटाडेटा (per-request-metadata) असलेल्या आवृत्त्यांना 'आधुनिक' (modern) मानतो. जो सर्व्हर फक्त या आवृत्तीला सपोर्ट करतो, त्याने जुन्या क्लायंटला MCP एंडपॉइंटवर 405 Method Not Allowed ते GET किंवा DELETE असे उत्तर दिले पाहिजे. तसेच, कोणत्याही Mcp-Session-Id हेडरकडे दुर्लक्ष करावे (ते तयार करू नये किंवा इको करू नये) आणि Last-Event-ID कडे दुर्लक्ष करावे, कारण स्ट्रीम्स पुन्हा सुरू करता येत नाहीत (resumable नाहीत). ड्युअल-एरा सर्व्हर एकाच एंडपॉइंटवर दोन्ही सेवा देऊ शकतो: आधुनिक _meta असलेली विनंती स्टेटलेस (stateless) पद्धतीने हाताळली जाते आणि initialize विनंती जुन्या सत्राचे (session) नियम निवडते.

त्यामुळे, यातील कोणत्याही गोष्टीवर विश्वास ठेवण्यापूर्वी रिव्हिजन स्ट्रिंग तपासा. जर तुमचा SDK अजूनही initialize पाठवत असेल, तर तुमच्या डिप्लॉयमेंटसाठी सत्रे (sessions) अजूनही अस्तित्वात आहेत आणि वर नमूद केलेल्या सत्राशी संबंधित समस्या तुम्हालाच हाताळाव्या लागतील. हेच क्लायंटच्या बाजूलाही लागू होते: तुमच्या स्वतःच्या मशीनवरील एजंट प्रोसेस, जसे की running a coding agent on a VPS मधील सेटअप, तेव्हाच स्टेटलेस असते जर ती वापरत असलेली लायब्ररी आधुनिक आवृत्तीमध्ये संवाद साधत असेल. तुमचा रनटाइम कोणती आवृत्ती नेगोशिएट करतो ते वाचा, त्यानंतर तपशीलाची संबंधित आवृत्ती वाचा आणि हे पान संपूर्ण प्रोटोकॉलऐवजी एका विशिष्ट आवृत्तीचे वर्णन करत आहे असे समजा.

FAQ

Stateless MCP सर्व्हरचा अर्थ असा आहे का की मी काहीही साठवू शकत नाही?

नाही. Stateless हा शब्द प्रोटोकॉलचे वर्णन करतो, तुमच्या ॲप्लिकेशनचे नाही. डेटाबेस, रांगा (queues) आणि कॅशे नेहमीप्रमाणेच काम करतात. बदल एवढाच होतो की, अनेक कॉल्समध्ये पसरलेली स्थिती (state) क्लायंटने प्रत्येक विनंतीवर पाठवलेल्या स्पष्ट आयडेंटिफायरद्वारे दर्शविली पाहिजे, जसे की टूल आर्गुमेंटमध्ये सर्व्हरने दिलेला हँडल. तुम्ही कनेक्शनवरून संदर्भाचा (context) अंदाज लावू शकत नाही: स्पेसिफिकेशननुसार, सर्व्हरने क्षमता, प्रोटोकॉल आवृत्ती किंवा क्लायंटची ओळख प्रस्थापित करण्यासाठी त्याच कनेक्शनवरील मागील विनंत्यांवर अवलंबून राहू नये, कारण प्रत्येक विनंतीमध्ये _meta द्वारे ही माहिती पुरवली जाते.

मला अजूनही माझ्या लोड बॅलन्सरवर sticky sessions ची गरज आहे का?

सामान्य विनंत्यांसाठी गरज नाही. रिव्हिजन 2026-07-28 अंतर्गत, प्रत्येक POST स्वतःची प्रोटोकॉल आवृत्ती, क्षमता आणि क्रेडेन्शियल्स सोबत नेते, त्यामुळे कोणतीही प्रतिकृती (replica) कोणत्याही विनंतीला उत्तर देऊ शकते आणि round-robin पद्धत योग्य ठरते. फक्त एक दीर्घकाळ चालणारी गोष्ट उरते, ती म्हणजे subscriptions/listen रिस्पॉन्स स्ट्रीम, जे एकाच प्रक्रियेसाठी एक उघडे कनेक्शन असते. जेव्हा ती प्रक्रिया संपते तेव्हा हे स्ट्रीम संपते आणि क्लायंट ते पुन्हा प्रस्थापित करण्यासाठी subscriptions/listen पुन्हा पाठवतो. हे कनेक्शनचे आयुष्य आहे, सेशन ॲफिनिटी नाही आणि कोणताही राउटिंग नियम याला रोखू शकत नाही.

Mcp-Session-Id आणि HTTP GET स्ट्रीमचे काय झाले?

SEP-2567 आणि SEP-2575 अंतर्गत, रिव्हिजन 2026-07-28 मध्ये दोन्ही काढून टाकण्यात आले. केवळ या रिव्हिजनची अंमलबजावणी करणाऱ्या सर्व्हरने MCP एंडपॉईंटवर 405 Method Not Allowed ते GET आणि DELETE ला उत्तर दिले पाहिजे आणि Mcp-Session-Id हेडर परत पाठवण्याऐवजी त्याकडे दुर्लक्ष केले पाहिजे. सर्व्हरद्वारे सुरू केलेल्या बदल सूचना आता स्वतंत्र GET स्ट्रीमऐवजी subscriptions/listen विनंतीच्या रिस्पॉन्स स्ट्रीमवरून जातात. ज्या सर्व्हरना जुन्या क्लायंटना सेवा देणे आवश्यक आहे, ते या रिव्हिजनसोबत जुन्या रिव्हिजनच्या वर्तनाचीही अंमलबजावणी करतात.

हँडशेक नसलेल्या MCP सर्व्हरची हेल्थ चेक कशी करावी?

दोन स्तरांचा वापर करा. प्रॉक्सीची ॲक्टिव्ह चेक तुमच्या ॲप्लिकेशनद्वारे सर्व्ह केल्या जाणाऱ्या साध्या HTTP पाथवर ठेवा, कारण MCP एंडपॉईंटवर केलेली GET विनंती चुकीच्या पद्धतीने 405 रिस्पॉन्स देते आणि त्यामुळे सुस्थितीत असलेला बॅकएंड 'डाउन' म्हणून चिन्हांकित होऊ शकतो. त्यानंतर, प्रत्येक 2026-07-28 सर्व्हरने अंमलबजावणी करणे आवश्यक असलेल्या server/discover ला POST करून प्रोटोकॉल तपासा आणि खात्री करा की उत्तर HTTP 200 आहे आणि त्यात तुमच्या क्लायंटद्वारे वापरली जाणारी प्रोटोकॉल आवृत्ती आहे. JSON-RPC एरर -32601 असलेला 404 रिस्पॉन्स म्हणजे प्रक्रिया चालू आहे पण ती पद्धत सर्व्ह करत नाही, आणि -32022 असलेला 400 रिस्पॉन्स म्हणजे तुम्ही विचारलेली आवृत्ती त्या बिल्डद्वारे समर्थित नाही.