MCP OAuth 2.1 फ़्लो समझाया गया: CIMD बनाम DCR, उदाहरणों के साथ

एक MCP क्लाइंट जब किसी सुरक्षित सर्वर को कॉल करना चाहता है, तो उसकी पहली ही रिक्वेस्ट पर ट्रस्ट की समस्या आती है। सर्वर ने इस क्लाइंट को कभी देखा नहीं है, और उसके पीछे का ऑथराइज़ेशन सर्वर भी इसके बारे में कुछ नहीं जानता। MCP ऑथराइज़ेशन स्पेक इसे OAuth 2.1 से सुलझाता है, और पिछले एक साल में सबसे ज़्यादा बदलाव इस बात में आया है कि क्लाइंट अपनी client_id कैसे पाता है। Client ID Metadata Documents (CIMD) 2025-11-25 रिवीज़न में एक अनुशंसित रजिस्ट्रेशन तरीके के रूप में आए, और 2026-07-28 रिवीज़न Dynamic Client Registration (DCR) को डेप्रिकेटेड बताती है। यह आर्टिकल MCP OAuth 2.1 फ़्लो को पहले 401 रिस्पॉन्स से लेकर पहली अधिकृत टूल कॉल तक ले जाता है, दोनों रजिस्ट्रेशन रास्तों के असली रिक्वेस्ट और रिस्पॉन्स दिखाता है, और अंत में दोनों में से चुनने का सीधा नियम देता है।

MCP को OAuth 2.1 की ज़रूरत क्यों है

एक होटल के फ्रंट डेस्क की कल्पना कीजिए। आप एक बार अपनी ID दिखाते हैं, डेस्क पुष्टि करता है कि आप कौन हैं, और आप एक रूम कार्ड लेकर चले जाते हैं जो सिर्फ़ आपका कमरा खोलता है, और कुछ नहीं। OAuth भी इसी पैटर्न पर चलता है। ऑथराइज़ेशन सर्वर फ्रंट डेस्क है, एक्सेस टोकन रूम कार्ड है, और MCP सर्वर वह दरवाज़ा है जो कार्ड जाँचता है। दरवाज़ा कभी आपका पासपोर्ट नहीं देखता, और कमरा 412 का कार्ड कमरा 518 नहीं खोलता।

MCP में ऑथराइज़ेशन वैकल्पिक है, लेकिन इसे चालू करते ही नियम सख्त हो जाते हैं। HTTP बेस्ड सर्वर SHOULD ऑथराइज़ेशन स्पेक का पालन करें, जबकि stdio सर्वर SHOULD NOT ऐसा करें और इसके बजाय क्रेडेंशियल एनवायरनमेंट से पढ़ें। स्पेक इन्हें अनिवार्य बनाता है:

• S256 मेथड के साथ PKCE। क्लाइंट को यह भी जाँचना होगा कि ऑथराइज़ेशन सर्वर code_challenge_methods_supported का विज्ञापन करता है, और अगर यह फ़ील्ड गायब है तो आगे बढ़ने से मना करना होगा।
• Protected Resource Metadata (RFC 9728). MCP सर्वर इसे प्रकाशित करता है, और क्लाइंट इसका उपयोग सही ऑथराइज़ेशन सर्वर खोजने के लिए करता है।
• Resource indicators (RFC 8707). क्लाइंट ऑथराइज़ेशन रिक्वेस्ट और टोकन रिक्वेस्ट, दोनों में resource पैरामीटर भेजते हैं।
• हेडर में Bearer टोकन। Authorization: Bearer हेडर हर HTTP रिक्वेस्ट के साथ जाता है, और टोकन कभी क्वेरी स्ट्रिंग में नहीं आते।
• Audience वैलिडेशन। MCP सर्वर सिर्फ़ वही टोकन स्वीकार करता है जो उसी के लिए जारी हुए हों।

चार एक्टर

इस आर्टिकल के हर फ़्लो में वही चार पक्ष शामिल हैं। इन्हें साफ़ रखें, तो बाकी आसानी से समझ आएगा।

💡 MCP सर्वर और ऑथराइज़ेशन सर्वर एक ही डिप्लॉयमेंट में रह सकते हैं, या दो अलग कंपनियों के हो सकते हैं। क्लाइंट ID सिर्फ़ उसी ऑथराइज़ेशन सर्वर के लिए मायने रखती है जिसने उसे जारी किया या स्वीकार किया, इसलिए क्लाइंट को कभी यह नहीं मानना चाहिए कि एक ID हर जगह काम करेगी।

401 से टोकन तक का फ़्लो

हैंडशेक सादे HTTP रिक्वेस्ट की एक छोटी श्रृंखला है। आप हर एक को टर्मिनल में देख सकते हैं, जिससे डीबगिंग एक्रोनिम सुनकर लगने वाली बात से कहीं कम रहस्यमय लगती है।

401 चैलेंज

क्लाइंट बिना टोकन के MCP रिक्वेस्ट भेजता है। सर्वर उसे मना करता है और बताता है कि कहाँ देखना है:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

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

scope पैरामीटर इस रिक्वेस्ट के लिए ज़रूरी सबसे कम अनुमतियों पर सर्वर का संकेत है। अगर resource_metadata पैरामीटर नहीं है, तो क्लाइंट जाने-माने URL पर वापस जाता है, पहले /.well-known/oauth-protected-resource/mcp (path inserted) और फिर root वाला वर्ज़न।

दो मेटाडेटा लुकअप

क्लाइंट Protected Resource Metadata दस्तावेज़ लाता है और पढ़ता है कि कौन-सा ऑथराइज़ेशन सर्वर इस्तेमाल करना है:

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://auth.example.com"],
  "scopes_supported": ["files:read", "files:write"]
}

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

फिर वह ऑथराइज़ेशन सर्वर से खुद का वर्णन माँगता है, पहले /.well-known/oauth-authorization-server पर और दूसरे विकल्प के रूप में OpenID Connect का /.well-known/openid-configuration। रिस्पॉन्स के अंदर का issuer उस URL से मेल खाना चाहिए जिससे क्लाइंट ने रिक्वेस्ट बनाई थी, वरना दस्तावेज़ को फेंक दिया जाता है। एक सामान्य जवाब कुछ ऐसा दिखता है:

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "registration_endpoint": "https://auth.example.com/register",
  "code_challenge_methods_supported": ["S256"],
  "client_id_metadata_document_supported": true,
  "authorization_response_iss_parameter_supported": true
}

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

उस जवाब के दो फ़ील्ड तय करते हैं कि क्लाइंट रजिस्टर कैसे करेगा: client_id_metadata_document_supported (CIMD) और registration_endpoint (DCR)। हम दोनों पर लौटेंगे।

PKCE और Resource पैरामीटर

client_id मिलने के बाद क्लाइंट एक बार-उपयोग वाला PKCE verifier बनाता है, उसका हैश निकालता है, और ब्राउज़र खोलता है। वह बाद में रिस्पॉन्स जाँचने के लिए अपेक्षित issuer भी रिकॉर्ड करता है।

GET https://auth.example.com/authorize?response_type=code
  &client_id=https%3A%2F%2Fapp.example.com%2Foauth%2Fclient-metadata.json
  &redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
  &resource=https%3A%2F%2Fmcp.example.com%2Fmcp
  &scope=files%3Aread
  &state=xyz123

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

resource वैल्यू MCP सर्वर का कैनोनिकल URI है। क्लाइंट को इसे MUST भेजना होगा, भले ही ऑथराइज़ेशन सर्वर इसे अनदेखा करे, क्योंकि इसी से टोकन किसी एक खास सर्वर से बंधा रहता है।

कोड एक्सचेंज और टोकन का उपयोग

उपयोगकर्ता मंज़ूरी देता है, और ब्राउज़र एक code, state और आदर्श रूप से एक iss पैरामीटर के साथ redirect URI पर वापस लौटता है। 2026-07-28 रिवीज़न RFC 9207 से एक issuer चेक जोड़ता है: अगर iss मौजूद है, तो क्लाइंट कोड कहीं भेजने से पहले उसकी तुलना दर्ज किए गए issuer से करता है। इससे mix-up हमले रुकते हैं, जहाँ कोई दुर्भावनापूर्ण ऑथराइज़ेशन सर्वर किसी ईमानदार सर्वर के लिए बने कोड चुराने की कोशिश करता है।

इसके बाद टोकन रिक्वेस्ट आती है, जो PKCE verifier के कब्ज़े को साबित करती है:

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback
&client_id=https%3A%2F%2Fapp.example.com%2Foauth%2Fclient-metadata.json
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&resource=https%3A%2F%2Fmcp.example.com%2Fmcp

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

रिस्पॉन्स में एक्सेस टोकन होता है, और उसके बाद MCP सर्वर की हर रिक्वेस्ट में Authorization: Bearer <access-token> शामिल होता है। अगर बाद में टोकन में कोई स्कोप कम पड़ता है, तो सर्वर 403 के साथ error="insufficient_scope" भेजता है, और क्लाइंट पुराने और नए स्कोप के मेल के साथ फिर से ऑथराइज़ करता है।

DCR: यह कैसे काम करता है, और कहाँ टूटता है

Dynamic Client Registration RFC 7591 से आता है। विचार सीधा है: पहले लॉगिन से पहले क्लाइंट अपनी जानकारी एक registration_endpoint को भेजता है और बदले में नया client_id पाता है। कोई इंसान फॉर्म नहीं भरता। सालों तक अज्ञात क्लाइंट को अपने-आप ऑनबोर्ड करने का यही मुख्य तरीका रहा, इसीलिए शुरुआती MCP ने इसे अपनाया।

एक रजिस्ट्रेशन रिक्वेस्ट

डेस्कटॉप MCP क्लाइंट के लिए एक यथार्थवादी आदान-प्रदान यह है:

POST /register HTTP/1.1
Host: auth.example.com
Content-Type: application/json

{
  "client_name": "Example MCP Client",
  "redirect_uris": ["http://localhost:3000/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none",
  "application_type": "native"
}

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

{
  "client_id": "s6BhdRkqt3",
  "client_name": "Example MCP Client",
  "redirect_uris": ["http://localhost:3000/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "token_endpoint_auth_method": "none",
  "client_id_issued_at": 1791247700
}

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

application_type पर ध्यान दें। 2026-07-28 रिवीज़न से क्लाइंट को इसे MUST सेट करना होगा। OpenID Connect बोलने वाले सर्वर गायब वैल्यू को web मानते हैं, और यह डिफ़ॉल्ट localhost redirect URIs को रद्द कर सकता है।

सर्वर इसमें क्यों संघर्ष करते हैं

DCR काम करता है, लेकिन यह ऑथराइज़ेशन सर्वर पर काफ़ी बोझ डाल देता है:

• एक सार्वजनिक राइट एंडपॉइंट। इंटरनेट पर कोई भी रिकॉर्ड बना सकता है, इसलिए आपको रेट लिमिट, एक्सपायरी और क्लीनअप जॉब्स की ज़रूरत पड़ती है।
• हर पेयरिंग के लिए एक रजिस्ट्रेशन। हर क्लाइंट को हर ऑथराइज़ेशन सर्वर के साथ अलग से रजिस्टर करना पड़ता है, और नतीजे को issuer के हिसाब से इंडेक्स करके सुरक्षित रूप से स्टोर करना पड़ता है। ऑथराइज़ेशन सर्वर बदलने पर क्लाइंट को दोबारा रजिस्टर करना पड़ता है।
• ऐसे नाम जिन्हें किसी ने वेरिफ़ाई नहीं किया। कंसेंट स्क्रीन पर रजिस्टर करने वाले ने जो भी client_name टाइप किया हो, वही दिखता है, इसलिए कोई हानिकारक ऐप खुद को कोई भी नाम दे सकता है।
• डेटाबेस का बढ़ना। एक लोकप्रिय क्लाइंट के हज़ारों इंस्टॉल हज़ारों ऐसे रिकॉर्ड बन जाते हैं जिनका मतलब एक ही होता है।

इन लागतों की वजह से स्पेक अब नए इम्प्लीमेंटेशन को कहीं और का रास्ता दिखाता है।

CIMD: URL ही Client ID है

पासपोर्ट के बारे में सोचिए। कोई सीमा अधिकारी आपको पहले से याद नहीं रखता। आप एक दस्तावेज़ देते हैं, और अधिकारी उसे जारी करने वाली संस्था से मिलाता है। CIMD रजिस्ट्रेशन को उसी तरह पलटता है। क्लाइंट एक स्थिर HTTPS URL पर JSON दस्तावेज़ प्रकाशित करता है, और वही URL ही client_id है। ऑथराइज़ेशन सर्वर पहली बार URL देखने पर दस्तावेज़ पढ़ता है, इसलिए पहले से कुछ रजिस्टर करने की ज़रूरत नहीं है।

मेटाडेटा दस्तावेज़

क्लाइंट के लिए नियम छोटे हैं। client_id को https इस्तेमाल करना होगा और उसमें path होना चाहिए, दस्तावेज़ में client_id, client_name और redirect_uris होने चाहिए, और फ़ाइल के अंदर का client_id उस URL से हूबहू मेल खाना चाहिए जहाँ से उसे सर्व किया गया। स्पेक का अपना उदाहरण ऐसा दिखता है:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

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

सर्वर क्या जाँचता है

जब client_id जैसे आकार वाले URL के साथ कोई ऑथराइज़ेशन रिक्वेस्ट आती है, तो ऑथराइज़ेशन सर्वर एक तय प्रक्रिया चलाता है:

1. सादे HTTPS GET से डॉक्यूमेंट फ़ेच करें।
2. पक्का करें कि वह वैध JSON है और उसमें ज़रूरी फ़ील्ड मौजूद हैं।
3. पक्का करें कि फ़ाइल में दिया गया client_id URL के बिल्कुल बराबर है।
4. पक्का करें कि रिक्वेस्ट में दिया गया redirect_uri फ़ाइल में सूचीबद्ध किसी एक से मेल खाता है।
5. HTTP कैश हेडर का पालन करते हुए नतीजे को कैश करें।
6. कंसेंट स्क्रीन पर यूज़र को client_name और रीडायरेक्ट होस्टनेम दिखाएँ।

चरण 1 से 3 का एक छोटा TypeScript स्केच, जो स्पष्टता के लिए लिखा गया है, न कि प्रोडक्शन उपयोग के लिए:

async function loadClient(clientId: string) {
  const url = new URL(clientId);
  if (url.protocol !== "https:" || url.pathname === "/") throw new Error("invalid_client");
  await assertPublicHost(url.hostname); // reject private, loopback and link-local addresses

  const res = await fetch(url, { redirect: "error", signal: AbortSignal.timeout(5000) });
  const doc = await res.json();

  if (doc.client_id !== clientId) throw new Error("invalid_client");
  if (!doc.client_name || !Array.isArray(doc.redirect_uris)) throw new Error("invalid_client");
  return doc;
}

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

CIMD सपोर्ट का विज्ञापन

ऑथराइज़ेशन सर्वर अपने मेटाडेटा में "client_id_metadata_document_supported": true के साथ इस सुविधा की घोषणा करता है। जो क्लाइंट इसे पाते हैं, वे अपने URL को client_id के रूप में इस्तेमाल करते हैं और रजिस्ट्रेशन पूरी तरह छोड़ देते हैं। चूँकि ID एक सार्वजनिक URL है, यह आसानी से दूसरी जगह भी काम आती है: वही क्लाइंट कल किसी दूसरे ऑथराइज़ेशन सर्वर से बिना फिर से रजिस्टर किए बात कर सकता है।

CIMD बनाम DCR, साथ-साथ

जो क्लाइंट हर विकल्प सपोर्ट करता है, उसे इस क्रम में चुनना SHOULD चाहिए:

1. अगर इस सर्वर के लिए पहले से रजिस्टर्ड क्लाइंट विवरण हैं, तो उन्हें इस्तेमाल करें।
2. अगर ऑथराइज़ेशन सर्वर सपोर्ट का विज्ञापन करता है, तो CIMD इस्तेमाल करें।
3. अगर registration_endpoint मौजूद है, तो DCR पर लौटें।
4. उपयोगकर्ता से क्लाइंट विवरण हाथ से टाइप करने को कहें।

💡 पहले से रजिस्ट्रेशन तब भी सबसे आगे रहता है, जब वह उपलब्ध हो। अगर आप क्लाइंट और ऑथराइज़ेशन सर्वर, दोनों को नियंत्रित करते हैं, तो एक तय client_id ऊपर की हर खोज को छोड़ देता है।

सुरक्षा जाँचें जिन्हें छोड़ा नहीं जा सकता

DCR से CIMD पर जाने से जोखिम खत्म नहीं होता। जोखिम बस दूसरी जगहों पर चला जाता है, और हर एक को किसी की ज़िम्मेदारी चाहिए।

fetch पर SSRF

CIMD में, एक गुमनाम विज़िटर तय करता है कि आपका सर्वर किस URL को रिक्वेस्ट करेगा। अगर client_id को https://169.254.169.254/latest/meta-data/ या किसी इंटरनल एडमिन पैनल की ओर इशारा कर दिया जाए, तो लापरवाह fetcher आपके नेटवर्क का प्रॉक्सी बन जाता है। पहले hostname को resolve करें और private, loopback और link-local रेंज रद्द करें। छोटा timeout सेट करें, रिस्पॉन्स साइज़ सीमित करें, और redirects पर सख्त रहें।

Localhost redirects

मेटाडेटा डॉक्यूमेंट यह साबित नहीं कर सकता कि localhost:3000 पर सुन रही कोई प्रोसेस उसी क्लाइंट की है जिसका नाम फ़ाइल में दिया गया है। कोई भी लोकल प्रोग्राम उस पोर्ट पर दावा कर सकता है। इसलिए ऑथराइज़ेशन सर्वर को कंसेंट स्क्रीन पर रीडायरेक्ट होस्टनेम दिखाना अनिवार्य है (MUST), जब हर रीडायरेक्ट URI localhost हो तो चेतावनी देना चाहिए (SHOULD), और ज़्यादा भरोसे के लिए अतिरिक्त अटेस्टेशन की माँग करना वैकल्पिक रूप से संभव है (MAY)। रीडायरेक्ट URI खुद हमेशा बिल्कुल सटीक रूप से मेल खाने चाहिए, प्रीफ़िक्स या पैटर्न से कभी नहीं।

Audience और token passthrough

MCP सर्वर आखिरी दरवाज़ा है, और उसे कार्ड को सिर्फ़ एक नज़र देखना नहीं, जाँचना है। सिग्नेचर, एक्सपायरी, स्कोप और सबसे ऊपर audience जाँचें। किसी दूसरी सेवा के लिए बना टोकन 401 के साथ रद्द होना चाहिए। अगर आपका MCP सर्वर किसी upstream API को कॉल करता है, तो उसे उस API के लिए अलग टोकन चाहिए, जो उसी API के ऑथराइज़ेशन सर्वर ने जारी किया हो। क्लाइंट के टोकन को आगे भेजने को token passthrough कहा जाता है, और स्पेक इसे पूरी तरह मना करता है।

आपके मॉनिटर के बगल में चिपकाने लायक एक छोटी चेकलिस्ट:

• हर ऑथराइज़ेशन एंडपॉइंट HTTPS पर सर्व करें, और केवल HTTPS या localhost redirects की अनुमति दें।
• एक्सेस टोकन को छोटी अवधि का रखें, और सार्वजनिक क्लाइंट के लिए refresh टोकन रोटेट करें।
• state पैरामीटर इस्तेमाल करें और उसकी पुष्टि करें।
• कोड रिडीम करने से पहले, iss मौजूद होने पर उसकी पुष्टि करें।
• एक ऑपरेशन के लिए ज़रूरी सभी स्कोप एक ही चैलेंज में शामिल करें, ताकि उपयोगकर्ता को बार-बार मंज़ूरी स्क्रीन से न गुज़रना पड़े।

रणनीति चुनना

फ़ैसला बहस के सुझाव से कहीं कम नाटकीय है। पहले CIMD सपोर्ट करें, DCR को एक पुल की तरह रखें, और ईमानदार रहें कि आप सर्वर की तरफ़ हैं या क्लाइंट की।

अगर आप MCP सर्वर चलाते हैं

Protected Resource Metadata हर हाल में प्रकाशित करें। ऐसा ऑथराइज़ेशन सर्वर चुनें जो CIMD सपोर्ट करता हो, और अगर आपका अभी नहीं कर सकता, तो हर क्लाइंट को ब्लॉक करने के बजाय DCR चालू रखें, साथ में रेट लिमिट और एक्सपायरी के साथ। अपने WWW-Authenticate चैलेंज में scope रखें, और जब टोकन कम पड़े तो 403 और insufficient_scope के साथ जवाब दें। हर रिक्वेस्ट पर audience की पुष्टि करें।

अगर आप MCP क्लाइंट बनाते हैं

अपना मेटाडेटा दस्तावेज़ ऐसे URL पर होस्ट करें जिसे आप सालों तक रख सकें, क्योंकि वही URL आपकी पहचान है। ऑथराइज़ेशन सर्वर मेटाडेटा पढ़ें, फिर कोड में रजिस्ट्रेशन का रास्ता चुनें:

function pickRegistration(as: AuthServerMetadata, saved?: SavedClient) {
  if (saved && saved.issuer === as.issuer) return { mode: "saved", clientId: saved.clientId };
  if (as.client_id_metadata_document_supported) return { mode: "cimd", clientId: CLIENT_METADATA_URL };
  if (as.registration_endpoint) return { mode: "dcr", endpoint: as.registration_endpoint };
  return { mode: "manual" };
}

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

जब आप DCR पर लौटें, तो क्रेडेंशियल्स को issuer के साथ स्टोर करें, डेस्कटॉप और CLI ऐप्स के लिए application_type: "native" सेट करें, और उन्हें किसी दूसरे ऑथराइज़ेशन सर्वर के साथ कभी दोबारा इस्तेमाल न करें।

PicassoIA पर आज़माएँ

हैंडशेक के जिस भी तरफ़ आप बनाएँ, आपको काफ़ी JSON, टेस्ट फ़िक्स्चर और डॉक्स लिखने होंगे। एक सक्षम लार्ज लैंग्वेज मॉडल इसे तेज़ करता है, और PicassoIA कई ऐसे मॉडल होस्ट करता है। अपने मेटाडेटा दस्तावेज़ के लिए रिव्यूअर के रूप में Claude Sonnet 5 का उपयोग करने का एक तेज़ तरीका यह है:

1. PicassoIA पर Claude Sonnet 5 पेज खोलें।
2. अपना client-metadata.json और अपने प्रोवाइडर से मिला ऑथराइज़ेशन सर्वर मेटाडेटा पेस्ट करें।
3. चेकलिस्ट जाँच माँगें: "Check this document against the CIMD rules: client_id equals the URL, https with a path, required fields present, redirect_uris exact. List every failure."
4. जवाब को नियम, नतीजा और सुधार वाली टेबल के रूप में माँगें, ताकि उसे पull request में आसानी से चिपकाया जा सके।
5. दूसरी राय के लिए वही प्रॉम्प्ट GPT 5.6 Sol पर चलाएँ, या Gemini 3.5 Flash पर एक तेज़ पास लगाएँ, और देखें कि हर एक किन विफलताओं को पकड़ता है।

💡 मॉडल दस्तावेज़ अच्छी तरह रिव्यू करते हैं, लेकिन असली टेस्ट की जगह नहीं ले सकते। शिप करने से पहले अपने फ़्लो को स्टेजिंग ऑथराइज़ेशन सर्वर पर चलाएँ।

डॉक्यूमेंटेशन को JSON जितनी ही तस्वीरों की भी ज़रूरत होती है। एक हीरो इमेज, डायग्राम बैकग्राउंड या सोशल कार्ड OAuth पर लिखी पोस्ट को शेयर करने में कहीं आसान बना देता है, और PicassoIA ठीक इसी काम के लिए बना है। फ़ोटोरियलिस्टिक नतीजे खास प्रॉम्प्ट से आते हैं: लेंस, रोशनी की दिशा और दृश्य की बनावट का नाम लें। कुछ ऐसा आज़माएँ: "a hotel receptionist sliding a room card across a marble counter, 50mm lens, soft window light from the right, film grain" और देखें कि क्या आता है। डेवलपर PicassoIA API और MCP कनेक्शन के ज़रिए PicassoIA के इमेज और वीडियो मॉडल तक भी पहुँच सकते हैं, ताकि वही प्रॉम्प्ट आपके अपने एजेंट से चल सके।

अपने खुद के विज़ुअल बनाने के लिए तैयार हैं? PicassoIA खोलें, एक मॉडल चुनें, और आज ही अपना पहला प्रॉम्प्ट आज़माना शुरू करें।