Stateless MCP server में क्या बदलाव आए हैं?

Stateless MCP server क्या है

एक stateless MCP server requests के बीच किसी भी client-specific state को सुरक्षित नहीं रखता है। प्रत्येक request में protocol version, client capabilities और वे credentials होते हैं जिनकी server को उत्तर देने के लिए आवश्यकता होती है, इसलिए किसी भी मशीन पर चल रही कोई भी process किसी भी request का उत्तर दे सकती है। MCP (Model Context Protocol, वह wire format जिसका उपयोग agents tools तक पहुँचने के लिए करते हैं) ने revision 2026-07-28 में इसे एक नियम बना दिया, जिसने initialize handshake और उसके नीचे मौजूद HTTP session को हटा दिया।

यही इसका मुख्य परिचालन उद्देश्य है। एक server जो प्रति-client कुछ भी सुरक्षित नहीं रखता, उसे बिना session affinity वाले सामान्य load balancer के पीछे रखा जा सकता है, deploy के दौरान clients को बाधित किए बिना restart किया जा सकता है, और एक के बजाय चार समान processes के रूप में चलाया जा सकता है। एक session-oriented server अतिरिक्त मशीनरी के बिना इनमें से कोई भी कार्य नहीं कर सकता है।

Model Context Protocol एक stateless protocol है: request को process करने के लिए आवश्यक सभी जानकारी स्वयं request में ही निहित होती है। एक server प्रत्येक request को स्वतंत्र रूप से process करता है; पिछले requests से किसी भी state का अनुमान नहीं लगाया जाना चाहिए, भले ही वे एक ही connection या stream पर क्यों न हों।

Stateless होने का अर्थ यह नहीं है कि आपका server कुछ भी store नहीं करता है। आपका database, queue और cache अभी भी वहीं मौजूद हैं। इसका अर्थ यह है कि protocol connection पर कोई state नहीं रखता है, इसलिए server को किसी connection, process या open socket को "यह client, बातचीत के बीच में है" के विकल्प के रूप में नहीं मानना चाहिए।

2026-07-28 के revision में क्या हटाया गया

2026-07-28 अगस्त 2026 तक specification का वर्तमान revision है। 2025-11-25 की तुलना में, इसमें सत्रों (sessions) को सपोर्ट करने वाली पाँच चीजें हटा दी गई हैं।

• initialize request और notifications/initialized notification। अब कोई handshake नहीं होता है (SEP-2575)।
• Mcp-Session-Id header, और HTTP DELETE के साथ सत्र समाप्ति (SEP-2567)।
• स्टैंडअलोन HTTP GET stream जिस पर सर्वर notifications push करते थे। इसे subscriptions/listen द्वारा प्रतिस्थापित किया गया है, जो एक सामान्य POST है जिसका response एक long-lived stream है।
• SSE (server-sent events) stream की resumability। Last-Event-ID header और प्रति-इवेंट IDs हटा दिए गए हैं, इसलिए टूटी हुई stream in-flight request को खो देती है और client को इसे एक नए request ID के साथ नए request के रूप में फिर से जारी करना होगा।
• ping, logging/setLevel और notifications/roots/list_changed। Log level अब प्रति-request field है, जो _meta में io.modelcontextprotocol/logLevel है।

एक method जोड़ा गया है, और प्रत्येक सर्वर को इसे लागू करना होगा। server/discover एक ही call में सर्वर के समर्थित protocol versions, क्षमताओं और पहचान को लौटाता है। यह handshake के सबसे करीब बची हुई चीज है, और clients के लिए इसे call करना वैकल्पिक है।

Production में session transport को चलाना कठिन क्यों था

2025-11-25 और उससे पहले के वर्ज़न में, सर्वर initialization के समय एक session ID बना सकता था और उसे InitializeResult पर Mcp-Session-Id हेडर में वापस भेज सकता था। इसके बाद क्लाइंट को हर बाद के अनुरोध (request) पर वह हेडर भेजना पड़ता था। नेगोशिएटेड प्रोटोकॉल वर्ज़न और क्लाइंट की क्षमताएं सर्वर की मेमोरी में उसी ID के आधार पर स्टोर रहती थीं। इन विकल्पों में से प्रत्येक की एक परिचालन लागत (operational cost) होती है।

• रीस्टार्ट करने पर session table डिलीट हो जाती थी। स्पेसिफिकेशन के अनुसार, सर्वर को किसी भी ऐसे अनुरोध का जवाब 404 Not Found के साथ देना होता था जिसमें मृत (dead) session ID हो, और क्लाइंट को नए InitializeRequest के साथ फिर से शुरुआत करनी पड़ती थी। हर डिप्लॉयमेंट हर कनेक्टेड क्लाइंट के लिए एक रीकनेक्ट इवेंट बन जाता था।
• दूसरी रेप्लिका को पहली रेप्लिका के सेशन की जानकारी नहीं होती थी। स्केल आउट करने का मतलब था लोड बैलेंसर पर sticky routing का उपयोग करना, या एक साझा session store रखना जिसे हर रेप्लिका हर अनुरोध पर पढ़ती थी।
• session table वह मेमोरी थी जो idle क्लाइंट्स के साथ बढ़ती जाती थी। DELETE वैकल्पिक था, और जो क्लाइंट इसे भेजे बिना बंद हो जाते थे, वे पीछे एंट्रीज़ छोड़ जाते थे।
• लिस्ट रिज़ल्ट हर कनेक्शन पर अलग हो सकते थे, इसलिए सर्वर के सामने कैशिंग करना असुरक्षित था।

सेशन को हटाने से ये चारों समस्याएं एक साथ खत्म हो जाती हैं। किसी भी कॉन्फ़िगरेशन को बदलने से पहले इस बदलाव को समझना आवश्यक है।

प्रत्येक अनुरोध में अब क्या शामिल होता है

MCP endpoint पर किया गया प्रत्येक 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 हेडर प्रत्येक अनुरोध पर आवश्यक है। Mcp-Name को tools/call, resources/read और prompts/get पर भेजा जाना आवश्यक है। हेडर का मान बॉडी से मेल खाना चाहिए, और जो सर्वर बॉडी को प्रोसेस करता है, उसे बेमेल होने पर 400 Bad Request और त्रुटि कोड -32020, HeaderMismatch के साथ अस्वीकार करना चाहिए। यह नियम इसलिए है क्योंकि हेडर के आधार पर रूटिंग करने वाला लोड बैलेंसर और बॉडी के आधार पर निष्पादन करने वाला सर्वर, सत्य के दो अलग-अलग स्रोत हैं। यदि आप इन हेडर्स पर रूटिंग या रेट-लिमिटिंग करते हैं, तो पहले MCP-Protocol-Version की जाँच करें: पुराने रिवीज़न में हेडर और बॉडी के बीच सत्यापन नहीं होता था, इसलिए उन संस्करणों पर हेडर का मान विश्वसनीय नहीं है।

संस्करण संबंधी असहमति अब विफल हैंडशेक के बजाय एक सामान्य प्रति-अनुरोध त्रुटि है। जो सर्वर अनुरोधित संस्करण को लागू नहीं करता है, वह त्रुटि -32022, UnsupportedProtocolVersion के साथ 400 Bad Request का उत्तर देता है, और data.supported में उन संस्करणों की सूची देता है जिनका वह समर्थन करता है। क्लाइंट उस सूची में से एक को चुनता है और पुनः प्रयास करता है।

स्टेट कहाँ गई: टोकन, कर्सर और सब्सक्रिप्शन

स्टेट गायब नहीं हुई है। यह उन जगहों पर चली गई है जिन्हें आप देख सकते हैं और लॉग कर सकते हैं।

क्रेडेंशियल्स हर रिक्वेस्ट में जाते हैं। यहाँ कोई ऐसा सेशन नहीं है जिससे पहचान (identity) को जोड़ा जा सके, इसलिए एक्सेस टोकन हर HTTP कॉल के साथ जाता है और हर बार वैलिडेट होता है। विवरण नीचे दिए गए ऑथेंटिकेशन सेक्शन में हैं।

कर्सर को अपनी स्थिति खुद संभालनी होती है। tools/list, resources/list, prompts/list और resources/templates/list पर पेजिनेशन एक अपारदर्शी (opaque) कर्सर स्ट्रिंग का उपयोग करता है, और क्लाइंट्स को इसे पार्स या मॉडिफाई नहीं करना चाहिए। सिंगल-प्रोसेस सर्वर पर सेशन के आधार पर मेमोरी में ऑफसेट रखना आम था। बिना सेशन के, कर्सर इतना सक्षम होना चाहिए कि कोई भी रेप्लिका लिस्टिंग को फिर से शुरू कर सके, इसलिए स्थिति को कर्सर के अंदर एनकोड करके साइन करें, या इसे ऐसे स्टोरेज में रखें जिसे सभी रेप्लिका शेयर करते हों। एक अमान्य कर्सर को -32602 रिटर्न करना चाहिए। इसे साइन करें क्योंकि एक अपारदर्शी कर्सर अभी भी क्लाइंट द्वारा दिया गया इनपुट है जिसे आपका कोड डिकोड करता है और जिस पर भरोसा करता है।

सब्सक्रिप्शन एक रिक्वेस्ट से संबंधित होते हैं, कनेक्शन से नहीं। जो क्लाइंट बदलाव की सूचनाएं चाहता है, वह उन प्रकारों को नाम देते हुए एक फिल्टर के साथ subscriptions/listen भेजता है जिन्हें वह चाहता है: toolsListChanged, promptsListChanged, resourcesListChanged और resourceSubscriptions। सर्वर notifications/subscriptions/acknowledged के साथ जवाब देता है और उस रिस्पॉन्स स्ट्रीम को खुला रखता है। यदि स्ट्रीम ड्रॉप हो जाती है, तो सर्वर कुछ भी नहीं रखता है, और क्लाइंट इसे वापस पाने के लिए subscriptions/listen को फिर से भेजता है।

क्रॉस-कॉल एप्लिकेशन स्टेट एक स्पष्ट हैंडल बन जाती है। जब सर्वर को वास्तव में कॉल्स के बीच कुछ याद रखने की आवश्यकता होती है, तो स्पेसिफिकेशन का उत्तर सर्वर द्वारा बनाया गया एक आइडेंटिफायर होता है जिसे एक सामान्य टूल आर्ग्युमेंट के रूप में वापस भेजा जाता है। यह टूल स्कीमा में दिखाई देता है, इसे लॉग किया जा सकता है, और यह कभी भी कनेक्शन द्वारा निहित (implied) नहीं होता है। एक सर्वर जिसके पीछे वास्तविक प्रति-उपयोगकर्ता डेटा है, जैसे कि एक self-hosted MCP email server, सेशन के बजाय इस पैटर्न का उपयोग करता है: मेलबॉक्स या ड्राफ्ट आइडेंटिफायर एक टूल आर्ग्युमेंट है, इसलिए कोई भी रेप्लिका अगली कॉल को पिक कर सकता है।

Deployment: reverse proxy, timeouts, health checks

MCP endpoint एक ऐसा path है जो POST requests स्वीकार करता है। अधिकांश traffic छोटी requests और JSON responses का होता है, जिसे कोई भी proxy आसानी से संभाल लेता है। अपवाद streaming response है, जहाँ proxy की default settings आपके विरुद्ध काम करती हैं। जब आप laptop demo से VPS पर चल रहे MCP server पर जाते हैं, तो यही वह हिस्सा है जो बदल जाता है।

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 डिफ़ॉल्ट रूप से proxied responses को buffer करता है, जो SSE events को तब तक रोक कर रखता है जब तक buffer भर न जाए या response समाप्त न हो जाए। Specification यह भी कहती है कि servers को SSE responses पर X-Accel-Buffering: no भेजना चाहिए, और nginx उस header का सम्मान करता है, इसलिए एक सही server आपके proxy को स्वयं ही सही निर्देश देता है। इस directive को set करें, क्योंकि यह वह हिस्सा है जिसे आप नियंत्रित करते हैं।

proxy_read_timeout डिफ़ॉल्ट रूप से 60 seconds पर set होता है। एक subscriptions/listen stream जो उससे अधिक समय तक शांत रहती है, उसे nginx द्वारा बंद कर दिया जाता है, न कि आपके server द्वारा। इसलिए आपके logs में process healthy दिखेगी, लेकिन client पर stream dropped दिखाई देगी। इसे केवल MCP location पर बढ़ाएं, पूरे server पर नहीं। Servers को शांत अवधि के दौरान keep-alive के रूप में एक SSE comment line (colon से शुरू होने वाली line) भेजने के लिए भी प्रोत्साहित किया जाता है, जो मध्यस्थों (intermediaries) को stream को time out करने से रोकता है।

Caddy को कम कॉन्फ़िगरेशन की आवश्यकता होती है। यह network दक्षता के लिए डिफ़ॉल्ट रूप से आंशिक रूप से buffer करता है और जब response में Content-Type: text/event-stream होता है, तो तुरंत flush कर देता है, इसलिए streaming बिना किसी अतिरिक्त directive के काम करती है।

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

ध्यान दें कि वह health check कहाँ point कर रही है। MCP endpoint पर GET के साथ active check न करें, क्योंकि केवल इस revision को लागू करने वाला server GET और DELETE के लिए 405 Method Not Allowed उत्तर देता है, और Caddy का डिफ़ॉल्ट health method GET है। ऐसी स्थिति में proxy एक पूरी तरह से healthy backend को down mark कर देगा। Proxy के लिए /healthz जैसा एक साधारण path रखें, और protocol की जाँच अलग से 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 list ले जाने वाला 200 यह दर्शाता है कि process चल रही है और protocol का पालन कर रही है। JSON-RPC error -32601 वाला 404 यह दर्शाता है कि process चल रही है लेकिन server/discover को serve नहीं कर रही है, जिसे हर 2026-07-28 server को लागू करना अनिवार्य है। -32022 के साथ 400 का अर्थ है कि आपके checker ने ऐसे version के लिए अनुरोध किया है जिसे यह build support नहीं करता है, और dependency upgrade के बाद आपको यही पकड़ना होता है। Open source nginx में active health checks नहीं होते हैं, इसलिए upstream पर passive max_fails और fail_timeout का उपयोग करें और अपनी monitoring से protocol check चलाएं।

Rolling restart में अब आपको केवल चल रही requests का नुकसान होता है, और कुछ नहीं। Drain करें, open POSTs को पूरा होने दें, नई process शुरू करें, और clients विफल हुए अनुरोधों को पुनः भेज देंगे। एकमात्र चीज़ जो आप अभी भी खो देते हैं वह है कोई भी open subscriptions/listen stream, क्योंकि वह stream एक विशिष्ट process से live connection है। Statelessness ने session affinity को हटा दिया है। इसने अभी खुली हुई stream के लिए connection affinity को नहीं हटाया है, और कोई भी routing rule इसे ठीक नहीं कर सकता है। Client अंतर बता सकता है: एक stream जो खाली subscriptions/listen result के साथ समाप्त होती है, वह शालीनता से बंद हो गई है, और जो उसके बिना समाप्त होती है वह drop हो गई है, जिसे client reconnect करने के कारण के रूप में देख सकता है।

Caching पहली बार संभव हो जाती है। List methods के परिणाम अब ttlMs और cacheScope ले जाते हैं, और cacheScope: "public" साझा मध्यस्थों को बताता है कि वे response को cache कर सकते हैं। यह केवल इसलिए सुरक्षित है क्योंकि list के परिणाम अब प्रति connection बदलते नहीं हैं, जो कि sessions को हटाने का सीधा परिणाम है।

जब session न हो तो authentication क्यों बदल जाता है

Session के साथ, initialize पर एक बार authenticate करना और उसके बाद session ID को ही हर चीज़ के लिए प्रमाण मान लेना आसान था। इस तरह इस्तेमाल किया गया session ID एक bearer credential है जिसका कोई audience, कोई expiry और कोई revocation path नहीं होता, जिसे आपका अपना सर्वर जारी करता है। Session को हटाने से वह शॉर्टकट खत्म हो जाता है, और उसका विकल्प अधिक सख्त है।

एक सुरक्षित MCP सर्वर OAuth 2.1 resource server के रूप में कार्य करता है। क्लाइंट से आने वाले प्रत्येक HTTP request में Authorization: Bearer <access token> होना चाहिए, और सर्वर हर request पर token को validate करता है। Validation में audience शामिल है: सर्वर को यह पुष्टि करनी होगी कि token विशेष रूप से उसी के लिए जारी किया गया था, RFC 8707 (Resource Indicators for OAuth 2.0) के अनुसार, और उसे किसी अन्य चीज़ के लिए बने tokens को स्वीकार या पास नहीं करना चाहिए। क्लाइंट सर्वर के canonical URI के साथ resource parameter भेजकर सही audience का अनुरोध करते हैं।

Discovery एक challenge से शुरू होती है। जब कोई request बिना किसी उपयोगी token के आती है, तो सर्वर 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 को पढ़ता है, उस document को fetch करता है (RFC 9728, OAuth 2.0 Protected Resource Metadata, जिसे MCP servers को implement करना अनिवार्य है), authorization server को ढूंढता है और flow को चलाता है। बहुत कम permissions वाले एक वैध token को 403 Forbidden मिलता है, जिसमें error="insufficient_scope" और उस operation के लिए आवश्यक scopes होते हैं।

इसे चलाने के तरीके के दो परिणाम हैं। Token validation अब हर session में एक बार के बजाय हर request पर होता है, इसलिए प्रति call एक introspection endpoint पर network round trip आपकी latency में दिखाई देगा: ऐसे tokens को प्राथमिकता दें जिन्हें आप signature, audience और expiry के आधार पर स्थानीय रूप से verify कर सकें, या token द्वारा keyed एक छोटी window के लिए validation result को cache करें। और चूंकि identity रखने वाला कोई session नहीं है, इसलिए authorization की गणना हर call पर token से की जानी चाहिए। यह session model की तुलना में अधिक पारदर्शी है, और यह credentials को agent process से बाहर रखने की व्यापक प्रथा के साथ मेल खाता है, जिसे AI agent से secrets को दूर रखना में कवर किया गया है।

इस revision के बारे में क्या सत्य है और क्या नहीं

ऊपर दी गई सभी जानकारी revision 2026-07-28 का वर्णन करती है। यह MCP का स्थायी वर्णन नहीं है, और न ही यह उस सर्वर का वर्णन है जिसे आपने पिछले वर्ष deploy किया था।

2025-11-25 और उससे पुराने revision वाले clients और servers अभी भी handshake model का उपयोग करते हैं। Specification इन revisions को legacy कहती है, और per-request-metadata वाले revisions को modern कहती है। यदि कोई सर्वर केवल इस revision का समर्थन करता है और उसे कोई पुराना client मिलता है, तो उसे MCP endpoint पर 405 Method Not Allowed से GET या DELETE का उत्तर देना चाहिए, किसी भी Mcp-Session-Id header को बिना mint या echo किए अनदेखा करना चाहिए, और Last-Event-ID को अनदेखा करना चाहिए क्योंकि streams resumable नहीं होती हैं। एक dual-era सर्वर एक ही endpoint पर दोनों को serve कर सकता है: एक request जिसमें modern _meta है, उसे stateless तरीके से serve किया जाता है, और एक initialize request पुराने session semantics का चयन करता है।

इसलिए, इस जानकारी पर भरोसा करने से पहले revision string की जाँच करें। यदि आपका SDK अभी भी initialize भेजता है, तो आपके deployment के लिए sessions अभी भी वास्तविक हैं और ऊपर बताए गए session-संबंधी मुद्दों का प्रबंधन आपको ही करना होगा। यही बात client side पर भी लागू होती है: आपके अपने box पर चलने वाली एक agent process, जैसे कि VPS पर कोडिंग एजेंट चलाना में बताया गया सेटअप, इस अर्थ में केवल तभी stateless है यदि वह library जिसका उपयोग वह करती है, किसी modern revision का उपयोग करती है। अपने runtime द्वारा negotiate किए गए version को पढ़ें, फिर specification के संबंधित revision को पढ़ें, और इस पृष्ठ को पूरे protocol के बजाय केवल एक विशिष्ट revision के वर्णन के रूप में देखें।

FAQ

क्या stateless MCP server का मतलब है कि मैं कुछ भी स्टोर नहीं कर सकता?

नहीं। Stateless शब्द protocol के लिए है, न कि आपके application के लिए। Databases, queues और caches पहले की तरह ही काम करते हैं। बदलाव यह है कि कई calls के बीच state को बनाए रखने के लिए एक स्पष्ट identifier का उपयोग करना होगा जिसे client हर request के साथ भेजे, जैसे कि tool argument में server द्वारा दिया गया handle। आप connection से context का अनुमान नहीं लगा सकते: specification के अनुसार, server को capabilities, protocol version या client identity स्थापित करने के लिए एक ही connection पर पिछली requests पर निर्भर नहीं रहना चाहिए, क्योंकि हर request में _meta के माध्यम से ये जानकारी दी जाती है।

क्या मुझे अभी भी अपने load balancer पर sticky sessions की आवश्यकता है?

सामान्य requests के लिए नहीं। Revision 2026-07-28 के तहत प्रत्येक POST अपना protocol version, capabilities और credentials साथ लाता है, इसलिए कोई भी replica किसी भी request का उत्तर दे सकता है और round-robin ठीक काम करता है। केवल एक चीज जो लंबे समय तक चलती है, वह है subscriptions/listen response stream, जो एक single process के लिए एक single open connection है। यह उस process के समाप्त होने पर बंद हो जाता है, और client इसे फिर से स्थापित करने के लिए subscriptions/listen भेजता है। यह session affinity के बजाय connection lifetime है, और कोई भी routing rule इसे नहीं रोकता है।

Mcp-Session-Id और HTTP GET stream का क्या हुआ?

दोनों को revision 2026-07-28 में, SEP-2567 और SEP-2575 के तहत हटा दिया गया था। केवल इस revision को लागू करने वाले server को MCP endpoint पर 405 Method Not Allowed से GET और DELETE का उत्तर देना चाहिए, और Mcp-Session-Id header को वापस echo करने के बजाय ignore करना चाहिए। Server द्वारा शुरू की गई change notifications अब standalone GET stream के बजाय subscriptions/listen request के response stream पर जाती हैं। जो servers पुराने clients को सेवा देना जारी रखना चाहते हैं, वे इस revision के साथ-साथ पुराने revision का व्यवहार भी लागू करते हैं।

बिना handshake वाले MCP server की health check कैसे करें?

दो स्तरों का उपयोग करें। Proxy की active check को एक साधारण HTTP path पर point करें जिसे आपका application serve करता है, क्योंकि MCP endpoint पर GET सही तरीके से 405 return करता है और एक healthy backend को down के रूप में चिह्नित कर देगा। फिर server/discover POST करके protocol की स्वयं जाँच करें, जिसे हर 2026-07-28 server को लागू करना होगा, और यह सुनिश्चित करें कि उत्तर HTTP 200 है और उसमें वह protocol version शामिल है जिसका उपयोग आपके clients करते हैं। JSON-RPC error -32601 के साथ 404 का मतलब है कि process चल रही है लेकिन उस method को serve नहीं कर रही है, और -32022 के साथ 400 का मतलब है कि जिस version के लिए आपने पूछा है, वह उस build द्वारा समर्थित नहीं है।