Figma के अपने डॉक्स में get_design_context का जवाब 351,378 टोकन दिखाया गया है, जबकि सीमा 25,000 है। यह लेख बताता है कि Figma MCP का आउटपुट क्या बढ़ाता है, हर कॉल को कैसे मापें, और सात उपाय, get_metadata से लेकर Code Connect तक, जो जवाबों को छोटा रखते हैं।
आप अपने कोडिंग एजेंट में एक Figma लिंक डालते हैं, एक प्राइसिंग कार्ड माँगते हैं, और रन रिस्पॉन्स साइज़ की एरर के साथ रुक जाता है। Figma के अपने ट्रबलशूटिंग पेज पर वही सटीक मैसेज दिखता है: get_design_context का जवाब 351,378 टोकन का था, जबकि सीमा 25,000 टोकन की है। वह रिक्वेस्ट सीमा से चौदह गुना ज़्यादा थी। और जब जवाब सीमा के नीचे भी रहता है, तब भी वह आपकी कॉन्टेक्स्ट विंडो में जाता है, पहले के निर्देशों को दूर धकेल देता है, और आगे के हर टर्न में दोबारा पढ़ा जाता है।
यह लेख बताता है कि Figma MCP सर्वर इतना आउटपुट क्यों बनाता है, हर कॉल की लागत कैसे देखें, और सात बदलाव जो नंबर घटाते हैं, जेनरेट हुए UI को और खराब किए बिना। टूल के नाम और सीमाएँ Figma के प्रकाशित डॉक्स से ली गई हैं। वर्कफ़्लो की सलाह इस अनुभव से आती है कि बड़ी डिज़ाइन फ़ाइलें छोटी कॉन्टेक्स्ट विंडो से टकराती हैं तो क्या होता है।
एक नोड लिंक सिर्फ़ एक आयत नहीं लौटाता। get_design_context चुनी गई लेयर्स का डिज़ाइन कॉन्टेक्स्ट निकालता है और उसे कोड के रूप में लौटाता है, डिफ़ॉल्ट रूप से React और Tailwind, और दूसरे फ़्रेमवर्क भी उपलब्ध हैं। अगर आप पूरा पेज फ़्रेम चुनते हैं, तो उसकी हर नेस्टेड लेयर साथ आती है: नेविगेशन बार, कार्ड, आइकन इंस्टेंस, टेक्स्ट स्टाइल, ऑटो लेआउट नियम, स्पेसिंग।
एक व्यस्त लैंडिंग पेज में हज़ारों नोड हो सकते हैं, और हर नोड में नाम, साइज़, फ़िल, स्ट्रोक, पैडिंग और टाइप सेटिंग्स होती हैं। कोड में बदलने पर यह सब लंबी क्लास लिस्ट और गहरे मार्कअप में बदल जाता है। लंबी क्लास लिस्ट के टोकन ठीक से नहीं बनते। अंग्रेज़ी गद्य के लिए एक आम अनुमान है लगभग चार अक्षर प्रति टोकन, और घने कोड और मार्कअप में आमतौर पर प्रति टोकन कम अक्षर आते हैं।
चार चीज़ें आउटपुट को सबसे तेज़ी से बढ़ाती हैं:
एक डिज़ाइन रिक्वेस्ट अक्सर कई रीड टूल चलाती है, और हर एक अपना पेलोड जोड़ता है। Figma का टूल रेफ़रेंस इन्हें सूचीबद्ध करता है:
| टूल | क्या लौटाता है | सापेक्ष आकार | सबसे अच्छा उपयोग |
|---|---|---|---|
get_metadata | लेयर ID, नाम, प्रकार, पोज़िशन और आकार वाला छोटा XML आउटलाइन | छोटा | डेटा लाने से पहले किसी बड़े फ़्रेम का मैप बनाना |
get_design_context | लेयर की स्टाइलिंग और स्ट्रक्चर कोड के रूप में, डिफ़ॉल्ट रूप से React और Tailwind में | बड़ा, सबट्री के साथ बढ़ता है | एक कॉम्पोनेंट या एक सेक्शन बनाना |
get_screenshot | लेआउट की सटीकता बनाए रखने के लिए चुने गए हिस्से की PNG | मध्यम, इमेज टोकन | नतीजे की विज़ुअल जाँच |
get_variable_defs | चुने गए हिस्से में इस्तेमाल हुए वेरिएबल और स्टाइल: रंग, स्पेसिंग, टाइपोग्राफ़ी | छोटा से मध्यम | डिज़ाइन टोकन से मिलान करना |
download_assets | PNG, JPG, SVG या PDF एक्सपोर्ट, या मूल सोर्स इमेज | एसेट्स पर निर्भर | आइकन और फ़ोटो को फ़ाइलों के रूप में सहेजना |
get_code_connect_map | नोड ID से कोड कॉम्पोनेंट मैपिंग | छोटा | ऐसे कॉम्पोनेंट दोबारा इस्तेमाल करना जो आप पहले से शिप करते हैं |
साइज़ कॉलम बताता है कि हर टूल आम तौर पर क्या लौटाता है। असली गिनती आपकी फ़ाइल पर निर्भर करती है, इसलिए किसी भी लेबल पर भरोसा करने से पहले मापें।
टूल के नतीजे बातचीत में बने रहते हैं। मान लीजिए एक पुल 40,000 टोकन लौटाता है: उसके बाद के हर मैसेज में वह बोझ साथ चलता है। प्रॉम्प्ट कैशिंग उसे दोबारा पढ़ने की कीमत घटा सकती है, लेकिन टोकन फिर भी विंडो में जगह घेरते हैं, और आपकी सोर्स फ़ाइलों, टेस्ट आउटपुट और निर्देशों को धकेल देते हैं। लंबे सेशन फिर ऑटोमैटिक कम्पैक्शन शुरू करते हैं, जो वे विवरण समेट देता है जिन्हें आप रखना चाहते थे।
💡 त्वरित जाँच: अगर Figma कॉल के तुरंत बाद एजेंट धीमा हो जाए या पिछले निर्देश भूल जाए, तो मॉडल को दोष देने से पहले ज़्यादा बड़े जवाब को दोष दें।
ज़्यादातर क्लाइंट बताते हैं कि विंडो कितनी भरी है। Claude Code में /context कमांड यह काम करता है। हर Figma कॉल से पहले और बाद में नंबर देखें। फ़र्क ही उस कॉल की असली लागत है, स्क्रीनशॉट समेत, और आपकी फ़ाइल के लिए यही इकलौता नंबर मायने रखता है।
एक असली फ़्रेम चुनें और नए सेशन में तीन कॉल चलाएँ, हर कॉल के बाद कॉन्टेक्स्ट साइज़ लिखते जाएँ:
get_metadata।get_design_context।get_design_context।नतीजे इस जैसी टेबल में दर्ज करें:
| कॉल | नोड | जोड़ा गया कॉन्टेक्स्ट | नोट्स |
|---|---|---|---|
get_metadata | पूरा फ़्रेम | यहाँ भरें | सिर्फ़ आउटलाइन |
get_design_context | पूरा फ़्रेम | यहाँ भरें | साइज़ एरर की जाँच करें |
get_design_context | एक चाइल्ड | यहाँ भरें | ऊपर वाली रो से तुलना करें |
कुछ फ़्रेम के बाद आपके पास अपनी लागत का कर्व होगा, जो किसी ब्लॉग पोस्ट के किसी भी नंबर से बेहतर है, इस पोस्ट के नंबर से भी। मेरा अपना अनुमान: पुल इतने छोटे रखें कि कम्पैक्शन से पहले एक सेशन में पाँच-छह पुल हो सकें। अगर एक ही पुल विंडो का एक-तिहाई खा जाए, तो नोड बहुत बड़ा है।
लगभग इस क्रम में, जिसमें इनसे होने वाली बचत ज़्यादा से कम है।
बहुत बड़े डिज़ाइनों के लिए Figma get_metadata की सलाह देता है, क्योंकि यह बिना स्टाइल के एक विरल XML आउटलाइन लौटाता है। आउटलाइन पढ़ें, वह सेक्शन चुनें जो आपको सच में चाहिए, फिर सिर्फ़ उस नोड ID पर get_design_context कॉल करें।
Run get_metadata on this frame. Do not call get_design_context yet.
List the top level sections with their node IDs and wait for my pick.
सर्वर उसी नोड पर काम करता है जिसे आप चुनते या लिंक करते हैं। पूरे पेज को नहीं, बटन को लिंक करें। पेज ऐसे बनाएँ जैसे कोई इंसान बनाता: हेडर, हीरो, प्राइसिंग, फ़ुटर, हर एक अपनी अलग रिक्वेस्ट में।
सोर्स फ़ाइल भी साफ़ रखें। बिना इस्तेमाल की लेयर्स और गहराई से नेस्टेड ग्रुप ऐसे नोड जोड़ सकते हैं जिन्हें आउटपुट को वर्णन करना पड़ता है, इसलिए डिज़ाइनर की दस मिनट की सफ़ाई अक्सर अगले ही पुल में अपनी लागत वसूल लेती है।
Figma के डॉक्स कहते हैं कि कोड के बेहतर पुन: उपयोग के लिए Code Connect सेट करें। मैपिंग get_code_connect_map और add_code_connect_map के ज़रिए एक Figma नोड को आपके रेपो के असली कंपोनेंट से जोड़ती हैं। हर रिक्वेस्ट पर कच्चे स्टाइल से बटन दोबारा बनाने के बजाय, एजेंट उस बटन की ओर इशारा कर सकता है जो आप पहले से शिप कर चुके हैं। इसका मतलब है कम जेनरेट किया गया कोड और कम रिव्यू कमेंट।
एक फ़र्क पर ध्यान दें: डेस्कटॉप सर्वर वे मैपिंग इस्तेमाल करता है जो आप चुनते हैं, जबकि रिमोट सर्वर को clientFrameworks पैरामीटर किसी खास लेबल पर सेट चाहिए, जैसे React या SwiftUI।
जब डिज़ाइनर रंग, स्पेसिंग और टाइप के लिए वेरिएबल्स और स्टाइल लगाते हैं, तो get_variable_defs चुनाव में इस्तेमाल हुए वेरिएबल्स लौटाता है। ऐसा आउटपुट जो टोकन नाम का संदर्भ देता है, सैकड़ों एलिमेंट्स में दोहराए गए वही हेक्स कोड और पिक्सेल मान से बेहतर है, और यह आपकी स्टाइलशीट के टोकन के साथ मेल खाता है।
💡 डिज़ाइन टीम से पूछें कि पहले MCP पुल से पहले फ़िल और स्पेसिंग को वेरिएबल्स से बाइंड करें। उनके कुछ मिनट लगेंगे और हर बाद की रिक्वेस्ट बचेगी।
React और Tailwind डिफ़ॉल्ट आउटपुट है। अगर आपका प्रोजेक्ट Vue, SwiftUI या सादा CSS चलाता है, तो React जवाब को बदलने के लिए दूसरा पास चाहिए, और आप दोनों की कीमत चुकाते हैं। प्रॉम्प्ट में टूल्स के सेट का नाम लें, और रिमोट सर्वर पर clientFrameworks साफ़-साफ़ सेट करें। स्टाइलिंग पर भी यही लागू होता है: बताएँ कि आप Tailwind, CSS मॉड्यूल या कंपोनेंट लाइब्रेरी इस्तेमाल करते हैं, क्योंकि एक ही पास में अलग-अलग तरीके मिलाना ही रीराइट की शुरुआत बनता है।
आइकन और फ़ोटो को फ़ाइलों के रूप में रेपो में एक्सपोर्ट करने के लिए download_assets इस्तेमाल करें, फिर उन्हें पाथ से रेफ़रेंस करें। हर उस कंपोनेंट के लिए एजेंट से इमेज नोड दोबारा मत पढ़वाइए जो एक ही लोगो दिखाता है। आइकन के लिए SVG और फ़ोटो के लिए PNG या JPG एक्सपोर्ट हो सकते हैं, इसलिए वही फ़ॉर्मेट चुनें जो आपका बिल्ड पहले से इस्तेमाल करता है। फ़ाइलें एक बार रेपो में आ जाएँ, तो बाद के प्रॉम्प्ट को सिर्फ़ फ़ाइल पाथ चाहिए।
Figma बताता है कि टोकन सीमा की चिंता हो तो स्क्रीनशॉट बंद किए जा सकते हैं, हालाँकि वह उन्हें चालू रखने की सलाह देता है क्योंकि वे लेआउट की सटीकता बचाते हैं। एक उचित बीच का रास्ता: सेक्शन की पहली बिल्ड के लिए उन्हें रखें, और लेबल बदलने या पैडिंग ठीक करने जैसे छोटे संपादनों में हटा दें।
एरर मैसेज MAX_MCP_OUTPUT_TOKENS बढ़ाने का सुझाव देता है, और Figma का ट्रबलशूटिंग पेज 50000 या 100000 को उदाहरण मान बताता है। Claude Code में आप एनवायरनमेंट सेटिंग्स में वेरिएबल सेट करते हैं और ऐप रीस्टार्ट करते हैं। इससे कॉल रुक जाती है, लेकिन जवाब में कितने टोकन हैं, इसमें कोई बदलाव नहीं होता। बड़ी सीमा सिर्फ़ बड़ा ढेर विंडो में आने देती है।
अगर एक सेक्शन लाने के बाद भी साइज़ की एरर आती है, तो नोड खुद भारी है। उसे बाँटें: उस नोड के चाइल्ड्स के लिए get_metadata माँगें, फिर उन्हें एक-एक करके लाएँ। अगर फिर भी कोई कंपोनेंट बहुत ज़्यादा लौटाता है, तो कारण आमतौर पर बहुत लंबी इंस्टेंस लिस्ट या टेक्स्ट-भारी लेयर होती है, और उसका समाधान प्रॉम्प्ट में नहीं, Figma फ़ाइल में होता है।
| तरीका | कॉन्टेक्स्ट पर असर | कब समझदारी है |
|---|---|---|
MAX_MCP_OUTPUT_TOKENS बढ़ाएँ | कोई असर नहीं, यह बस बड़े रिस्पॉन्स को पास होने देता है | एक दुर्लभ एक-बार का पुल जिसे बाँटा नहीं जा सकता |
| चाइल्ड नोड लाएँ | रिस्पॉन्स का आकार नाटकीय रूप से घटाता है | सेक्शन से बड़ी किसी भी चीज़ के लिए डिफ़ॉल्ट |
| स्क्रीनशॉट बंद करें | इमेज पेलोड हटाता है | छोटे एडिट |
| Code Connect | एजेंट द्वारा लिखा गया कोड छोटा करता है | कॉम्पोनेंट लाइब्रेरी वाला कोई भी प्रोजेक्ट |
| हर सेक्शन के लिए नई बातचीत | पुराने पेलोड साफ़ करता है | लंबे सेशन |
नियम फ़ाइल छोटी रह सकती है। बस इतना काफ़ी है:
Design to code rules
- Framework: React with Tailwind. Reuse components from src/components first.
- Colors and spacing: use the tokens in src/styles/tokens.css, never raw hex values.
- Figma: call get_metadata first on any frame larger than one section.
- Fetch one node per request. Do not re-pull a node that is already built.
हर सेशन में इसकी कीमत कुछ दर्जन टोकन है, और यह सबसे महँगी आदतों को शुरू होने से पहले रोक देती है।
get_metadata से शुरू करें और एक नोड चुनें।एक प्राइसिंग पेज लें, जिसमें हेडर, तीन प्लान कार्ड, एक FAQ और फ़ुटर हो। महँगा रास्ता है पूरे फ़्रेम का एक लिंक और प्रॉम्प्ट "यह पेज बनाओ"। किफ़ायती रास्ता कुछ ऐसा दिखता है:
get_metadata आउटलाइन और नोड ID लौटाता है।get_design_context माँगते हैं।PlanCard कंपोनेंट बनाता है।तीन प्लान कार्ड, एक डिज़ाइन पुल। पूरे पेज पर, "हर सेक्शन के लिए एक पुल" और "सब कुछ के लिए एक पुल" के बीच का यही फ़ासला सबसे ज़्यादा बचत लाता है।
| गलती | इसकी कीमत क्यों चुकानी पड़ती है | समाधान |
|---|---|---|
| पूरा पेज लिंक करना | पूरा सबट्री वापस आ जाता है | एक सेक्शन लिंक करें |
एक नोड पर get_design_context को दो बार कॉल करना | वही पेलोड कॉन्टेक्स्ट में दो बार पहुँचता है | पहला नतीजा दोबारा इस्तेमाल करें |
| एक छोटे बदलाव के लिए दोबारा पुल करना | एक लाइन के बदलाव के लिए नया पेलोड | कोड सीधे एडिट करें |
| डिफ़ॉल्ट रूप से सीमा बढ़ाना | बड़े पुल आम हो जाते हैं | डिफ़ॉल्ट रखें, अस्थायी रूप से बढ़ाएँ |
| फ़्रेमवर्क को नज़रअंदाज़ करना | एक और कन्वर्ज़न पास | पहले टूल्स का सेट बताएँ |
कुछ उपाय Figma फ़ाइल में होने चाहिए, प्रॉम्प्ट में नहीं। डिज़ाइन टीम से कहें कि लंबे फ़्लो को हर फ़्रेम में एक सेक्शन के हिसाब से बाँटें, सेक्शन का नाम उनके काम के अनुसार रखें, और दोबारा इस्तेमाल होने वाले कंपोनेंट्स को पेजों पर कॉपी करने के बजाय एक लाइब्रेरी में रखें। साफ़ फ़ाइल get_metadata को एक साफ़ आउटलाइन देती है, जिससे हर बाद का पुल छोटा और एजेंट के लिए पढ़ने में आसान होता है। अपने समान-फ़्रेम वाले नंबर भी उनके साथ साझा करें। किसी पुल को बहुत बड़े से मामूली होते देखना, टोकन लागत को डिज़ाइन की आदत बनाने का सबसे तेज़ तरीका है।
कुछ कम्युनिटी सर्वर दावा करते हैं कि वे Figma डेटा को दुबले आउटपुट में समेट देते हैं। उन्हें देखना सार्थक हो सकता है, लेकिन बदलने से पहले उन पर वही समान-फ़्रेम टेस्ट चलाएँ, और जाँचें कि वे क्या छोड़ देते हैं। छोटा जवाब तभी फ़ायदा है जब आपके लिए ज़रूरी लेआउट विवरण बचे रहें।
डिज़ाइन से कोड तक के रन में Figma कॉल से ज़्यादा कुछ होता है। आस-पास का बहुत सारा काम अपने कोडिंग एजेंट के कॉन्टेक्स्ट के भीतर बिल्कुल होना ज़रूरी नहीं है, और यहीं PicassoIA Large Language Models संग्रह के मॉडल मदद करते हैं।
इमेज बचत की एक और जगह है। हीरो फ़ोटो और प्लेसहोल्डर शॉट्स को Figma सर्वर से गुज़रना ज़रूरी नहीं। Flux 2 Pro, Seedream 4.5 या P-Image से प्रॉम्प्ट के ज़रिए इन्हें बनाएँ, और इनमें से कुछ भी आपके कोडिंग एजेंट के कॉन्टेक्स्ट को नहीं छूता। लैंडिंग पेज के लिए मोशन चाहिए? Seedance 2.0 और PicassoIA Video एक प्रॉम्प्ट या स्टिल इमेज को छोटे क्लिप में बदलते हैं।
आपका अगला डिज़ाइन से कोड सेशन तेज़ चलेगा, अगर पहले प्रॉम्प्ट से पहले इमेज तैयार हों। Picasso IA खोलें, एक छोटा सीन विवरण लिखें, और उसे Flux 2 Pro और Seedream 4.5 पर साथ-साथ चलाएँ। जो आपके लेआउट में फ़िट बैठे उसे रखें, फिर अगर पेज को मूविंग हीरो चाहिए तो Seedance 2.0 से उसे एनिमेट करें।
आज कुछ प्रॉम्प्ट आज़माएँ और देखें कि आपको कौन-सा बेहतर लगता है। हर मॉडल picassoia.com/en/all-models पर सूचीबद्ध है, इसलिए आप जितने चाहें उतने परख सकते हैं।
अपनी भाषा चुनें
