MCP विनिर्देश – 2025-06-18 संस्करण में बदलाव

• MCP स्पेक का नया अपडेट structured metadata और context management पर मुख्य ज़ोर देता है। इसका उद्देश्य extensibility बढ़ाना और अलग-अलग सिस्टमों के बीच interoperability को मजबूत करना है
• नए data fields जोड़े गए हैं, और मौजूदा required fields को अधिक स्पष्ट रूप से परिभाषित किया गया है। metadata संरचना के hierarchical होने से सिस्टम-विशिष्ट अलग extension तरीकों को सपोर्ट करना संभव हुआ है
• context tracking और property updates के लिए स्पष्ट नियम दिए गए हैं, और पहले की तुलना में consistent state information management पर ज़्यादा ज़ोर है
• permission management और data validation प्रक्रियाओं को protocol specification में स्पष्ट रूप से शामिल किया गया है। नए जोड़े गए कुछ fields को भविष्य के protocol versions के साथ compatibility ध्यान में रखकर बनाया गया है
• cross-platform integration समर्थन: कई AI platforms और cloud service environments में भी context data को एकसमान तरीके से एक्सचेंज करने की बुनियाद प्रदान करता है

---

• MCP(Model Context Protocol) मशीन लर्निंग मॉडल, large language model और अन्य विभिन्न AI systems के बीच context metadata के आदान-प्रदान के लिए एक protocol है

Major changes

1. JSON-RPC batching support हटाया गया (PR #416)
2. structured tool output support जोड़ा गया (PR #371)
3. MCP server को OAuth resource server के रूप में वर्गीकृत किया गया, और protected resource metadata जोड़ा गया ताकि जुड़े हुए Authorization server को खोजा जा सके (PR #338)
4. MCP clients के लिए RFC 8707 के Resource Indicator को implement करना अनिवार्य (दुर्भावनापूर्ण server द्वारा access token हासिल करने से रोकने के उद्देश्य से) (PR #734)
5. Authorization specification में security considerations और best practices को स्पष्ट किया गया, और अलग security guide page जोड़ा गया
6. Elicitation(अतिरिक्त जानकारी अनुरोध) सुविधा जोड़ी गई, ताकि server उपयोगकर्ता से अतिरिक्त जानकारी मांग सके (PR #382)
7. Resource Links support जोड़ा गया, जिससे tool call results में resource links शामिल किए जा सकते हैं (PR #603)
8. protocol version negotiation के दौरान HTTP में MCP-Protocol-Version header अनिवार्य (PR #548)
9. Lifecycle Operation में SHOULD को MUST में बदला गया (संदर्भ)

---

Other schema changes

1. _meta field को और अधिक interface types में जोड़ा गया (PR #710), और उचित उपयोग का उल्लेख किया गया
2. CompletionRequest में context field जोड़ा गया, जिसमें पहले से व्याख्यायित variables शामिल किए जा सकते हैं (PR #598)
3. प्रोग्राम-उपयोग identifier से अलग, user-friendly display के लिए title field जोड़ा गया (name कोड identifier के लिए, title display के लिए) (PR #663)

[kernel00]

Hacker News की टिप्पणी थोड़ी निराशाजनक है। लगता है उन्होंने सिर्फ stdio ही देखा है, जबकि अभी remote MCP server और उन्हें बीच में जोड़ने वाली registry कितनी तेजी से जगह-जगह उभर रही हैं....

[GN⁺]

Hacker News राय

• MCP(Machine Context Protocol) की लहर के दौरान मैंने सबसे बड़ी बात यह सीखी कि backend software development में ज़रूरी नहीं कि MCP का इस्तेमाल किया ही जाए। आर्किटेक्चर के हिसाब से कुछ हिस्सों में यह फिट नहीं बैठता। खासकर Elixir जैसे environment में तो और भी ज़्यादा ऐसा लगता है। अगर हर API के लिए अलग server रखा जाए, तो इसका मतलब होगा 500 APIs के लिए 500 microservices चलाना। खुद 20 तरह के MCP servers इस्तेमाल करने के बाद समझ आया कि आखिरकार MCP भी function call का ही एक wrapper था। हर API को server की बजाय अलग module के रूप में बनाना काफी है। बेवजह नवीनतम MCP spec के पीछे भागने की, या spec बदलने पर हर बार सैकड़ों microservices update करने की ज़रूरत नहीं है। निष्कर्ष यही है कि यह अनावश्यक जटिलता है
  • जब तक client gateway या BFF से गुज़रे बिना हर microservice से सीधे connect नहीं करता, तब तक बस MCP को पूरे service stack के आगे रखकर API, GraphQL, RPC जैसी पुरानी विधियों की तरह केवल functionality expose कर सकते हैं। असल में यह LLM के लिए विशेषीकृत interface जैसा लगता है। OpenAPI spec आधारित tool call भी पूरी तरह इस्तेमाल किए जा सकते हैं। वैसे भी सभी microservices को आपस में सिर्फ MCP से communicate करवाना बहुत ज़्यादा बढ़ा-चढ़ा विचार है
  • मैंने MCP को बस Claude जैसे systems में API cost के बिना function call संभव बनाने वाले plugin-style integration solution की तरह देखा। अगर तुम पहले से API इस्तेमाल कर रहे हो और कोई खास जल्दी नहीं है, तो यह ज़रूरी विकल्प नहीं है
  • असल में MCP को मैं client और model को जोड़ने वाला standard protocol मानता हूँ। यह सिर्फ tool call को लपेटने वाला container नहीं है
  • हाँ, हर API के लिए एक MCP server रखना scalable structure नहीं है। nango.dev जैसी चीज़ इस्तेमाल करें तो एक server में 400 से अधिक APIs कवर की जा सकती हैं। यह authentication handling, visibility, और सीधे tool call कर सकने वाले कई interfaces भी देता है। (संदर्भ के लिए, मैं founder हूँ)
  • मैं इससे भी आगे जाकर यह मानता हूँ कि LLM से JSON output जबरन निकलवाने की संस्कृति ही मूर्खतापूर्ण है। LLM को वैसे भी पसंद न आने वाले इस कठिन format में ढालने के लिए बहुत समय और मेहनत लगती है। इससे कहीं अधिक constrained text-based DSL एक बहुत बेहतर विकल्प रहा। पुराने GPT 3.5 के समय prompt में कुछ सरल examples देने भर से English-based DSL को भरोसेमंद तरीके से output कराया जा सकता था। लेकिन नवीनतम models के बारे में भी यह चेतावनी बनी हुई है कि वे कभी-कभी JSON schema के कुछ हिस्सों को नज़रअंदाज़ कर देते हैं। यह चौकोर छेद में गोल कील ठूँसने जैसा लगता है, काश सब लोग यह ज़बरदस्ती न करें
• अब authenticated MCP servers तक जाने का एक आसान रास्ता आ गया है, इससे मैं सच में बहुत खुश हूँ। MCP community और Anthropic team के प्रति दिल से आभार जताना चाहता हूँ
  • मुझे ठीक से समझ नहीं आता कि MCP server की ज़रूरत ही क्यों है। अगर agent को RPC करना है, तो क्या वह बस RPC ही इस्तेमाल नहीं कर सकता?
• यह बात सच में दिलचस्प लगती है कि core spec OpenAPI या किसी और चीज़ की बजाय TypeScript में लिखी गई है। इसके पीछे कोई ठोस कारण होगा, लेकिन फिर भी यह अप्रत्याशित लगता है
  • यह चौंकाने वाली बात क्यों है, यह जानने की जिज्ञासा है। मैं भी TypeScript बहुत इस्तेमाल करता हूँ, लेकिन इस नज़रिए से कभी नहीं सोचा था, इसलिए language design की तरफ़ से कौन-से निर्णय लिए गए होंगे यह जानना चाहता हूँ
• WWW-Authenticate challenge जोड़ा जाना बेहद स्वागतयोग्य खबर है। अब तस्वीर साफ हो गई है कि MCP server client को resource provider के OAuth flow पर भेज सकता है, और बस Authorization: Bearer ... header वापस ले सकता है
• मुझे लगता है कि <i>ज़्यादातर</i> मामलों में यह अनावश्यक जटिलता है, लेकिन batch execution feature का जाना खलता है। 'यह सारे काम कर लो, फिर एक साथ result दो' जैसी चीज़ implement करना मज़ेदार था। हाँ, client खुद भी batch response जोड़ सकता है, फिर भी इसमें मज़ा था
  • सही बात। JSON-RPC batch feature ऐसा था कि सच में लगा, “वाह, यह तो दिलचस्प है।” spec से हटना अफ़सोस की बात है, लेकिन आखिरकार यह complexity भी बढ़ाता है, इसलिए वजह समझ में आती है
• मुझे लगता है कि elicitation (inference-based prompt processing) बड़ा लाभ है। मेरे पसंदीदा MCP servers में से एक मेरा खुद बनाया हुआ SSH server है। इससे पूरे server tasks का 90% automate किया जा सकता है। authentication मैंने config file से संभाला, लेकिन जब भी किसी नए server से जुड़ना होता है, तो उसे हाथ से edit करना पड़ता है, जो थोड़ा असुविधाजनक है
  • ऐसे मामलों में fabfile.org जैसी चीज़ भी इस्तेमाल की जा सकती है। अगर बातचीत ऐसी है जिसमें LLM लाना ज़रूरी नहीं, तो उसे निजी रखना ही बेहतर है
• पिछले कुछ दिनों में मैंने MCP के साथ dataset wrapper बनाते हुए प्रयोग किए

1. मुझे यह LLM क्षेत्र की सबसे रोमांचक कोशिशों में से एक लगती है। हाँ, पुराना API & tool call approach लेकर भी कुछ ऐसा किया जा सकता है, लेकिन किसी कम तकनीकी दोस्त को सिर्फ Claude के लिए MCP URL भेजकर कुछ clicks में चीज़ चलवा देना बहुत प्रभावशाली था
2. मैं csharp SDK इस्तेमाल कर रहा हूँ, और authentication feature अभी branch में ही है, इसलिए सब कुछ बहुत शुरुआती स्थिति में है। MCP integration के दौरान 95% समय authentication implement करने में गया (अगर local build नहीं है तो यह अनिवार्य है)। आगे documentation बढ़ेगी तो चीज़ें बेहतर होंगी, लेकिन अभी यह काफी मेहनत वाला process है
3. developer logs की कमी भी महसूस होती है। Claude web पर (desktop नहीं) क्या भेज रहा है, क्या पा रहा है, और कहाँ error हो रही है—यह developer mode में request/response logs के रूप में दिखना चाहिए। authentication refresh problem के कारण मैं काफ़ी देर तक उलझा रहा, और बाद में पता चला कि मैं गलत endpoint log कर रहा था। अगर बेहतर MCP logging होती तो यह काम कुछ ही मिनटों में खत्म हो जाता। desktop और MCP inspector में यह ठीक काम करता है
4. सबसे बड़ी चिंता long-running tasks को लेकर है। जो dataset मैं expose करता हूँ, वह कई PDF documents का है। Claude खुद PDF संभाल नहीं पाता दिखता है (अगर कोई तरीका हो तो ज़रूर बताएं!), इसलिए फिलहाल मैं पहले gemini से text conversion कराकर फिर MCP से दे रहा हूँ। छोटे documents पर यह ठीक चलता है, लेकिन लंबे documents में processing time बढ़ जाता है। अभी मैं सिर्फ इतना संदेश देता हूँ कि 'processing चल रही है, बाद में फिर कोशिश करें'। progress API है, लेकिन इसके लिए server से लगातार connection बनाए रखना पड़ता है (Cloudflare पर कुछ समय बाद connection टूट जाता है), इसलिए इसकी practical limits लगती हैं। अगर कोई ऐसा तरीका हो जिसमें LLM को x सेकंड बाद फिर check करने को कहा जाए, और तब तक वह दूसरे काम कर सके, फिर timer खत्म होने तक execution 'अस्थायी रूप से रोक' दी जाए, तो वह सच में शानदार होगा। अभी या तो connection बनाए रखने पर LLM कुछ नहीं कर पाता और waiting state में रहता है, या फिर job ID देकर लौटाने पर अक्सर incomplete response मिलता है और पूरा context गायब हो जाता है। जो काम 10 मिनट से ज़्यादा लेते हैं, उनके लिए यह बड़ी रुकावट बन सकती है

• long-running tasks अभी भी सार्वजनिक चर्चा का विषय हैं। मेरी जानकारी में MCP आगे चलकर इसे address करना चाहता है। कई proposals चल रहे हैं, और हमेशा पहले से पता नहीं होता कि कोई task लंबा चलेगा या नहीं, इसलिए सिर्फ अलग long-running task API बना देना समाधान नहीं है। इसे समग्र रूप से हल करने के लिए मेरा भी एक प्रस्ताव है discussion लिंक
• MCP spec का तेज़ी से बेहतर होना देखना बहुत अच्छा लगता है। हर नए release में मैं देखता हूँ कि MCP integration को लेकर मेरी पुरानी शिकायतों में से कोई न कोई भर दी गई है
• यह बात दिलचस्प लगी कि spec changes को merge होने के लिए सिर्फ एक approval चाहिए
• मुझे समझ नहीं आता कि MCP वास्तव में किस समस्या का समाधान करता है। व्यक्तिगत रूप से मुझे यह बस laptop पर जल्दी prototype बनाने जैसी भूमिका में ही दिखता है। अगर मैं कोई local program बना रहा हूँ, तो मैं यह कहीं ज़्यादा बारीकी से नियंत्रित करना चाहूँगा कि LLM किन tools तक पहुँच सकता है। उदाहरण के लिए Google Calendar के लिए MCP server सोचें, तब भी MCP बहुत समय नहीं बचाता। वही API मैं खुद भी इस्तेमाल कर सकता हूँ, और LLM को यह साफ़-साफ़ बताना ही पड़ेगा कि Google Calendar को कब और कैसे call करना है, इसलिए मैं यह किसी तीसरे पक्ष को सौंपना नहीं चाहूँगा। फिर चाहे MCP किसी भी language में लिखा गया हो, अपने environment में मनमाने process चलाना भी बोझिल लगता है। अगर मेरी तरफ़ Python है लेकिन user को अलग से TypeScript runtime install करना पड़े, तो यह मुश्किल हो सकती है। MCP wrapper में कोई vulnerability आ जाए तो security concern भी है। server environment में इसका औचित्य साबित करना और कठिन है। अलग-अलग machines के बीच implementation details जाने बिना call करने का बहुत अच्छा तरीका पहले से RPC है। MCP उसके ऊपर opinionated middleware और security issues ही जोड़ता हुआ लगता है
  • जो बात मुझे समझ नहीं आती, वह यह है कि अब तक मैंने जितने MCP देखे हैं वे सभी command-based हैं, HTTP interface क्यों नहीं इस्तेमाल करते। अगर यह HTTP होता, तो एक ही server चलाकर पूरी organization उसे share कर सकती, और हर व्यक्ति को अलग toolchain setup करने की ज़रूरत नहीं पड़ती
  • backend के fixed flow लागू करने वाले पुराने तरीकों के विपरीत, MCP का लाभ यह है कि orchestration खुद LLM सीधे कर सकता है। उदाहरण के लिए web search करते समय वह query को फिर से लिखकर तब तक retry कर सकता है जब तक वांछित जानकारी न मिल जाए। CLI में किसी विशेष समस्या को हल करते समय भी यह कई tools को सही क्रम में इस्तेमाल कर सकता है। यह वह organization है जो fixed flow में संभव नहीं
  • MCP जिस हिस्से का समाधान करता है, वह यह है कि LLM-केंद्रित agent में tools जैसी कई capabilities को standardized protocol से जोड़ा जाए
  • इस बात से मैं भी काफ़ी हद तक सहमत हूँ। इसे सच में इस्तेमाल करने पर यह बहुत धीमा लगता है। मैं तो 2 साल पहले LLM client बनाने के लिए नौकरी छोड़ चुका हूँ, फिर भी अभी तक Google calendar integration नहीं कर पाया। कम से कम user के नज़रिए से MCP ऐसे अस्थायी gaps भरने के काम आता है। मुझे iPhone home screen की वह बात याद आती है जहाँ ऊपर की 3 पंक्तियाँ लगभग एक जैसी होती थीं, लेकिन आख़िरी पंक्ति हर किसी की अलग होती थी। लगता है आगे भी IT departments और development teams अपने-अपने काम के हिसाब से अलग MCP servers बनाते रहेंगे