MCP: एक (संयोगवश) सार्वभौमिक प्लगइन सिस्टम

 (worksonmymachine.substack.com)
30 पॉइंट द्वारा GN⁺ 2025-06-29 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • USB-C की अहमियत सिर्फ चार्जिंग या फ़ाइल ट्रांसफ़र तक सीमित नहीं है, बल्कि इसकी सार्वभौमिकता में है, जो इसे कई तरह के उपयोगों तक फैलने देती है
  • MCP(Model Context Protocol) मूल रूप से AI assistants के लिए डिज़ाइन किया गया था, लेकिन व्यवहार में यह सभी data sources और tools को जोड़ने वाला एक सार्वभौमिक plugin system बन सकता है
  • NFT Base64 के उदाहरण की तरह, कोई protocol अपने मूल उद्देश्य से आगे बढ़कर वास्तविक दुनिया के data को सीधे store और use करने के तरीके में विस्तारित हो सकता है
  • MCP servers जितने बढ़ेंगे, उतना ही हर app बिना अलग integration के विविध features आसानी से इस्तेमाल कर सकेगा
  • USB-C की तरह MCP भी 'किसी भी चीज़ को जोड़ सकने वाली संभावनाओं की जगह' बन सकता है, जो अनपेक्षित innovation की नींव रखेगा

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C और अप्रत्याशित सार्वभौमिकता

  • USB-C को सब लोग चार्जिंग या फ़ाइल ट्रांसफ़र के लिए ही समझते थे, लेकिन उसकी बनावट की वजह से यह कई तरह के उपयोगों तक फैल सकता है
  • लेखक के दोस्त Rex ने एक toaster को monitor से जोड़ दिया, जिससे toaster में HDMI output की क्षमता आ गई; यह USB-C की असीम संभावनाओं को दिखाता है
  • ऐसा इसलिए संभव है क्योंकि USB-C की संरचना ऐसी है कि power और data specs की ज़्यादा परवाह किए बिना, अगर connector फिट हो जाए तो लगभग कुछ भी जोड़ा जा सकता है

कार cigarette lighter socket का सिद्धांत

  • कार का cigarette lighter socket मूल रूप से सिगरेट जलाने के लिए था, लेकिन अब यह एक तरह के universal power port के रूप में इस्तेमाल होता है
  • इस socket की तरह protocols भी उपयोगकर्ता की पसंद को सीमित नहीं करते, बल्कि कई तरह के उपयोगों की अनुमति देते हैं
  • MCP में भी ऐसी ही विस्तार क्षमता है

MCP की फिर से खोज: संयोग से एक सार्वभौमिक प्लगइन सिस्टम

  • आम तौर पर MCP(Model Context Protocol) को AI assistants (जैसे Claude) के लिए data इस्तेमाल कराने वाले माध्यम के रूप में जाना जाता है
  • आधिकारिक दस्तावेज़ों में भी लिखा है कि यह “AI models को कई data sources और tools से standard तरीके से जोड़ता है”
  • लेकिन अगर इसमें से AI वाला हिस्सा हटा दें, तो MCP “किसी भी चीज़ को अलग-अलग data sources और tools से जोड़ने” का माध्यम बन जाता है
  • यानी यह अपने शुरुआती उद्देश्य से परे एक universal connection protocol बन सकता है

The NFT Base64 Revelation

  • NFT मूल रूप से images को refer करने के लिए था, लेकिन एक समय ऐसा आया जब वही reference खुद data बन गया
  • protocol का मूल आशय बदलते-बदलते library card ही असली किताब की भूमिका निभाने लगा
  • यह मूल इरादे से कहीं अधिक व्यापक, वास्तविक दुनिया के data को सीधे संभालने वाला tool बन गया

ऐसा network effect जिसकी किसी ने कल्पना नहीं की थी

  • जैसे-जैसे AI के लिए MCP servers बढ़ेंगे, वैसे-वैसे बिना अलग development के हर app नए features हासिल कर सकेगा
  • उदाहरण के लिए, अगर कोई Spotify MCP server बना दे, तो एक workout app MCP के ज़रिए अपने-आप playlist बना सकेगा
  • एक-दूसरे को न जानने वाले developers और apps स्वाभाविक रूप से जुड़ जाएंगे, और इससे सबको फायदा देने वाला network effect पैदा होगा
  • हर MCP server को एक universal plugin की तरह दोबारा इस्तेमाल किया जा सकेगा
  • किसी ने इसकी योजना नहीं बनाई, फिर भी संयोग से एक universal plugin ecosystem बन जाएगा

USB-C का मतलब और MCP का दर्शन

  • MCP की तुलना अक्सर AI के USB-C से की जाती है, लेकिन USB-C की असली खासियत सिर्फ एक साधारण port होना नहीं, बल्कि किसी भी चीज़ को जोड़ सकने वाली संभावनाओं की जगह होना है
  • जैसे USB-C power, data, video और दूसरी अज्ञात क्षमताओं को स्वीकार करता है, वैसे ही MCP भी सिर्फ 'AI के लिए' नहीं, बल्कि 'functions के लिए एक अच्छी तरह से डिज़ाइन किया गया छेद' है, जिससे कोई भी किसी भी functionality को जोड़ सकता है

अब वह हिस्सा जहाँ मैं बताता हूँ कि मैं क्या बना रहा हूँ

  • लेखक APM(Actions Per Minute) नाम का एक task management app बना रहा है
  • APM अपने plugin system के लिए पूरी तरह सिर्फ MCP servers का इस्तेमाल करता है
  • उपयोगकर्ता जब भी कोई नया feature जोड़ना चाहें, उन्हें सिर्फ एक MCP server connect करना होगा (जैसे spell check, coffee auto-ordering, game character reactions आदि)
  • इससे app खुद लचीला और कई रूप लेने वाला बन जाता है

The Toaster Protocol Principle

  • सभी महान protocols शुरू में जिस काम के लिए बनाए जाते हैं, उससे अलग अनपेक्षित उपयोगों में जाकर innovation पैदा करते हैं
    • HTTP: academic papers → civilization infrastructure
    • Bluetooth: hands-free → main door unlock करना आदि
    • USB: input devices → portable fan charging आदि
  • MCP भी मूल रूप से AI context पहुँचाने के लिए बना था, लेकिन अपने सार में यह हर चीज़ को हर चीज़ से जोड़ने वाला protocol है
  • यह plugin ecosystem की वह नींव है जो अप्रत्याशित innovation को जन्म दे सकती है
  • यह शायद कभी इरादतन नहीं था, लेकिन toaster और monitor को HDMI से जोड़ने वाले युग के लिए बिल्कुल उपयुक्त है

समापन

  • PS: अगर आप MCP server की मदद से ऐसी computer बना दें जिससे ताज़ी ब्रेड की खुशबू आए, तो ज़रूर संपर्क करें
  • PPS: APM early access खुल चुका है, और अनोखे प्रयासों तथा रचनात्मक प्रयोगों को प्रोत्साहित किया जा रहा है
  • (कहीं न कहीं कोई protocol अब भी अपने मूल उद्देश्य के मुताबिक इस्तेमाल हो रहा है। यह काफ़ी संदिग्ध लगता है)

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

4 टिप्पणियां

 
a1eng0 2025-06-30

MCP सर्वर के responses में अक्सर कोई तय schema नहीं होता, और वे natural language में होते हैं.

इस natural language response को LLM के बिना programmatically process करना मुश्किल होगा.
 
winterjung 2025-06-30

जानकारी के लिए, mcp 2025-06-18 स्पेसिफिकेशन में नया structured tool output जोड़ा गया है, जिससे response schema को describe करना संभव हो गया है। जैसा आपने कहा, अभी तक implement किए गए ज़्यादातर mcp tools unstructured होंगे, लेकिन आगे आने वाले mcp tools से काफ़ी उम्मीद की जा सकती है।
 
a1eng0 2025-07-01

विंटर-निम, आपसे यहाँ फिर मुलाकात हो गई, हाहा

मैं 250618 स्पेक को फॉलो-अप नहीं कर पा रहा था। धन्यवाद!
 
GN⁺ 2025-06-29
Hacker News राय

  • मुझे यह लेख और MCP प्रोटोकॉल सच में बहुत पसंद आया। लेकिन MCP को देखते ही मुझे किसी वजह से microservices और SOA की याद आती है। डर लगता है कि कहीं यह नए failure points पैदा करने वाला वही पुराना दुःस्वप्न फिर न बन जाए। दूसरी तरफ, यह उम्मीद भी है कि agents के आने से reliability बेहतर करना शायद अधिक स्वाभाविक हो जाए

  • मैं लेख की सोच से सहमत हूँ, और लेखक MCP का इस्तेमाल जिस तरह से कर रहा है, वह थोड़ा हटकर होने के बावजूद काफ़ी दिलचस्प है। इस विचार का असली सार यह नहीं है कि कोई ऐसा protocol आ गया है जो पहले कभी न हुई नई चीज़ें संभव बनाता है। सच कहें तो, दूसरे comments की तरह, MCP अपने-आप में कोई बहुत नई या रोमांचक idea नहीं है। असली दिलचस्प बात यह है कि AI agent लहर की वजह से interoperability पर ध्यान गया है, और vendor lock-in को अब पुराने ज़माने की समस्या की तरह देखा जा रहा है। यह माहौल कितने समय तक रहेगा, पता नहीं, लेकिन अभी के लिए अच्छा लग रहा है

    • यह देखकर मुझे Winsock के आने का समय याद आता है। एक दौर में Windows पर networking से जुड़ी हर चीज़ अलग-अलग private interfaces से चलती थी। फिर वह कहानी है कि एक दिन कई vendors साथ बैठे और सबके फ़ायदे के लिए एक साझा standard बनाने का फ़ैसला किया। देखें: Winsock Wikipedia
    • मुद्दा सिर्फ इतना नहीं है कि interoperability trend में है या चीज़ें आसानी से connect हो सकती हैं। असली innovation यह है कि LLM खुद tools का उपयोग करना सीख चुका है। अगर मैं backend बना दूँ, तो frontend अब मेरी समस्या नहीं रह जाती और AI उसे संभाल लेता है। Claude और Gemini भी सिर्फ़ लक्ष्य बताने पर tools का इस्तेमाल खुद कर लेते हैं। पहले मनचाहा परिणाम पाने के लिए step-by-step साफ़ प्रक्रिया लिखनी पड़ती थी, लेकिन अब तयशुदा programs की तुलना में LLM बदलती परिस्थितियों में कहीं बेहतर ढल जाता है—यह बहुत बड़ा बदलाव है
    • इस समय hype ज़्यादा लगती है। लेकिन मेरे हिसाब से AI agents ने interoperability के लिए ठोस motivation ज़रूर बना दी है। पहले सब लोग अपने-अपने systems में धीरे-धीरे काम करते थे और वही नौकरी की सुरक्षा थी, लेकिन अब रुझान सब कुछ जोड़ने का है। जैसे CEO का खुद hackathon में pizza पहुँचाना कभी-कभी सस्ता पड़ जाए—agents integration पर निर्भर करते हैं। मैं पहले की API integration wave पर सीधे सवार रहा हूँ, इसलिए अब लगता है कि दुनिया आख़िरकार वहाँ पहुँची है। उम्मीद है यह माहौल बना रहे
    • AI agents की hype ने interoperability trend को आगे बढ़ाया है और vendor lock-in को पुराना बना दिया है—इस बात से मैं पूरी तरह सहमत नहीं हूँ। हाल में चर्चा में रहे Cursor जैसे tools भी MCP का इस्तेमाल सिर्फ़ one-way तरीके से करते हैं; वे conversation history या context बाहर नहीं भेजते। मुझे Cursor पसंद है, लेकिन non-open-source VS Code fork से शुरू होकर यह “वापस कुछ न देने” वाली सोच developers के trust पर बुरा असर डालेगी। आख़िरकार lock-in अभी भी बहुत मज़बूत है
    • विडंबना यह है कि हाल की API access restrictions AI training data को लेकर और कड़ी हुई हैं। सच तो यह है कि ऐसी API lockdowns पहले से थीं, और अगर openness का यह नया trend hype के हिसाब से आगे नहीं बढ़ा तो दरवाज़े फिर कभी भी बंद हो सकते हैं—ऐसी शंका भी जायज़ है

  • लेखक MCP की universality को लेकर बहुत उत्साहित है, लेकिन ईमानदारी से कहूँ तो समझ नहीं आता कि यह API के विचार से मूलतः कितना अलग है। MCP की जगह REST लिख दें, तो क्या लेख का मतलब बहुत बदलेगा? OS APIs, POSIX, और Unix pipes से भी इसकी समानता दिखती है। हाँ, MCP इन सबसे कहीं अधिक simple और generic है। लेकिन क्या असली समाधान हर बार नया abstraction बनाना है, या फिर बुनियादी तौर पर सरल software बनाना?

    • MCP, REST से अलग है। बल्कि, MCP ऐसा protocol लगता है जो runtime पर REST endpoints को dynamic तरीके से discover करने देता है, और user को यह configure करने देता है कि कौन-से REST endpoints इस्तेमाल करने हैं। उदाहरण के लिए, अगर किसी app में Spotify song चलानी है, तो आप Spotify API ही इस्तेमाल करेंगे। बाद में Sonofm को support करना हो तो पुराने तरीके में code बदलना, conditionals जोड़ना, नया version deploy करना, update बताना—सब करना पड़ेगा। MCP इसके उलट runtime पर यह configuration संभव बनाता है, इसलिए यह कहीं अधिक extensible लगता है
    • मुख्य फ़र्क यह है कि MCP में introspection शुरू से अनिवार्य है। REST के साथ OpenAPI है, लेकिन वह बाद में जोड़ा गया है और उसका standard उपयोग भी कम है। MCP इसके विपरीत सबसे पहले description publish करने की माँग करता है, इसलिए accessibility अलग स्तर की है
    • मेरी नज़र में MCP की सच में नई बात बस यह है कि protocol level पर schema उपलब्ध कराना अनिवार्य है। हाँ, request और response structures का consistent होना उन libraries के लिए भी सुविधाजनक है जो dynamic types को static types से wrap करती हैं। असल में लगभग सभी लोग APIs में पहले से कुछ न कुछ ऐसा कर रहे थे। हम बस उस envelope shape पर सहमत नहीं थे। schema देना पहले से ज़रूरी हो, और AI models उसे तुरंत उपयोग कर सकें—शायद इसी वजह से इसे इतना ध्यान मिल रहा है
    • MCP और REST के बीच बड़ा फ़र्क built-in list-tools command है। REST APIs में resources को list करने के कई तरीके होते हैं, लेकिन MCP एक ही standardized तरीका देता है
    • एक और बड़ा अंतर यह है कि MCP में discovery प्रक्रिया protocol के अंदर ही बनी हुई है। REST में ऐसा कोई तत्व नहीं है जो client को बताए कि कौन-से resources उपलब्ध हैं या API क्या-क्या कर सकती है

  • MCP को लेकर बहुत लोग कहते हैं कि यह कमाल की चीज़ है, लेकिन मैंने अब तक बहुत कम ऐसे उदाहरण देखे हैं जहाँ इससे वाक़ई कुछ शानदार बना हो। थोड़ा वैसा ही एहसास है जैसा blockchain hype के समय था। आख़िर में MCP भी शायद AI के और smarter होने तक का एक अस्थायी उपाय ही निकले। दो साल बाद शायद MCP की जगह tools के docs या OpenAPI को सीधे दे दिया जाएगा और AI पूरा context खुद समझ लेगा

    • उदाहरण के लिए, सिर्फ़ Ableton Live का documentation दे देने से Claude को खुद संगीत बनाने में क्या मदद मिलेगी, इस पर मुझे संदेह है
    • चाहे model कितना भी बेहतर हो जाए, अगर deterministic tool access और दुनिया की वर्तमान स्थिति की जानकारी सीधे न दी जाए, तो उसकी उपयोगिता बहुत सीमित रहेगी। और security को देखते हुए भी आप model को production में बिना नियंत्रण के मनमाने requests नहीं करने दे सकते। MCP को लेकर hype कुछ ज़्यादा है, लेकिन यहाँ जिस समस्या की बात हो रही है, वह सच में महत्वपूर्ण है। अगर इस protocol की वजह से developers अपनी functionality को साफ़ APIs के रूप में खोलने लगें, तो वह काफ़ी उत्साहजनक होगा
    • blockchain hype और MCP काफ़ी अलग चीज़ें हैं। मैं भी शुरुआत में skeptical था, लेकिन जब आप थोड़ा-सा MCP server खुद implement करते हैं तो पता चलता है कि अनुभव बिल्कुल अलग है। conversational/voice AI, मौजूदा LLMs, MCP, और तरह-तरह के tools व functions को APIs और private data/services के साथ मिलाना संभव हो जाता है, और तब सच में लगता है कि हम एक नई frontier में आ गए हैं। यह 100% perfect नहीं है, लेकिन लगभग हर practical use case के लिए काफ़ी है, और आगे apps बनाने का तरीका ही बहुत बदल सकता है
    • सच में, मैं यह जानना चाहता था कि मेरे राज्य के legislators ने इस हफ़्ते क्या किया, और जानकारी आसानी से मिल नहीं रही थी। फिर सुना कि MCP और congress.gov API का मेल अच्छा रहेगा, तो मैंने एक MCP server बना लिया। कोड यहाँ है. अब मैं इसे अमेरिकी कांग्रेस की गतिविधियाँ real time में देखने के लिए सच में उपयोग कर रहा हूँ
    • जब तक AI model architectures विकसित होते रहेंगे, बीच की middleware layer—यानी MCP—का यूँ ही गायब हो जाना मुश्किल है

  • मुझे लगता है Microsoft की पुरानी “Embrace, Expand, Extinguish” रणनीति यहाँ भी काम कर रही है। system stability और security के नाम पर, अगर agents बिना किसी management के tools को dynamically discover करें तो conflicts का जोखिम बढ़ता है। PydanitcAI जैसे alternatives हैं, लेकिन आख़िरकार Microsoft ने MCP को ‘Build 2025’ में आधिकारिक रूप से push करके अपनी रफ़्तार पर industry को चलाना शुरू कर दिया है। Anthropic ने ऐसा standard जारी किया जिसमें tools कमज़ोर हैं और governance की कमी है, इसलिए Microsoft के लिए उसे कब्ज़े में लेना आसान बनता है। अगला चरण शायद यह हो कि Microsoft अपनी registry को industry standard बना दे और उसे Windows-specific commands के साथ जोड़ दे। आख़िर में “security” के मानक भी अपने फ़ायदे के हिसाब से तय कर दे और rivals को किनारे कर दे

  • अगर AI वाला हिस्सा पूरी तरह हटा दें तो? चिंता यह है कि अगर AI middleware के बिना सीधे MCP servers पर निर्भर हुआ जाए, तो तुरंत backward compatibility की समस्या सामने आ सकती है। क्योंकि MCP servers मानकर चलते हैं कि caller एक AI algorithm है, इसलिए tools या input/output schemas पर आधारित breaking changes कभी भी आ सकते हैं

  • मैंने भी ऐसा ही सोचा था, लेकिन फिर लगा कि ज़्यादातर MCP servers शायद मौजूदा APIs के लिए बस नए clients ही हैं। उदाहरण के लिए Kagi MCP server सिर्फ़ Kagi API को call करता है। तो फिर क्या API को सीधे इस्तेमाल करना बेहतर नहीं होगा? और system में MCP servers की संख्या के हिसाब से Python interpreters बढ़ते जाएँगे—तो क्या आगे कोई ऐसा “hosting” service आएगा जो इन्हें इकट्ठा करके एक साथ bridge कर दे?

    • मेरी समझ में MCP असल में मौजूदा API में बस एक /list-tools endpoint और जोड़ने जैसा है। हर client पहले /list-tools पर जाकर available tools की list लाता है, और फिर आगे individual APIs को call करता है
    • मेरा approach यह है: अगर किसी API के लिए पहले से OpenAPI spec मौजूद है, तो क्या उसे FastMCP से wrap कर देना काफ़ी नहीं होगा? मैंने authentication requests जैसी चीज़ें संभालते हुए इसे Goose से जोड़ा भी, और नतीजा यह निकला कि Goose को बस मौजूदा API routes पर curl commands चलानी थीं। अगर OpenAPI spec काफ़ी अच्छी हो, तो MCP ज़रूरी न भी हो सकता है। हाँ, अगर मौजूदा API ही न हो, तो शायद MCP server खुद core behavior को implement करने की दिशा में विकसित हो सकता है

  • comments में skepticism काफ़ी है, और मैं उससे सहमत हूँ। मैंने पिछले हफ़्ते खुद एक MCP server implement किया था, और ईमानदारी से कहूँ तो इसे “well-designed” कहना कुछ ज़्यादा ही तारीफ़ होगी। MCP के लक्ष्यों में से एक यह है कि इसे “आसान बनाया जाए”, लेकिन व्यवहार में यह उतना आसान नहीं है। फिर भी महत्वपूर्ण बात यह है कि इस समय बहुत सारे developers की नज़र एक ही दिशा में है। ऐसे momentum में समस्याओं के हल बहुत तेज़ी से आ सकते हैं। साथ ही किसी ecosystem के बनने के लिए एक critical mass चाहिए होती है, और लगता है कि वह inflection point सच में आ गया है। सबको patience और good luck मिले

    • अगर आप सिर्फ़ MCP Python library इस्तेमाल करें, तो यह सच में आसान है। बस functions पर decorators लगा दीजिए और tools तैयार हो जाते हैं। मुझे MCP protocol की कोई समझ नहीं थी, फिर भी उस तरीके से सब ठीक चल रहा है। हाँ, अगर protocol खुद implement करना पड़े तो बात अलग हो सकती है
    • MCP server को बस “मौजूदा public या semi-public API” को दोबारा expose करना होता है। यह बात काफ़ी समझदार लगती है कि जहाँ तक संभव हो, original endpoints में बहुत कम बदलाव करके ही इसे बनाया जाना चाहिए
    • पहले भी ऐसी कोशिशें हुई हैं, लेकिन कुछ साल बाद apps endpoints बंद कर देते हैं ताकि सिर्फ़ chatgpt, claude वगैरह जैसे चुनिंदा servers ही पहुँच सकें। interoperability असल में user mobility भी है, और व्यवहार में बहुत-सी tech companies mobility से ज़्यादा lock-in और monopoly चाहती हैं

  • यह बात ज़ोर देकर कहने लायक है कि technology adoption और diffusion के लिए entry barrier कम करना इतिहास भर में बहुत महत्वपूर्ण रहा है। MCP भी उसी परंपरा का हिस्सा है, और इसे नज़रअंदाज़ नहीं किया जाना चाहिए। हमारी team में भी, जिसका कोई technical background नहीं था, वह file-sharing tasks को automate करने वाले agent का इस्तेमाल खुद कर पाया। पहले यह काम सैकड़ों programming languages, libraries और APIs के ज़रिए ही संभव था, लेकिन MCP की वजह से अब non-specialists भी बिना उन सबकी चिंता किए सीधे समाधान पा सकते हैं। performance के लिहाज़ से यह सबसे बेहतरीन नहीं है, और implementation भी optimal नहीं है, लेकिन यह नया तरीका जो value ला रहा है, वह मौजूदा resources और technology level पर अभूतपूर्व है। असली बात वही है

    • मुझे लगता है कि यह कहना कि कोई non-technical teammate अकेले file-sharing cleanup बहुत अच्छी तरह कर गया, थोड़ा बढ़ा-चढ़ाकर कहा गया है। अगर बात हज़ारों files की हो तो अलग है, लेकिन मेरे अनुभव में लगभग हर file-share cleanup प्रयास में संबंधित departments का सहयोग लेना ही मुश्किल होता है। जिनके काम का मामला होता है, वे भी अक्सर इसे अपना काम नहीं मानते। कई बार senior executives तक को शामिल करना पड़ता है, या साथ बैठकर सिर्फ़ file structure निकालने में एक घंटा लग जाता है। काम का 50% inter-department politics, 20% process updates, 20% training, और technical समस्याएँ सिर्फ़ 10% होती हैं। मैंने छोटे-बड़े हादसे और अंतहीन अफ़रा-तफ़री देखी है, इसलिए यह मानना मुश्किल है कि AI tools के कारण वास्तविकता इतनी सरल हो जाएगी। मुझे तो ज़्यादा लगता है कि कुछ महीनों बाद backup restore करना पड़ेगा

  • “काश AI agent Warcraft 3 में peon की तरह आदेश ले और जवाब दे” वाला मज़ाक—मेरे लिए तो जवाब होगा कि मैं तो sailing करना पसंद करूँगा

    • मैं बस यह बताना चाहूँगा कि “I'd rather be sailing” Warcraft 2 की line है, जबकि Warcraft 3 में जवाब होता है “I'd rather be flying”