/sse जाल: 387 सर्वर जो खराब दिखते हैं पर हैं नहीं

MCP दो अलग तरीकों से HTTP बोलता है, और ये आपस में बदले नहीं जा सकते। Streamable HTTP सीधे एक एंडपॉइंट पर JSON-RPC भेजता है। पुराना HTTP+SSE ट्रांसपोर्ट बिल्कुल अलग है: पहले आप एक स्ट्रीम खोलते हैं, फिर सर्वर बताता है कि कहाँ भेजना है।

गलत होने पर कैसा दिखता है

यदि आप HTTP+SSE एंडपॉइंट पर initialize अनुरोध भेजते हैं, तो त्रुटि नहीं मिलती। यह मिलता है:

HTTP 200
content-type: text/event-stream

event: endpoint
data: https://example.com/my-mcp/api/process

दो सौ OK। न कोई त्रुटि कोड, न शिकायत। बस एक शालीन सूचना: "असली एंडपॉइंट वहाँ है।" और जो क्लाइंट इसकी अपेक्षा नहीं कर रहा, वह इसे खाली उत्तर समझ लेता है।

जाल यही है। सफलता लौटाने वाली विफलता को पहचानना, 500 लौटाने वाली विफलता से कहीं कठिन है।

हम खुद इसमें गिरे

जिन सर्वरों को हम पढ़ नहीं पाते, उन्हें "unknown" कहते हैं। जब देखा कि यह श्रेणी इतनी बड़ी क्यों है, तो पता चला कि 387 सर्वर दरअसल HTTP+SSE एंडपॉइंट हैं जिन पर हम गलत तरीके से अनुरोध भेज रहे थे। जिन सर्वरों का URL /sse पर समाप्त होता है, उनमें 84% unknown चिह्नित थे — जबकि पूरे कैटलॉग में यह 10% है। आठ गुना अंतर संयोग नहीं, उँगलियों का निशान है।

वे सर्वर हमेशा ठीक थे। गलत प्रोटोकॉल हम बोल रहे थे।

कैसे बचें

• खाली या अपठनीय JSON-RPC बॉडी वाले 200 उत्तर को मृत सर्वर नहीं, ट्रांसपोर्ट बेमेल मानिए।
• यदि उत्तर का कंटेंट टाइप text/event-stream है और पहली घटना का नाम endpoint है, तो उसका अनुसरण कीजिए और अनुरोध वहीं भेजिए।
• केवल URL पर भरोसा मत कीजिए। /sse पर समाप्त होना संकेत है, गारंटी नहीं — और कई HTTP+SSE एंडपॉइंट /sse पर समाप्त होते ही नहीं।

यदि आप सर्वर प्रकाशित करते हैं, तो सबसे सस्ता उपाय है अपनी रजिस्ट्री प्रविष्टि में बताना कि आप कौन-सा ट्रांसपोर्ट बोलते हैं। अधिकांश क्लाइंट आप पर भरोसा करेंगे।