MCP का नया रोडमैप: उस पर निर्माण करने वालों के लिए इसका क्या मतलब है

22 अगस्त को Model Context Protocol के रखरखावकर्ताओं ने अगले छह से बारह महीनों के प्रोटोकॉल कार्य को समेटता अद्यतन रोडमैप प्रकाशित किया। इसमें पाँच प्राथमिकता क्षेत्र हैं, हर क्षेत्र के जिम्मेदार Core Maintainers हैं, और एक चुपचाप महत्वपूर्ण नियम है कि कौन-से प्रस्ताव पहले समीक्षा पाएँगे। पिछला रोडमैप मार्च का था; उसने चार चीजों का वादा किया था और उनमें से ज्यादातर जुलाई विनिर्देश रिलीज़ में जारी कर दीं, इसलिए इस रोडमैप ने गंभीरता से लिए जाने का हक कमाया है। मेरा आकलन: MCP जानबूझकर सामान्य वेब आधारभूत संरचना बन रहा है, और निर्माणकर्ताओं के लिए उपयोगी सवाल यह है कि आपके तकनीकी ढाँचे का कौन-सा हिस्सा पहले बदलेगा।

मुख्य बातें - रोडमैप पाँच प्राथमिकताएँ तय करता है: एजेंटिक संदेश-व्यवस्था, HTTP-मूल ट्रांसपोर्ट, एजेंट पहचान और उद्यम सुरक्षा, अधिक साफ टूल आदिम संरचनाएँ, तथा विनिर्देश से जनित SDK। - इन क्षेत्रों के भीतर आने वाले विनिर्देश प्रस्ताव, SEPs, त्वरित समीक्षा पाते हैं। बाहर हों तो लंबी कतार और कड़ी कसौटी की अपेक्षा करें। - मार्च रोडमैप के वादे बड़े हिस्से में 2026-07-28 विनिर्देश में आ गए: स्टेटलेस कोर, कैश किए जा सकने वाले सूची परिणाम, और Multi Round-Trip Requests। - कोड को छूने की सबसे ज्यादा संभावना वाले दो बदलाव हैं एजेंट पहचान, DPoP और कार्यभार पहचान संघीकरण; तथा बड़े कैटलॉग के लिए क्रमिक टूल खोज। - रोडमैप को दिशा मानें, प्रतिबद्धता नहीं। रखरखावकर्ता खुद यही कहते हैं। इसके इंतजार में निर्माण न रोकें।

MCP रखरखावकर्ताओं ने वास्तव में क्या घोषित किया?

पहले तथ्य। 22 अगस्त 2026 दिनांकित अद्यतन MCP रोडमैप अगले विनिर्देश चक्र को पाँच प्राथमिकता क्षेत्रों में व्यवस्थित करता है, हर एक के साथ नामित Core Maintainers और एक या अधिक Working Groups:

1. एजेंटिक संदेश आदिम संरचनाएँ: सर्वर-आरंभित घटनाएँ, चैनल, सदस्यताएँ और वेबहुक, ताकि क्लाइंट पोलिंग बंद कर सकें; साथ में संयोजन समीक्षा, ताकि Tasks, ट्रिगर और प्रगति सूचनाएँ एक जीवनचक्र साझा करें।

2. HTTP-मूल ट्रांसपोर्ट एकीकरण और सुदृढ़ीकरण: Streamable HTTP को एकल बाइंडिंग बनाना, अंततः स्थानीय सर्वरों के लिए stdio पर वही भाषा बोलना, और कैशिंग को ETags तक विस्तारित करना।

3. एजेंट पहचान और उद्यम-तैयार सुरक्षा: DPoP, यानी प्रदर्शन द्वारा स्वामित्व का प्रमाण, को अंतिम रूप देना और मौजूदा IETF मानकों पर एजेंट पहचान तथा प्रत्यायोजन के लिए स्पष्ट मार्ग परिभाषित करना।

4. बेहतर आदिम संरचनाएँ: tools/call की परिणाम संरचना का पुनःडिज़ाइन, और नया क्रमिक खोज प्रयास, ताकि क्लाइंट सर्वर कैटलॉग को जरूरत के अनुसार सीखें।

5. बेहतर SDK डेवलपर अनुभव: एक्सटेंशन अनुबंध, और ऐसा प्रयोग जिसमें Tier 1 SDK तथा त्वरित आरंभ उदाहरण सीधे विनिर्देश से उत्पन्न हों।

इन पाँच क्षेत्रों के साथ एक नियम है जो बाकी सबको आकार देगा: प्राथमिकता क्षेत्रों के भीतर SEPs को त्वरित समीक्षा मिलती है, और Working Group समर्थन वाले प्रस्ताव सबसे तेज आगे बढ़ते हैं। रखरखावकर्ताओं के अपने शब्दों में, "रखरखावकर्ताओं का समीक्षा समय सीमित है। हम उसे पहले यहीं खर्च करते हैं।" रोडमैप साफ कहता है कि ये पक्की प्रतिबद्धताएँ नहीं, मौजूदा सोच है; इसलिए अलग-अलग मदें खिसक सकती हैं या अलग रूप में आ सकती हैं।

22 अगस्त 2026 को प्रकाशित MCP रोडमैप अगले छह से बारह महीनों के लिए पाँच प्राथमिकता क्षेत्र तय करता है: एजेंटिक संदेश-व्यवस्था, HTTP-मूल ट्रांसपोर्ट, एजेंट पहचान, बेहतर टूल आदिम संरचनाएँ और विनिर्देश-जनित SDK। इन क्षेत्रों के प्रस्ताव त्वरित समीक्षा पाते हैं; बाहर वाले लंबी कतार में जाते हैं।

यह रोडमैप मायने क्यों रखता है?

क्योंकि पिछला पूरा हुआ। नए मुक्त-स्रोत प्रोजेक्टों के रोडमैप अक्सर आकांक्षी दस्तावेज़ होते हैं जो चुपचाप पुराने हो जाते हैं। इस वाले का पूरा करने का रिकॉर्ड है। मार्च 2026 रोडमैप ने चार प्राथमिकताएँ तय कीं, और उनमें से बड़ा हिस्सा पाँच महीने बाद 2026-07-28 विनिर्देश रिलीज़ में जारी हुआ:

अपनाव रोडमैप को वजन देता है। जुलाई 2026 तक प्रोटोकॉल के Tier 1 SDK करीब प्रति माह आधा अरब डाउनलोड देख रहे थे, और TypeScript तथा Python SDK दोनों कुल एक अरब डाउनलोड पार कर चुके थे। इस पैमाने का प्रोटोकॉल दिशा बताए तो नक्शा पढ़ना चाहिए।

स्रोत: MCP रोडमैप, मार्च और अगस्त 2026, तथा 2026-07-28 विनिर्देश घोषणा।

मार्च 2026 MCP रोडमैप ने ट्रांसपोर्ट विकास, एजेंट संचार, शासन परिपक्वता और उद्यम तैयारी का वादा किया। पाँच महीने बाद 2026-07-28 विनिर्देश ने स्टेटलेस प्रोटोकॉल कोर, Tasks एक्सटेंशन, Multi Round-Trip Requests और बारह महीने की न्यूनतम अवधि वाली औपचारिक अवमूल्यन नीति जारी की।

यदि आप MCP पर निर्माण कर रहे हैं तो इसका क्या मतलब है?

निर्माणकर्ताओं के लिए तत्काल प्रभाव असमान है। पाँच में से दो क्षेत्र एक साल के भीतर आपके कोड को बदलेंगे। बाकी तीन आपके आसपास प्रोटोकॉल का शासन और रखरखाव बदलते हैं। हर क्षेत्र का व्यावहारिक अर्थ यह है।

एजेंटिक संदेश-व्यवस्था: पोलिंग का अंत

वास्तविक एजेंट कार्य अनुरोध-प्रतिक्रिया में नहीं समाता। कार्य कई मिनट चलते हैं; सर्वर उस समय पूरा कर सकता है जब क्लाइंट देख नहीं रहा, और आज क्लाइंट का जवाब पोलिंग है, जो महँगी और भद्दी है। रोडमैप सर्वर-आरंभित घटनाओं को प्राथमिकता देता है: चैनल, सदस्यताएँ और वेबहुक, ताकि सर्वर क्लाइंट को बता सके कि काम पूरा है। संयोजन समीक्षा उतनी ही महत्वपूर्ण है। Tasks, subscriptions/listen और प्रगति सूचनाएँ अभी "सर्वर का काम अभी पूरा नहीं हुआ" के तीन अलग उत्तर बनने के जोखिम में हैं, और रखरखावकर्ता चाहते हैं कि वे जीवनचक्र, रद्दीकरण मॉडल और त्रुटि सतह साझा करें। यदि आप लंबे समय चलने वाले टूल बनाते हैं, Discord पर इसी क्षेत्र पर नजर रखें।

एक ट्रांसपोर्ट, हर जगह वही भाषा

2026-07-28 रिलीज़ ने दूरस्थ MCP सर्वर को सामान्य HTTP कार्यभार बना दिया। रोडमैप अब दूरस्थ-स्थानीय विभाजन मिटाना चाहता है: Streamable HTTP को एकल बाइंडिंग बनाना, स्थानीय सर्वरों में stdin और stdout पर वही भाषा बोलना, HTTP/2 से मल्टीप्लेक्सिंग करना, साथ में उपप्रक्रिया सुरक्षा और जीवनचक्र गारंटियाँ रखना। आज हर HTTP-मूल सुविधा को दूसरा stdio-विशिष्ट डिज़ाइन चाहिए या वह स्थानीय रूप में काम नहीं करती, और SDK दो ट्रांसपोर्ट पाइपलाइन बनाए रखते हैं। एक ट्रांसपोर्ट मॉडल का अर्थ इस दोहराव में कमी है। कैशिंग भी विस्तारित होती है: जुलाई में आए ttlMs और cacheScope संकेतों के ऊपर ETags, ताकि टूल कॉल परिणाम दोबारा प्राप्त करने की जगह संस्करणित किए जा सकें।

एजेंट पहचान: जो सबसे पहले असर डालेगी

MCP प्राधिकरण सहमति के समय ब्राउज़र के साथ मानव को मानकर चलता है। कॉल करने वाला तेजी से एजेंट बन रहा है: अपनी पहचान वाला क्लाउड कार्यभार, अनुपस्थित उपयोगकर्ता की ओर से कार्य करता हुआ, या उप-एजेंट उत्पन्न करता हुआ जिन्हें मूल एजेंट से सीमित अधिकार मिलने चाहिए। जुलाई रिलीज़ घोषणा में उद्धृत Honeycomb पहले ही मासिक इंटरैक्टिव क्वेरी का करीब 20% एजेंटों से आने की बात करता है। इस बीच बहुत से प्रोडक्शन MCP सर्वर चिपकाई गई API कुंजियों और लंबे समय चलने वाले रिफ़्रेश टोकन पर निर्भर हैं, ठीक वही प्रथा जिसे यह कार्य समाप्त करना चाहता है। योजना DPoP को अंतिम रूप देकर अपनाने की है, साथ में Workload Identity Federation, SEP-1933, Enterprise-Managed Authorization के पीछे ID-JAG अनुदान और RFC 8693 टोकन विनिमय के जरिए मानक प्रत्यायोजन मार्ग, IETF OAuth और WIMSE Working Groups के साथ समन्वय में।

MCP का प्राधिकरण मॉडल ब्राउज़र में मानव मंजूरी के लिए बना था, लेकिन कॉल करने वाले अब एजेंट हैं। रोडमैप DPoP और Workload Identity Federation तथा RFC 8693 टोकन विनिमय पर आधारित मानक प्रत्यायोजन मार्ग को प्राथमिकता देता है, ताकि सर्वर चिपकाई गई API कुंजियों या लंबे समय चलने वाले टोकन के बिना एजेंट पहचानों को पहचान सकें।

टूल परिणाम और क्रमिक खोज

यहाँ दो उलझनें दूर होती हैं। पहली, tools/call का एक साथ content और structuredContent लौटाना, जिससे अलग-अलग कार्यान्वयन बने क्योंकि सर्वर लेखक नहीं जान सकता कि क्लाइंट मॉडल को कौन-सा रूप दिखाया जाएगा। अनुबंध का पुनःडिज़ाइन होगा। दूसरी, पैमाना: सौ टूल वाले सर्वर से जुड़ें तो उपयोगकर्ता का पहला सवाल पूछने से पहले मॉडल पूरी सतह की टोकन लागत देता है, और सूची बढ़ते ही टूल चयन खराब होता है। टोकन बिल सैद्धांतिक नहीं। Cloudflare के फ़रवरी 2026 परीक्षण में 2,500-एंडपॉइंट API को MCP टूल परिभाषाओं के रूप में उजागर करने में करीब 1.17 मिलियन टोकन लगे, कोड-कॉलिंग के करीब 1,000 की तुलना में। प्रस्तावित उत्तर क्रमिक खोज है: छोटा प्रवेश-बिंदु जो बातचीत सीमित होने पर कैटलॉग का अधिक हिस्सा दिखाए, ऊपर वाली कैशिंग से जुड़ा हुआ। मैंने कब साधारण API बेहतर विकल्प है पर लिखा है; क्रमिक खोज उसी अंतर को घटाने की MCP की कोशिश है।

विनिर्देश से जनित SDK

सबसे शांत दिखने वाला बिंदु शायद सबसे संकेतपूर्ण है। आज SDK, संदर्भ सर्वर और त्वरित आरंभ उदाहरण हाथ से बनाए रखे जाते हैं। रोडमैप का प्रयोग है: विनिर्देश से उम्मीदवार Tier 1 SDK और साथ के त्वरित आरंभ उदाहरण उत्पन्न करें, अनुरूपता परीक्षण-संग्रह के विरुद्ध दोनों को सत्यापित करें, फिर निष्कर्ष प्रकाशित करें, जिसमें यह भी हो कि कौन-सी परतें नियतात्मक कोड जनन होनी चाहिए और कौन-सी मॉडल-सहायित। यह काम किया तो विनिर्देश की स्पष्टता संबंधी बग जनन विफलताओं से सामने आएँगे, और SDK उस दस्तावेज़ से भटकना बंद करेंगे जिसे उन्हें लागू करना है।

अभी क्या करें?

तात्कालिकता के क्रम में चार चीजें:

1. इस सप्ताह: अवमूल्यित सतहों पर नया कार्य बनाना बंद करें। Roots, Sampling, Logging और पुराना HTTP+SSE ट्रांसपोर्ट 2026-07-28 विनिर्देश में बारह महीने की न्यूनतम अवधि के साथ अवमूल्यित किए गए। वे अभी काम करते हैं। नए कार्यान्वयन उन्हें न अपनाएँ।

2. इस महीने: सर्वर को कैश-अनुकूल बनाइए। सूची परिणाम पहले से ttlMs और cacheScope रखते हैं, और ETags आ रहे हैं। आज उचित कैश संकेत जारी करने वाला सर्वर माइग्रेशन में एक कदम आगे है।

3. इस तिमाही: ऑडिट करें कि एजेंट कैसे प्रमाणित होते हैं। आपके किसी MCP सर्वर में बिना निगरानी वाला कॉलर चिपकाई गई API कुंजी या लंबे समय चलने वाले रिफ़्रेश टोकन के कारण भरोसेमंद है तो ठीक इसी पैटर्न को Agent Identity Working Group बदलने के लिए बना है। अपनी प्रत्यायोजन योजना गढ़ने की जगह समूह पर नजर रखें। शासन का पहलू AI एजेंट शासन से जुड़ता है।

4. यदि प्रोटोकॉल को आकार देना है: SEP प्राथमिकता क्षेत्र के भीतर लिखें। पहले संबंधित Working Group के साथ मुद्दा उठाएँ और उसका समर्थन लें। रोडमैप-संगत प्रस्ताव त्वरित समीक्षा पाते हैं; बाकी कतार में जाते हैं।

दो चीजें न करें। अगले विनिर्देश के इंतजार में निर्माण न रोकें: मौजूदा संस्करण स्थिर आधार है, और अवमूल्यन नीति अब तोड़ने वाले बदलाव पर बारह महीने की चेतावनी की गारंटी देती है। और रोडमैप को वादा न मानें। पहला खंड खुद कहता है कि प्राथमिकताएँ बदल सकती हैं और सूचीबाह्य कार्य भी जारी हो सकता है। यदि आप यात्रा की शुरुआत में हैं, तो पहला MCP सर्वर बनाने की व्यावहारिक मार्गदर्शिका और जोड़ने लायक सर्वरों की चयनित सूची व्यावहारिक शुरुआती बिंदु हैं।

2026-07-28 MCP विनिर्देश ने Roots, Sampling, Logging और पुराने HTTP+SSE ट्रांसपोर्ट को बारह महीने की न्यूनतम अवधि के साथ अवमूल्यित किया। रिलीज़ घोषणा पुष्टि करती है कि उस अवधि में वे काम करते रहेंगे, लेकिन नए कार्यान्वयन उन्हें न अपनाएँ।

बड़ी तस्वीर

एक कदम पीछे जाएँ तो पैटर्न साफ है: सार्वजनिक रूप से परिपक्व होता प्रोटोकॉल। MCP को दिसंबर 2025 में OpenAI और Block को सह-संस्थापक रखते हुए Linux Foundation के तहत विक्रेता-तटस्थ Agentic AI Foundation को दान किया गया। तब से Contributor Ladder, फीचर जीवनचक्र, अवमूल्यन नीति, और अब रखरखावकर्ताओं का ध्यान कहाँ जाता है उसका सार्वजनिक वक्तव्य जुड़ चुका है। एक्सटेंशन ढाँचा भी शांत लेकिन वास्तविक काम करता है: SEP-2133 किसी Working Group को औपचारिक प्रस्ताव से पहले experimental-ext- रिपॉजिटरी में प्रयोग करने देता है, ताकि कोर अस्थिर किए बिना विचार जाँचे जा सकें।

अगली दो तिमाहियों में मैं देखूँगा कि stdio पर HTTP आता है या नहीं। स्थानीय और दूरस्थ सर्वर सच में एक ट्रांसपोर्ट पर एकरूप हों तो "MCP सर्वर" विशेष किस्म का सॉफ़्टवेयर रहना बंद करके मानक रूप वाली वेब सेवा बन जाता है। वही बिंदु है जहाँ प्रोटोकॉल आंतरिक पाइपलाइन में गायब हो जाता है, जैसा अच्छी आधारभूत संरचना को होना चाहिए।

अक्सर पूछे जाने वाले सवाल

क्या MCP अब निर्माण करने लायक स्थिर है?

हाँ, माइग्रेशन अनुशासन के साथ। 2026-07-28 विनिर्देश ने बारह महीने की न्यूनतम अवधि वाली औपचारिक अवमूल्यन नीति लागू की, और SDK तोड़ने वाले बदलावों के लिए माइग्रेशन नोट जारी करते हैं। प्रोटोकॉल बदलता रहेगा, लेकिन अब जिस चीज पर आप निर्भर हैं उसके जाने से एक साल पहले बताता है।

MCP सत्रों का क्या हुआ?

2026-07-28 विनिर्देश में सेवानिवृत्त हो गए। initialize हैंडशेक और Mcp-Session-Id हेडर हटा दिए गए, SEP-2575, SEP-2567। हर अनुरोध अब स्व-वर्णित है, _meta में प्रोटोकॉल संस्करण और क्लाइंट क्षमताएँ रखता है, और शुरुआत में क्षमताएँ जानने वाले क्लाइंटों के लिए वैकल्पिक server/discover कॉल हैंडशेक की जगह लेता है। कोई भी अनुरोध राउंड-रॉबिन लोड बैलेंसर के पीछे किसी भी इंस्टेंस पर जा सकता है।

निर्माण करने से पहले अगले विनिर्देश का इंतजार करूँ?

नहीं। रोडमैप अगले छह से बारह महीनों की दिशा बताता है, प्रतिबद्ध सुविधाएँ नहीं, और रखरखावकर्ता स्पष्ट रूप से यही कहते हैं। मौजूदा विनिर्देश स्थिर, कैशयोग्य और स्टेटलेस है। उसी पर निर्माण करें, अवमूल्यित सतहों से दूर रहें, और उन दो Working Groups पर नजर रखें जिनका निष्कर्ष आपको सबसे ज्यादा छुएगा।