मैं अब भी Skills की तुलना में MCP को पसंद करता हूँ

• MCP एक API abstraction-आधारित standard interface है, जिसमें LLM टूल की आंतरिक संरचना जाने बिना भी काम का अनुरोध कर सकता है, और यह remote use तथा automatic updates को support करता है
• Zero-Install संरचना, OAuth authentication, और sandboxing security के जरिए installation का बोझ और permission से जुड़ी समस्याएँ कम होती हैं, और किसी भी platform पर एक जैसा environment मिलता है
• दूसरी ओर Skills में CLI installation dependency, authentication और deployment की complexity, तथा platform-specific compatibility issues के कारण वास्तविक execution environment में friction अधिक होता है
• Skills को knowledge layer और MCP को connection layer के रूप में अलग समझना चाहिए; LLM जब external systems के साथ interact करे तो MCP, और procedural knowledge देने के लिए Skills का उपयोग उपयुक्त है
• MCP Nest जैसी cloud tunneling services के जरिए local MCP server को remotely access किया जा सकता है, इसलिए इसे standardized AI integration environment बनाने का एक प्रमुख आधार माना जा रहा है

---

MCP के फायदे

• Model Context Protocol(MCP) एक API abstraction structure पर आधारित है, जिसमें LLM को टूल के अंदरूनी कामकाज को समझने की ज़रूरत नहीं होती; वह सिर्फ request देकर काम करवा सकता है
  • उदाहरण: जब LLM DEVONthink के साथ interact करता है, तो devonthink.do_x() call करने पर MCP server सारी processing संभाल लेता है
• Zero-Install remote use संभव है, इसलिए client सिर्फ MCP server URL बताकर बिना अलग installation के तुरंत काम कर सकता है
• Automatic updates supported हैं; remote MCP server में नए tools या resources जुड़ते ही सभी clients तुरंत latest version इस्तेमाल कर सकते हैं
• OAuth-आधारित authentication से security बेहतर होती है, और user को खुद token manage नहीं करना पड़ता
• Portability अधिक है; Mac, mobile, web जैसे किसी भी environment से उसी MCP server के जरिए access किया जा सकता है
• Sandboxing structure local environment में direct execution permissions को सीमित करता है और केवल controlled interface expose करता है
• Smart search और automatic update features के माध्यम से केवल ज़रूरी tools load किए जाते हैं, और local installation होने पर भी execution के समय auto-update संभव है

Skills की सीमाएँ और friction

• Skills LLM को specific knowledge या usage सिखाने में उपयोगी हैं, लेकिन वास्तविक execution के समय CLI dependency समस्या बन जाती है
• ज़्यादातर Skills अलग CLI installation मांगते हैं, लेकिन ChatGPT, Perplexity, Claude के web versions आदि में CLI चलाना संभव नहीं होता
• इससे निम्न समस्याएँ पैदा होती हैं
  • Deployment complexity: CLI को binary, NPM, uv आदि के रूप में distribute और manage करना पड़ता है
  • Secret management issues: authentication token को .env file में plain text में रखना पड़ता है, या session reset होने पर authentication गायब हो जाता है
  • Ecosystem fragmentation: Skill installation और update का तरीका platform के अनुसार बदलता है, जिससे compatibility issues और YAML parsing errors होते हैं
  • Context waste: LLM को भले सिर्फ एक function call चाहिए हो, फिर भी पूरा SKILL.md load करना पड़ता है
• जिन Skills में “पहले CLI install करें” जैसी हिदायतें शामिल होती हैं, वे अनावश्यक complexity बढ़ाती हैं; उनकी जगह remote MCP अधिक efficient विकल्प है

सही टूल चुनने के मानदंड

• MCP कब इस्तेमाल करें: जब LLM को website, service, application जैसे external systems से connect करना हो, तब इसे standard interface की तरह इस्तेमाल करें
  • उदाहरण: Google Calendar के लिए OAuth-आधारित remote MCP authentication और execution संभाले; उससे CLI installation की मांग नहीं होनी चाहिए
  • Chrome, Hopper, Xcode, Notion आदि के लिए भी उनके फीचर्स को control करने वाले built-in MCP endpoints उपलब्ध होना आदर्श होगा
• Skills कब इस्तेमाल करें: जब फोकस pure knowledge transfer और context देने पर हो
  • पहले से installed tools (curl, git, gh, gcloud) के usage सिखाने के लिए
  • संगठन के भीतर terminology, workflows, और writing style को standardize करने के लिए
  • PDF processing या secret management (fnox usage आदि) जैसे procedural knowledge sharing के लिए
• Skills को knowledge layer और MCP को connection layer के रूप में अलग किया जाना चाहिए

Connectors और manual

• Skills और MCP की भूमिकाओं को स्पष्ट रूप से अलग करने के लिए यह प्रस्ताव है कि Skills को LLM manual(LLM_MANUAL.md) और MCP को connector कहा जाए
• वास्तविक operation में चल रहे उदाहरण
  • mcp-server-devonthink: एक local MCP server जिससे LLM DEVONthink को सीधे control कर सकता है
  • microfn: mcp.microfn.dev पर remote MCP उपलब्ध कराता है
  • Kikuyo: mcp.kikuyo.dev पर remote MCP उपलब्ध कराता है
  • MCP Nest: local MCP server को cloud तक tunnel करके remote access देने वाली service (mcp.mcpnest.dev/mcp)
• कुछ projects CLI के लिए Skill भी साथ देते हैं, लेकिन MCP usage समझाने वाला Skill अधिक उपयोगी है
  • Skill, MCP की functionality, tool relationships, और usage timing को समझाने वाली knowledge layer की तरह काम करता है
  • MCP वास्तविक connection और execution संभालता है
• इस संयोजन से LLM बार-बार trial and error किए बिना MCP का अधिक efficient उपयोग कर सकता है

MCP और Skills का साथ में उपयोग

• MCP इस्तेमाल करते समय मिले date format errors या search limitations जैसी non-intuitive patterns को Skill में व्यवस्थित करके दोबारा उपयोग किया जा सकता है
• इस तरह बना Skill, MCP के लिए cheat sheet की तरह काम करता है, जिससे LLM बिना अनावश्यक token waste किए सही तरीके से काम कर सके
• .claude/skills folder के जरिए project-specific AI behavior instructions बनाए रखे जा सकते हैं, और अक्सर इस्तेमाल होने वाली प्रक्रियाओं को dotfiles के रूप में manage किया जा सकता है
• AI integration का भविष्य standardized interface (MCP) पर निर्भर है, और CLI-आधारित fragmented approach से बचना चाहिए
• उम्मीद है कि Skyscanner, Booking.com, Trip.com, Agoda.com जैसी प्रमुख services आधिकारिक MCP उपलब्ध कराएँगी

MCP Nest परिचय

• MCP Nest एक ऐसी service है जो local-only MCP servers (जैसे Fastmail, Gmail) को cloud tunneling के जरिए remotely accessible बनाती है
• इसे Claude, ChatGPT, Perplexity जैसे MCP-supporting clients में समान रूप से इस्तेमाल किया जा सकता है
• local machine को सीधे expose किए बिना भी सभी devices पर एक जैसा MCP environment बनाए रखा जा सकता है

[jujumilk3]

बस दोनों बिल्कुल अलग चीज़ें हैं, फिर ऐसी बातें बार-बार क्यों आती रहती हैं?

[xguru]

क्योंकि मुझे लेख के आखिर में MCP Nest का प्रचार करना है.. हाहा लगता है काफ़ी तुलना-आधारित दावों को ज़्यादा तवज्जो मिल रही है।

[jjw9512151]

Skills तलवारबाज़ी है और MCP तलवार है.. इनका उपयोग अलग है, और दोनों ही ज़रूरी हैं

[ide127]

Skills और MCP की भूमिकाएँ अलग-अलग हैं, लेकिन लगता है कि ऐसे लेखों की वजह से लगातार भ्रम पैदा हो रहा है।

[ide127]

वैसे भी AI इंडस्ट्री पहले से ही ऐसे तूफ़ान में है जहाँ ढोंगी प्रचारकों की भरमार है।

[GN⁺]

Hacker News की राय

• मैं जिस बात पर ज़ोर देना चाहता हूँ, वह यह है कि व्यक्तिगत पसंद से ज़्यादा हमें इस पर ध्यान देना चाहिए कि LLM के बेहतर काम करने के लिए किस तरह की tool design चाहिए
  MCP उल्टा अतिरिक्त friction जोड़ता है। उदाहरण के लिए, अगर आप embedded systems के साथ काम कर रहे हैं, तो LLM को सीधे debugging·reset·emulator run जैसी चीज़ें करने देने वाला CLI-आधारित monitoring interface बनवाइए, और उसका इस्तेमाल skill file में document कर दीजिए
  साधारण कामों के लिए MCP की ज़रूरत नहीं है। जैसे git या AWS cost calculation जैसी चीज़ें LLM पहले से अच्छी तरह संभाल लेता है। सिर्फ़ complex systems के लिए सीधे tools बनाकर उन्हें document करना ज़्यादा efficient है

  • MCP पर चर्चा में बहुत से concepts आपस में मिल गए हैं। असली मुद्दा session persistence है
    अगर काम one-off है तो CLI या API काफ़ी है, लेकिन अगर persistent access चाहिए तो MCP server उपयोगी है
    अच्छी तरह बनाया गया MCP prompt waste किए बिना agent को usage बता देता है। persistent access को skill file से imitate करना inefficient है। MCP external tools को agent session में integrate करने का सबसे effective तरीका है
  • MCP और skill पूरक संबंध में हैं। दोनों को एक-दूसरे के विरोध में देखना ग़लतफ़हमी है
  • मौजूदा LLM tool chain अभी भी standardize न हुए transitional phase जैसी लगती है। .md या skill जैसी अलग-अलग जगहों पर जानकारी रखने के बजाय, automated self-reflection loop के ज़रिए उसे सही जगह व्यवस्थित करने वाला standard चाहिए
  • मैं भी ऐसा ही approach अपनाता हूँ। ज़्यादातर CLI tools Claude ने सीधे बनाए हैं, और मैं IDE लगभग इस्तेमाल नहीं करता
    JetBrains refactoring features को भी scripts से replace कर दिया, जिससे session speed 5 मिनट से घटकर 10 सेकंड हो गई
    अभी तक MCP बिल्कुल इस्तेमाल नहीं करता। REST + Swagger + codegen + Claude + skill का combination काफ़ी है
  • MCP का फ़ायदा permission control है। उदाहरण के लिए, अगर आप नहीं चाहते कि AI को git पर write access मिले, तो MCP से exposure scope सीमित किया जा सकता है। सिर्फ़ READ_ONLY_SKILL काफ़ी नहीं है

• यह बहस आख़िरकार individual developer vs organization-scale collaboration का मामला है
  अगर आप अकेले तेज़ feedback loop चाहते हैं तो CLI बेहतर है, और अगर organization level पर control और consistency चाहिए तो MCP सही है
  अभी MCP बहुत context खा जाता है, लेकिन इसे gradual exposure तरीके से सुधारा जाना है

  • organizations में MCP access control मुश्किल होने की समस्या है। इंसान ग़लती से दो चीज़ें delete करे तो भी बात है, लेकिन agent पलभर में हज़ारों delete कर सकता है। CLI में access scope सीमित किया जा सकता है, इसलिए वह सुरक्षित है
  • context waste client implementation की समस्या है। gradual loading spec बदले बिना भी संभव है
  • MCP और CLI अलग उद्देश्यों वाले tools हैं, और साथ इस्तेमाल होने पर सबसे ताकतवर होते हैं

• मैं API से ज़्यादा मौजूदा CLI tools को वैसे ही इस्तेमाल करने वाला agent चाहता हूँ
  जब मैं local पर CLI इस्तेमाल कर रहा हूँ तो MCP जोड़ने की कोई ख़ास वजह नहीं है। remote model भी नहीं चाहिए
  अगर API call की ज़रूरत हो तो skill काफ़ी है

  • मैं भी custom API call करने के लिए curl command सीधे skill में डालता हूँ। LLM यह अच्छे से संभाल लेता है
  • लेकिन secret key management में MCP ज़्यादा सुरक्षित है। MCP server पहले शुरू कर दिया जाए तो agent environment में keys expose नहीं होतीं
  • MCP agent और external world के बीच security boundary layer का काम करता है। हर बार ज़रूरी नहीं, लेकिन उपयोगी है
  • कुछ environments में LLM को CLI access ही नहीं मिलती। तब skill-आधारित CLI call बेकार हो जाती है
  • authentication (authn) और authorization (authz) की समस्या भी है। MCP इन्हें middleware के ज़रिए control कर सकता है

• MCP और Skill zero-sum relationship में नहीं हैं
  MCP infrastructure layer के standardized interface का काम करता है, जबकि Skill project-specific behavioral context संभालता है
  दोनों को मिलाकर stability और flexibility दोनों मिल सकती हैं

  • MCP आख़िरकार CLI को लपेटने का ही रूप है। उल्टा MCP में context overhead ज़्यादा है
  • कुछ paid MCP वाक़ई value देते हैं। उदाहरण के लिए web search MCP, खुद crawler चलाने से ज़्यादा आसान है
  • cloud-hosted agents में Skill + MCP combination एक key architecture है। authentication और dependency management आसान हो जाते हैं
  • लेखक भी इस combination का समर्थन करता है। MCP की portability ज़्यादा है, इसलिए ChatGPT, Claude, Perplexity वगैरह में एक जैसा इस्तेमाल संभव है
  • Skill को LLM ignore कर सकता है, लेकिन MCP policies server side पर enforceable होती हैं

• ज़्यादातर चर्चा local पर coding agents चलाने वाले लोगों के नज़रिए से हो रही है
  ऐसे environment में Skill ज़्यादा सुविधाजनक है, लेकिन आम users ChatGPT जैसे cloud-based सिस्टम इस्तेमाल करते हैं
  इस स्थिति में MCP default choice बन जाता है। authentication और remote access इसकी ताकत हैं

  • लेकिन कुछ लोगों के हिसाब से MCP बस एक शोरगुल वाला API wrapper है
    server चलाना पड़ता है, और LLM के लिए यह उल्टा बोझ बन जाता है। Skill API docs को LLM-friendly तरीके से encode करता है, इसलिए ज़्यादा simple है
  • “ज़्यादातर users local agents इस्तेमाल नहीं करते” इस दावे पर भी सबूत माँगने वाली प्रतिक्रिया थी
  • ‘agronomic’ typo को ‘ergonomic’ बताने वाला मज़ाक भी था

• मैं Skill को पसंद करता हूँ। क्योंकि इससे इंसानों द्वारा इस्तेमाल किए जाने वाले CLI tools को वैसे का वैसा reuse किया जा सकता है
  Skill इंसान के पढ़ने-लिखने लायक document है, इसलिए LLM और इंसान एक ही tools share करते हैं
  दूसरी ओर MCP में LLM-विशेष API अलग से बनानी पड़ती है, और documentation भी अलग maintain करनी पड़ती है
  Skill सिर्फ़ ज़रूरत पड़ने पर load होता है, इसलिए context साफ़-सुथरा रहता है

• “सिर्फ़ Skill” कहने वाले ज़्यादा non-technical लोग हैं, जबकि “सिर्फ़ CLI” की बात individual developers ज़्यादा करते हैं
  MCP enterprise environments के लिए उपयुक्त है। यह authentication और interface को standardize करता है

  • बहुत से लोग JIRA MCP की instability की वजह से MCP के प्रति नकारात्मक हैं। acli-आधारित Skill ज़्यादा stable था
  • मैंने कंपनी के अंदर इस्तेमाल के लिए खुद MCP बनाया है। उसमें Google Workspace authentication जोड़ा है, ताकि Claude internal data lookup या app deployment सुरक्षित तरीके से कर सके
    MCP को update और deploy करना आसान है, इसलिए non-technical users के लिए भी accessibility अच्छी है
  • यह तर्क भी है कि enterprises के पास पहले से internal authentication systems होते हैं, इसलिए CLI बेहतर हो सकता है
    MCP आख़िरकार API के subset को structured रूप में पेश करने से ज़्यादा कुछ नहीं है
  • MCP जल्दी खड़ा किया जा सकता है। Codex → LiteLLM → VLLM → MCP वाला setup कुछ ही मिनटों में बन जाता है
  • मैं मौजूदा SaaS systems को legacy मानता हूँ। जिन APIs से data access मुश्किल है, उनसे बेहतर local SQL DB ज़्यादा efficient है
    MCP बस एक और RPC protocol है, और authentication की समस्या भी अब तक अनसुलझी है

• मेरा मानना है कि इंसानी अतार्किकता की वजह से MCP ज़रूरी है
  बहुत-सी organizations आज भी API या CLI उपलब्ध नहीं करातीं। MCP इस digital disconnect को भरता है
  कंपनियों के भीतर reporting chain या political structures automation को रोकते हैं, और MCP इससे बचने का रास्ता दे सकता है

  • मैं भी सहमत हूँ। अगर सहकर्मियों के agents आपस में collaboration कर सकें, तो organization की digitization काफ़ी आसान हो जाएगी। MCP इस wiring complexity को छिपा देता है, इसलिए अच्छा है

• Skill में पूरी documentation को context में डालना पड़ता है, जिससे context bloat की समस्या होती है
  MCP में भी कुछ ऐसा है, लेकिन tool discovery feature की वजह से gradual loading संभव है
  बड़ी समस्या यह है कि MCP output सीधे agent context में चला जाता है। अगर CLI के ज़रिए MCP service call की जाए तो filtering या caching संभव है

  • इस पर “तो फिर सीधे HTTP request ही क्यों न इस्तेमाल करें?” जैसी प्रतिक्रिया भी आई
  • लेखक ने समझाया कि नया MCP पहले ही tool discovery-आधारित lazy loading से इस समस्या को सुलझा चुका है। Claude Code sub-agents का इस्तेमाल करके log flood रोकता है
  • मैंने local MCP को memory cache से wrap करके यह समस्या हल की। हर tool output को ID देता हूँ, और उसी ID से दूसरे tools call करता हूँ। इससे token बचते हैं और speed बढ़ती है

• Skill intuitive knowledge रखने के लिए अच्छा है, और MCP repeatable automation के लिए उपयुक्त है
  अगर LLM बार-बार वही script लिख रहा है, तो उसे एक tool के रूप में स्थिर कर देना ज़्यादा efficient है

  • ज़्यादातर processes को scripts से pre-process करना चाहिए, और LLM को सिर्फ़ planning और validation में शामिल होना चाहिए
    यानी जहाँ तक संभव हो, ज़्यादा से ज़्यादा हिस्सों को script से pre-process करना ही कुंजी है
  • scripts को सीधे skill के अंदर भी शामिल किया जा सकता है। skill में code भी रखा जा सकता है
  • मूल लेखक ने स्पष्ट किया कि यह लेख AI ने नहीं, बल्कि उड़ान के दौरान एक वास्तविक इंसान ने लिखा था
  • कुछ लोगों ने कहा कि वे repetitive tasks के लिए भी skill इस्तेमाल करते हैं, और इसके जवाब में MCP के API contract दृष्टिकोण से चर्चा आगे बढ़ी
    अगर script छोटी है, तो उसे सीधे context में डालकर “इसे इस्तेमाल करो” कहना ही काफ़ी है