एआई डेवलपर टूल्स
संकेत तैयार करें, मॉडल एपीआई का परीक्षण करें, एआई सीएलआई कमांड उत्पन्न करें, संरचित JSON आउटपुट को मान्य करें, और एक वर्कफ़्लो में लाइव एमसीपी टूल का निरीक्षण करें।
शेयर करने से पहले मुझे प्रॉम्प्ट साफ़ करना है।
यदि इनपुट में रिपॉज़िटरी नोट्स, घटना विवरण या सीक्रेट्स हों, तो पहले प्रॉम्प्ट सफाई, रिडैक्शन और चंकिंग करें।
AI Prompt Toolkit खोलें
मुझे एआई कोडिंग असिस्टेंट के लिए सटीक कमांड और फ़्लैग चाहिए।
जब आपको Claude Code, Codex या OpenCode के लिए सही कमांड चाहिए और आप रेफ़रेंस डॉक्स दोबारा नहीं पढ़ना चाहते, तब CLI builder का उपयोग करें।
AI CLI Tools खोलें
मुझे OpenAI-संगत एंडपॉइंट का परीक्षण करने की आवश्यकता है।
मॉडल लोड करने, चैट या प्रतिक्रिया अनुरोध भेजने और कॉमयूटिल प्रॉक्सी के बिना संगतता का निरीक्षण करने के लिए ब्राउज़र-डायरेक्ट प्रोफ़ाइल का उपयोग करें।
एलएलएम एपीआई परीक्षक खोलें
मेरी ऐप के उपयोग से पहले मुझे JSON आउटपुट सत्यापित करना है।
payload पर भरोसा करने से पहले missing fields, wrong types या extra keys पकड़ने के लिए structured-output workbench का उपयोग करें।
Structured Output Playground खोलें
मुझे एक एमसीपी सर्वर को सत्यापित करना होगा और उसके एक टूल को आज़माना होगा।
इस config को MCP क्लाइंट में जोड़ने से पहले transport, required fields और environment usage की जांच करें।
MCP सर्वर जांच
मुझे notes को agent skill में बदलना है.
जब rough Markdown draft को साफ SKILL.md frontmatter और copy-ready file चाहिए, तब skill builder इस्तेमाल करें.
Agent Skill Builder खोलें
हर चरण यह दायरा घटाता है कि अब भी क्या गलत हो सकता है। प्रॉम्प्ट पहले साफ़ कर लेने का मतलब है कि बाद की विफलता उस टेक्स्ट से नहीं आई जिसे आप भेजना ही नहीं चाहते थे; आउटपुट जाँचने से पहले एंडपॉइंट परखने का मतलब है कि स्कीमा त्रुटि ट्रांसपोर्ट की नहीं, मॉडल की समस्या है।
1. प्रॉम्प्ट तैयारी
टेक्स्ट को आपके वर्कफ़्लो से बाहर जाने से पहले साफ़ करें और विभाजित करें।
2. कमांड निर्माण
जिस असिस्टेंट का आप उपयोग कर रहे हैं, उसके लिए सटीक CLI invocation बनाएं।
3. एपीआई परीक्षण
चयनित समापन बिंदु को सीधे कॉल करें और उसकी वास्तविक प्रतिक्रिया का निरीक्षण करें।
4. आउटपुट जांच
सत्यापित करें कि JSON प्रतिक्रिया अभी भी आपकी अपेक्षित संरचना को पूरा करती है।
5. कॉन्फ़िग डीबगिंग
इस config को MCP क्लाइंट में जोड़ने से पहले transport, required fields और environment usage की जांच करें।
किसी मॉडल को ऐप्लिकेशन में लाना असल में पाँच अलग-अलग काम हैं, जो आम तौर पर पाँच अलग जगहों पर होते हैं: प्रॉम्प्ट को भेजने लायक सुरक्षित बनाना, कमांड या रिक्वेस्ट तैयार करना, एंडपॉइंट को कॉल करना, यह जाँचना कि जवाब अब भी उसी आकार का है जिसे आपका कोड पार्स करता है, और वह सर्वर कॉन्फ़िग जाँचना जिसे एजेंट लोड करेगा। यहाँ जुड़ा हर पेज इनमें से एक काम करता है, और हर एक उसी ब्राउज़र टैब में चलता है जो पहले से खुला है, इसलिए जिस प्रॉम्प्ट, की या पेलोड को आप डिबग कर रहे हैं, उसे किसी ऐसी सेवा में चिपकाने की ज़रूरत नहीं जो आपके नियंत्रण में न हो।
इस पेज का क्रम वही है जिस क्रम में काम आम तौर पर होता है। प्रॉम्प्ट सफ़ाई, CLI कमांड बनाना, स्किल फ़ाइल तैयार करना और स्ट्रक्चर्ड आउटपुट जाँचना — ये आपका इनपुट कहीं नहीं भेजते, पूरी तरह पेज की स्क्रिप्ट में चलते हैं। दो टूल को नेटवर्क तक जाना पड़ता है, और दोनों आपके ब्राउज़र से सीधे उसी एंडपॉइंट पर जाते हैं जो आपने बताया है, जबकि क्रेडेंशियल इसी ब्राउज़र के लोकल स्टोरेज में रहते हैं। इसी सीधे रास्ते की वजह से यहाँ मिली विफलता भरोसेमंद है: जब LLM API टेस्टर या MCP सर्वर जाँच कोई त्रुटि बताती है, तो वह आपके एंडपॉइंट और उसके ट्रांसपोर्ट, CORS या ऑथ कॉन्फ़िगरेशन से आई है, बीच के किसी प्रॉक्सी से नहीं।
- किसी बाहरी असिस्टेंट को भेजने से पहले प्रॉम्प्ट से की, होस्टनाम और ग्राहक टेक्स्ट हटाना
- तीन अलग रेफ़रेंस दस्तावेज़ पढ़ने के बजाय Claude Code, Codex या OpenCode की सटीक कमांड पाना
- कोड में जोड़ने से पहले यह पक्का करना कि नया बेस URL, की या गेटवे जवाब देता है और कितनी तेज़ी से
- यह जाँचना कि मॉडल का JSON अब भी उस कॉन्ट्रैक्ट पर खरा उतरता है जिसे आपका ऐप्लिकेशन पार्स करता है
- किसी क्लाइंट कॉन्फ़िग में जोड़ने से पहले MCP सर्वर का ट्रांसपोर्ट और टूल सूची जाँचना
- कच्चे Markdown ड्राफ़्ट को ऐसी SKILL.md फ़ाइल में बदलना जिसे एजेंट लोड कर सके
- प्रॉम्प्ट टूलकिट, CLI बिल्डर, स्किल बिल्डर, स्ट्रक्चर्ड आउटपुट: इनपुट पेज से बाहर नहीं जाता
- LLM API टेस्टर: आपका ब्राउज़र सीधे आपके सेट किए एंडपॉइंट को कॉल करता है, और प्रोफ़ाइल व की लोकल स्टोरेज में रहती हैं
- MCP सर्वर जाँच: आपके बताए सर्वर से जुड़ती है और टूल कॉल चलाने से पहले पुष्टि माँगती है
- गाइड पेजों में कोई इनपुट फ़ील्ड नहीं होता; वे वर्कफ़्लो समझाते हैं और असली टूल से जोड़ते हैं
- इस पेज पर कुछ भी प्रॉम्प्ट, की या पेलोड को प्रोसेसिंग के लिए ComUtil पर अपलोड नहीं करता
अगर मेरे पास सिर्फ़ एक कच्चा प्रॉम्प्ट है तो कहाँ से शुरू करूँ?
पहले AI प्रॉम्प्ट टूलकिट से गोपनीय जानकारी छिपाएँ और टेक्स्ट को कॉन्टेक्स्ट विंडो में समाने लायक हिस्सों में बाँटें; इसके बाद इस पर निर्भर करता है कि आप कोडिंग असिस्टेंट चला रहे हैं या खुद एंडपॉइंट कॉल कर रहे हैं — तदनुसार CLI बिल्डर या API टेस्टर पर जाएँ।
क्या इनमें से कोई टूल मेरा प्रॉम्प्ट या API की ComUtil को भेजता है?
नहीं। टेक्स्ट टूल पूरी तरह ब्राउज़र में चलते हैं, और नेटवर्क कॉल करने वाले दोनों टूल उन्हें आपके ब्राउज़र से सीधे आपके सेट किए एंडपॉइंट पर भेजते हैं। की इसी ब्राउज़र के लोकल स्टोरेज में रहती हैं और साइट डेटा साफ़ करने पर हट जाती हैं।
CLI बिल्डर और LLM API टेस्टर में क्या अंतर है?
CLI बिल्डर सिर्फ़ Claude Code, Codex या OpenCode जैसे AI कोडिंग असिस्टेंट के लिए कमांड टेक्स्ट बनाता है; यह कुछ भी चलाता नहीं। API टेस्टर सचमुच मॉडल एंडपॉइंट पर रिक्वेस्ट भेजता है और लौटे स्टेटस, स्ट्रीम हुए टोकन, समय और उपयोग को दिखाता है।
जो रिक्वेस्ट मेरे टर्मिनल से चलती है, वही API टेस्टर में क्यों विफल होती है?
ब्राउज़र से जाने वाली रिक्वेस्ट के लिए प्रोवाइडर का CORS हेडर लौटाना ज़रूरी है, टर्मिनल की रिक्वेस्ट के लिए नहीं। अगर एंडपॉइंट कोई हेडर नहीं भेजता, तो पेज के पढ़ने से पहले ही ब्राउज़र जवाब रोक देता है। मॉडल के आगे ऐसा गेटवे लगाएँ जो CORS हेडर लौटाए, या टेस्टर से बनी वह curl कमांड चलाएँ जिसमें गोपनीय मान छिपे होते हैं।
किसी MCP सर्वर को क्लाइंट में जोड़ने से पहले जाँचने के लिए कौन-सा पेज इस्तेमाल करूँ?
MCP सर्वर जाँच। यह रिमोट Streamable HTTP सर्वर से जुड़ती है, उसके बताए टूल उनके इनपुट स्कीमा के साथ सूचीबद्ध करती है, और कॉल तभी चलाती है जब आप पुष्टि कर दें — पहुँच योग्य सर्वर और गलत कॉन्फ़िगर सर्वर में फ़र्क करने के लिए यह काफ़ी है।