MCP Apps बनाम A2UI: कौन-सा Agent UI स्टैंडर्ड इस्तेमाल करें?

आपका एजेंट सही जवाब दे देता है, फिर भी वह टेक्स्ट की एक लंबी दीवार की तरह दिखता है। दो ओपन स्टैंडर्ड अब इस समस्या को हल करते हैं, और बाकी लगभग हर बात पर वे आपस में असहमत हैं। MCP Apps एक छोटा वेब ऐप भेजता है जो सैंडबॉक्स्ड iframe के भीतर चलता है। A2UI एक JSON ब्लूप्रिंट भेजता है और होस्ट को उसे अपने नेटिव कंपोनेंट से बनाने देता है। एक में सर्वर पिक्सल पर नियंत्रण रखता है। दूसरे में वह नियंत्रण क्लाइंट के पास चला जाता है।

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

दो स्टैंडर्ड, दो दर्शन

अंतर को एक वाक्य में कहना आसान है। MCP Apps UI को एक रिसोर्स मानता है जिसे सर्वर सौंपता है। A2UI UI को डेटा मानता है जिसे एजेंट वर्णित करता है। इस लेख की बाकी हर बात इसी एक अंतर से निकलती है।

MCP Apps असल में क्या करता है

MCP Apps की शुरुआत नवंबर 2025 में प्रस्ताव SEP-1865 के रूप में हुई। Anthropic, OpenAI और कम्युनिटी प्रोजेक्ट MCP-UI के मेंटेनर्स ने इसे मिलकर लिखा, और यह MCP-UI और OpenAI के Apps SDK पर आधारित है। जनवरी 2026 में यह Model Context Protocol का पहला आधिकारिक एक्सटेंशन बन गया, और इसका अपना स्पेक 2026-01-26 की तारीख के साथ ext-apps रिपॉज़िटरी में है।

यह तंत्र MCP के दो सामान्य प्रिमिटिव्स, यानी एक टूल और एक रिसोर्स, का उपयोग करता है:

1. एक टूल घोषणा करता है _meta.ui.resourceUri, जो एक ui:// रिसोर्स की ओर इशारा करता है।
2. सर्वर उस रिसोर्स के लिए MIME टाइप text/html;profile=mcp-app के साथ HTML परोसता है।
3. होस्ट उस पेज को बातचीत के भीतर एक सैंडबॉक्स्ड iframe में लोड करता है।
4. ऐप और होस्ट postMessage के ज़रिए बात करते हैं, जिसमें ui/ मेथड्स वाला JSON-RPC डायलेक्ट इस्तेमाल होता है, जैसे ui/initialize।

चूँकि पेलोड सादा वेब कोड है, फ़्रेमवर्क आप चुनते हैं। ext-apps रिपॉज़िटरी में React, Vue, Svelte, Preact, Solid और vanilla JavaScript के लिए स्टार्टर टेम्प्लेट हैं। @modelcontextprotocol/ext-apps से मिलने वाली App क्लास एक सुविधा-रैपर है, ज़रूरी नहीं। अगर आप कम डिपेंडेंसी चाहते हैं, तो आप postMessage प्रोटोकॉल खुद लागू कर सकते हैं।

A2UI असल में क्या करता है

A2UI, यानी Agent-to-User Interface, Google का ओपन स्टैंडर्ड है, जो दिसंबर 2025 में Apache 2.0 लाइसेंस के तहत जारी हुआ। एजेंट HTML नहीं भेजता। वह डिक्लेरेटिव JSON स्ट्रीम करता है, जो कंपोनेंट और उनके डेटा के नाम बताता है। क्लाइंट भरोसेमंद कंपोनेंट्स की एक कैटलॉग रखता है, हर मैसेज को उस कैटलॉग के आधार पर वैलिडेट करता है, और नतीजे को एक नेटिव UI ट्री पर मैप करता है।

Google की अपनी टैगलाइन इसे समेट देती है: डेटा की तरह सुरक्षित, कोड की तरह अभिव्यंजक। स्पेक v0.9.1 पर है, और अक्टूबर 2026 तक v1.0 कैंडिडेट स्टेज पर है। Angular, Flutter और Lit के लिए रेंडरर मौजूद हैं, और Google Opal, Gemini Enterprise और Flutter GenUI SDK में A2UI पहले से इस्तेमाल करता है। पेलोड MIME टाइप application/a2ui+json के तहत जाते हैं।

💡 मेंटल मॉडल: MCP Apps का मतलब है "एक छोटी वेबसाइट भेजना।" A2UI का मतलब है "एक ब्लूप्रिंट भेजना और होस्ट को उसे मंज़ूर किए गए हिस्सों से बनाने देना।"

हर स्टैंडर्ड UI कैसे रेंडर करता है

iframe वाला रास्ता

MCP Apps में सर्वर तय करता है कि चीज़ें कैसी दिखेंगी। होस्ट सिर्फ़ फ़्रेम, सैंडबॉक्स और मैसेज ब्रिज देता है। इससे आपको पूरा वेब प्लेटफ़ॉर्म मिलता है: D3 चार्ट, WebGL सीन, PDF व्यूअर, मैप, CesiumJS ग्लोब या Three.js सीन। ये ext-apps रिपॉज़िटरी के असली उदाहरण हैं, इनके साथ एक बजट एलोकेटर, कोहॉर्ट हीटमैप और सिस्टम मॉनिटर भी हैं।

इसकी कीमत है विज़ुअल ड्रिफ़्ट। iframe होस्ट का डिज़ाइन सिस्टम अपने आप नहीं अपनाता, इसलिए आपका ऐप चैट के भीतर एक बाहरी चीज़ जैसा दिख सकता है। उस पर एक ब्राउज़र पेज का बोझ भी होता है: उसकी अपनी स्क्रिप्ट्स, अपनी मेमोरी और अपना लोड टाइम।

कैटलॉग वाला रास्ता

A2UI में क्लाइंट तय करता है कि चीज़ें कैसी दिखेंगी। एजेंट कहता है "एक कार्ड जिसमें शीर्षक, एक चार्ट और दो बटन हों," और क्लाइंट अपना कार्ड, अपना चार्ट और अपने बटन बनाता है। थीमिंग होस्ट से आती है, इसलिए नतीजा बिना webview के वेब, मोबाइल या डेस्कटॉप पर आसपास के ऐप से मेल खाता है।

यह फ़ॉर्मेट भाषा मॉडलों के लिए भी अनुकूल है। यह छोटा, संरचित है और स्ट्रीमिंग के लिए बना है, इसलिए मॉडल UI को एक-एक कदम करके उत्सर्जित कर सकता है, जबकि यूज़र उसे बनते हुए देखता है। सीमा कैटलॉग की है: अगर क्लाइंट के पास वह कंपोनेंट नहीं है जो आप चाहते हैं, तो आप पेलोड के भीतर उसे गढ़ नहीं सकते।

तुलना एक नज़र में यह रही:

सिक्योरिटी: सैंडबॉक्स बनाम एलाउलिस्ट

दोनों डिज़ाइनों के पीछे बहुत अलग थ्रेट मॉडल हैं। एक कोड को अलग रखता है। दूसरा कोड को बिल्कुल स्वीकार ही नहीं करता।

MCP Apps जोखिम को कैसे सीमित करता है

ऐप एक सैंडबॉक्स्ड iframe में चलता है, इसलिए वह पैरेंट पेज के DOM तक नहीं पहुँच सकता, होस्ट की कुकीज़ या लोकल स्टोरेज नहीं पढ़ सकता, और पैरेंट पेज को रीडायरेक्ट नहीं कर सकता। सारा ट्रैफ़िक postMessage बाउंड्री से होकर गुज़रता है, और होस्ट तय करता है कि क्या आगे जाए। बचाव की कई परतें हैं:

• पहले से घोषित टेम्पलेट। क्योंकि टूल्स ui:// रिसोर्स का हवाला पहले ही दे देते हैं, इसलिए होस्ट किसी भी टूल के चलने से पहले टेम्पलेट को प्रीफ़ेच करके उसकी समीक्षा कर सकता है।
• Content Security Policy। _meta.ui.csp फ़ील्ड उन बाहरी ऑरिजिन की सूची देती है जिनसे कोई ऐप लोड कर सकता है।
• परमिशन। ऐप कैमरा या माइक्रोफ़ोन जैसी क्षमताओं का अनुरोध _meta.ui.permissions के ज़रिए करता है।
• ऑडिट किए जा सकने वाले मैसेज। सब कुछ JSON-RPC में होता है, इसलिए होस्ट उसे लॉग कर सकता है।
• वैकल्पिक सहमति। UI से शुरू किया गया टूल कॉल आगे बढ़ने से पहले होस्ट यूज़र से पूछ सकते हैं।

A2UI जोखिम को कैसे सीमित करता है

A2UI सैंडबॉक्स का सवाल ही नहीं उठाता, क्योंकि वह कभी कुछ execute नहीं करता। रेंडरर केवल वैलिडेट किया गया JSON स्वीकार करता है, और केवल वे कंपोनेंट जो कैटलॉग में मौजूद हों। Google इसे capability-based security कहता है: क्लाइंट केवल भरोसेमंद कंपोनेंट रेंडर करता है और कुछ नहीं।

इससे A2UI अपने आप सुरक्षित नहीं हो जाता। कैटलॉग का एक बटन फिर भी कोई एक्शन ट्रिगर कर सकता है, इसलिए क्लाइंट को हर घोषित एक्शन को अधिकृत करना होगा और हर पेलोड को वैलिडेट करना होगा। एलाउलिस्ट UI की रक्षा करती है। वह आपके बिज़नेस लॉजिक की रक्षा नहीं करती।

ऐसे जोखिम जिन्हें कोई भी स्टैंडर्ड नहीं हटाता

दोनों स्टैंडर्ड कंटेंट को एजेंट से स्क्रीन तक ले जाते हैं, इसलिए दोनों एजेंट की कमज़ोरियाँ भी विरासत में लेते हैं। एक मॉडल जो किसी दुर्भावनापूर्ण वेब पेज को पढ़ता है, उसे यह समझाया जा सकता है कि वह एक असली जैसा लगने वाला नकली फ़ॉर्म रेंडर करे, चाहे वह फ़ॉर्म iframe में हो या कैटलॉग कार्ड पर। किसी भी जनरेटेड UI से ट्रिगर हुई टूल कॉल को अविश्वसनीय इनपुट मानें: सर्वर पर परमिशन जाँचें, टोकन का दायरा सीमित रखें, और पैसे खर्च करने या डेटा बदलने वाली किसी भी चीज़ के लिए पुष्टि माँगें।

आज कौन क्या सपोर्ट करता है

MCP Apps होस्ट

अभी होस्ट सपोर्ट MCP Apps के पक्ष में सबसे मज़बूत तर्क है। आधिकारिक दस्तावेज़ Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam और Archestra.AI को सूचीबद्ध करते हैं, और ChatGPT भी इन्हें रेंडर करता है। MCP प्रोजेक्ट एक क्लाइंट मैट्रिक्स रखता है, और यह मायने रखता है: ऐप UI का सपोर्ट बेसिक MCP टूल्स के सपोर्ट से कम व्यापक है। जो क्लाइंट आपके टूल्स को कॉल करता है, वह फिर भी आपके ui:// रिसोर्स को अनदेखा कर सकता है।

अगर आप खुद होस्ट बनाते हैं, तो आपके पास दो रास्ते हैं। @mcp-ui/client पैकेज React कंपोनेंट देता है, और SDK का App Bridge मॉड्यूल सैंडबॉक्स्ड रेंडरिंग, मैसेज पासिंग, टूल कॉल प्रॉक्सिंग और पॉलिसी लागू करना संभालता है।

A2UI रेंडरर और ट्रांसपोर्ट

A2UI का सपोर्ट इस बात पर निर्भर करता है कि आपका क्लाइंट कौन-सा रेंडरर शिप करता है, न कि चैट प्रोडक्ट्स की किसी सूची पर। आप Angular, Flutter या Lit चुनते हैं, अपना कैटलॉग तय करते हैं, और एक ट्रांसपोर्ट जोड़ते हैं। A2A प्रोटोकॉल एजेंटों के बीच A2UI ले जाता है, और CopilotKit प्रोटोकॉल AG-UI दिन-एक कंपैटिबिलिटी का दावा करता है। A2UI MCP पर भी चल सकता है: स्टैटिक स्क्रीन के लिए पेलोड resources/read से आते हैं, और डायनामिक स्क्रीन के लिए tools/call से, a2ui:// URI स्कीम के तहत।

परिदृश्य के अनुसार डिसीज़न टेबल

ब्रांड से नहीं, काम से चुनें। यह टेबल दिखाती है कि टीमें आम तौर पर काम को कैसे बाँटती हैं:

MCP Apps कब चुनें

तब चुनें जब आपके पास पहले से एक वेब प्रोडक्ट है और आप उसे चैट के भीतर लाना चाहते हैं। आपका सर्वर लॉजिक रखता है, आप हर पिक्सल पर नियंत्रण रखते हैं, और आप पहले से मौजूद React कंपोनेंट दोबारा इस्तेमाल कर सकते हैं। प्रोटोटाइप की रफ़्तार मायने रखे तो भी इसे चुनें: शिप करने के लिए एक HTML फ़ाइल काफ़ी है।

A2UI कब चुनें

तब चुनें जब स्क्रीन पहले से पता न हो। एक एजेंट जो "पिछली तिमाही दिखाओ" के जवाब में आज एक टेबल और कल एक चार्ट देता है, उसके लिए हर मामले के लिए हाथ से बनाए गए पेज की तुलना में एक कैटलॉग कहीं ज़्यादा उपयुक्त है। इसे तब भी चुनें जब आपका क्लाइंट नेटिव हो, या जब आपकी सिक्योरिटी टीम चैट में थर्ड-पार्टी स्क्रिप्ट्स को मंज़ूरी न दे।

वे गलतियाँ जो हफ़्तों का नुकसान करती हैं

• बहुत छोटा कैटलॉग बनाना। तब एजेंट सादे टेक्स्ट पर लौट आते हैं और यूज़र को कोई फ़ायदा नहीं दिखता।
• iframe को अपने डेटा की सीमा मानना। सैंडबॉक्स होस्ट की रक्षा करता है, आपके टोकन की नहीं।
• टेक्स्ट फ़ॉलबैक छोड़ना। MCP Apps वैकल्पिक हैं, इसलिए सर्वरों को उन होस्ट्स के लिए केवल-टेक्स्ट रास्ता रखना चाहिए जो UI रेंडर नहीं करते।
• v0.9.1 पर हार्ड कोडिंग। A2UI अभी भी v1.0 की ओर बढ़ रहा है, इसलिए अपने रेंडरर को एक एडैप्टर के पीछे अलग रखें।

दोनों को साथ इस्तेमाल करना

यह चुनाव एक ही विकल्प तक सीमित नहीं है। Google का डेवलपर ब्लॉग, जो 17 जून 2026 को प्रकाशित हुआ, तीन इंटीग्रेशन पैटर्न बताता है, और ये "किसी एक को चुनो" के मायने बदल देते हैं।

तीन कॉम्बिनेशन पैटर्न

1. MCP सर्वरों पर A2UI। MCP सर्वर रिसोर्स या टूल रिज़ल्ट के ज़रिए A2UI पेलोड भेजता है, a2ui:// स्कीम का उपयोग करते हुए। इसमें iframe की ज़रूरत नहीं है।
2. A2UI के भीतर MCP Apps। एक कस्टम A2UI रैपर कंपोनेंट एक MCP ऐप एम्बेड करता है, जिसकी स्टेट इवेंट लूप के ज़रिए सिंक होती है और वापस बैकएंड एजेंट तक भेजी जाती है।
3. MCP Apps के भीतर A2UI। MCP ऐप अपना A2UI रेंडरर साथ बंडल करता है, जो उन होस्ट्स तक जनरेटिव UI पहुँचाता है जो A2UI को नेटिव रूप से नहीं बोलते।

एक समझदार डिफ़ॉल्ट स्टैक

ज़्यादातर टीमों के लिए काम के आधार पर बँटवारा ठीक रहता है। स्थिर, उच्च-जोखिम वाली सतहें, जैसे अप्रूवल, सेटिंग्स और अकाउंट व्यू, MCP Apps में रखें। लचीली, जनरेटेड सतहें, जैसे रिपोर्ट और सारांश, A2UI में रखें। दोनों को एक ही MCP सर्वर से परोसें, ताकि आपके एजेंट का एक ही कनेक्शन रहे। पैटर्न 3 वह विकल्प है जब किसी होस्ट में रेंडरर न हो।

हर तिमाही में बँटवारे की समीक्षा करें। अगर कोई जनरेटेड सतह को ऐसे कस्टम चार्ट चाहिए जिन्हें कैटलॉग नहीं बना सकता, तो वह स्क्रीन A2UI से आगे निकल चुकी है और उसे MCP ऐप में होना चाहिए। अगर कोई MCP ऐप हर नए डेटा आकार के लिए दोबारा बनाया जाता रहता है, तो वह कैटलॉग में जाने का उम्मीदवार है।

PicassoIA पर GPT 5 Structured इस्तेमाल करें

A2UI पेलोड हाथ से लिखना थकाऊ हो जाता है, और जो भाषा मॉडल सख्त JSON लौटाता है, वह एक स्वाभाविक ड्राफ़्टिंग साथी है। PicassoIA पर GPT 5 Structured ठीक इसी काम के लिए बना है: आप एक JSON schema तय करते हैं, और हर जवाब उसके अनुरूप होता है।

1. मॉडल पेज खोलें और model फ़ील्ड में एक टियर चुनें: gpt-5, gpt-5-mini, या gpt-5-nano।
2. अपना कैटलॉग पेस्ट करें instructions में। उन कंपोनेंट्स की सूची बनाएँ जिन्हें आपका क्लाइंट स्वीकार करता है, उनकी प्रॉपर्टीज़ के साथ।
3. स्क्रीन का वर्णन करें prompt में, जैसे "आइटम्स की टेबल और एक कन्फ़र्म बटन वाला ऑर्डर सारांश।"
4. json_schema सेट करें A2UI स्पेक के मैसेज schema पर। simple_schema की जगह json_schema का उपयोग करें, क्योंकि सरल वर्ज़न नेस्टेड ऑब्जेक्ट्स को सपोर्ट नहीं करता।
5. reasoning_effort को minimal पर रखें जल्दी ड्राफ़्ट के लिए। घने लेआउट के लिए इसे बढ़ाएँ और max_output_tokens भी बढ़ाएँ, क्योंकि हाई रीज़निंग बजट खत्म कर सकती है और खाली जवाब लौटा सकती है।
6. रेंडर करने से पहले आउटपुट को स्पेक के विरुद्ध वैलिडेट करें।

💡 मॉडल के आउटपुट को ड्राफ़्ट मानें। आपके रेंडरर का वैलिडेटर अंतिम द्वार है, ठीक वैसे ही जैसा A2UI सिक्योरिटी मॉडल चाहता है।

दूसरे मॉडलों के ड्राफ़्ट की तुलना करना चाहते हैं? Claude Sonnet 5 और Gemini 3.5 Flash भी PicassoIA पर उपलब्ध हैं, तो आप वही कैटलॉग और प्रॉम्प्ट हर एक पर चला सकते हैं और सबसे साफ़ नतीजा रख सकते हैं।

आज अपनी इमेज आज़माएँ

आप जो भी स्टैंडर्ड चुनें, आपके एजेंट की स्क्रीन को तस्वीरें चाहिए: प्रोडक्ट थंबनेल, हीरो बैनर, रिपोर्ट के हेडर फ़ोटो। MCP Apps इमेज को सादे HTML के रूप में रेंडर करते हैं। A2UI उन्हें उस इमेज कंपोनेंट के ज़रिए रेंडर करता है जो आपका कैटलॉग परिभाषित करता है। दोनों ही स्थितियों में, इमेज पहले चाहिए।

PicassoIA जनरेटर्स को एक ही जगह रखता है। Seedream 5 Pro, Flux 2 Pro, Imagen 4 और PicassoIA Image, सभी टेक्स्ट-टू-इमेज कलेक्शन में हैं, ताकि आप एक ही प्रॉम्प्ट कई मॉडलों पर चला सकें और अपने लेआउट में फ़िट होने वाला वर्ज़न रख सकें। PicassoIA अपने जनरेटर्स MCP कनेक्शन के ज़रिए भी उपलब्ध कराता है, इसलिए ऊपर चर्चा किए गए प्रोटोकॉल को बोलने वाला एजेंट सीधे इमेज माँग सकता है।

कलेक्शन खोलें, अपने अगले कार्ड या बैनर के लिए प्रॉम्प्ट लिखें, और कुछ वेरिएंट जनरेट करें। अपने एजेंट की एक स्क्रीन चुनें, उसे एक असली इमेज दें, और देखें कि विज़ुअल पक्ष लॉजिक से कितनी जल्दी आगे आ जाता है।