Web 2.0 2.0 का आगमन: MCP

• Model Context Protocol(MCP) को तेज़ी से अपनाया जा रहा है और यह एक नए open standard के रूप में उभर रहा है
• MCP का मुख्य मूल्य परिपूर्णता में नहीं, बल्कि openness और interoperability में है
• Web 2.0 का असली अर्थ closed platforms नहीं, बल्कि open API और data sharing है
• अतीत के बंद हो चुके दौर से फिर open web के मूल्य की ओर लौटने का रुझान बन रहा है
• MCP अपनाने से डेवलपर्स द्वारा platform control और transparency की माँग और बढ़ सकती है

---

MCP: नए open web का उदय

पिछले कुछ महीनों में डेवलपर्स के बीच Model Context Protocol(MCP) को लेकर रुचि विस्फोटक रूप से बढ़ी है। इसकी शुरुआत Anthropic ने 2023 में अपने LLM(Claude) सिस्टम को अलग-अलग apps के साथ interact करने लायक डिज़ाइन करके की थी। इसके बाद OpenAI ने ChatGPT में इसी protocol का support जोड़ा, और यह तेज़ी से एक standard के रूप में स्थापित हो गया। अब इसे Windows में भी अपनाया जा रहा है, और यह बड़े platforms तक फैल रहा है.

दिलचस्प बात यह है कि MCP की ताकत उसकी स्पष्टता या पूर्णता से ज़्यादा, उसके इस्तेमाल की सुविधा और गति में है। पारंपरिक, कड़ाई से डिज़ाइन किए गए standards से अलग, MCP कुछ हद तक अस्पष्ट और loosely defined specification होने के बावजूद व्यवहार में अच्छी तरह काम करता है। सबसे महत्वपूर्ण बात यह है कि यह एक open protocol है, इसलिए कोई भी इसका उपयोग कर सकता है.

असली open web का मतलब

वेब की वास्तविक दुनिया में, जब अपूर्ण और कुछ हद तक कमज़ोर standards को तेज़ी से अपनाया जाता है, तभी असली प्रगति होती है। इसी तरह की धारा ने "जहाँ भी आप podcasts सुनते हैं, वहाँ कभी भी सुनें" जैसी नवाचारों को जन्म दिया।

Web 2.0 की भावना open API, data sharing, और users व developers के नियंत्रण को बढ़ाने वाले open ecosystem की ओर उन्मुख थी। यह याद रखना ज़रूरी है कि Facebook जैसे closed platforms ही Web 2.0 को खत्म करने वाले प्रमुख कारक थे। पहले Flickr, del.icio.us, Upcoming जैसी सेवाओं ने sharing और connection को महत्व देने वाली संस्कृति का नेतृत्व किया था, और live blogs जैसे platforms पर API/protocol के open standards को लेकर सक्रिय चर्चा होती थी.

openness की वापसी

एक पीढ़ी बीतने के बाद, अब फिर interoperability को लेकर उम्मीदें बढ़ रही हैं। अतीत में बड़े tech कंपनियों की बंद नीतियों के कारण API बंद होने और सेवाएँ खत्म होने का अनुभव बार-बार हुआ। उदाहरण के लिए, लेखक द्वारा बनाया गया social network data analysis tool अंततः platform की API block होने के कारण बंद करना पड़ा। ऐसी नीतियों ने Web 2.0 के open data और compatibility वाले विज़न को तोड़ दिया। इसके कारण content embedding न हो पाना, data portability में बाधा जैसी समस्याएँ रोज़मर्रा की बात बन गईं.

लेकिन MCP के आने से AI एक trigger के रूप में programmability और openness की वापसी को आगे बढ़ा सकता है। कई platforms द्वारा एक ही protocol अपनाना तकनीकी आधार पर सकारात्मक चक्र को संभव बनाता है.

जब platforms protocol को उसी रूप में स्वीकार करते हैं और standardization के प्रति ईमानदार रहते हैं, तब पूरे ecosystem में सकारात्मक बदलाव आते हैं। यह ज़ोर देकर कहा गया है कि "specification से भी बेहतर बनाने" की डेवलपर महत्वाकांक्षा विडंबना से ecosystem को नुकसान पहुँचा सकती है। HTML भी एक perfect spec नहीं था, फिर भी वही इंटरनेट पर बड़े पैमाने की interoperability की नींव बना.

standards का पालन क्यों ज़रूरी है

डेवलपर्स की नई पीढ़ी एक ही protocol और format पर आधारित innovation की ताकत को सीधे अनुभव कर रही है। यह अनुभव उन्हें फिर से open standards के प्रति लगभग आग्रहपूर्ण बना सकता है। माहौल कुछ वैसा ही बनता दिख रहा है जैसा उस दौर में था जब RSS, Podcast, OpenID, OAuth, OpenSocial जैसे open formats ने वास्तव में users को ताकत दी थी.

यह समय सिर्फ बड़ी कंपनियों के अधिकार का नहीं, बल्कि developers और user communities के अपने अधिकार जताने का भी है। सभी को platforms से experience control और transparency की माँग करने में सक्षम होना चाहिए, और MCP जैसे open standards अपनाने पर platform के अंदरूनी कामकाज और data उपयोग की transparency ज़रूरी रूप से साथ आनी चाहिए। MCP खुला है, लेकिन internal workings और security issues के मामले में अभी भी अधूरा है, इसलिए आगे सुधार की ज़रूरत है.

Web 2.0 की भावना के फिर लौटने की संभावना

MCP सभी समस्याओं का जादुई समाधान नहीं है, लेकिन यह Web 2.0 के दौर के खुले ecosystem की वापसी को प्रेरित करने वाला एक मौका बन सकता है। AI पर चर्चा में अतिशयोक्ति और आलोचना की कमी जैसी सीमाएँ अभी भी मौजूद हैं.

फिर भी, खासकर युवा डेवलपर्स के बीच programmable web और closedness से बाहर निकलने के मूल्य को फिर से महत्व मिल रहा है। वेब कुछ विशाल कंपनियों की निजी संपत्ति नहीं था, बल्कि एक ऐसा खुला मंच था जिसे हर कोई अपने मनचाहे तरीके से उपयोग कर सकता था, और MCP उस दर्शन को फिर से सामने ला सकता है.

[GN⁺]

Hacker News राय

• मेरा मानना है कि बहुत से लोग इस बात को नज़रअंदाज़ कर देते हैं कि MCP का मूल आकर्षण enterprise software के लिए इसकी उपयुक्तता है। LLM एक तरह के universal translator की तरह काम कर सकता है और उन systems को जोड़ने वाली flexible middle layer बन सकता है जिन्हें आपस में जोड़ना कठिन है। वास्तव में B2B SaaS उद्योग में भी MCP servers को अपनाने की रफ़्तार तेज़ है। कंपनियों के भीतर भी API usage patterns के अनुसार सीमाएँ और संरचना समायोजित करने पर चर्चा बढ़ रही है। भले ही protocol कई मायनों में पूरी तरह “enterprise-ready” न हो, मुझे नहीं लगता कि यह बहुत महत्वपूर्ण है। standards के इतिहास में बार-बार देखा गया है कि थोड़े कच्चे या ‘ढीले-ढाले’ specs भी अगर बाज़ार की ज़रूरत पूरी करें तो अंततः अपनाए जाते हैं।
  • मेरी समझ में MCP लंबे connection पर चलने वाले RPC जैसा है और आम तौर पर WebSocket आधारित होता है। व्यक्तिगत रूप से मुझे RPC ज़्यादा आसान लगता है। पहला कारण यह है कि यह REST endpoints डिज़ाइन करते समय होने वाली अनावश्यक बहसों को कम करता है, जैसे POST से पूरा resource replace किया जाए या PUT से केवल fields बदले जाएँ। दूसरा, LLM को REST terminology/semantics जानने की ज़रूरत नहीं होती; वह सिर्फ RPC methods देखकर तुरंत call कर सकता है। निष्कर्षतः, ये दोनों बहुत बड़े फ़ायदे हैं।
  • corporate नज़रिए से देखें तो MCP एक शानदार revenue model है। हर data request सीधे paid LLM execution से जुड़ी होती है। दूसरी ओर, अफ़सोस यह है कि MCP अपनाने के साथ schema negotiation जैसी कोई optimization मौजूद नहीं है जो future queries को सस्ता बना सके।
  • पहले से ही REST और OpenAPI मौजूद हैं, और वे self-discovery जैसी क्षमताएँ सपोर्ट करते हैं। मेरा मानना है कि जो कंपनियाँ MCP देंगी, वे वैसे भी अच्छी APIs उपलब्ध कराएँगी।
  • इस बात से मैं सचमुच सहमत हूँ। बड़े enterprises में बहुत से engineers ऐसे होते हैं जो सुबह 9 से शाम 5 तक ही शानदार काम पर ध्यान देते हैं और उसके बाद कंपनी के बारे में सोचना भी नहीं चाहते। ऐसे में company के लिए working hours के भीतर employee productivity को अधिकतम करना ही सबसे तार्किक विकल्प बन जाता है।
• मैं सोच रहा हूँ कि MCP server के ज़रिए cockroach जैसी जीवित चीज़ों को नियंत्रित करने वाले प्रयोग आने में कितना समय लगेगा। वास्तव में पिछले 10 से अधिक वर्षों में robo-roach experiments, cyborg cockroach जैसी कई मिसालें सामने आ चुकी हैं।
• पहले Unix developers specifications को बहुत सख़्ती से लिखते थे, लेकिन समय बदल गया है। मैं कहना चाहूँगा कि यही कठोरता और extensibility की थकान XML-आधारित architecture की विफलता के कारणों में से एक थी। उस दौर में XSL, XHTML, XSD, WSDL, RDF, RSS जैसी चीज़ों के कारण architecture अत्यधिक जटिल हो गया था, और इसी वजह से JSON जैसे सरल formats लोकप्रिय हुए। हालांकि हाल के समय में मैंने XML के उपयोग में फिर बढ़ोतरी का रुझान भी देखा है। खास तौर पर Anthropic जैसे LLM system prompts में XML या Markdown जैसे structured text का काफ़ी उपयोग होता दिखता है। लेकिन मुझे लगता है कि MCP model ग़लत है। model से यह कहने के बजाय कि वह जानकारी "खींचकर लाए", बेहतर तरीका यह है कि जानकारी को पहले से "push" किया जाए, यानी context पहले से उपलब्ध कराया जाए।
  • दिलचस्प बात यह है कि हाल ही में JSON-आधारित macro extension language बनाते समय मुझे एहसास हुआ कि मैं असल में XSLT या XPath को फिर से आविष्कार कर रहा था। graph traversal में xpath spec की ताक़त देखकर मैं प्रभावित हुआ। BaseX जैसे tools से arbitrary XML को DB में लाया जा सकता है और XPATH/XQUERY से query किया जा सकता है, जो बहुत उपयोगी है। अगर LLM के लिए hallucination रोकने वाला कोई भरोसेमंद data interface बनाना हो, तो मुझे लगता है कि सबसे अच्छा समाधान यह होगा कि system prompt में XML schema डाला जाए और उससे data queries generate कराई जाएँ।
  • मुझे संदेह है कि “context को पहले से push करने वाला model” व्यवहार में कितनी समस्याओं तक निपट सकता है। अगर उपयोगकर्ता पहले से जानकारी जानता हो, तो वह सीधे समस्या हल कर देगा। MCP की ज़्यादातर मांग मुझे “15 अलग-अलग sources को जोड़ना सीखे बिना बस query process कर दो” जैसी लगती है।
  • LLM tag-आधारित XML को अच्छी तरह संभाल लेते हैं, लेकिन व्यवहार में अधिकांश लोग ठीक-ठाक XML blob (<?xml version="1.0" encoding="UTF-8"?> की शुरुआत, namespaces, schemas आदि सहित) का उपयोग नहीं करते; वे बस SGML-style tags के एक ढीले समूह जैसी चीज़ें लिखते हैं।
  • मैं इस व्यावहारिक कारण पर ज़ोर देना चाहूँगा कि semantic web वास्तव में इसलिए विफल हुआ क्योंकि वह ad insertion या business model integration में सफल नहीं हो पाया।
  • मैं “context push” दृष्टिकोण के प्रति आलोचनात्मक हूँ। LLM की context processing capacity, यानी context window, बहुत सीमित होती है, इसलिए केवल आवश्यक जानकारी को न्यूनतम रूप में देना ही सर्वोत्तम है। जब individual models स्वयं ज़रूरी context चुनकर pull कर सकें, तभी इन सीमाओं को पार करने की संभावना अधिक है।
• MCP ऐसा लग सकता है कि AI की लोकप्रियता के कारण विभिन्न platforms किसी भी उद्देश्य के लिए programmable हो जाएँगे, लेकिन मुझे लगता है कि इसका अंत विफलता में होगा। semantic web भी इसलिए असफल हुआ क्योंकि वह टिकाऊ revenue structure नहीं बना पाया। यही बात AI के उस “research” फ़ंक्शन पर भी लागू होती है जो web की जगह गहराई से खोज करता है। उदाहरण के लिए, restaurant menus को metadata के रूप में publish किया जा सकता था ताकि “Texas में सबसे सस्ता taco खोजो” जैसी automation संभव हो सके, लेकिन वास्तविकता में हमें data lockdown और उसे bypass करने वाले AI crawlers की infrastructure race दिखाई देती है। बड़े परिप्रेक्ष्य में देखें तो मौजूदा system अक्षम है।
  • MCP अंततः robots.txt के evolved रूप जैसा ही है। मूल विचार यही है: “मेरे resources को ठीक से describe करो, तो मैं उनका उपयोग करूँगा।” 1990s के Java-आधारित agent systems भी agents के बीच information asymmetry की समस्या के कारण विफल हुए थे, और चिंता यह है कि अगर इस design limitation को पूरी तरह हटा दिया जाए, तो समाज और business का पूरा तंत्र ही रुक सकता है।
  • मेरा अनुभवजन्य निष्कर्ष यह है कि open APIs की समस्या केवल monetary revenue नहीं है। यदि practically unlimited resources न झोंके जाएँ, तो AI agents के request bots की लहर resource exhaustion पैदा करेगी और अंततः दिवालियापन तक ले जा सकती है। लंबे समय में RPC pay-per-call pricing एक स्थिर विकल्प लगती है। model/agent operators clearing house की तरह payment संभालेंगे और उस लागत को subscriptions आदि में शामिल करेंगे—मुझे यही दिशा सबसे संभावित लगती है।
  • HATEOAS जैसे REST architecture के ideal 2010s की शुरुआत में बहुत लोकप्रिय थे, लेकिन swagger yaml जैसी automation tools के अलावा कोई वास्तविक विस्तार नहीं हुआ और वे धीरे-धीरे समाप्त हो गए। मुझे लगता है कि इसकी terminology ही इतनी कठिन थी कि उसने अपनी विफलता खुद तय कर ली।
  • मैं इस विचार से सहमत नहीं हूँ कि human-readable text कोई artificial barrier है। इसके विपरीत, restaurants से JSON production skills या software adoption की मांग करना ही असली artificial barrier है। NLP tools की वजह से मौजूदा data को उसी रूप में इस्तेमाल करना संभव हो गया है, जिससे development cost लगभग शून्य तक सिमट जाती है। भाषा की कुछ अस्थिरता भले हो, पर वह तो मानवीय भाषा का स्वाभाविक गुण है, इसलिए मैं उसे बड़ी समस्या नहीं मानता।
  • semantic web की आलोचना करते हुए यह बात कहने में सावधानी चाहिए, लेकिन अगर कोई restaurant owner वास्तव में ऐसा चाहे तो वह कभी भी metadata publish कर सकता है, और इससे buyers तथा sellers को आसानी से जोड़ने का अवसर मिल सकता है। WordPress plugins का उदाहरण लें तो schema.org/Restaurant, Menu, MenuItem, Offer जैसे metadata support पहले से मौजूद हैं। इसलिए मुझे लगता है कि सबसे बड़ी बाधा शायद Cloudflare जैसी gatekeeping है। वास्तव में यही Python automation ideas को रोकने वाला व्यावहारिक कारक हो सकता है।
• चूँकि LLM API documentation पढ़कर अपने-आप adapt कर सकता है, इसलिए पहले की तुलना में standard API spec compliance अब उतनी अनिवार्य नहीं रह गई है। MCP spec अपनाया जाए या नहीं, यह अपेक्षा कि हर site “API दे” अपने-आप में एक बड़ा बदलाव है।
  • वास्तविक वातावरण में API documentation कमज़ोर हो सकती है, इसलिए LLM ग़लत code या calls generate कर सकता है। फिर user उसे ठीक करके LLM को वापस देता है, और परिणामस्वरूप अंत में एक middle layer—MCP-जैसा server—बन ही जाता है। LLM को direct API access देने पर security और resource management के लिहाज़ से भी ख़तरे पैदा होते हैं, जैसे अत्यधिक calls से भारी लागत आ जाना। ऐसे कई अतिरिक्त pain points हैं, और उनमें से कुछ का समाधान शुरू से बीच में MCP-जैसा interface रखकर किया जा सकता है। यह अलग सवाल है कि वह “middleman” ज़रूरी तौर पर MCP ही हो, लेकिन इस समय के लिए यह काफ़ी व्यावहारिक समाधान है।
• MCP को लेकर मेरी सबसे बड़ी चिंता इसका कमज़ोर protocol level नहीं, बल्कि यह है कि Anthropic और OpenAI जैसी कंपनियों के भीतर की teams के पास ही सुधार और बदलाव की शक्ति केंद्रित है। मुझे यह आशंका भी हुई कि यह spec वास्तविक developers/operators की ज़रूरतों से ज़्यादा brainstorming stage में अटका हुआ है। इससे कुछ-कुछ Visa-Mastercard duopoly जैसी छाया महसूस होती है।
  • Microsoft भी steering committee में शामिल हुआ
• “semantic web” असल में शायद केवल grammatical structure भर था, और संभव है कि MCP में ही पहली बार वास्तविक, व्यावहारिक क्रियान्वयन की संभावना हो।
• एक धारणा यह है कि “पुराने Unix developers बहुत ज़्यादा नखरीले थे”, लेकिन विडंबना यह है कि Unix ही “जल्दी बनाओ और तोड़कर देखो” संस्कृति का मूल स्रोत था। पीढ़ियाँ बदल जाएँ, पर सार शायद नहीं बदलता।
• एक वास्तविक चिंता यह भी है कि MCP का दुरुपयोग Google search engine optimization (SEO) की तरह AI की ओर लक्षित ads और spam फैलाने के लिए हो सकता है।
• मुझे लगता है कि यह भ्रम पालने से बचना चाहिए कि MCP की वजह से हर किसी को हर तरह के data तक आसानी से पहुँच मिल जाएगी। हक़ीक़त शायद यह होगी कि कई परतों वाले payment auth, allowed white list IPs और अन्य security controls के कारण असली users को अंततः सिर्फ “ERR 402” ही दिखाई देगा।