Claude Skills कमाल है, शायद MCP से भी बड़ा इनोवेशन

 (simonwillison.net)
52 पॉइंट द्वारा GN⁺ 2025-10-18 | 12 टिप्पणियां | WhatsApp पर शेयर करें
  • Anthropic द्वारा घोषित Claude Skills एक नया पैटर्न है, जिसमें मॉडल को किसी खास काम को करने के लिए ज़रूरी निर्देश, scripts और resources फ़ोल्डर के रूप में दिए जाते हैं, और यह काम-विशेष विशेषज्ञता को dynamic तरीके से load करता है
  • Skills Markdown files और optional scripts से मिलकर बनते हैं; session शुरू होने पर हर skill का सिर्फ metadata कुछ दर्जन tokens में load होता है, और पूरा content केवल ज़रूरत पड़ने पर लाया जाता है, इसलिए token efficiency बहुत ऊँची होती है
  • Claude Code के ज़रिए Skills, एक साधारण coding tool से आगे बढ़कर general-purpose automation agent तक फैलता है; अगर filesystem और command execution environment हो, तो कई तरह के काम automate किए जा सकते हैं
  • MCP से अलग, Skills protocol नहीं बल्कि Markdown और YAML आधारित एक सरल संरचना है, इसलिए दूसरे models या tools में भी इसे तुरंत इस्तेमाल किया जा सकता है और इसे share व फैलाना आसान है
  • इसी सादगी और दक्षता की वजह से उम्मीद है कि Skills का ecosystem, MCP की तुलना में कहीं तेज़ी से फैलेगा; data journalism से लेकर brand guidelines तक, कई क्षेत्रों में specialized agents बनाए जा सकते हैं (और MCP की token खपत व जटिल spec से बचा जा सकता है)

Skills की अवधारणा और संरचना

  • Anthropic ने 16 अक्टूबर 2025 को आधिकारिक तौर पर Claude Skills की घोषणा की
    • यह फ़ोल्डर-आधारित capability extension system है, जिसमें मॉडल के लिए किसी खास काम (जैसे Excel का काम, या किसी संगठन की brand guidelines का पालन) से जुड़े निर्देश, scripts और resources रखे जाते हैं
    • Claude केवल उसी समय उस skill तक पहुँचता है जब वह काम से संबंधित हो, जिससे specialized tasks करने की क्षमता बेहतर होती है
  • anthropic/skills GitHub repository में आधिकारिक skill examples उपलब्ध हैं
  • Skills वैचारिक रूप से बेहद सरल हैं
    • इसकी core चीज़ एक Markdown file है, जो मॉडल को बताती है कि काम कैसे करना है
    • वैकल्पिक रूप से इसमें अतिरिक्त documents और पहले से लिखी scripts शामिल हो सकती हैं, जो task completion में मदद करती हैं
  • सितंबर में घोषित Claude की document generation feature वास्तव में पूरी तरह Skills से implement की गई थी
    • .pdf, .docx, .xlsx, .pptx files को process करने वाले skills, public repository में देखे जा सकते हैं

Token efficiency: Skills की मुख्य ताकत

  • Session शुरू होने पर Claude सभी available skill files को scan करता है और हर skill के frontmatter YAML से सिर्फ छोटा description पढ़ता है
  • हर skill के लिए शुरुआती token खपत सिर्फ कुछ दर्जन tokens की होती है, जो बेहद efficient है
  • पूरा detail तभी load होता है जब user ऐसा task माँगे जिसमें वह skill मदद कर सकता हो
  • यही वह मुख्य अंतर है जो इसे सिर्फ disk पर files रखने से आगे बढ़ाकर एक functional system बनाता है

Slack GIF बनाने वाले skill का व्यावहारिक उदाहरण

  • slack-gif-creator skill के metadata description में
    • Slack के लिए optimized animated GIF generation toolkit
    • size constraints validator और composable animation primitives शामिल हैं
    • यह "X doing Y के बारे में Slack के लिए GIF बनाओ" जैसे requests पर लागू होता है
  • वास्तविक test process
    • Claude mobile web app में Sonnet 4.5 model के साथ slack-gif-creator skill activate किया गया
    • "Make me a gif for slack about how Skills are way cooler than MCPs" prompt डाला गया
    • Claude ने अपने-आप GIF generate कर दिया (quality में सुधार की गुंजाइश है, लेकिन skill को बार-बार बेहतर बनाना आसान है)
  • Generate की गई Python script की उल्लेखनीय बातें
    • Skill directory को Python path में जोड़ना: sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
    • Skill की core/ directory में मौजूद GIFBuilder class का उपयोग
    • File को /mnt/user-data/outputs/ में save करना
    • Slack size limit (2MB) validation function check_slack_size() का उपयोग कर specification compliance की जाँच
    • Size ज़्यादा होने पर model अपने-आप छोटा file दोबारा generate करने की कोशिश कर सकता है

Skills की environment dependencies

  • Skills mechanism को पूरी तरह काम करने के लिए मॉडल को इन चीज़ों तक पहुँच होनी चाहिए
    • filesystem
    • filesystem exploration tools
    • environment में commands execute करने की क्षमता
  • यह LLM tooling का एक सामान्य pattern है
    • ChatGPT Code Interpreter इसका 2023 की शुरुआत का पहला बड़े पैमाने का उदाहरण था
    • इसके बाद यह Cursor, Claude Code, Codex CLI, Gemini CLI जैसे coding agent tools के ज़रिए local machine तक फैला
  • यही requirement, MCP, ChatGPT Plugins जैसी पुरानी LLM capability extension कोशिशों से सबसे बड़ा अंतर है
  • यह एक अहम dependency है, लेकिन इसके ज़रिए खुलने वाली नई capabilities का पैमाना हैरान करने वाला है
  • Safety issues अब भी महत्वपूर्ण हैं
    • सुरक्षित coding environment देना ज़रूरी है
    • prompt injection जैसे हमलों से नुकसान को स्वीकार्य स्तर तक सीमित करने के लिए sandbox environment बनाने के तरीके चाहिए

Claude Code: general agent की ओर विकास

  • लेखक ने जनवरी 2025 में अनुमान लगाया था कि "agents" असफल होंगे, लेकिन यह पूरी तरह गलत साबित हुआ
    • 2025 वास्तव में "agents" का साल बन गया (हालाँकि इसकी कई परिभाषाएँ हैं, यहाँ इसे "tools in a loop" के रूप में परिभाषित किया गया है)
  • Claude Code का नाम भ्रामक है
    • यह सिर्फ coding tool नहीं, बल्कि general-purpose computer automation tool है
    • कंप्यूटर पर command चलाकर हासिल किए जा सकने वाले हर तरह के काम को automate कर सकता है
    • इसे general agent कहना सबसे उपयुक्त है
  • Skills इस संभावना को कहीं अधिक स्पष्ट और प्रत्यक्ष बना देता है
  • इसके applications चक्कर में डाल देने जितने व्यापक हैं
    • data journalism उदाहरण: ऐसे skill folders बनाए जा सकते हैं जो इन कामों को संभालें
      • U.S. Census data के source और structure को समझना
      • अलग-अलग formats के data को Python libraries से SQLite/DuckDB में load करना
      • S3 के Parquet files या Datasette Cloud tables के रूप में data को online publish करना
      • नए datasets में दिलचस्प stories खोजने के तरीके (अनुभवी data reporters के निर्देश)
      • D3 का उपयोग कर साफ़, पढ़ने योग्य data visualizations बनाना
    • नतीजा: सिर्फ Markdown files और कुछ Python script examples से U.S. Census data में stories ढूँढने और publish करने वाला "data journalism agent" बनाया जा सकता है

Skills vs MCP तुलना

  • Model Context Protocol (MCP) ने नवंबर 2024 में लॉन्च होने के बाद बहुत ज़्यादा ध्यान खींचा
    • हर कंपनी को "AI strategy" चाहिए थी, और MCP implementation की घोषणा उस ज़रूरत को पूरा करने का आसान तरीका बन गई
  • MCP की सीमाएँ धीरे-धीरे सामने आने लगीं
    • सबसे महत्वपूर्ण समस्या token usage है
    • GitHub का official MCP अकेले ही कई दसियों हज़ार context tokens खा जाता है
    • इसमें कुछ और जोड़ते ही LLM के पास असली उपयोगी काम करने के लिए बहुत कम जगह बचती है
  • Coding agents को गंभीरता से देखने के बाद लेखक की MCP में रुचि कम हो गई
    • MCP से होने वाले लगभग हर काम को CLI tools से replace किया जा सकता है
    • LLM को cli-tool --help कैसे चलाना है, यह पता होता है, इसलिए usage instructions पर बहुत tokens खर्च करने की ज़रूरत नहीं
    • Model ज़रूरत पड़ने पर खुद समझ सकता है
  • Skills में यही फायदे मौजूद हैं, और इससे भी आगे
    • नया CLI tool implement करने की भी ज़रूरत नहीं
    • बस ऐसा Markdown file डालें जो बताए कि काम कैसे करना है
    • अतिरिक्त scripts सिर्फ तभी जोड़ें जब वे reliability या efficiency बढ़ाएँ

Skills ecosystem के तेज़ी से बढ़ने की संभावना

  • Skills की सबसे दिलचस्प बातों में से एक है इसे share करना आसान होना
    • उम्मीद है कि कई skills सिर्फ एक single file में implement हो जाएँगे
    • ज़्यादा sophisticated skills, कुछ files वाले folder के रूप में होंगे
  • Anthropic द्वारा उपलब्ध कराए गए resources
  • लेखक खुद भी Datasette plugin कैसे बनाएं जैसे skill ideas पर सोच रहे हैं
  • दूसरे models में भी इस्तेमाल संभव है: Skills design का एक और फायदा
    • Skill folder को Codex CLI या Gemini CLI से जोड़कर "pdf/SKILL.md पढ़ो और इस project को समझाने वाला PDF बनाओ" कहें, तो यह काम कर सकता है
    • भले ही उस tool या model को skill system का built-in ज्ञान न हो
  • अनुमान: इस साल के MCP rush को फीका कर देने वाला Skills का Cambrian explosion देखने को मिल सकता है

सादगी ही इसकी सबसे बड़ी ताकत है

  • कुछ लोगों का तर्क है कि Skills इतनी सरल है कि इसे feature कहना भी मुश्किल है
    • बहुत से लोग पहले ही Markdown files में extra instructions डालकर coding agents से उन्हें पढ़वाने वाला trick आज़मा चुके हैं
    • AGENTS.md एक अच्छी तरह स्थापित pattern है, और इसमें "PDF generate करने से पहले PDF.md पढ़ो" जैसे निर्देश रखे जा सकते हैं
  • Skills design की यही मूल सादगी लेखक को सबसे ज़्यादा उत्साहित करती है
  • MCP एक पूरा protocol specification है
    • host, client, server, resources, prompts, tools, sampling, roots, elicitation
    • और तीन transport methods शामिल हैं (stdio, streamable HTTP, पहले SSE)
  • Skills = Markdown + थोड़ा YAML metadata + optional executable scripts
    • यह LLM की प्रकृति के कहीं ज़्यादा करीब है: text दो और model को उसे समझकर काम करने दो
  • Skills मुश्किल हिस्सों को LLM harness और उससे जुड़े computer environment को outsource करता है
    • पिछले कुछ वर्षों में LLM की tool execution क्षमता के बारे में जो कुछ सीखा गया है, उसे देखते हुए यह बेहद समझदारी भरी रणनीति है

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

12 टिप्पणियां

 
shakespeares 2025-10-19

कोडिंग में Claude Code इस्तेमाल करते समय भी क्या यह जुड़ने लायक हिस्सा हो सकता है, ऐसा लगता है।
अभी भी मैं Claude.md में गाइड डालकर रखता हूँ, और डिटेल्ड गाइड को अलग-अलग बांटकर आगे बढ़ा रहा हूँ।
 
labeldock 2025-10-19

कम टोकन में ज़्यादा काम करने के लिए मुझे लगता है कि prompt optimization की बजाय multi-agent और summarization का इस्तेमाल करने वाला तरीका इसे काफ़ी सरलता से हल कर सकता है। समस्या पर मैं सहमत हूँ, लेकिन समाधान का तरीका सीमित लगता है।
 
savvykang 2025-10-18

क्या Skills भी tokens का उपयोग नहीं करते? अगर ऐसा है, तो लगता है कि token usage की समस्या फिर से आएगी, लेकिन उस समय इसका सामना कैसे करेंगे, यह मुझे ठीक से समझ नहीं आ रहा।
 
dnjstmxhs 2025-10-19

ऐसा लग रहा था कि context में पूरा SKILLS.md नहीं, बल्कि ऊपर की तरह सिर्फ नाम और description वाला हिस्सा ही हमेशा पहले शामिल होता है.

name: skill-creator
description: प्रभावी skills बनाने के लिए गाइड. इस skill का उपयोग तब किया जाना चाहिए जब users एक नया skill बनाना चाहते हों (या किसी मौजूदा skill को अपडेट करना चाहते हों) जो specialized knowledge, workflows, या tool integrations के साथ Claude की capabilities को बढ़ाता हो.
license: LICENSE.txt में पूरी शर्तें
 
ds2ilz 2025-10-18

Claude Code के साथ काम करते समय बार-बार निर्देश या नियमों को context में खिलाना पड़ता है, और आखिर में token usage और context के बीच संतुलन को लेकर सोचना पड़ता है। फिर मेरे मन में यह तरीका आया कि एक folder बनाया जाए, उसमें feature के हिसाब से अलग-अलग md files में विस्तृत बातें लिखी जाएँ, और claude.md में सिर्फ यह बताने वाले बहुत-से pointers रखे जाएँ कि क्या करना हो तो क्या देखना है। यह तरीका काफ़ी सस्ता और अच्छा चला। Skills भी आखिरकार ऐसे ही चीज़ों का संग्रह होगा, इसलिए यह काफ़ी काम का लग रहा है।
 
laeyoung 2025-10-19

और जैसा घोषणा की गई थी, अगर skills marketplace भी आ जाता है, तो ज़रूरत के skill ही लेकर उन्हें ज़रूरत पड़ने पर enable करके रखना काफ़ी ठीक लग रहा था।
 
shakespeares 2025-10-19

ओह, मुख्य व्याख्या के लिए धन्यवाद।
 
2025-10-18
[यह टिप्पणी छिपाई गई है.]
 
dnjstmxhs 2025-10-19

Context handling और Claude Skills का आपस में क्या संबंध हो सकता है? मुझे पहले लगा था कि यह बस पुराने Claude Code custom commands से अलग क्या है? लेकिन दस्तावेज़ पढ़ते-पढ़ते मुझे लगा कि सबसे बड़ा फर्क शायद यह है कि एक ही skill के अंदर Python या JavaScript जैसी script code को शामिल करके चलाया जा सकता है।
 
2025-10-18
[यह टिप्पणी छिपाई गई है.]
 
GN⁺ 2025-10-18
Hacker News की राय

  • मुझे Claude Skills इस बात का सबूत लगते हैं कि UX के लिहाज़ से RAG को बेवजह मुश्किल बना दिया गया है. तकनीकी जटिलता उतनी समस्या नहीं है, असली समस्या UX है. अगर सिर्फ यह हिस्सा ठीक कर दिया जाए, तो शायद Claude Skills खुद ही अनावश्यक हो जाएँ. Claude Skills की MCP पर बढ़त यह है कि इन्हें बनाना आसान है. इन्हें बस लिखकर बनाया जा सकता है, इसलिए कोई भी इस्तेमाल कर सकता है. लेकिन ये environment पर बहुत निर्भर हैं. उदाहरण के लिए, अगर किसी काम के लिए कोई खास tool चाहिए, तो उसे automate करने के लिए sandbox setup कैसे होगा? और यह पक्का करना भी मुश्किल है कि सही version ही इस्तेमाल हो रहा है

  • हमारी कंपनी के भीतर हम कुछ ऐसा ही आज़मा रहे हैं. हमारे monorepo की context files बहुत बड़ी हो गई थीं, इसलिए हमने task के हिसाब से धीरे-धीरे load होने वाला fragment tree बनाया. ये context documents पारंपरिक developer docs जैसे दिखते हैं, लेकिन असल में कहीं ज़्यादा उपयोगी और task-oriented हैं. अब सोचता हूँ कि हम पहले ऐसे docs क्यों नहीं बना पाए.

    1. feedback loop बहुत लंबा था. आप docs लिखते थे लेकिन वे असरदार हैं या नहीं, यह शायद कभी पता ही न चले, या कई साल बाद पता चले. बदलाव करने पर A/B test जैसी कोई चीज़ संभव नहीं थी. अब बस context markdown लिखकर Claude से काम करवा सकते हैं और तुरंत सुधार कर सकते हैं
    2. tools ने docs लिखना भी आसान बना दिया है. पहले अच्छे docs बनाना हमेशा मुश्किल था, और examples, links, और उपयोगी अतिरिक्त जानकारी जोड़ने में बहुत समय लगता था, लेकिन अब tools की वजह से लागत कम हो गई है
    3. developers में काफ़ी self-interested लोग भी होते हैं. दूसरों के लिए docs लिखने की प्रेरणा कम होती है, लेकिन अगर वही docs AI को बेहतर तरीके से इस्तेमाल करने में मदद करें, तो खुद से motivation आ जाती है क्या किसी और के पास इसके लिए दूसरी theories हैं?

    • यह असल में principal-agent problem है, जिसमें marshmallow test जैसा पहलू भी मिला हुआ है. अगर developer AI के बजाय किसी दूसरे इंसान के लिए docs लिख रहा है, तो उसे यह भी नहीं पता होता कि वह व्यक्ति कौन है, उसे क्या चाहिए, या वह docs कभी देखेगा भी या नहीं. हाँ, आगे चलकर यह खुद उसके भी काम आ सकता है, लेकिन इसे समझना या उसके लिए समय और अनुशासन जुटाना आसान नहीं होता. लेकिन अगर AI उन्हीं docs का इस्तेमाल करके सीधे मेरी मदद कर रहा हो, तो ज़रूरी जानकारी दर्ज करने की बहुत मज़बूत और तात्कालिक प्रेरणा पैदा होती है. feedback loop भी छोटा हो जाता है. और वैसे भी, LLM की प्रकृति के कारण code comments अक्सर मिट जाते हैं, इसलिए आजकल मैं docs ज़्यादा छोड़ता हूँ और comments बहुत कम

    • नए developers अक्सर यह शिकायत नहीं करते कि docs ख़राब हैं, क्योंकि उन्हें डर होता है कि वे बेवकूफ़ लगेंगे. लेखक को खुद अपने दिमाग़ में पूरा model पता होता है, इसलिए उसे समस्या महसूस नहीं होती, और अच्छे docs लिखना कभी-कभी अपनी नौकरी को जोखिम में डालने जैसा माना जाता था. लेकिन अगर आप एक बेवकूफ़ robot को ख़राब docs दे दें, और वह काम न कर पाए, तो दोष खुद को देना पड़ता है. आखिरकार मुझे लगता है कि बात #2 + #3 की ही है. बड़ा बदलाव यह है कि “replaceability” अब नकारात्मक से सकारात्मक चीज़ बन गई है (अपनी जगह किसी सस्ते agent से छिनने से पहले खुद को agent से replace कर देना)

    • यह उसी वजह जैसा है जिसके कारण technical debt होता है: business pressure, खराब design, और resources की कमी. पहले code बदलते समय अच्छे docs को लगातार बनाए रखना सच में बहुत महँगा पड़ता था

  • जब कहा गया कि एक folder में कई skills हो सकते हैं, तो मेरे दिमाग़ में ऐसे tasks आए जैसे US Census data की location ढूँढना या उसकी structure समझना. यह सुनते ही मुझे याद आया जब मैंने पहली बार Wolfram Alpha इस्तेमाल किया था. सामान्य search engine से अलग, किसी सचमुच structured tool से समस्या हल होते देख मैं दंग रह गया था. अभी फिर से इस्तेमाल किया और यह अब भी कमाल का है: Wolfram Alpha से US population query करना. मेरे दिमाग़ में Skills का model कुछ ऐसा है जैसे Wolfram Alpha में custom extensions जोड़ दिए जाएँ

    • मैंने आपका दिया हुआ link खोला तो Wolfram Alpha में query what%27s the total population of the United States%3F के रूप में खुली. नतीजा काफ़ी मज़ेदार है: 6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates) दिख रहा है. यह कैसे calculate हुआ, जानने की जिज्ञासा है

    • सच कहूँ तो पुराना Wolfram Alpha वाकई पागलपन की हद तक बड़ी उपलब्धि था. आज भी हैरानी होती है कि उस समय AI के बिना इतना जटिल सिस्टम कैसे बना लिया गया था जो कठिन गणितीय समस्याएँ तक संभाल लेता था

  • Skills और मौजूदा tools के बीच फ़र्क थोड़ा उलझाने वाला है. कई skills को तो बस tools ही कहा जा सकता है, या फिर multiple tools के bundle के साथ कुछ अतिरिक्त instructions. लेकिन tool definition और skill definition अलग-अलग जगह नहीं होतीं क्या? इनके बीच dependency कैसे व्यक्त की जानी चाहिए, यह जानना चाहता हूँ. अगर skill यह बताए कि “command line access, python, tool A, tool B चाहिए”, तो क्या इसका मतलब है कि skill load होते ही ये tools भी activate हो जाएँगे?

  • असल बात यह है कि सब लोग MCP पर ज़रूरत से ज़्यादा फ़िक्सेट हो गए और path dependency में फँस गए. सच में दिलचस्प चीज़ तो बस “tool call” खुद है. tool call वास्तव में उपयोगी और रोमांचक है. MCP तो बस उसे हासिल करने के कई तरीकों में से एक है. और वह भी कोई ख़ास शानदार तरीका नहीं

    • मुझे लगता है MCP के इतना फैलने की वजह पूरी तरह timing है. MCP से पहले भी tool calling मौजूद था, लेकिन models उसमें अच्छे नहीं थे. MCP ठीक उसी समय आया जब models tool calling में बेहतर होने लगे. इसलिए MCP hype का असली सार यह है कि लोगों को पता चला कि LLM दूसरे systems के साथ interact करने के लिए tools call कर सकता है

    • MCP server तो मूलतः tool calls register करने वाली registry है. तो फिर यह सामान्य tool call से बदतर कैसे है?

    • MCP की असली अहमियत यह है कि यह LLM को oauth की अवधारणा सिखाता है. इसी वजह से server-based tool calling संभव हुआ. पहले हर CLI को अलग से install करना पड़ता था और उसके भीतर authentication भी अलग से संभालना पड़ता था. यह सही है कि tool calling LLM की सबसे बड़ी ताकतों में से एक है, लेकिन “tool authentication का भी ध्यान रखना होगा” यह बात सामने लाना भी काफ़ी मूल्यवान है

    • वैसे, यह भी याद दिला दूँ कि MCP भी Anthropic की ही एक innovation थी

    • Skills को अलग रखकर भी, अगर MCP से बेहतर कोई तरीका है, तो वह क्या हो सकता है, यह जानने की जिज्ञासा है

  • MCP का प्रभाव सिर्फ terminal तक सीमित नहीं है, उससे कहीं व्यापक है. इसे ChatGPT, Claude Web, n8n, LibreChat में भी इस्तेमाल किया जा सकता है, और इसमें authentication, resources, यहाँ तक कि UI (apps-sdk वगैरह) तक पर विचार किया गया है. अगर ध्यान coding workflows या CLI-based agents (जैसे Claude Code) पर है, तो CLI tools की बहुत बड़ी उपयोगिता है, लेकिन CRM, sales, support, operations, finance जैसे क्षेत्रों में MCP-based tools ज़्यादा उपयुक्त रूप हैं. Skills और MCP प्रतिस्पर्धी नहीं, बल्कि पूरक उद्देश्य रखते हैं. खासकर तब, जब Skills का Python code interpreter के ज़रिए सीधे MCP call कर सके — वही असली छलांग है (हमने भी यह किया है और यह बहुत अच्छा काम करता है)

    • terminal-based tools की तुलना में MCP का एक बड़ा फ़ायदा यह है कि यह पूरी तरह isolated Linux environment जैसे sandbox के बिना भी चल सकता है. और इसे कहीं अधिक simple models के साथ भी इस्तेमाल किया जा सकता है. laptop या यहाँ तक कि phone पर चलने वाले models भी दो-तीन MCP आराम से संभाल सकते हैं. ईमानदारी से कहूँ तो ऐसे models से files पढ़ने और curl तक भरोसेमंद तरीके से चलाने की उम्मीद करना मुश्किल है

    • LLM को external software या physical world के साथ integrate करना आजकल सच में बहुत शानदार लगता है. और यह सब natural language के ज़रिए संभव है. यहाँ तक कि LLM MCP server code भी बना सकता है, इसलिए बिल्कुल नई capabilities भी आसानी से बनाई जा सकती हैं

  • सच कहूँ तो मुझे लगता है MCP को ज़रूरत से ज़्यादा बढ़ा-चढ़ाकर पेश किया गया है और इसकी सीमाएँ भी साफ़ हैं. मौजूदा MCP servers में से 95% बेकार हैं, और उन्हें साधारण tool calls से आसानी से बदला जा सकता है

    • यह तो साफ़ बात है कि अच्छे MCP servers वाकई बहुत अच्छे होते हैं. लेकिन ख़राब MCP servers उल्टा और गंभीर समस्याएँ पैदा करते हैं. आमतौर पर हर product team पर यह दबाव रहता है कि “MCP hot है”, इसलिए उन्हें MCP server बनाना ही चाहिए. customers के पास भी AI adoption से जुड़े अनिवार्य goals होते हैं, इसलिए वे ऐसी चीज़ें माँगते हैं. लेकिन असल में उन्हें पता नहीं होता कि चाहिए क्या; बस इतना काफी है कि कहा जा सके “इसमें AI है”. नतीजा यह होता है कि product teams, भले AI adoption का कोई साफ़ असर न हो, MCP की मदद से जल्दी से यह मार्केट कर पाती हैं कि “हम AI product हैं”. यह AI के सार से बहुत ज़्यादा जुड़ी चीज़ नहीं है

    • MCP का इस्तेमाल करने के लिए आपको server provider पर भरोसा करना पड़ता है. असल में आप server की ईमानदारी पर निर्भर होते हैं. व्यवहार में Uber जैसी कंपनियाँ तरह-तरह की prompt engineering करके LLM को लगातार यह मानने पर मजबूर करेंगी कि उनकी service ही सबसे अच्छा विकल्प है. यानी MCP publisher और consumer के बीच incentives पूरी तरह misaligned हैं

    • मैं सहमत हूँ कि आखिरकार tool call ही मूल चीज़ है. लेकिन CLI की तुलना में MCP के कम से कम दो फ़ायदे हैं. पहला यह कि जब tool-calling LLM structured output माँगते हुए complex interactions लागू करता है, तब MCP, CLI से आसान पड़ता है. दूसरा यह कि tool calls के बीच state को MCP server में स्वाभाविक रूप से बनाए रखा जा सकता है. शुरू में मुझे भी लगा था कि शायद मैं hype में बह गया हूँ, लेकिन हाल ही में MCP सीखने के लिए मैंने एक छोटा demo बनाया (https://github.com/cournape/text2synth), और वह CLI से बनाने की तुलना में आसान था. मुझे लगता है यह MCP के दिलचस्प उपयोगों की अच्छी मिसाल है

    • MCP servers hackers में बहुत लोकप्रिय लगते हैं. बहुत सारे instances बेहद ढीले ढंग से configure किए गए हैं और जल्दबाज़ी में deploy किए गए हैं. कंपनियाँ जैसे अपनी सारी पुरानी deployment defenses हटाती जा रही हों

    • हमारी frontend team ने figma MCP से बहुत बड़ा value निकाला. जो काम 3 हफ़्ते लेता, वह एक दिन में हो गया

  • मैंने भी कुछ markdown files से skills जैसी चीज़ बना ली थी. बस हर session में एक बार agent को वह skill याद दिला दो, इतना काफी होता है. Claude यह कर रहा है, इसमें मुझे कोई बहुत खास बात नहीं दिखती

    • किसी pattern को नाम देना अपने-आप में अहम होता है. बहुत से लोग इसे पहले से स्वाभाविक रूप से खोजकर इस्तेमाल कर रहे थे; यह एक उपयोगी pattern था. लेकिन नाम मिल जाने से इस पर ज़्यादा उच्च-स्तरीय चर्चा संभव हो जाती है. Anthropic ने खास तौर पर यह भी पहचाना कि यह pattern coding agents की पुरानी समस्या “context pollution” को हल करने में मदद करता है. पहले AGENTS.md या MCP में context में बहुत ज़्यादा जानकारी भर जाती थी, जिससे वे अव्यावहारिक हो जाते थे, लेकिन skills pattern कहीं अधिक efficient है

    • यह कुछ वैसा लगता है जैसे पहले से हल की जा चुकी समस्या को औपचारिक रूप से structure दे दिया गया हो और थोड़ी automation जोड़ दी गई हो. जिन MCPs का मैंने पहले इस्तेमाल किया था, उनमें से कई बस fancy documentation search ही थे, और उम्मीद है कि इस तरह के skills उन्हें replace कर देंगे

    • मेरे मन में भी वही सवाल है. मैं इसे Aider या CC के साथ एक साल से ज़्यादा समय से इस्तेमाल कर रहा हूँ

  • यह थोड़ा नकारात्मक लग सकता है, लेकिन देखना चाहता हूँ कि क्या कोई और भी ऐसा महसूस करता है. अगर आप औसत user से कहें कि वह खुद ऐसी services set up करे, तो उसका “क्या तुम पागल हो?” कहना बिल्कुल सही होगा. ज़्यादातर लोग बस login करना चाहते हैं, कुछ माँगना चाहते हैं, और चाहते हैं कि system बाकी सब अपने-आप संभाल ले. MCP, Apps, Skills, Gems — ये सब समस्या को गलत तरह से पकड़ रहे हैं. यह कुछ वैसा है जैसे YouTube पर हर 6 महीने में कोई कहे “नई programming language या framework सबसे बढ़िया है”, फिर एक todo app बनाए, और वही वीडियो अधिकतम 6 बार दोहराता रहे. बस बार-बार होने वाले सतही सुधार हैं, लेकिन बुनियादी समस्या हल नहीं होती. tech की दुनिया में कहीं न कहीं कुछ गड़बड़ है; जब पैसा किसी दिशा में उमड़ता है, तो ऐसे ही announcements की बाढ़ आ जाती है, फिर अगला release, promotion, job switch — और असली value पीछे छूट जाती है

    • जहाँ तक “बुनियादी समस्या” के हल न होने की बात है, आजकल solutions तो नए problems को भी साथ पैक करके लाते हैं. डिब्बा खोलो तो problem और solution दोनों साथ बाहर कूदते हैं, एक-दूसरे का पीछा करते और भागते रहते हैं. और आपको लगता है कि आप तकनीकी रूप से और विकसित इंसान बन गए हैं

    • MCP, Apps, Skills, Gems वगैरह सब गलत समस्या पर काम कर रहे हैं — इस पर मेरे नकारात्मक नज़रिए से देखें तो हम AI के लिए और ज़्यादा docs और APIs बना रहे हैं, जबकि अगर यही docs इंसानों के लिए बनाए जाते, तो शायद नतीजे बहुत अलग नहीं होते. मेरा आधा समय बिना docs वाले जटिल systems को debug करने में ही निकल जाता है

    • “बुनियादी समस्या” से आपका मतलब क्या है, और 2023 में ChatGPT के mainstream होने से पहले ऐसे “बुनियादी problems” को हल करने का cycle लगभग कितना था, यह जानना चाहता हूँ

    • अगर “एक ही todo app को 6 बार बनाकर भूल जाना” वाली बात को उदाहरण लें, तो मुझे समझ नहीं आता कि इसमें समस्या क्या है. tech स्वभाव से incremental और iterative तरीके से आगे बढ़ती है. कल फिर कोई “सबसे बढ़िया frontend framework” पर वीडियो डालेगा; पहले Nextjs था, उससे पहले React, Angular, JQuery, PHP, HTML के साथ भी यही होता था. अगर AI पर इतना निवेश न आया होता, तो हम शायद अभी भी GPT-3 या Claude 2 पर अटके होते. tools के स्तर पर कई कमज़ोर चीज़ें निकलती हैं (हालाँकि मुझे Skills काफ़ी अच्छे लगते हैं), लेकिन इससे यह नहीं कहा जा सकता कि पूरी industry सड़ चुकी है

    • खैर, अभी सब कुछ शुरुआती दौर में है और असल में क्या काम करेगा, यह किसी को नहीं पता. ऊपर से यह सतही प्रयोग जैसा लगता है, लेकिन वास्तव में यह cutting edge है

  • यह पूरी तरह अलग अवधारणा है. MCP में external services से connection, oauth जैसी authentication handling तक शामिल है. Skills मूलतः CLI tools + prompts का संयोजन हैं. दोनों के उपयोग-क्षेत्र अलग हैं, इसलिए इनकी सीधी तुलना आसान नहीं है. वैसे, MCP आने से पहले हम भी Skillset नाम का एक system बनाकर इस्तेमाल करते थे, और अब पीछे मुड़कर देखूँ तो लगता है कि वह MCP और Skills — दोनों की खूबियों को मिलाने वाला एक बेहतरीन hybrid था
 
github88 2025-10-18

यह वाकई हद से ज़्यादा बढ़ा-चढ़ाकर कहना है