MCP Gateway AWS बनाम Azure: विकल्प और सेटअप की तुलना

आपका एजेंट तीन टूल्स के साथ ठीक चलता है। फिर टीम एक बिलिंग API, एक टिकटिंग सिस्टम, एक सर्च इंडेक्स और कुछ इंटरनल सर्विसेज़ जोड़ती है, और हर MCP क्लाइंट को अपने अलग URL, अपने अलग क्रेडेंशियल और सुरक्षित रिक्वेस्ट की अपनी अलग समझ संभालनी पड़ती है। एक MCP गेटवे हर टूल के सामने एक नियंत्रित एंडपॉइंट रखकर इस समस्या को हल करता है। मुश्किल हिस्सा यह तय करना है कि वह कहाँ रहेगा। AWS एजेंट्स के लिए बना एक मैनेज्ड गेटवे देता है, Azure एक API मैनेजमेंट प्रोडक्ट को आगे बढ़ाता है जो कई टीमें पहले से चलाती हैं, और जब आपको पूरा नियंत्रण चाहिए तो दोनों क्लाउड आपको खुद का प्रॉक्सी होस्ट करने देते हैं।

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

MCP गेटवे क्या करता है

गेटवे एक रिवर्स प्रॉक्सी है जो Model Context Protocol की भाषा बोलता है। क्लाइंट Streamable HTTP पर tools/list और tools/call जैसे JSON-RPC मैसेज भेजते हैं, और गेटवे तय करता है कि कौन क्या कॉल कर सकता है, हर कॉल को सही बैकएंड तक भेजता है और जो हुआ उसे रिकॉर्ड करता है। आपके AI एजेंट्स को कभी यह जानने की ज़रूरत नहीं पड़ती कि कोई टूल Lambda फ़ंक्शन में है, REST API में है या किसी दूसरे रीजन के कंटेनर में।

टूल्स के लिए एक फ़्रंट डोर

गेटवे के बिना हर MCP क्लाइंट सीधे हर MCP सर्वर की ओर इशारा करता है। दस एजेंट और आठ सर्वर का मतलब है अस्सी कनेक्शन जिन्हें कॉन्फ़िगर, सुरक्षित और मॉनिटर करना पड़ेगा। गेटवे के साथ दस क्लाइंट एक ही एंडपॉइंट से बात करते हैं और गेटवे कॉल्स को पीछे के सर्वरों में बाँट देता है। किसी बैकएंड को बदलना अब क्लाइंट रोलआउट नहीं, बल्कि गेटवे का बदलाव बन जाता है।

गेटवे कहाँ फ़ायदेमंद है

• केंद्रीय ऑथेंटिकेशन: टोकन को हर सर्वर के अंदर नहीं, एक बार वैलिडेट करें।
• रेट लिमिट और कोटा: किसी लूप में फँसे एजेंट को आपके बिलिंग API पर टूट पड़ने से रोकें।
• ऑडिट ट्रेल: एक ही जगह देखें कि किस एजेंट ने किस टूल को कब कॉल किया।
• टूल क्यूरेशन: आपके API में मौजूद सभी 200 ऑपरेशन्स की जगह वे 12 ऑपरेशन्स दिखाएँ जिनकी एजेंट्स को ज़रूरत है।
• मिले-जुले बैकएंड: एक ही tools/list के पीछे Lambda फ़ंक्शन, REST API और रिमोट MCP सर्वर।

💡 टिप: पूछें कि हर टूल को कौन कॉल करता है और कितनी बार। अगर ईमानदार जवाब है "एक डेवलपर, लोकल पर", तो गेटवे अभी जल्दी है। जैसे ही दूसरी टीम या बाहरी ग्राहक आता है, यह ऐच्छिक नहीं रहता।

AWS के विकल्प

AgentCore Gateway की बुनियादी बातें

Amazon Bedrock AgentCore अक्टूबर 2025 में जनरल अवेलेबिलिटी तक पहुँचा, और AgentCore Gateway एजेंट ट्रैफ़िक के लिए उसका एंट्री पॉइंट है। एक गेटवे तीन श्रेणियों में से एक या अधिक टार्गेट रखता है:

• MCP टार्गेट: गेटवे MCP सर्वर की तरह काम करता है और हर MCP टार्गेट को एक वर्चुअल सर्वर में जोड़ देता है, ताकि क्लाइंट्स को एक ही एकीकृत tools/list दिखे।
• HTTP टार्गेट: ट्रैफ़िक सीधे बैकएंड तक जाता है, जैसे कोई दूसरा एजेंट, पाथ-बेस्ड राउटिंग के साथ, बिना एग्रीगेशन या प्रोटोकॉल ट्रांसलेशन के।
• इंफ़रेंस टार्गेट: LLM रिक्वेस्ट एक ही एंडपॉइंट से मॉडल प्रोवाइडर्स तक पहुँचती हैं, और रिक्वेस्ट में model फ़ील्ड तय करता है कि वे कहाँ जाएँगी।

हर गेटवे को एक इनबाउंड ऑथोराइज़र चाहिए। विकल्प हैं JWT के साथ OAuth, AWS Signature Version 4 के साथ IAM, एक "सिर्फ़ ऑथेंटिकेट" मोड जो टोकन वैलिडेट करता है और ऑथराइज़ेशन टार्गेट पर छोड़ता है, और डेवलपमेंट के लिए बिना किसी ऑथराइज़ेशन का विकल्प। प्रोडक्शन में पहले दो में से एक इस्तेमाल होना चाहिए।

जुड़ने वाले टार्गेट

MCP टार्गेट के लिए AWS कई सोर्स टाइप सूचीबद्ध करता है:

• Lambda फ़ंक्शन: गेटवे आपका फ़ंक्शन इनवोक करता है और जवाब को MCP फ़ॉर्मेट में बदलता है।
• API Gateway REST APIs जो आप पहले से चलाते हैं।
• OpenAPI स्पेसिफ़िकेशन: मौजूदा REST API MCP टूल्स के एक सेट में बदल जाता है।
• Smithy मॉडल: AWS सर्विसेज़ और कस्टम APIs के लिए उपयोगी।
• रिमोट MCP सर्वर: गेटवे टूल्स के साथ-साथ प्रॉम्प्ट और रिसोर्स भी आगे पहुँचा सकता है।

OpenAPI और MCP टार्गेट की आउटबाउंड कॉल्स क्रेडेंशियल प्रोवाइडर्स से होकर जाती हैं, जो API क्रेडेंशियल या OAuth सेटिंग्स स्टोर कर सकते हैं, SigV4 से साइन कर सकते हैं, या सार्वजनिक एंडपॉइंट्स के लिए ऑथेंटिकेशन छोड़ सकते हैं। Lambda और Smithy टार्गेट आपके जोड़े गए एक्ज़िक्यूशन रोल का इस्तेमाल करते हैं। स्केल पर दो और चीज़ें मायने रखती हैं: सिमेंटिक टूल सर्च, जो एजेंट को सैकड़ों में से सही टूल ढूँढने में मदद करता है, और MCP टार्गेट के लिए कैपेबिलिटी सिंक्रोनाइज़ेशन।

ECS या EKS पर खुद चलाना

कुछ टीमें मैनेज्ड विकल्प छोड़कर Application Load Balancer के पीछे ECS या EKS पर एक ओपन सोर्स MCP प्रॉक्सी चलाती हैं। स्केलिंग, पैचिंग, टोकन वैलिडेशन और लॉगिंग की ज़िम्मेदारी आपकी होती है, लेकिन बदले में आपको कस्टम राउटिंग, एक ही कोडबेस जिसे किसी भी क्लाउड पर दोबारा इस्तेमाल किया जा सके, और किसी एक वेंडर की फ़ीचर लिस्ट पर निर्भरता नहीं रहती। यह Kubernetes का अनुभव रखने वाली प्लेटफ़ॉर्म टीमों के लिए ठीक है, और बाकी सबके लिए यह महँगी आदत बन जाती है।

Azure के विकल्प

MCP गेटवे के रूप में API Management

Azure API Management (APIM) MCP सर्वर प्रकाशित करने के दो अंतर्निहित तरीके देता है:

1. REST API को MCP सर्वर के रूप में: APIM में मैनेज की गई कोई भी REST API एक्सपोज़ की जा सकती है, और उसके ऑपरेशन्स MCP टूल्स बन जाते हैं।
2. मौजूदा MCP सर्वर: LangChain, LangServe, Azure Logic Apps या Azure Functions से बने सर्वर के सामने APIM लगाएँ।

गवर्नेंस पॉलिसी इंजन के ज़रिए चलती है। पॉलिसीज़ फ़िलहाल किसी MCP सर्वर में टूल्स के रूप में एक्सपोज़ किए गए सभी ऑपरेशन्स पर लागू होती हैं, और Microsoft रेट लिमिटिंग और कोटा, Microsoft Entra ID या किसी दूसरे आइडेंटिटी प्रोवाइडर के साथ JWT वैलिडेशन, IP फ़िल्टरिंग और रिस्पॉन्स कैशिंग सूचीबद्ध करता है। ट्रैफ़िक Azure Monitor और Application Insights में दिखता है, और Azure API Center एक प्राइवेट रजिस्ट्री का काम कर सकता है ताकि टीमें मौजूद सर्वरों को खोज सकें। सब कुछ Bicep, Terraform, Azure CLI या ARM टेम्पलेट्स से कोड के रूप में भी मैनेज किया जा सकता है।

उपलब्धता व्यापक है: क्लासिक Developer, Basic, Standard और Premium टियर, v2 टियर (Basic v2, Standard v2, Premium v2), और आपके अपने इंफ़्रास्ट्रक्चर के लिए self-hosted गेटवे। दो लिमिट मायने रखती हैं। APIM केवल MCP टूल्स सपोर्ट करता है, रिसोर्सेज़ या प्रॉम्प्ट नहीं, और MCP फ़ीचर वर्कस्पेसेज़ में उपलब्ध नहीं हैं।

Microsoft का ओपन सोर्स MCP गेटवे

APIM से अलग, GitHub पर microsoft/mcp-gateway रिपॉज़िटरी Kubernetes पर MCP सर्वरों के लिए एक रिवर्स प्रॉक्सी और मैनेजमेंट लेयर है। इसका डेटा प्लेन सेशन-अवेयर स्टेटफ़ुल राउटिंग इस्तेमाल करता है, यानी एक ही सेशन ID वाली रिक्वेस्ट एक ही सर्वर इंस्टेंस तक पहुँचती हैं, और इसका कंट्रोल प्लेन सर्वर एडैप्टर्स को डिप्लॉय, अपडेट और डिलीट करता है। ऑथराइज़ेशन Entra ID रोल्स पर निर्भर है, और रिपो AKS पर Azure Container Registry और Cosmos DB के साथ PowerShell और Bicep डिप्लॉयमेंट रास्ते देता है।

💡 स्पेक बदलाव: 2026-07-28 MCP स्पेसिफ़िकेशन रिवीज़न ने प्रोटोकॉल सेशन हटा दिए, जिससे initialize हैंडशेक और Mcp-Session-Id हेडर खत्म हो गए। पुराने रिवीज़न वाले सर्वरों या मेमोरी में स्टेट रखने वाले सर्वरों के लिए सेशन एफ़िनिटी अब भी मायने रखती है, लेकिन नए सर्वरों को इसकी ज़रूरत नहीं है।

इसके पीछे लगाए जा सकने वाले बैकएंड

APIM के पीछे मौजूदा सर्वरों के Microsoft के अपने उदाहरण LangChain, LangServe, Logic Apps और Functions हैं। कोई भी MCP-कम्पैटिबल सर्वर जिस तक APIM HTTP पर पहुँच सके, वह उम्मीदवार है, जो गेटवे को पुराने और नए सर्वरों के मिले-जुले इंफ़्रास्ट्रक्चर के लिए एक सुविधाजनक रैपर बना देता है।

आमने-सामने तुलना

आइडेंटिटी। दोनों मैनेज्ड विकल्प JWT वैलिडेट करते हैं, और APIM साफ़ तौर पर Entra ID या दूसरे आइडेंटिटी प्रोवाइडर्स के टोकन स्वीकार करता है। AgentCore उन कॉलर्स के लिए SigV4 जोड़ता है जिनके पास पहले से AWS क्रेडेंशियल हैं, जो सर्विस-टू-सर्विस ट्रैफ़िक के लिए काम का है। आप जो भी चुनें, यह ज़रूर जाँचें कि गेटवे बिना ऑथेंटिकेट हुई कॉल का जवाब कैसे देता है। MCP ऑथराइज़ेशन मॉडल OAuth पर बना है, और एक साफ़ 401 जो क्लाइंट्स को सही ऑथराइज़ेशन सर्वर की ओर भेजे, वही उन्हें बिना हाथ से लिखे कॉन्फ़िग के साइन इन करने देता है।

बिलिंग। AgentCore Gateway उन कॉल्स के लिए चार्ज करता है जो आपके एजेंट इसके ज़रिए करते हैं, जिन्हें ListTools, CallTool और Ping जैसे MCP ऑपरेशन्स के रूप में गिना जाता है, साथ में सर्च क्वेरी और सिमेंटिक सर्च के लिए इंडेक्स किए गए टूल्स भी। APIM की कीमत टियर और स्केल यूनिट्स के हिसाब से तय होती है, इसलिए आपका बिल कॉल्स के बजाय क्षमता पर निर्भर करता है। Microsoft का गेटवे ओपन सोर्स है, लेकिन आप क्लस्टर, रजिस्ट्री, डेटाबेस और उन्हें पैच करने वाले लोगों का खर्च उठाते हैं। अचानक आने वाला, कम वॉल्यूम का ट्रैफ़िक प्रति-ऑपरेशन प्राइसिंग के पक्ष में जाता है, और लगातार भारी ट्रैफ़िक फ़्लैट कैपेसिटी के पक्ष में। मौजूदा नंबरों के लिए हर वेंडर का प्राइसिंग पेज देखें।

💡 टिप: चूँकि AgentCore पर ListTools और Ping भी बिलेबल ऑपरेशन्स हैं, जो बातूनी क्लाइंट हर टर्न पर टूल लिस्ट रिफ़्रेश करते हैं, वे बिल बढ़ाते हैं। लिस्ट को क्लाइंट पर कुछ मिनट के लिए कैश करें।

AWS और Azure पर सेटअप

अगर आपका बैकएंड पहले से मौजूद है तो दोनों रास्ते पहले टूल के लिए तेज़ होते हैं। नीचे के स्टेप्स उस स्तर पर हैं जहाँ तक डॉक्यूमेंटेशन गारंटी देता है, इसलिए कंसोल लेबल और CLI फ़्लैग्स को मौजूदा डॉक्स से मिलाएँ।

AgentCore Gateway सेटअप स्टेप्स

1. इनबाउंड ऑथोराइज़र चुनें। OAuth (JWT) ऑथोराइज़र को अपने आइडेंटिटी प्रोवाइडर के OpenID कॉन्फ़िगरेशन URL और अनुमत audiences से जोड़ें, या AWS-नेटिव कॉलर्स के लिए IAM चुनें।
2. उस ऑथोराइज़र के साथ गेटवे बनाएँ।
3. एक टार्गेट जोड़ें। उसके टूल स्कीमा के साथ एक Lambda फ़ंक्शन जोड़ें, एक OpenAPI स्पेक अपलोड करें, या किसी रिमोट MCP सर्वर का URL डालें।
4. आउटबाउंड क्रेडेंशियल्स जोड़ें। जब बैकएंड को API क्रेडेंशियल या OAuth टोकन चाहिए, तब क्रेडेंशियल प्रोवाइडर के ज़रिए उन्हें जोड़ें।
5. गेटवे का MCP एंडपॉइंट कॉपी करके अपनी क्लाइंट कॉन्फ़िगरेशन में डालें।
6. tools/list कॉल करें और पुष्टि करें कि आपके अपेक्षित सभी टूल दिखते हैं, और उनके अलावा कुछ नहीं।

API Management सेटअप स्टेप्स

1. टियर की पुष्टि करें। MCP सपोर्ट करने वाला क्लासिक या v2 टियर चुनें, या self-hosted गेटवे।
2. एक मैनेज्ड REST API से MCP सर्वर बनाएँ और चुनें कि कौन से ऑपरेशन्स टूल बनेंगे, या APIM को किसी मौजूदा MCP सर्वर की ओर इशारा करें।
3. इनबाउंड पॉलिसीज़ जोड़ें। पहले टोकन वैलिडेट करें, फिर कॉल रेट सीमित करें, क्योंकि ऑथेंटिकेशन से पहले लगाई गई लिमिटर अनाम ट्रैफ़िक को कोटा जल्दी खत्म करने देती है।
4. Application Insights के साथ मॉनिटरिंग जोड़ें और एक correlation ID हेडर डालें।
5. सर्वर को API Center में रजिस्टर करें ताकि दूसरी टीमें उसे खोज सकें।

एक शुरुआती पॉलिसी कुछ ऐसी दिखती है:

<inbound>
  <base />
  <validate-jwt header-name="Authorization" failed-validation-httpcode="401"
                failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
    <audiences>
      <audience>api://mcp-gateway</audience>
    </audiences>
  </validate-jwt>
  <rate-limit calls="60" renewal-period="60" />
</inbound>

प्रॉम्प्ट कॉपी करें

एक रिक्वेस्ट से दोनों की जाँच करें

वही रिक्वेस्ट किसी भी गेटवे पर काम करती है, इसलिए यह उन्हें निष्पक्ष रूप से तुलना करने का एक तरीका है:

curl -X POST "$GATEWAY_URL" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

प्रॉम्प्ट कॉपी करें

पुराने स्पेक रिवीज़न वाले सर्वर पहले एक initialize कॉल और बाद में एक Mcp-Session-Id हेडर की उम्मीद कर सकते हैं, जबकि 2026-07-28 रिवीज़न वाला सर्वर ऐसा नहीं करता। स्मोक टेस्ट से आगे के लिए MCP Inspector को गेटवे से जोड़ें और एक असली टूल कॉल चलाएँ, क्योंकि एक-बार की रिक्वेस्ट यह नहीं दिखाएगी कि स्ट्रीम्ड जवाब कैसे व्यवहार करते हैं।

वे गलतियाँ जो रोलआउट तोड़ती हैं

• हर ऑपरेशन को टूल बना देना। मॉडल अक्सर 200 टूल की सूची में से 12 की सूची के मुकाबले कमज़ोर टूल चुनते हैं। APIM पर टूल्स की सूची चुनिंदा रखें, और AgentCore पर सिमेंटिक टूल सर्च का सहारा लें।
• प्रमाणीकरण से पहले रेट लिमिटिंग। अनाम कॉलर्स को पहले ही रोका जाना चाहिए, उन्हें गिना नहीं जाना चाहिए।
• क्लाइंट का टोकन बैकएंड तक भेजना। गेटवे को अपने आउटबाउंड क्रेडेंशियल खुद रखने दें, ताकि कोई बैकएंड ऐसा टोकन कभी स्वीकार न करे जो किसी और ऑडियंस के लिए जारी हुआ हो।
• मान लेना कि सेशन मौजूद हैं। टूल्स को स्टेटलेस बनाएँ। अगर किसी टूल को स्टेट चाहिए, तो एक क्रिएशन कॉल से ID लौटाएँ और मॉडल से उसे एक सामान्य आर्गुमेंट की तरह वापस भेजने को कहें।
• MCP पथ पर भारी पॉलिसी लॉजिक। जो भी स्ट्रीम्ड रिस्पॉन्स को पढ़ता या बफ़र करता है, वह इवेंट्स में देरी कर सकता है। किसी असली क्लाइंट के साथ जाँच करें।
• सिर्फ़ टूल्स वाली सीमा को नज़रअंदाज़ करना। अगर आपके सर्वर प्रॉम्प्ट या रिसोर्स पर निर्भर हैं, तो APIM इन्हें अभी नहीं ढोएगा।

आप जो भी चुनें, पहला एजेंट लाइव होने से पहले गेटवे की टेलीमेट्री को उन डैशबोर्ड्स में भेजें जिन्हें आपकी टीम पहले से देखती है। टूल-कॉल वॉल्यूम, एरर रेट और हर टूल की लेटेंसी बताती है कि एजेंट वास्तव में क्या इस्तेमाल करते हैं, और आपके 200 ऑपरेशनों में से कौन-से ऐसे हैं जिन्हें कोई कभी नहीं बुलाता।

किसे चुनें

जब आपका काम AWS पर हो तो AgentCore चुनें

इसे तब चुनें जब आपके टूल्स Lambda फ़ंक्शन, API Gateway REST APIs या OpenAPI specs हों, जब आप चाहते हों कि एक मैनेज्ड एंडपॉइंट उन्हें एक साथ जोड़े, और जब IAM या OAuth पहले से आपके कॉलर्स को नियंत्रित करता हो। यह उन टीमों के लिए भी ठीक है जो सिमेंटिक टूल सर्च खुद बनाए बिना चाहती हैं, और उन सर्वरों के लिए भी जो प्रॉम्प्ट और रिसोर्स पर निर्भर हैं।

अगर आप Microsoft-first हैं तो API Management चुनें

इसे तब चुनें जब आपकी REST APIs पहले से APIM में हों, आपकी आइडेंटिटी Entra ID हो, और आपकी प्लेटफ़ॉर्म टीम पॉलिसी इंजन को जानती हो। आपको रेट लिमिट, कोटा, कैशिंग और मॉनिटरिंग मिलती है, जिन पर आप पहले से भरोसा करते हैं। Microsoft का ओपन-सोर्स गेटवे तभी चुनें जब आपको Kubernetes-स्तर का नियंत्रण चाहिए और उसे खुद चलाने की क्षमता हो।

दोनों क्लाउड पर चला रहे हैं? AgentCore रिमोट MCP सर्वरों को जोड़ सकता है, और APIM उन सर्वरों के आगे खड़ा हो सकता है जिन तक वह HTTP से पहुँचता है, इसलिए एक क्लाउड का गेटवे दूसरे क्लाउड के टूल्स के आगे लगाया जा सकता है। यह काम करता है, लेकिन इससे लेटेंसी, egress चार्ज और मिलाने के लिए एक दूसरा आइडेंटिटी सिस्टम जुड़ जाता है। व्यवहार में, एक साझा आइडेंटिटी प्रोवाइडर के साथ हर क्लाउड के लिए अलग गेटवे आम तौर पर एक ही गेटवे को दोनों ओर फैलाने से सरल होता है।

💡 त्वरित जाँच: पहले अपने टूल सोर्स गिनें, फिर अपना आइडेंटिटी प्रोवाइडर, फिर अपने ट्रैफ़िक का ढाँचा। ज़्यादातर Lambda और OpenAPI हों तो AgentCore की ओर इशारा करते हैं। ज़्यादातर REST जो पहले से APIM में है, तो API Management की ओर। सख्त नियंत्रण वाली Kubernetes प्लेटफ़ॉर्म टीम की ज़रूरत हो तो खुद चलाने वाले विकल्प की ओर।

Picasso IA पर अपनी इमेज बनाएँ

MCP गेटवे प्लंबिंग है, और अच्छी प्लंबिंग वह हिस्सा है जो कोई नहीं देखता। यही बात उन सर्विसेज़ पर लागू होती है जिन्हें आपके एजेंट कॉल करते हैं। उदाहरण के लिए PicassoIA api.picassoia.com/v1 पर एक डेवलपर API देता है जिसमें बेयरर ऑथेंटिकेशन है, एसिंक्रोनस जॉब्स हैं जिन्हें आप बनाते हैं और फिर पोल करते हैं, और हर अकाउंट के लिए 5 एक साथ चलने वाली प्रेडिक्शन की सीमा है, जिसे API और MCP कनेक्शन साझा करते हैं। ऐसी सीमा ठीक वही है जो गेटवे आपके लिए लागू करे: एजेंट्स को रिजेक्शन जमा करने देने के बजाय अपनी ओर से कतार या थ्रॉटल करें।

भाषा मॉडल सेटअप के काम में भी मदद करते हैं। आप Claude Sonnet 5 के साथ अपने गेटवे के लिए Bicep, Terraform या OpenAPI स्पेक का ड्राफ़्ट बना सकते हैं, GPT 5.6 Sol के साथ किसी पॉलिसी की समीक्षा कर सकते हैं, या Gemini 3.5 Flash के साथ किसी लंबे वेंडर चेंजलॉग का तेज़ सारांश ले सकते हैं। उनके आउटपुट को पहला ड्राफ़्ट मानें, और उसे उसी समीक्षा से गुज़ारें जो आप किसी सहकर्मी के पull request को देते।

फिर विज़ुअल्स हैं। आर्किटेक्चर लेख, इंटरनल विकी और लॉन्च पोस्ट एक मज़बूत हीरो फ़ोटो के साथ बेहतर दिखते हैं। Picasso IA खोलें, Seedream 4.5 जैसा टेक्स्ट-टू-इमेज मॉडल चुनें, कुछ वाक्यों में वह दृश्य बताएँ जो आप चाहते हैं, और कई वेरिएशन जनरेट करें। लेंस, रोशनी या सेटिंग बदलें और तुलना करें। आपकी पहली इमेज सबसे अच्छी नहीं होगी, और पाँचवीं अक्सर होती है। हर मॉडल picassoia.com/en/all-models पर देखें, और आज ही अपनी इमेज बनाएँ।