MCP पर एक आलोचनात्मक नज़र

• MCP(Model Context Protocol) LLM को बाहरी दुनिया के साथ इंटरैक्ट करने के लिए एक standardized integration तरीका देता है
• हाल में IBM का ACP और Google का A2A जैसे समान standard सामने आए हैं, और MCP implementations तथा संबंधित tools तेज़ी से बढ़ रहे हैं
• लेकिन design में भ्रम, अधूरा documentation, और वास्तविक protocol spec की कमी जैसी अपरिपक्व engineering practices को समस्या के रूप में रेखांकित किया गया है
• HTTP+SSE और Streamable HTTP जैसे मौजूदा proposed transport तरीके complexity और security issues बढ़ाते हैं, और WebSocket के उपयोग को एक विकल्प के रूप में सुझाया गया है
• नवीनतम protocol authorization और session management में inconsistency रखते हैं और ज़रूरत से ज़्यादा complexity जोड़ते हैं

---

MCP और हालिया रुझानों की समीक्षा

• MCP एक open protocol है, जिसे applications द्वारा large language models(LLM) को context देने के तरीके को standardize करने के लिए बनाया गया है
• पिछले एक महीने में MCP, LLM को agent में बदलने वाले एक अहम standard के रूप में उभरा है, और इसका उपयोग व implementation तेज़ी से फैल रहे हैं
• IBM का ACP और Google का A2A जैसे, समान उद्देश्य वाले अधिक orthodox standards भी तेज़ी से सामने आ रहे हैं

Engineering practices और protocol specification की समस्याएँ

• वास्तविक implementation और documentation का स्तर कई जगह कमज़ोर दिखाई देता है
• बड़ी tech कंपनियाँ model training में भारी निवेश करती हैं, लेकिन SDK और documentation का स्तर कम होने से users में भ्रम पैदा होता है
• MCP में भी ऐसी ही समस्याएँ दिखती हैं; कुछ design अव्यावहारिक हैं और specification, examples, तथा guidelines की कमी है

Transport protocol पर चर्चा

stdio transport तरीका

• Stdio MCP server और client को local environment में pipe(stdout, stdin) के ज़रिए सीधे जोड़ने का पारंपरिक तरीका है
• इसमें जटिल socket handling या OS-specific issues कम होते हैं, और environment variables, input/output streams जैसी सरल environment configuration संभव होती है

HTTP+SSE / Streamable HTTP तरीका

• web युग के अनुरूप HTTP-based support देने के इरादे से HTTP+SSE और Streamable HTTP तरीके अपनाए गए हैं
• लेकिन WebSocket का विकल्प बनने की कोशिश में यह तरीका उलटे अधिक ambiguity, design confusion, और complexity पैदा करता है
• एक ही session और connection को कई तरीकों से create या terminate किया जा सकता है, जिससे server-side state management और security पर काफी बोझ पड़ता है

MCP server/client implementation examples में कठिनाइयाँ

• आधिकारिक Go SDK की अनुपस्थिति सहित कई भाषाओं में support की कमी साफ़ दिखाई देती है
• documentation और specification अस्पष्ट होने के कारण कई बार वास्तविक implementation reverse engineering के सहारे करना पड़ता है
• अधिकांश example servers Python, JavaScript आधारित हैं, फिर भी dependency और portability issues के कारण उन्हें production environment में लागू करना कठिन है
• server implementation में SSE/Streamable HTTP socket जैसा दिखने की कोशिश करता है, लेकिन व्यवहार में session और connection state को लगातार बनाए रखना कठिन होता है, और message queue जैसी अलग infrastructure की ज़रूरत पड़ती है

HTTP+SSE और Streamable HTTP की संरचना व समस्याएँ

HTTP+SSE mode

• client server के साथ एक SSE session खोलता है, फिर अलग endpoint पर write request भेजता है; server 202 response लौटाता है और मौजूदा SSE connection के माध्यम से response भेजता है
• session connection और state synchronization बनाए रखना ज़रूरी है, लेकिन इस प्रक्रिया का documentation अधूरा है और operational complexity बहुत अधिक है

Streamable HTTP mode

• session creation, SSE open, और response delivery सभी में कई तरीके मिलेजुले रूप में इस्तेमाल होते हैं, जिससे एक request-response flow सुसंगत नहीं रहता
• कई तरह के state management, अलग-अलग endpoints और header approaches के मिश्रण से व्यावहारिक implementation और scalability में गंभीर बाधाएँ पैदा होती हैं

सामान्य निहितार्थ

• तकनीकी complexity बढ़ने के साथ developer की cognitive load और maintenance का बोझ बढ़ता है, और अलग-अलग server/client implementations के बीच compatibility mismatch और unpredictable behavior जैसी समस्याएँ उभरती हैं
• server को हर state और connection स्थिति को track करना पड़ता है, और distributed environment में efficient scaling तथा state synchronization और भी कठिन हो जाती है

Security implications

• सूक्ष्म और विविध connection/session तरीके session hijacking, replay attacks, और denial of service(DoS) जैसी state management security vulnerabilities को बढ़ाते हैं
• कई entry points और response mechanisms attack surface को बढ़ाते हैं, और अनचाहे flow के माध्यम से malicious activity को छिपाने की संभावना बनती है

Authorization protocol में भ्रम

• मौजूदा specification सिर्फ HTTP transport के लिए OAuth2 जैसी बाध्यता लगाती है, जबकि STDIO transport में मनमाने ढंग से environment variables इस्तेमाल करने जैसे असंगत नियम लागू करती है
• सिर्फ HTTP transport पर जटिल OAuth2 implementation थोपने का कारण भी भ्रम और असंगति पैदा करता है

सुधार के सुझाव

• एक ही JSON RPC protocol पर transport को व्यावहारिक रूप से Stdio और WebSocket तक सरल करना चाहिए
• Stdio environment के variables को HTTP environment के headers से, और input/output को क्रमशः WebSocket के bidirectional streams से map करना उपयुक्त होगा
• इससे अनावश्यक session tracking, state management, और अनेक exception handling को हटाया जा सकता है
• WebSocket को सभी HTTP-based transports के लिए standard choice होना चाहिए, और इससे जटिल state synchronization issues भी सुलझ सकते हैं

वैकल्पिक protocols की तुलना और बाज़ार रुझान

• IBM का ACP और Google का A2A, agent interoperability के लिहाज़ से अधिक सरल transport design और agent discovery capabilities देते हैं
• लेकिन मूल रूप से इन्हें अधिकांश MCP build environments के भीतर अलग tools के रूप में integrate किया जा सकता है
• लगातार नए protocols का उभरना standards की भरमार का जोखिम पैदा कर सकता है, इसलिए transport की simplicity को प्राथमिकता देना industry growth के लिए महत्वपूर्ण है

[GN⁺]

Hacker News राय

• मुझे पूरा यक़ीन है कि LLM vendors के लिखे दस्तावेज़ इतने भ्रमित करने वाले इसलिए हैं क्योंकि वे दस्तावेज़ लिखने के लिए खुद LLM का इस्तेमाल कर रहे हैं। यह बहुत खराब तरीका है, और खासकर specification जैसे काम में LLM का उपयोग करना, अच्छे दस्तावेज़ लिखने के लिए LLM इस्तेमाल करने से भी कहीं ज़्यादा बुरा है। specification लिखने की प्रक्रिया खुद ही सबसे अहम होती है; इसमें human designers का सोच-समझकर खामियों, कमियों और edge cases को पहचानना और उन्हें संभालना ज़रूरी है। MCP specification में मुझे ऐसी मानवीय गहराई के निशान बहुत कम दिखते हैं। उसका खास सपाट अंदाज़, बिखराव, और list-केंद्रित संरचना बिल्कुल LLM के लिखे हुए जैसी लगती है
  • DeepSeek का documentation उल्टा इस वजह से समस्या वाला है कि उसमें spelling और grammar की गलतियाँ बहुत ज़्यादा हैं। ऐसी कंपनी, जो दिन-भर भाषा से ही काम करती है और जिसके पास एक समय दुनिया का बेहतरीन English LLM तक था, अगर पेशेवर दिखने लायक documentation भी न बना पाए, तो यह सचमुच अजीब है
  • मुझे भी बहुत मज़बूती से लगता है कि यह specification भी LLM ने लिखी है। सारे संकेत उसी ओर इशारा करते हैं। मेरा अंदाज़ा है कि ज़्यादातर products अब investors को IPO के लिए दिखाने वाले ऐसे systems बन चुके हैं जो बस सबसे plausible output का average निकालते हैं
  • अगर यह सच है, तो यह वाकई दुखद है। Anthropic में बहुत होशियार लोग हैं, फिर भी महत्वपूर्ण ecosystem के एक core component में ऐसी चीज़ होना अफ़सोसजनक है
  • अभी जाकर मेरे दिमाग में आया कि AI coding vendors के पास documentation को जानबूझकर कठिन बनाने की motivation भी हो सकती है। अगर वे ऐसा code बना दें जिसे इंसान न समझ सकें और केवल उनकी AI ही interpret कर सके, तो users उनकी खास AI service पर पूरी तरह निर्भर हो जाएंगे। अगर वे 2 साल के भीतर असली programmers को पूरी तरह replace नहीं कर पाए, तो यह strategy अंततः consumers को ही खत्म कर देगी और उनके अपने market को भी गिरा देगी। आख़िर में इंसानों और AI के बीच अनुवाद-योग्य न रहने वाला code का एक विशाल ढेर ही बचेगा
  • जब मैं LLM द्वारा लिखी prose पढ़ता हूँ तो मेरा ध्यान टूट जाता है, और अब लगता है कि यह सिर्फ मेरी समस्या नहीं है। मशीनों द्वारा बनाया गया यह दोहरावदार और संदर्भहीन लेखन गहरे विचारों से खाली होता है और धीरे-धीरे भावनात्मक थकान भी पैदा करता है। जब यही LLM technical specifications भी लिखने लगते हैं, तो ऐसे हिस्से अनजाने में घुस जाते हैं जिन्हें लेखक खुद भी नहीं समझता। यही बात मुझे बढ़ती हुई चिंता देती है
  • DeepSeek का documentation कुल मिलाकर इतना बुरा नहीं लगा। यह जल्दी-जल्दी बनाया हुआ लगता है, लेकिन स्तर खराब नहीं है। इसका मतलब यह हो सकता है कि "LLM से लिखा documentation हमेशा बुरा ही होता है"—इस तर्क के कुछ अपवाद भी हो सकते हैं
• आजकल LLM क्षेत्र software paradigms की नकल कुछ cheat code की तरह तेज़ी से कर रहा है। remote functions expose करने के तरीके के कई उदाहरण पहले से रहे हैं—DLL, gRPC, SOAP, IDL, dCOM वगैरह—फिर भी मौजूदा LLM दुनिया को जैसे इनके अस्तित्व का भी ठीक से पता नहीं है। उम्मीद है समय के साथ चीज़ें ज़्यादा mature होंगी, लेकिन जो अधूरा काम बचा है, उसे अंततः निपटाना ही पड़ेगा
  • कुछ महीनों में यह ज़रूर mature होगा, लेकिन शुरुआती Python ecosystem को देखकर याद आता है कि कैसे गलतियाँ नीचे वाले stack में जम जाती हैं और फिर सब उसी के ऊपर नए tools बनाते जाते हैं। इस बार दुख की बात यह है कि AI ecosystem के पास अतीत की वही गलतियों का इतिहास पहले से मौजूद होने के बावजूद वह उसी दिशा में बढ़ रहा है
  • जब मैंने पहली बार MCP देखा तो COM/DCOM याद आया, और पुराना DLL Hell भी दिमाग में आया। आगे MCP कैसे चलता है, यह मैं देखना चाहता हूँ
  • मुझे अब तक ऐसा कोई स्पष्ट explanation नहीं मिला जिससे समझ आ सके कि MCP ठीक-ठीक है क्या, और पुरानी development languages की शब्दावली में इसे क्या कहा जा सकता है
  • मैं यह बताना चाहता हूँ कि ऐसे सख़्त और declarative protocol में LLM की संभावित meaning space और semantic ताकत गायब हो जाती है। शायद ज़्यादा सहज तरीका यह हो कि web root में बस एक agents.json file रख दी जाए और semantic conversation के ज़रिए agents खुद-ब-खुद काम संभाल लें। तब नतीजतन HTTP ही agents का standard input/output बन जाएगा
  • मुझे लगता है कि दिए गए सभी उदाहरण उपयुक्त हैं
  • क्या MCP, JSON-RPC पर आधारित है?
• मैं लेख की कुल दिशा से सहमत हूँ, खासकर MCP site पर कोई ठोस जानकारी न मिल पाने वाला वह उलझनभरा अनुभव मैंने भी महसूस किया है। RFC पढ़ना कठिन होता है, लेकिन "बस SDK इस्तेमाल करो" से तो कहीं बेहतर है
  • अच्छा होता अगर ज़्यादा लोग इस blog post की अहमियत समझें। MCP अपनाने से थोड़ा रुककर यह दोबारा देखना चाहिए कि क्या इसकी तकनीकी बुनियाद सच में मजबूत है। अभी बहुत उत्साह है, लेकिन जैसे ही implementation के स्तर पर गहराई में जाएंगे, निराशा हो सकती है। core functionality में WebSocket जैसी कई decisions सवाल खड़े करती हैं, और सब कुछ नहीं तो भी इसका कुछ हिस्सा जल्दबाज़ी में बनाए गए workaround जैसा लगता है
  • अफ़सोस है कि site पर कोई साफ़ specification नहीं है। specification का आधा हिस्सा जैसे Sonnet से निकाला गया लगे, और protocol वास्तव में कैसे काम करता है यह स्पष्ट रूप से लिखा ही नहीं गया। इसके मुकाबले GraphQL specification कहीं बेहतर लिखी गई है
• अभी AI क्षेत्र का अधिकतर काम mathematicians, (data) scientists, students, और amateur enthusiasts कर रहे हैं। professional software engineers के मानकों से देखें तो इसमें बहुत कुछ weekend project के स्तर का, यानी अभी अपरिपक्व, लगता है
  • मुझे लगता है कि professional software engineers वास्तव में काम का बड़ा हिस्सा कर रहे हैं
• MCP को शुरू से stateless HTTP के साथ जाना चाहिए था। ज़्यादातर servers में state बनाए रखने की ज़रूरत नहीं होती; globally state store करना या सिर्फ session identifier रखना ही काफ़ी होता
  • मुझे MCP के actual interaction structure की समझ नहीं आती। यह stateless क्यों नहीं है, connection खुला क्यों रखना पड़ता है—मैं इसका कारण जानना चाहता हूँ
  • मेरा व्यक्तिगत अनुभव कम है, लेकिन request के बाद connection बंद कर दें तो अगली request के लिए फिर से connect करना पड़ेगा। session को खुला रखना है या बंद करना है, यह usage pattern, memory usage और कई दूसरे variables पर निर्भर करता है
• मैं ninja.ai नाम की Ruby on Rails आधारित MCP service बना रहा हूँ। यह एक app store है जो one-click में MCP servers install करता है। यह client device पर Model Context Protocol server को Tauri के ज़रिए install करता है। Rails के माध्यम से cloud MCP servers भी देता है। मैं HTTP+SSE या Streamable HTTP को लेकर आलोचनात्मक हूँ। bidirectional real-time communication के लिए WebSockets बेहतर हैं, और Rails में SSE support सीमित होने की वजह से मुझे endpoints को Falcon web server पर migrate करना पड़ा। यह जानना दिलचस्प होगा कि Shopify engineers ने Streamable HTTP क्यों चुना। शायद इसकी वजह infrastructure/deployment constraints हों। यह भी ध्यान देने योग्य है कि MCP transport layer abstracted है। भविष्य की implementations में WebSockets या WebRTC जोड़ने की पर्याप्त गुंजाइश है
• मैं MCP registries में से एक (glama.ai/mcp/servers) का operator हूँ। लेखक की राय से मैं आंशिक रूप से सहमत हूँ, लेकिन protocol अभी बहुत शुरुआती चरण में है, इसलिए आगे इसमें काफी बदलाव हो सकते हैं। उम्मीद से कहीं ज़्यादा ध्यान मिलने की वजह से शुरुआत में servers की संख्या कुछ दर्जनों से अचानक हज़ारों तक पहुँच गई, लेकिन उनमें से सिर्फ कुछ ही वास्तव में काम कर रहे थे, इसलिए छँटाई में बहुत समय लगा। यह MCP के mature होने से पहले ही उस पर public attention आ जाने का असर था। लेकिन हाल में ecosystem—जैसे code frameworks, registries, MCP-supporting clients—हैरान करने वाली रफ़्तार से बढ़ा है। सिर्फ आधे साल में ऐसा बदलाव असामान्य है। अगर यही रुझान रहा तो मुझे भविष्य उज्ज्वल लगता है। नए लोगों के लिए उपयोगी resources का एक संग्रह भी उपलब्ध कराया गया है
  • protocol design की शुरुआत में गलती हो जाए तो उसे हमेशा ढोना पड़ता है, इसलिए specification को विनम्रता और सावधानी से बनाना चाहिए। SSE जैसी कोई Rube Goldberg machine अगर एक बार रह गई, तो हो सकता है उसे बाद में ठीक ही न किया जा सके और वह स्थायी बन जाए। enterprise level पर कोई भी protocol-breaking बदलाव आसान नहीं होता, इसलिए शुरुआती decisions में लंबे समय तक फँसे रहना पड़ सकता है
  • MCP protocol खुद समय के साथ evolve होगा, यह तो स्वाभाविक है। शुरुआत से ही उसमें पूरी परिपक्वता की उम्मीद करना ज़्यादा अजीब है। सबसे बढ़कर, agentic API standardization सच में बहुत शक्तिशाली बदलाव है। अगर आप खुद code लिखकर deploy करें और AI उसे तुरंत पहचानकर अपने-आप इस्तेमाल करने लगे, तो उसका असर सीधे अनुभव करने पर ही समझ आता है
  • मेरी चिंता यह है कि इतनी तेज़ी के बीच MCP कहीं transport layer design को बहुत जल्दी स्थायी रूप से स्वीकार न कर ले। इससे 90s के browser wars जैसी standard fragmentation की स्थिति बन सकती है, जो बहुत लंबे समय तक हल नहीं होती—जैसे IE11 बहुत लंबे समय तक बना रहा था
• Authentication को लेकर जो विवाद था, उस पर पहले ही updates शुरू हो चुके हैं। Anthropic और security community के साथ मिलकर MCP में resource server (RS) और authorization server (AS) की roles separation लागू की गई है। नए protocol version के आधिकारिक होने तक अस्थायी रूप से एक draft specification प्रकाशित की गई है
  • मैं जानना चाहता हूँ कि MCP spec का कितना हिस्सा LLM output है। क्या बार-बार दिखने वाले warning signs देखकर लोगों ने इसे सहज रूप से भाँप लिया?
  • मैं खुद को काफ़ी neutral मानता हूँ, लेकिन OAuth draft जैसे बस ऊपर-ऊपर से copy किया गया लगता है, और HTTP इस्तेमाल करते समय बिना विकल्प के इसे मानना पड़े—यह संरचना मुझे पसंद नहीं। असल में इसे कहीं ज़्यादा साफ़ तरीके से ऐसे व्यवस्थित किया जा सकता था कि client और server, दोनों के लिए OAuth2 support वैकल्पिक हो
• MCP के Streamable HTTP release को लेकर मैंने एक issue उठाया था कि क्या सब कुछ सिर्फ HTTP requests से नहीं किया जा सकता। MCP specification LLM और tools को जोड़ने के लिए एक promising universal solution लगती है, लेकिन व्यवहार में इसे authentication, streaming, tool-specific custom commands, और tools की reliability verification जैसी कई मुश्किलों का सामना करना पड़ता है। मुझे लगता है कि केवल REST API से integration करना ज़्यादा सरल है। OpenAI या Gemini जैसी कंपनियों ने भी MCP अपनाने की बात कही है, लेकिन मेरा अनुमान है कि specification जल्द ही ऐसे UI और interaction layers में mismatch से टकराएगी जिन्हें वह चाहती ही नहीं, और इससे brand-fit की समस्या या authentication hijack होने जैसे मुद्दे सामने आएँगे
  • Anthropic ने MCP बनाया हो, फिर भी ChatGPT की तुलना में उसका scale काफ़ी छोटा है। यह सवाल बना रहता है कि OpenAI, Google जैसी बड़ी कंपनियाँ क्या लंबे समय तक किसी बाहरी team द्वारा तय की गई user experience की सीमाओं वाली specification को स्वीकार करेंगी। पहले ChatGPT Plugins के साथ भी शानदार engineering होने के बावजूद consumer experience की सीमाओं की वजह से असफलता देखी गई थी। फिर भी मैं एक मज़बूत community की ताकत पर दाँव लगाने को तैयार हूँ
  • blog post प्रकाशित होने के बाद मैंने भी इसी तरह का issue सीधे दर्ज किया था। यह इतना महत्वपूर्ण मामला है कि इसमें गलती हो जाए तो उसे पलटना बहुत कठिन होगा
• मुझे समझ नहीं आता कि MCP इतना लोकप्रिय क्यों हो रहा है, लेकिन जो भी हो, यह trend बन चुका है। मैं सुनना चाहता हूँ कि OpenAPI specification की तुलना में MCP किस मायने में बेहतर है
  • मेरी राय में MCP की लोकप्रियता का बड़ा कारण यह है कि हाल में LLMs की tool usability वास्तव में बेहतर हुई है। 2023 के OpenAI plugins इसलिए विफल हुए क्योंकि उस समय LLMs tool use के मामले में पर्याप्त भरोसेमंद नहीं थे, जबकि MCP का timing कहीं बेहतर रहा
  • MCP server शुरू करना बहुत आसान है, और entry barrier कम होना भी एक बड़ा कारण है। tools बढ़ने पर LLM को भेजा जाने वाला text भी बढ़ता है, लेकिन अगर OpenAPI दिया जाए तो individual paths की detailed information और explanatory messages भेजकर Claude भी बेहतरीन integration कर सकता है
  • MCP के महत्वपूर्ण होने का एक कारण यह है कि OpenAPI static documentation है, इसलिए LLM को request generation की पूरी प्रक्रिया खुद संभालनी पड़ती है, जबकि MCP servers abstraction के ज़रिए यह बोझ कम कर देते हैं। नतीजतन LLM के नज़रिए से यह आसान, तेज़ और सुरक्षित बन जाता है
  • मैं MCP को perfect नहीं मानता, लेकिन OpenAPI की तुलना में यह कुछ मायनों में LLMs के लिए ज़्यादा उपयुक्त है। सबसे पहले, MCP tools को कहीं छोटे और सरल रूप में specify किया जा सकता है, जबकि OpenAPI specs अक्सर इतने बड़े होते हैं कि वे LLM context का बहुत ज़्यादा हिस्सा घेर लेते हैं। LLM असल में calls execute नहीं करता, वह output text generate करता है, इसलिए MCP वाला तरीका ज़्यादा natural लगता है। और MCP tools के addition/change जैसी dynamic संरचनाओं के प्रति भी कहीं अधिक flexible है, जिससे OpenAPI की static limitations पार की जा सकती हैं। हाँ, समस्याएँ भी साफ़ हैं, खासकर transport layer में सुधार की काफी गुंजाइश है, लेकिन representative libraries काफ़ी अच्छी तरह implement की गई हैं