Web 2.0 2.0 का आगमन: MCP

 (anildash.com)
2 पॉइंट द्वारा GN⁺ 2025-05-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Model Context Protocol(MCP) एक specification है जिसे Anthropic ने LLMs को बाहरी apps और systems से जोड़ने के लिए बनाया था। OpenAI द्वारा ChatGPT में support देने के बाद यह कई platforms के common interface की तरह फैल गया
  • Specification ढीला और अधूरा हो, फिर भी अगर कई participants जल्दी से वही तरीका अपनाते हैं, तो असली web पर open protocol ताकत हासिल कर सकता है
  • Web 2.0 की मूल value बंद social sites से ज़्यादा open APIs और interoperable tools से बने developer और user ecosystem के करीब थी
  • Facebook और Twitter जैसे बड़े platforms ने APIs बंद करके interoperability की जिस उम्मीद को कमजोर किया, MCP उसे AI coding tools की धारा में फिर से programmable platform के रूप में जीवित कर सकता है
  • MCP कोई universal solution नहीं है और data processing की अपारदर्शिता व security risks भी बड़े हैं, लेकिन यह standards compliance और transparency मांगने का नया अवसर बन सकता है

MCP के standard की तरह फैलने की पृष्ठभूमि

  • Model Context Protocol, यानी MCP, Anthropic द्वारा Claude के लिए design की गई specification है
    • इसका उद्देश्य LLM को कई apps से जानकारी मांगने या दूसरे systems के साथ interact करने में सक्षम बनाना है
  • कुछ महीने पहले OpenAI ने ChatGPT में इसी protocol को support किया, जिसके बाद MCP कई जगहों पर अपनाए जाने वाले standard जैसा बन गया
  • Windows में भी MCP शामिल हुआ, जो इसके फैलाव की सीमा दिखाता है
  • अहम बात specification की completeness से ज़्यादा यह है कि कई players ने वही interface जल्दी अपना लिया
  • MCP एक loose specification के करीब है, लेकिन open होने और काम करने के लिहाज से यह web की सफलता के तरीके से मिलता-जुलता है

Web 2.0 मूल रूप से किस ओर इशारा करता था

  • Web 2.0 का मतलब Facebook जैसी बंद और proprietary sites नहीं था
  • शुरुआती Web 2.0 community के केंद्र में यह प्रवाह था कि कई sites open APIs दें और developers व users को लोगों और data को जोड़ने दें
  • Flickr, Del.icio.us, Upcoming उस दौर की representative sites थीं जिन्होंने tags और social sharing जैसी features की शुरुआत की
  • LiveJournal और Movable Type जैसे platforms ने भी APIs और protocols के इर्द-गिर्द open standards work को प्रभावित किया
  • उस समय की shared values अपेक्षाकृत साफ थीं
    • tools, technologies और platforms को open data और open protocols पर बनाना
    • users के पास control होना
    • developers का consistent और interoperable tools के जरिए systems से interact करना

बंद platforms ने interoperability को कैसे तोड़ा

  • एक generation तक developers के लिए apps और platforms के बीच interoperability को स्वाभाविक रूप से expect करना मुश्किल हो गया
  • बड़े VCs और tech industry leaders पर openness के युग को खत्म करने की आलोचना भी हुई
  • social network activity analyze करने वाले tools ने ऐसे मामले देखे जहाँ बड़े social network platforms ने APIs बंद कर दीं और products व user-based services बंद हो गईं
  • Facebook और Twitter जैसे platforms ने कई लोगों के लिए open data और interoperable technology वाली Web 2.0 की उम्मीद तोड़ दी
  • नतीजतन, users के लिए अपने network को मनचाहे तरीके से संभालना मुश्किल होना रोजमर्रा की बात बन गया
    • Twitter timeline में embedded Instagram photos नहीं देखे जा सकते
    • fediverse या Bluesky में संभव followers import/export जैसी features इस्तेमाल करना मुश्किल है
    • अपनी पसंद के app से अपने network को control करना मुश्किल है

MCP फिर से कौन-सी संभावना खोल सकता है

  • MCP का उभार AI के coders के बीच popular होने की धारा से जुड़ता है और यह उम्मीद बनाता है कि platforms सिर्फ LLMs के लिए नहीं, बल्कि विविध programming purposes के लिए भी खुल सकते हैं
  • मुख्य बात यह है कि Anthropic द्वारा बनाई गई specification को दूसरे platforms ने जस का तस अपनाया
  • किसी दूसरी company के protocol को ईमानदारी से second adopter के रूप में अपनाने से पूरा ecosystem उसी तरीके से ज्यादा आसानी से काम कर सकता है
  • इसके उलट, protocol को copy करके extend करना और आखिर में खत्म कर देना ecosystem को नुकसान पहुंचा सकता है
  • जब समान interface इस्तेमाल करने की सद्भावनापूर्ण adoption होती है, तो कई tools और platforms के साथ मिलकर काम करने की गुंजाइश बढ़ती है

Standard को जस का तस follow करने की कठिनाई

  • Standard को जस का तस support करना जितना दिखता है, उससे कठिन है
  • AI platforms के लिए semantic caching product launch करते समय भी developers को सामान्य ChatGPT API को जस का तस इस्तेमाल करने के लिए मनाना आसान नहीं था
  • Developers अक्सर सोचते हैं कि वे इसे “बेहतर बना सकते हैं”, लेकिन standard से अलग होते ही चीजें उलटे और खराब हो सकती हैं
  • कभी-कभी inconsistencies वाली खराब specification भी सभी द्वारा उसी तरीके से implement किया जाना ज्यादा महत्वपूर्ण होता है
  • HTML भी बहुत-सी चीजों से खाली एक incomplete specification था, लेकिन web उसी पर बना
  • पूरा internet भी कई incomplete specifications पर टिका है

Standards compliance और transparency की मांग

  • नई generation के developers यह अनुभव कर रहे हैं कि पसंदीदा tools और platforms के समान protocols और formats इस्तेमाल करने पर कैसी creativity और possibilities पैदा होती हैं
  • RSS, podcasting, OpenID, OAuth, OpenSocial जैसी धाराओं में से कुछ बाद में fediverse और ActivityPub जैसे परिणामों तक पहुंचीं
  • Developers, coders, tech enthusiasts और आम users भी platforms से code के जरिए अपने experience को control करने का access मांग सकते हैं
  • MCP जैसे open standards से access करते समय platforms वास्तव में क्या कर रहे हैं, इस पर transparency भी साथ में मांगनी चाहिए
  • MCP flexible है, लेकिन कई risks छोड़ता है
    • Platform user data को कैसे handle करता है, यह अस्पष्ट है
    • MCP के जरिए interaction में कौन-सी actions होंगी, यह जानना मुश्किल है
    • Security risks बहुत बड़े हैं
    • Protocol इन concerns को पर्याप्त रूप से address नहीं करता

Web 2.0-style openness की सीमाएं और उम्मीद

  • MCP developer ecosystem की सभी समस्याएं ठीक करने वाला universal solution नहीं है
  • यह AI के इर्द-गिर्द hype और discussion की distortion को भी ठीक नहीं करता
  • हालांकि, पिछली generation के Web 2.0 दौर का अनुभव न करने वाले युवा developers MCP के बहाने web को उसकी original architecture के करीब वापस ले जाने की कोशिश कर सकते हैं
  • Web को proprietary या कुछ बड़ी companies के चंद लोगों द्वारा control की जाने वाली structure के रूप में intended नहीं किया गया था
  • Web को उन rough specifications के जरिए programmable होना था जिन्हें सभी ने जल्दी-जल्दी अपनाया था, और ऐसा hackable आनंद web पर version number लगने से पहले से मौजूद था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-25
Hacker News की राय

  • MCP में बहुत से लोग जो बात मिस कर रहे हैं, वह यह है कि यह enterprise software के लिए अच्छी तरह फिट बैठता है
    LLM एक general-purpose translator है, इसलिए यह उन कटे-फटे systems को जोड़ने वाले glue के रूप में उपयुक्त है जिन्हें बीच में कुछ हद तक ढीली layer के बिना connect करना बेहद मुश्किल होता है
    इसलिए B2B SaaS industry MCP servers ला रही है, और internally इस पर चर्चा कर रही है कि बदले हुए usage patterns के हिसाब से API और उसकी limitations को कैसे redesign किया जाए
    protocol कई definitions के हिसाब से “enterprise ready” नहीं है, लेकिन लेखक जैसा कहते हैं, वह बहुत मायने नहीं रखता। standards का इतिहास देखें तो messy और “bad” चीजें भी सही समय पर सही लोगों के लिए fit हो जाएं तो व्यापक रूप से अपनाई जाती हैं

    • MCP लंबी connection के ऊपर बस RPC है, और ज्यादातर WebSocket होता है। मेरे हिसाब से RPC set up करना ज्यादा आसान है
      user object के fields बदलना मूल user object को replace करने वाला PUT है या POST, जैसी बहसें कम हो जाती हैं। REST verbs पर काफी समय खर्च कर चुका हूं
      LLM को भी API की REST semantics समझने की जरूरत नहीं होती। वह available RPC methods देखता है और जो call काम कर सकती है, वह कर देता है। मेरे हिसाब से सार सचमुच बस इतना ही है
    • पैसे कमाने के लिए बढ़िया structure है। हर data request में paid LLM round trip शामिल होता है
      ऐसा भी नहीं कि endpoints आपस में आगे सस्ते में query करने लायक schema negotiate कर रहे हों
    • हमारे पास पहले से REST और OpenAPI हैं
      सिर्फ उनसे भी self-discovery जैसे features संभव हैं
      जो जगह MCP देगी, वह वैसे भी ठीक-ठाक API भी देगी
    • पूरी तरह सहमत हूं। बड़ी कंपनियां ऐसे engineers से भरी हैं जो 9 से 5 तक शानदार चीजें बनाना चाहते हैं और घर जाते ही अगले दिन तक काम भूल जाना चाहते हैं
      कौन-सी company office hours के दौरान अपने employees से maximum productivity निकालना नहीं चाहेगी

  • “पहले के उन दिनों की तुलना में, जब चिड़चिड़े बूढ़े Unix अंकल specs लिखा करते थे” वाला हिस्सा, मेरे हिसाब से semantic web के fail होने की कई वजहों में से एक है। यह लेखक के “worse is better” वाले मुख्य point से भी contradict नहीं करता
    मुझे लगता है लोग XML के eXtensible में बहुत ज्यादा डूब गए थे और कुछ हद तक fatigue जमा हो गई थी। XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS वगैरह बहुत ज्यादा हो गए थे
    उस समय दुनिया को एक simple exchange format चाहिए था और JSON ने उस जरूरत को पूरा किया, जबकि XML side data format को लेकर architectural spaceflight जैसी चीज बन गई थी
    लेकिन अब मुझे यह भी लगता है कि XML का समय आ गया है। Anthropic जैसी जगहों के leaked system prompts में XML अक्सर दिखता है। LLM structured text formats, खासकर Markdown और XML, को काफी अच्छी तरह handle करते दिखते हैं
    हालांकि मुझे लगता है MCP गलत model है। model को खुद context “खींचकर लाने” का निर्देश देने के बजाय, मुझे लगता है हमें model में context “push” करना चाहिए

    • दिलचस्प observation है। हाल ही में JSON macro expansion language बनाते हुए XML/XSLT में मेरी काफी दिलचस्पी हो गई
      चार macro tags (#=, #&, #?, #!) क्रमशः assignment, substitution, cond जैसी conditional branching, और user-defined function call के रूप में खुद को macro expansion result से replace करते थे, लेकिन अंत में मुझे एहसास हुआ कि मैं XSLT ही फिर से बना रहा हूं
      मुझे सच में जो चाहिए था वह XPath था। यह graph को कई axes के along आगे-पीछे traverse करने का तरीका describe करने का तरीका है, और वास्तव में शानदार spec है
      फिर मुझे BaseX https://basex.org/ मिला, जो arbitrary XML documents को queryable database में import करने और XPath या XQuery से query करने देता है
      hallucination-free भरोसेमंद natural language dataset interface बनाने के लिए सबसे अच्छा तरीका यह लगता है कि XML schema को system prompt में दिया जाए और model को data fetch करने वाली query लिखने दी जाए
    • “model को खुद context खींचकर लाने देने के बजाय context push करना चाहिए” — यह उन cases में कैसे संभव होगा जिन्हें लोग intern से solve करवाना चाहते हैं, समझ नहीं आता
      अगर जानकारी पहले से पता होती तो शायद वे खुद ही problem solve कर लेते
      MCP से मिलने वाली value ज्यादा “15 sources को जोड़ना सीखो मत, मेरी ओर से कौन-सी query चलानी है चला दो” जैसी लगती है
    • XML tags LLM पर अच्छा काम करते हैं। लेकिन ज्यादातर वे बस XML tags ही होते हैं
      कोई भी™ LLM को XML declaration से शुरू होने वाला proper XML नहीं खिलाता, और namespaces या XSLT, XML Schema जैसी चीजें भी इस्तेमाल नहीं करता
      यह बस SGML-style tags का arbitrary collection जैसा है
    • hobby code में document source format के तौर पर कभी-कभी XML से काम करता हूं, लेकिन आखिरकार उससे दूर जाने की वजह syntax के आसपास की छोटी-छोटी चीजें होती हैं
      XML angle brackets से कहीं बड़ी spec है, और हर case को cover करने, security और character encoding को सही तरह handle करने की कोशिश करती है
      इसलिए “plain text editing” बहुत intuitive नहीं है। इस paragraph जैसा कुछ type करें तो compatibility mode में parse हो सकता है, लेकिन valid नहीं भी हो सकता
      exchange format के रूप में या उसके हिसाब से बनी applications में load होने वाले format के रूप में इसकी संभावना ज्यादा है, और LLM भी जाहिर तौर पर इसे समझने में दिक्कत नहीं करेगा, इसलिए यह अच्छी बात है
      अतीत की कई समस्याएं उन programmers से आईं जिनके पास समय कम था और जो features जल्दी ठूंसना चाहते थे, इसलिए उन्होंने strongly structured specs को blunt weapon की तरह इस्तेमाल किया। “XML? regex से लिख देंगे।” अगर तीन अलग-अलग programs और तीन authors यह दोहराएं तो अफरा-तफरी हो जाती है
      व्यक्तिगत रूप से मैं जो चाहता था, उसके वास्तव में करीब format BBCode था। यह कई चीजों के source format के रूप में शानदार है। basic तौर पर यह अभी भी angle-bracket वाली category में है, लेकिन general-purpose frontend syntax के रूप में इस्तेमाल करने लायक structure और flexibility रखता है
      शुरुआती implementation “regex से लिख देंगे” ही था, लेकिन दशकों की real-world validation के बाद आजकल ज्यादा elegant parsers भी हैं
    • semantic web इसलिए fail हुआ क्योंकि वह ads डालने का तरीका नहीं खोज पाया

  • “MCP के उभार से, जैसे-जैसे AI coders के बीच लोकप्रिय हो रहा है, यह उम्मीद मिलती है कि LLM सिर्फ अपने नियंत्रण के लिए नहीं, बल्कि किसी भी उद्देश्य से प्रोग्राम किए जा सकने के लिए दूसरे platforms को खोल सकता है” — इस वाक्य के उलट सोचता हूँ
    MCP उसी वजह से असफल होने के लिए अभिशप्त है जिस वजह से semantic web असफल हुआ था। क्योंकि अगर कोई चीज़ लॉक नहीं है, तो उससे कोई पैसा नहीं कमाता
    AI का हमारे बदले web search करना—माफ़ कीजिए, जिसे “deep-research” कहा जाता है—उसमें से कितना हिस्सा बेहतर तरीके से हल हो सकता था, यह सोचकर हैरानी होती है
    रेस्तरां अपने menus को metadata format में publish कर सकते थे और कोई भी Python script से Texas में सबसे सस्ता taco ढूँढ सकता था, लेकिन हकीकत यह है कि एक हाथ से data को कृत्रिम barriers के पीछे लॉक किया जाता है और दूसरे हाथ से उसे bypass करने के लिए datacenter तक शामिल कर AI बनाया जाता है। macro स्तर पर देखें तो यह बस मूर्खता है

    • मुझे भी सही लगता है। MCP ऐसा लगता है जैसे robots.txt किसी उच्चतर जीव में evolve हो गया हो, लेकिन फिर भी यह “कृपया अपने resources का वर्णन करें ताकि हम उनका दोहन कर सकें” के करीब है
      पिछले agent wave के मरने की वजह आखिरकार यह थी कि सबको समझ आ गया कि negotiated machines पर चल रहे अपने code पर भरोसा नहीं किया जा सकता। यह 90s के Java वाली बात थी
      मूल रूप से, interact करने वाले agents के बीच जानबूझकर design की गई information asymmetry की समस्या होती है। उसे हटा दें तो समाज का बड़ा हिस्सा काम करना बंद कर देगा
    • बात सिर्फ यह नहीं कि free open API देकर पैसा नहीं बनता। ऐसी API चलाने के लिए असल में unlimited resources चाहिए
      समस्या पर आप कितने भी resources फेंक दें, कोई न कोई बहुत छोटे लाभ के लिए उन resources को exhaust करने का तरीका ढूँढ लेगा
      MCP सिर्फ समस्या को और खराब करेगा, जब AI agents public MCP servers पर टिड्डियों के झुंड की तरह टूट पड़ेंगे
      स्थिर विकल्प शायद per-call charged RPC pricing होगा। कम से कम model या agent चलाने वाली entity payment clearinghouse की तरह काम करेगी, इसलिए Web 2.0 API के समय की तुलना में इसकी संभावना ज्यादा है
      शायद सबसे plausible billing model यह होगा कि इन costs को subscription plans में शामिल कर दिया जाए। incentives align करने का यही सबसे अच्छा तरीका लगता है
    • 2010s की शुरुआत में HATEOAS सपना था, और API consumption को मामूली काम बनाना चाहता था, लेकिन अंत में swagger yaml बनाने से ज्यादा आगे लगभग नहीं बढ़ पाया
      जिसने भी शुरू में इसका नाम HATEOAS रखा, उसने इसे असफल करने की बिसात पहले ही बिछा दी थी
    • MCP की लोकप्रियता को मैं अभी AI को ऊपर धकेल रहे overheated bubble का side effect मानता हूँ। यह AI से किए जा सकने वाले plausible कामों में से बस एक है
      अगर data को standard format में publish करने में कोई “easy” value होती, तो interoperable endpoints कहीं ज्यादा अपनाए गए होते
      जैसे schema.org या common shared ontology इस्तेमाल करने का तरीका। लेकिन वास्तविकता में हर बार खास magic SDK माँगने वाले custom formats बहुत हैं
    • सामान्य इंसान द्वारा पढ़ा जा सकने वाला text “कृत्रिम barrier” नहीं है। यही हमारी दुनिया का सार है
      रेस्तरां से menu को metadata format में publish करने की माँग करना ही कृत्रिम barrier है
      नए natural language processing tools की खूबसूरती यहीं है। restaurant owner को JSON सीखने या JSON generate करने वाला software package खरीदने की जरूरत नहीं
      हम data को जैसा है वैसा इस्तेमाल कर सकते हैं। उपयोगी tools बनाने की cost लगभग 0 के करीब हो जाती है
      यह inaccurate तो होगा, लेकिन human language मूल रूप से ऐसी ही होती है

  • जो लोग सोचते हैं कि MCP होने से सब कुछ access किया जा सकेगा, वे दयनीय लगते हैं
    ऐसी चीज़ें payment verification और authentication layers की दर्जनों परतों के पीछे छिपी होंगी। बेशक allowlisted IP भी होगा, और जाहिर है वह IPv4 होगा
    आपको जो दिखेगा, वह शायद सिर्फ ERR 402; होगा

  • MCP को लेकर सबसे ज्यादा चिंता मुझे यह नहीं कि protocol खराब तरह से बनाया गया है, बल्कि यह है कि इसे ठीक और बेहतर करना सिर्फ Anthropic और OpenAI की internal teams पर निर्भर है
    protocol बनाने वाले लोग ऐसे engineers नहीं लगते जो वास्तव में implementation भी करके देखते हों
    धुंधले तौर पर यह Visa-Mastercard oligopoly जैसा लगता है

  • अब अगर LLM API documentation पढ़कर adapt कर सकता है, तो क्या standard API follow करना पहले से कम जरूरी नहीं हो गया?
    मेरे लिए अहम फायदा यह है कि site MCP spec follow करे या नहीं, उसके पास API “है” ऐसी expectation बनती है

    • API documentation खराब लिखी हो सकती है
      documentation अच्छी हो तब भी LLM API से interact करने वाला गलत code generate कर सकता है। अगर generated code को ठीक करके LLM से वही code call करवाकर API से interact कराया जाए, तो आप वैसे भी middle layer की राह पर चल पड़े हैं। असल में आप “MCP जैसा” server बना रहे हैं
      LLM को API का direct access देने में security या resource allocation की समस्याएँ भी हैं। LLM को API आखिरी बार कब call हुई थी, इसकी जानकारी सीमित होती है। वह बहुत बार call कर सकता है, और अगर per-call cost महंगी हो तो अप्रत्याशित infrastructure bills आ सकते हैं
      इसके अलावा भी कई संभावित pain points हैं जो बीच में कुछ रख देने से हल हो जाते हैं
      वह “कुछ” MCP ही होना चाहिए या नहीं, इस पर समझदार लोग अलग-अलग राय रख सकते हैं। अभी तो यह लोगों के काम निपटाने के लिए पर्याप्त अच्छी तरह काम करता दिखता है

  • अब semantic web बनाया जा सकता है। संगठनों को बस एक छोटा protocol बनाना होगा जिसमें वे SQL CREATE TABLE DDL को ऐसे static files के रूप में share करें जिन्हें MCP app पढ़ सके। MCP का optional extension ही काफी है
    फिर AI/LLM function calls को SQL से जोड़ने वाले पहले से मौजूद tools का इस्तेमाल करके data को समझा और query किया जा सकेगा, और वही semantic web होगा
    यह तरीका उस missing link को भरता है जिसने semantic web को हमेशा रोके रखा था: कंपनियों के पास proprietary data types के बजाय standard “data types” इस्तेमाल करने का incentive नहीं था
    MCPQ, यानी queries वाला MCP, आ जाए तो अचानक संगठनों के पास data structure layer पर सहयोग करने की वजह बन जाएगी

  • पता चला कि “semantic web” तो शुरू से syntactic web ही था, और शायद इस बार सचमुच कुछ हो सकता है

  • सोच रहा हूँ कि किसी को तिलचट्टे जैसी चीज़ को control करने वाला MCP server बनाने में कितना समय लगेगा
    संदर्भ सामग्री:
    https://www.technologynetworks.com/informatics/news/robo-roa...
    https://www.sciencealert.com/scientists-turned-cockroaches-i...
    और 10 साल से भी पहले तक जाने वाले कई और उदाहरण भी हैं

  • “वह दौर जब specs चिड़चिड़े बूढ़े Unix अंकल लिखा करते थे” वाला expression काफी मज़ेदार है
    यह देखना दिलचस्प है कि यह पीढ़ी “बूढ़े Unix अंकलों” को चिड़चिड़े लोगों के रूप में imagine करती है। जबकि Unix तो MIT school के खिलाफ ultimate move fast and break things वाली बगावत था
    लगता है कुछ चीज़ें कभी नहीं बदलतीं :-)