क्या MCP खत्म हो चुका है?

 (quandri.io)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • MCP LLM को बाहरी टूल्स से जोड़ता है, लेकिन डेवलपर वर्कफ़्लो में context cost, operational stability, और CLI/API overlap बड़ा बोझ बनकर सामने आते हैं
  • Quandri के माप के अनुसार Linear·Notion·Slack·Postgres के 77 tool definitions लगभग 21,077 tokens हैं, जो Claude 200K context का 10.5% घेरते हैं
  • Linear issue lookup में MCP तरीका 42 tool definitions हमेशा लोड करता है, इसलिए यह CLI तरीका के लगभग 200 tokens की तुलना में कहीं अधिक, लगभग 12,957 tokens खर्च करता है
  • MCP में अलग server process के साथ authentication·initialization·conflict·external round-trip latency का बोझ जुड़ता है, जबकि CLI/API को terminal में reproduce, debug, और compose करना आसान है
  • Quandri ने मौजूदा CLI को Skills में wrap करके लगभग 21K tokens बचाए, और MCP का उपयोग केवल वहीं किया जहाँ CLI नहीं था या team-level permission control की ज़रूरत थी

MCP ने जो मुख्य लागत उजागर की

  • MCP(Model Context Protocol) LLM को GitHub, Linear, Notion, Slack जैसे बाहरी टूल्स से जोड़ता है, लेकिन वास्तविक डेवलपमेंट वर्कफ़्लो में context usage, operational stability, और मौजूदा CLI/API के साथ overlap बड़ी समस्या बन जाते हैं
  • 2024 के अंत में लॉन्च होने के बाद इसे “AI ecosystem का USB-C” कहा गया, लेकिन इसे रोज़ इस्तेमाल करने वाले डेवलपर्स के लिए पहले दूसरी लागतें सामने आईं
  • Claude Code में इस माप के बाद Tool Search with Deferred Loading जोड़ा गया, जो ज़रूरत पड़ने पर MCP tool schema लोड करता है और context usage को 85% से अधिक घटाता है
  • अभी Claude Code में context bloat की समस्या काफी हद तक कम हुई है, लेकिन performance, debugging, और architecture की समस्याएँ अब भी बाकी हैं

Context window का बड़ा हिस्सा खा जाता है

  • Context window वह जगह है जिसका उपयोग LLM काम करने के लिए करता है, और जब MCP server जोड़ा जाता है तो वास्तविक काम की सामग्री नहीं बल्कि केवल tool definitions ही उसका बड़ा हिस्सा घेर लेते हैं
  • Quandri environment में जुड़े MCP servers की वास्तविक tool definitions निकालकर मापने पर पाया गया कि सभी 4 servers को जोड़ने पर सिर्फ tool definitions ही context window का 10.5% उपयोग कर लेते हैं
  • Tool definition का आकार:
    • Linear: 42 tools, लगभग 51,229 characters, लगभग 12,807 tokens
    • Notion: 14 tools, लगभग 16,156 characters, लगभग 4,039 tokens
    • Slack: 12 tools, लगभग 15,168 characters, लगभग 3,792 tokens
    • Postgres: 9 tools, लगभग 1,755 characters, लगभग 438 tokens
    • कुल: 77 tools, लगभग 84,308 characters, लगभग 21,077 tokens
  • Model के अनुसार context usage:
    • Claude 200K context में tool definitions 10.5% जगह लेते हैं
    • GPT-4o 128K context में tool definitions 16.5% जगह लेते हैं
  • सिर्फ Linear में भी 42 tool definitions हमेशा लोड होते हैं और लगभग 12,800 से अधिक tokens घेरते हैं; वास्तविक उपयोग में भले ही केवल get_issue और save_issue इस्तेमाल हों, फिर भी पूरी definition साथ लोड होती है
  • बड़ी tool definitions के उदाहरण:
    • linear/save_issue: 2,479 characters, लगभग 619 tokens
    • slack/search_public: 1,614 characters, लगभग 403 tokens
    • linear/list_issues: 1,588 characters, लगभग 397 tokens
    • notion/fetch: 1,379 characters, लगभग 344 tokens
    • slack/send_message: 1,248 characters, लगभग 312 tokens

Operational stability और performance का बोझ

  • MCP में अलग process शुरू करके उसे बनाए रखना पड़ता है, इसलिए initialization failure और बार-बार authentication की समस्या हो सकती है
  • हर tool call पर external server तक round-trip की ज़रूरत पड़ती है, जिससे AI response speed धीमी हो जाती है
  • MCP server process crash हो जाए तो session के बीच में tools गायब हो सकते हैं
  • हर tool के पास वास्तव में कौन-सी permission है यह स्पष्ट नहीं होता, इसलिए permission visibility कम रहती है
  • MCP is dead. Long live the CLI के Jira MCP benchmark में direct REST API call की तुलना में MCP प्रति call 3 गुना धीमा था, और initialization सहित पहला call 9.4 गुना धीमा था
  • यह performance gap केवल Jira तक सीमित नहीं है, बल्कि LLM और base API के बीच MCP server नाम की process layer जुड़ने वाली संरचना से आता है
  • यही overhead Quandri stack के Linear, Notion, और Slack servers पर भी लागू होता है

मौजूदा CLI/API के साथ overlap

  • CLI/API में इंसान और LLM एक ही commands इस्तेमाल कर सकते हैं, लेकिन MCP केवल LLM conversation के अंदर मौजूद रहता है
  • CLI/API को pipe, jq, grep के साथ स्वतंत्र रूप से जोड़ा जा सकता है, जबकि MCP server द्वारा लौटाए गए format तक सीमित रहता है
  • CLI/API को terminal में तुरंत reproduce और debug किया जा सकता है, लेकिन MCP को केवल conversation context के अंदर ही reproduce किया जा सकता है
  • LLM पहले से man page और StackOverflow के ज़रिए CLI/API का इस्तेमाल सीख चुका है, लेकिन MCP के लिए अलग tool definitions चाहिए
  • CLI/API आमतौर पर पहले से installed होते हैं, जबकि MCP में server setup, authentication, और process management अतिरिक्त रूप से चाहिए

Linear issue lookup की token cost

  • एक ही Linear issue को देखते समय MCP तरीका CLI तरीके की तुलना में लगभग 65 गुना अधिक tokens खर्च करता है
  • CLI तरीका लगभग 200 tokens इस्तेमाल करता है:
    • curl command prompt: लगभग 50 tokens
    • response: लगभग 150 tokens
  • MCP तरीका लगभग 12,957 tokens इस्तेमाल करता है:
    • हमेशा लोड होने वाली 42 Linear tool definitions: लगभग 12,807 tokens
    • tool call और response: लगभग 150 tokens
  • CLI उदाहरण Linear GraphQL API को सीधे call करता है:
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

विकल्प: CLI-first रणनीति और Skills

  • CLI → API → docs क्रम में उपलब्ध कराना ज़्यादा हल्का और सीधा तरीका है
  • LLM पहले से man page और StackOverflow से CLI usage सीख चुका है, इसलिए अलग tool definitions को हमेशा साथ लोड करने की ज़रूरत नहीं है
  • मौजूदा CLI का सीधे उपयोग करने पर tool definitions के कारण context बर्बाद नहीं होता, और इंसान व AI एक ही interface इस्तेमाल करते हैं, इसलिए debugging आसान होती है
  • Pipeline के ज़रिए इसे अन्य commands के साथ स्वतंत्र रूप से जोड़ा जा सकता है
  • अगर MCP “खाने की मेज़ पर पहले से पूरा मेन्यू फैला देने” जैसा है, तो Skills “ज़रूरत पड़ने पर केवल वही किताब मँगाने” जैसा है
  • MCP connection के समय सभी tool definitions लोड करता है और हमेशा context घेरता है, जबकि Skills केवल ज़रूरत पड़ने पर लोड होते हैं और उपयोग के समय ही context लेते हैं
  • Server बढ़ते जाने पर MCP का context pressure बढ़ता है, जबकि Skills केवल skills की संख्या के अनुपात में हमेशा context नहीं घेरते
  • मुख्य बात यह है कि CLI usage instructions को Skills के भीतर रखा जाए, और CLI-first रणनीति के साथ मिलाकर यह सबसे प्रभावी बनता है
  • Linear Skill उदाहरण में केवल API URL, authentication तरीका, issue lookup के लिए curl command, GraphQL search तरीका, और jq से JSON parse करने का निर्देश शामिल है:
# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq
  • इस तरीके में LLM केवल उसी Skill को call करते समय ऊपर की सामग्री context में लोड करता है
  • 42 Linear tool definitions को हमेशा साथ ढोने के बजाय केवल ज़रूरी CLI command ही लोड करनी होती है

जहाँ MCP अब भी उपयोगी है

  • जब किसी service के लिए CLI नहीं हो, तब MCP ही एकमात्र connection तरीका हो सकता है
  • गैर-डेवलपर users के लिए, जो terminal इस्तेमाल नहीं करते, MCP अधिक सुलभ हो सकता है
  • साधारण request-response से आगे के real-time bidirectional communication में MCP उपयुक्त हो सकता है

Database access चुनने के मानदंड

  • Database access का मूल अर्थ query execution ही है, और LLM पहले से SQL और MongoDB queries अच्छी तरह जानता है
  • अगर DB जानकारी और CLI usage को Skill में रखकर schema दिया जाए, तो MCP के बिना भी LLM queries लिख सकता है
  • Postgres Skill उदाहरण में केवल host, table schema, और psql CLI usage शामिल है:
# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."
  • Database में MCP के कुछ फायदे भी हैं:
    • Query safety: MCP server read-only mode लागू कर सकता है और खतरनाक queries को server level पर block कर सकता है
    • Credential protection: CLI तरीके में prompt में connection string उजागर हो सकती है, जबकि MCP server अंदर ही credentials संभालता है
  • Local development या personal DB के लिए Skills + CLI हल्का, तेज़, और गलती से उबरने में आसान है
  • Production DB या shared team environment के लिए MCP उपयुक्त है, जहाँ server-level query validation और access control जैसे सुरक्षा उपाय महत्वपूर्ण हैं
  • ज़्यादातर डेवलपर वर्कफ़्लो में MCP आसानी से over-engineering बन सकता है

Quandri इसे कैसे उपयोग करता है

  • Quandri service के अनुसार Bash + CLI, Skills, और MCP का साथ में उपयोग करता है
  • gh, psql, aws जैसे रोज़ इस्तेमाल होने वाले tools के लिए Bash + CLI इस्तेमाल होता है:
    • context cost नहीं है
    • flexibility अधिक है
    • terminal में तुरंत debugging संभव है
  • Commit लिखने और PR review जैसे दोहराए जाने वाले multi-step workflows के लिए Skills उपयोग किए जाते हैं:
    • केवल call होने पर लोड होते हैं
  • Slack, Linear, Notion जैसी services जिनके लिए मजबूत CLI नहीं है, वहाँ MCP उपयोग होता है
  • Production database access जैसे मामलों में, जहाँ team-level authentication या permission scope महत्वपूर्ण हो, वहाँ भी MCP उपयोग होता है
  • अगर पहले से CLI मौजूद है और local authentication संभव है, तो आमतौर पर वही सबसे हल्का तरीका है
  • अगर service के लिए CLI नहीं है या पूरी team के लिए consistent authentication चाहिए, तो MCP उपयोगी बनता है

निष्कर्ष और measurement method

  • सब कुछ जोड़ देने से अधिक महत्वपूर्ण है अच्छी तरह सिखाना
  • Quandri ने मौजूदा CLI को wrap करने वाले Skills से MCP servers को बदलकर लगभग 21K tokens का context वापस हासिल किया
  • रोज़मर्रा के workflows में initialization failure गायब हो गए, और debugging terminal में ही बनी रही
  • केवल ज़रूरी tools को, ज़रूरत के समय, CLI instructions के साथ लोड करना अधिक प्रभावी है
  • MCP भविष्य में इन समस्याओं को हल करने के लिए evolve हो सकता है, लेकिन अभी के हिसाब से Skills बेहतर विकल्प हैं
  • Measurement method:
    • Claude Code environment में वास्तव में लोड हुए MCP servers के प्रत्येक tool JSON schema को निकाला गया
    • tool name, description, और parameters के आधार पर आकार मापा गया
    • token estimation के लिए लगभग 4 characters प्रति 1 token heuristic का उपयोग किया गया
    • पूरे server का अनुमान sample tools के average से extrapolate किया गया

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

2 टिप्पणियां

 
aer0700 3 시간 전

मुझे तो लगता है कि बस अपनी स्थिति के हिसाब से सही तकनीक चुन लेनी चाहिए। इसे मरा हुआ कहना मुश्किल है, क्योंकि इसका इस्तेमाल पहले से ही बहुत ज़्यादा हो रहा है।
 
GN⁺ 5 시간 전
Hacker News की राय

  • मैं OpenAI में उस टीम का नेतृत्व करता हूँ जो ChatGPT App Store, Codex plugins, और व्यापक रूप से MCP पर काम करती है, और “MCP मर चुका है” जैसी पोस्टें जिस बात को मिस करती हैं वह यह है कि MCP ट्रांसपोर्ट प्रोटोकॉल के रूप में इस्तेमाल हो रहा है या नहीं, यह व्यावहारिक रूप से उतना महत्वपूर्ण नहीं है
    MCP इसलिए नहीं मरा है क्योंकि पृथ्वी पर लगभग हर कंपनी MCP server बना रही है, और हमें यह इसलिए पता है क्योंकि हमारा उनसे सीधा संपर्क है
    इन कंपनियों में से कई के पास CLI नहीं है, यहाँ तक कि external API भी नहीं है, लेकिन वे MCP server बना रही हैं
    आंतरिक रूप से आप सभी MCP server को CLI में बदल सकते हैं, या code mode का उपयोग कर सकते हैं, या tool discovery लागू कर सकते हैं, लेकिन वह implementation detail है; मूल बात यह है कि AI agents उन services तक पहुँच पा रहे हैं जिन तक वे पहले पहुँच नहीं सकते थे
    यह अस्पष्ट हो सकता है कि models के सीधे बातचीत करने वाली communication layer के रूप में MCP मर चुका है या नहीं, लेकिन protocol के रूप में MCP बिल्कुल भी मृत नहीं है
    Codex app की computer/browser use सुविधा के कारण यह दावा पहले से कमजोर हो गया है, और अगर आपने इसे अभी तक नहीं आज़माया है, तो यह सचमुच चौंकाने वाले स्तर का है

    • मुझे लगता है कि MCP के मरने की संभावना काफ़ी ज़्यादा है
      सबसे बड़ा कारण यह है कि असली implementation चाहे API हो, web हो या CLI, उसके ऊपर एक और layer और एक और व्यक्ति जुड़ जाता है, जहाँ sync टूट सकता है
      AI को मनुष्यों द्वारा उपयोग किए जाने वाले तरीकों से अलग कोई protocol या instruction set इस्तेमाल नहीं करना चाहिए
      अभी कंपनियाँ ट्रेंड की वजह से MCP server expose करना चाहती हैं, लेकिन हक़ीक़त यह है कि Claude से existing API के ऊपर MCP server बनवाया जाता है, और फिर कभी-कभी उसे public docs के मुताबिक update करने को फिर से कहा जाता है
      API docs पहले से public हैं और Claude Code ने भी इंटरनेट पर मौजूद public docs पढ़कर MCP server बनाया था, इसलिए MCP अभी models की सीमाओं के लिए एक अस्थायी workaround जैसा लगता है
    • आखिरकार MCP एक तरह से “API जिसे large language models इस्तेमाल कर सकें” जैसा brand name है
      इसका नतीजा यह है कि जो कंपनियाँ पहले ज़्यादा तकनीक-केंद्रित नहीं थीं, वे भी agent युग में अपने tools को पुराना न दिखाने के लिए API बना रही हैं
      मैं इस लक्ष्य से सहमत हूँ, लेकिन क्या मैं इसके लिए यही protocol चुनूँगा, यह अलग बात है; फिर भी यह ऐसा protocol बन गया है जिसके बारे में लोग सुन चुके हैं और जिसे वे वास्तव में इस्तेमाल कर रहे हैं
    • “पृथ्वी पर लगभग हर कंपनी MCP server बना रही है” यह बात ही echo chamber जैसी लगती है
    • MCP असल में ऐसे problem को हल करने की कोशिश करता है जो मौजूद ही नहीं है, और फिर भी कीमती context window खर्च करता है
      यह दावा कि MCP के बिना agents services तक पहुँच नहीं सकते, अच्छी से अच्छी स्थिति में भी भ्रामक है, और जैसा लेख में कहा गया है, command-line tools और उनके input/output के ज़रिए भी पहुँचा जा सकता है
      शुद्ध तकनीकी नज़रिए से भी MCP की composability command-line tools की तुलना में कम है, और जो composability को महत्व नहीं देते, उन्हें अंततः इसकी कीमत चुकानी पड़ेगी
      साफ़ कहूँ तो इसमें investment bias दिखता है, और यह तथ्य कि आप कई कंपनियों को MCP बेच रहे हैं, उस bias को खारिज नहीं करता
      सिर्फ़ Microsoft को देखकर भी समझा जा सकता है कि उपयोगिता और तकनीक कितनी गहराई से दब सकती है; कुछ लोग तो इसे उल्टा मानते हैं
      मुझे संदेह है कि OpenAI अभी MCP को जिस तरह आगे बढ़ा रहा है, उसमें संगठनात्मक कारण भी बड़े हैं, और अंदर से यह बात देखना आसान नहीं होगा
    • जहाँ CLI नहीं है, वहाँ MCP बनाया जा रहा है—यह बात काफ़ी चिंताजनक है
      मौजूदा CLI functionality को बेहतर agent integration के लिए दोहराना एक बात है, और सबको ऐसे एकमात्र interface से बाँध देना दूसरी, जो बाद में शायद कमतर specification साबित हो
      तब बाद में MCP debt चुकाना पड़ेगा, और अंत में शायद यह सब न करना ही सस्ता पड़ता

  • यह लेख पढ़कर लगता है जैसे इसे AI ने लिखा हो
    MCP मूल रूप से कुछ विशेष fields वाले JSON-RPC के काफ़ी क़रीब है
    JSON-RPC को लेकर चिंताएँ हैं, लेकिन large language models के एकीकरण के लिए service discovery layer की ज़रूरत है
    यह websites, desktop applications, backend services जैसी कई जगहों पर काम कर सके, और CLI तो बस ऐसे systems से मिलने का एक बिंदु है
    MCP की जगह जो भी आए, भले communication protocol या tool discovery fields अलग तरह से परिभाषित किए जाएँ, उसके मिलते-जुलते रूप में होने की संभावना काफ़ी ज़्यादा है

    • जब भी मैं MCP पर कोई लेख पढ़ता हूँ, लगता है जैसे पूरा इंटरनेट या पूरा HN सामूहिक उन्माद में चला जाता है
      लोग कहते हैं API, MCP से बेहतर है, लेकिन MCP तो बस API ही है जिसमें AI को उसके इस्तेमाल का तरीका समझने के लिए थोड़ी-सी guidance जोड़ दी गई है
      कुछ लोग CLI इस्तेमाल करने को कहते हैं, लेकिन उसका ठीक-ठीक मतलब क्या है, यह मुझे समझ नहीं आता
      large language models ffmpeg जैसे आम CLI tools का अच्छे से उपयोग इसलिए कर लेते हैं क्योंकि वह ज्ञान उनके weights में पहले से जम चुका है
      अगर आप कोई नया CLI tool बनाते हैं, तब भी आपको AI को उसका इस्तेमाल सिखाना पड़ेगा, और अगर वह “सिखाने” वाला हिस्सा server से देना है तो MCP, और अगर उसे local static रूप में रखना है तो skill
      इतनी सरल अवधारणा पर इतना विवाद क्यों है, यह मुझे समझ नहीं आता
    • समस्या यह है कि MCP context को अपेक्षाकृत स्थायी रूप से घेर लेता है, और इसके साथ साफ़-सुथरी install/remove और discovery व्यवस्था नहीं आती
      skills को पूरी तरह MCP-आधारित होना चाहिए, ज़रूरत पड़ने पर ही बुलाया जाना चाहिए, और मनुष्यों व AI—दोनों के लिए उन्हें आसानी से manage और discover किया जा सके, तभी यह सही तरह से काम करेगा
      वास्तविक उपयोग-क्षेत्र को देखें तो शुरुआती scope बहुत संकरा था, लेकिन अगर इसके ऊपर कुछ बनाया जाए तो यह अभी भी फिर से जीवित हो सकता है

  • “समस्या 1: यह context window को निगल जाता है” वाले दावे पर, linearcli --help, notioncli --help, slackcli --help को बारी-बारी से चलाने से यह किस तरह अलग है, समझ नहीं आता
    बल्कि MCP में execution environment हर tool का सिर्फ शीर्षक context में डाल सकता है, और पूरा दस्तावेज़ ज़रूरत पड़ने पर MCP server या tool के हिसाब से बाद में जोड़ा जा सकता है
    CLI में वही असर पाने के लिए हर CLI को --short-descr जैसा command देना होगा
    “समस्या 2: कम operational reliability” भी, अगर tool REST API इस्तेमाल करता है, तो protocol लगभग समान है, इसलिए MCP के ज़्यादा धीमा होने की कोई वजह नहीं है
    अगर धीमा है, तो संभव है यह implementation की समस्या हो, जैसे API के ऊपर MCP की एक और परत जुड़ गई हो, या यह किसी दूर के data center में मौजूद outsourced server पर चल रहा हो
    ज़्यादातर MCP server खराब हालत में हो सकते हैं, लेकिन वह protocol की नहीं बल्कि industry की समस्या है
    “समस्या 3: यह मौजूदा CLI/API से ओवरलैप करता है” यह तब सही है जब पहले से CLI tool मौजूद हो, और SQL MCP server या curl MCP token की बर्बादी जैसे लगते हैं
    लेकिन ज़्यादातर संगठनों में CLI होता ही नहीं, और अगर API होता भी है, तो वह बड़े language model के लिए नहीं बल्कि प्रोग्राम के इस्तेमाल के लिए डिज़ाइन किया गया होता है
    “CLI → API → docs के क्रम में उपलब्ध कराओ” सुनने में ऐसा लगता है जैसे यह कहना कि कंपनी को धीमी और बेकार website की जगह पहले desktop native client और mobile native client देने चाहिए

    • मैंने इस क्षेत्र में बहुत गहराई से नहीं देखा है, लेकिन नवीनतम Claude Code release को छोड़ दें तो मेरी जानकारी में MCP पहले से context में लोड हो जाता है
      अगर उसकी बार-बार ज़रूरत न हो, तो उसे बंद करके ज़रूरत पड़ने पर फिर चालू करना पड़ता है
      skill file में usage examples डालने से पहले --help call की ज़रूरत कम हो सकती है, और CLI हो तो अलग context वाले sub-agent को चलाकर सिर्फ परिणाम वापस लेना भी आसान लगता है

  • लेख में तारीख नहीं है, लेकिन उसमें कहा गया है कि lazy tool loading लेख लिखे जाने के बाद आया हाल का update है
    लेकिन lazy tool loading नवंबर 2025 में जोड़ा गया था: https://www.anthropic.com/engineering/advanced-tool-use
    इसलिए ये आँकड़े कम-से-कम 7 महीने पुराने हैं, और पता नहीं यह अभी क्यों पोस्ट किया गया

    • अभी भी इस पर चर्चा होना अजीब है
      lazy tool loading, बड़ा context, और prompt caching की वजह से 2026, 2025 से पूरी तरह अलग हो चुका है
      CLI token बचाता है, यह बहस भी टूट जाती है अगर पहला चरण --help चलाना ही हो
      अगर call करने का तरीका parameters सहित याद नहीं है, तो अंततः उसे context में रखना ही पड़ेगा
    • यह उससे भी पुराना लेख लगता है, और संकेत देता है जैसे GPT-4o अभी भी सबसे नया हो
    • lazy tool loading MCP का हिस्सा नहीं है
      यह Claude API के लिए खास parameter है, जिसे ज़्यादातर दूसरे बड़े language model API support नहीं करते
    • लेख 29 मई 2026 का है, और यह कहना कि वह update उसके बाद का “हाल का” बदलाव था, खुद को बेहतर दिखाने के लिए बोला गया झूठ है

  • मुझे लगता है MCP तब बहुत अच्छा फिट बैठता है जब संगठन स्तर पर, internal agent tools इस्तेमाल करने वाले गैर-तकनीकी कर्मचारियों को internal utility API तक एकीकृत और सुरक्षित access देना हो
    workflow को skill के रूप में code करके instances के बीच share किया जा सकता है, और जहाँ context-aware API access चाहिए वहाँ MCP उसे संभाल सकता है

    • क्या यह वही लेख है? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
    • अगर हाँ, तो यह जानना चाहूँगा कि agent के सीधे API access की तुलना में MCP का फ़ायदा क्या है
    • सोच रहा हूँ, क्या यह API की सुरक्षा के लिए permission system की जगह लेता है
      API में वैसे भी किसी-न-किसी रूप में permission mechanism तो होना ही चाहिए
    • सही बात है
      Runlayer जैसी कंपनियों का तेज़ी से बढ़ना भी इसी वजह से है, और central control plane के बिना MCP एक minefield बन जाता है

  • पहले से कही गई बातों के अलावा, remote MCP producer-driven होता है, इसलिए producer को हर client की skill और CLI update किए बिना भी नई सुविधाएँ जोड़ने की सुविधा मिलती है
    और remote MCP ज़्यादा सुरक्षित भी है, क्योंकि उसे local system पर असली code execution permission की ज़रूरत नहीं होती
    skill अक्सर npx/uvx के साथ script bundle करते हैं, और यह असल में curl npm.com | bash जितना खतरनाक है

  • मैंने teamों को internal management system से जोड़ने वाली skill implement की थी, और अंत में उसे MCP के रूप में register कर दिया
    MCP सिर्फ docs grep और API call expose करता है, इसलिए अपने आप में यह बिल्कुल उपयोगी नहीं है, लेकिन यह रास्ता चुनने की मुख्य वजह deployment थी
    गैर-तकनीकी team ऐसी UI चाहती हैं जहाँ URL जोड़ते ही सब काम करने लगे और OAuth के लिए guidance मिले, और MCP Claude या ChatGPT में यह संभव बनाता है
    chat UI में MCP call जिस तरह दिखते हैं, वह भी बेहतर है और user के लिए ज़्यादा स्पष्ट है

  • MCP server संभालने और हर platform के लिए CLI deploy करने की जगह, क्या API को SSH के ज़रिए expose करना बेहतर नहीं होगा
    SSH बड़े language model के लिए लगभग आदर्श protocol है
    coding agent इसे पहले से इस्तेमाल कर सकते हैं, और ssh api@example.com list-users काफ़ी है
    90% users के पास शायद पहले से ssh installed होगा, और input भी text है, output भी text, इसलिए यह बड़े language model के लिए बिल्कुल उपयुक्त है
    यह public key authentication, streaming output, interactive input/output, और चाहें तो scp/rsync के ज़रिए file transfer तक संभाल लेता है
    अगर user ने अपना account Github या GitLab से जोड़ा है, तो ssh key निकालकर authentication पहले से सेट किया जा सकता है, ताकि बस connect करते ही सीधे अंदर पहुँच जाए

    • इसे पूरे संगठन के पैमाने पर बढ़ाकर सोचो

  • restaurant वाली analogy अच्छी नहीं है
    वह कुछ ऐसी है: “10 menu table पर फैले हैं, इसलिए खाना रखने की जगह नहीं है, और हर बार order देने पर menu फिर निकालना पड़ता है”, लेकिन repeated order tapas restaurant को छोड़कर आम नहीं है
    खाना menu के ऊपर भी रखा जा सकता है, और आम तौर पर order देने के बाद menu हटा दिए जाते हैं, यानी table, यानी context खाली हो जाता है
    अगर analogy से समझाना है, तो उसे ज़्यादा प्रासंगिक बनाने की कोशिश करनी चाहिए