एजेंट-नेटिव डोमेन रजिस्ट्रार क्या है?

डोमेन रजिस्ट्रार के पास लंबे समय से एप्लिकेशन प्रोग्रामिंग इंटरफेस (API) हैं। Extensible Provisioning Protocol (EPP), वह मशीन-से-मशीन भाषा जिसका उपयोग रजिस्ट्रार रजिस्ट्रियों से बात करने के लिए करते हैं, ने मार्च 2004 में Proposed Standard का दर्जा प्राप्त किया — यानी दो दशक से भी पहले। तब से उस पर बने हर ICANN-मान्यताप्राप्त रजिस्ट्रार के पास उपलब्धता जांचने, पंजीकरण जमा करने और रिकॉर्ड अपडेट करने के लिए REST या SOAP API का कोई न कोई रूप रहा है। इसलिए “क्या इस रजिस्ट्रार के पास API है?” का ईमानदार जवाब बाज़ार के लगभग हर रजिस्ट्रार के लिए है: हाँ, और वर्षों से है।

मगर यही सवाल गलत साबित होता है। आपकी ओर से डोमेन पंजीकृत करने की कोशिश कर रहा AI एजेंट इसलिए विफल नहीं होता कि रजिस्ट्रार के पास API नहीं है। वह इसलिए विफल होता है क्योंकि API ऐसे डेवलपर के लिए बनाई गई थी जो दस्तावेज़ एक बार पढ़ता है, इंटीग्रेशन कोड हाथ से लिखता है और उसे तैनात कर देता है — न कि ऐसे सिस्टम के लिए जिसे रनटाइम पर API खोजनी हो, JSON प्रतिक्रिया से तय करना हो कि क्या हुआ, और बिना किसी व्यक्ति के चेकआउट पेज देखते हुए खरीद पूरी करनी हो। ये अलग-अलग आवश्यकताएँ हैं, और दूसरी आवश्यकताओं को पूरा करना ही इस लेख में एजेंट-नेटिव कहलाता है।

यह लेख इस शब्द को सटीक रूप से परिभाषित करता है, किसी भी रजिस्ट्रार (या किसी भी API) को परखने के लिए एक चेकलिस्ट देता है, और फिर उस चेकलिस्ट को Namefi समेत 2026 में उपलब्ध प्लेटफ़ॉर्म पर ईमानदारी से लागू करता है। परिभाषा के बजाय प्लेटफ़ॉर्म-दर-प्लेटफ़ॉर्म तुलना के लिए Cloudflare vs Name.com vs Namefi: एजेंट-नेटिव रजिस्ट्रार या व्यापक AI-एजेंटिक डोमेन प्लेटफ़ॉर्म गाइड देखें। यदि आप अब भी “AI और डोमेन” को ब्रांडेबल स्ट्रिंग सुझाने वाले नाम जनरेटर के रूप में देखते हैं, तो नीचे की चेकलिस्ट बताएगी कि एजेंट-नेटिव मानक कितना आगे है — उस अंतर के पूरे विवरण के लिए AI डोमेन नेम जनरेटर से आगे: एजेंट युग देखें।

“API है” और “एजेंट-नेटिव” एक ही दावा क्यों नहीं हैं

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

एक एजेंट लगातार बिना पूर्व जानकारी के आता है। कोडिंग एजेंट के साथ हर बातचीत, हर नया MCP क्लाइंट, व्यवहार में ऐसा डेवलपर है जिसने आपकी API कभी नहीं देखी और उसे समझने के लिए उसके पास केवल कुछ सेकंड का संदर्भ बजट है। अगर “एजेंट इस API को उपयोग करना कैसे सीखता है?” का जवाब है “किसी इंसान ने वर्षों पहले दस्तावेज़ पढ़े और जोड़ने वाला कोड लिख दिया,” तो खरीद के समय कोई व्यक्ति क्लिक न भी करे, API के निष्पादन पथ में व्यक्ति स्थायी रूप से फँसा हुआ है। यह लेख बताता है कि उस कोल्ड-स्टार्ट एजेंट को सफल बनाने के लिए रजिस्ट्रार में स्वयं क्या सही होना चाहिए — उसी हस्तांतरण को खरीदार की दृष्टि से देखने के लिए AI एजेंट बिना इंसान के डोमेन कैसे खरीदते हैं (2026) देखें।

एजेंट-नेटिव चेकलिस्ट

एजेंट-नेटिव रजिस्ट्रार वह है जिसे AI एजेंट पूरी तरह अपने दम पर खोज, समझ और लेन-देन के लिए इस्तेमाल कर सके — बिना ब्राउज़र, बिना किसी इंसान के पहले दस्तावेज़ पढ़े, और बिना किसी व्यक्ति के कार्ड नंबर टाइप किए। इसके लिए केवल “API होना” नहीं, छह विशिष्ट बातें सही होनी चाहिए:

यह परिभाषा का संक्षिप्त रूप है: एजेंट-नेटिव रजिस्ट्रार वह है जो खोज-योग्यता, प्राकृतिक-भाषा दस्तावेज़, मशीन-पठनीय त्रुटियाँ, ब्राउज़र-रहित खरीद और प्रोग्रामेटिक भुगतान की कसौटी पर खरा उतरता है — जबकि नीति-नियंत्रण वह हिस्सा है जिस पर पूरी श्रेणी अभी काम कर रही है।

खोज-योग्यता: llms.txt और MCP एजेंटों के लिए साइटमैप हैं

मानवीय डेवलपर API को खोज कर या दस्तावेज़ साइट पर क्लिक करके पाता है। एजेंट को या तो ऐसी फ़ाइल चाहिए जिसे वह एक बार में प्राप्त और पढ़ सके, या ऐसा प्रोटोकॉल कनेक्शन जिसे वह उपलब्ध कार्यों के लिए पूछ सके। आज दो चीज़ें यह भूमिका निभाती हैं।

llms.txt, प्रस्ताव के अपने शब्दों में, “अनुमान के समय LLMs को वेबसाइट इस्तेमाल करने में मदद देने वाली जानकारी प्रदान करने के लिए /llms.txt फ़ाइल के उपयोग को मानकीकृत करने का प्रस्ताव” है। विचार robots.txt जैसा ही है, लेकिन क्रॉलर को यह बताने के बजाय कि वह क्या इंडेक्स कर सकता है, यह भाषा मॉडल को बताता है कि साइट क्या है और उसे कैसे इस्तेमाल करना है। जब रजिस्ट्रार ऐसी फ़ाइल प्रकाशित करता है, तो वह कैसी दिखती है, यह देखने के लिए डोमेन के लिए llms.txt: ऐसी API जिसे हर AI एजेंट पढ़ सके देखें।

MCP (Model Context Protocol) एक जुड़ी हुई समस्या हल करता है: यह “AI एप्लिकेशन को बाहरी प्रणालियों से जोड़ने का ओपन-सोर्स मानक” है। जहाँ llms.txt ऐसा दस्तावेज़ है जिसे एजेंट खुद को दिशा देने के लिए एक बार पढ़ता है, MCP लाइव कनेक्शन है जिसे एजेंट का क्लाइंट परिभाषित कॉल किए जा सकने वाले उपकरणों वाले सर्वर से खोलता है। दोनों प्रतिस्पर्धी नहीं, पूरक हैं: llms.txt से एजेंट जानता है कि कोई रजिस्ट्रार मौजूद है और वह मोटे तौर पर क्या कर सकता है; MCP से एजेंट का क्लाइंट वास्तव में कनेक्ट होकर कार्यों को कॉल करता है।

Namefi दोनों प्रकाशित करता है। namefi.io/llms.txt में api.namefi.io/mcp पर MCP सर्वर का प्रवेश बिंदु, namefi.io/.well-known/mcp/servers.json पर MCP डिस्कवरी फ़ाइल और पूर्ण REST संदर्भ, साथ ही वॉलेट-आधारित भुगतान और आउटबाउंड एजेंट वर्कफ़्लो के लिए सहायक फ़ाइलों का दस्तावेज़ीकरण है। दो स्थापित प्रदाताओं को सीधे जाँचने पर: Cloudflare के रजिस्ट्रार दस्तावेज़ अपना llms.txt developers.cloudflare.com/registrar/llms.txt पर प्रकाशित करते हैं, लेकिन उनके सार्वजनिक दस्तावेज़ में यह नहीं कहा गया है कि Cloudflare रजिस्ट्रार उत्पाद के लिए समर्पित MCP सर्वर चलाता है — रिपोर्टिंग के अनुसार beta का दावा यह है कि API “उन उपकरणों के अंदर काम करने के लिए बनाई गई है जहाँ डेवलपर पहले से काम करते हैं: MCP सहायता वाले कोड संपादक जैसे Cursor और Claude Code”, जो अधिक सीमित बात है — संपादक MCP-सक्षम है, Cloudflare का रजिस्ट्रार स्वयं आवश्यक रूप से नहीं। सीधे जाँचा गया GoDaddy डेवलपर पोर्टल मानवीय डेवलपर के लिए REST एंडपॉइंट दिखाता है और इस लेखन तक llms.txt या MCP सर्वर का कोई संदर्भ नहीं दिखाता।

भुगतान: सहेजा हुआ कार्ड एजेंटों को क्यों रोकता है और उसकी जगह क्या आता है

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

दो विकल्प उपलब्ध हो रहे हैं। पहला API-key billing है: रजिस्ट्रार पूर्व-वित्तपोषित या चालान वाले खाते से जुड़ा प्रमाण-पत्र जारी करता है, और एजेंट कार्ड के बजाय हर कॉल में उसी key से प्रमाणीकरण करता है। Namefi दस्तावेज़ इस key को namefi.io/api-key पर बनाने और हर अनुरोध में x-api-key हेडर के रूप में भेजने का वर्णन करते हैं — न ब्राउज़र session, न कार्ड फ़ॉर्म। Cloudflare की .ai pricing उसी at-cost तर्क का पालन करती है: वह “.ai domain registrations और renewals को wholesale prices पर, बिना अतिरिक्त markups के” देता है — एक निश्चित, पूर्वानुमेय कीमत उस कीमत की तुलना में एजेंट के लिए समझना आसान है जो promotion के अनुसार बदलती है।

दूसरा विकल्प वॉलेट-हस्ताक्षरित भुगतान है, जो केवल कार्ड नहीं बल्कि खाते को ही हटाता है। Namefi के web3 दस्तावेज़ में HTTP 402 स्थिति कोड और x402 पैटर्न पर बना प्रवाह वर्णित है: भुगतान के बिना डोमेन के लिए अनुरोध 402 प्रतिक्रिया में कीमत लौटाती है, कॉलर का वॉलेट EIP-3009 authorization पर हस्ताक्षर करता है और हस्ताक्षरित authorization को हेडर के रूप में दोबारा भेजकर एक ही चरण में पंजीकरण और निपटान पूरा होता है — स्पष्ट रूप से “Namefi account या EIP-712 signing की आवश्यकता नहीं है।” यहाँ बात अधिक सीमित है — यह ऐसी भुगतान विधि है जिसे सॉफ़्टवेयर स्वयं रख और उपयोग कर सकता है, जबकि सहेजा हुआ क्रेडिट कार्ड संरचनात्मक रूप से ऐसा नहीं हो सकता। इस प्रवाह का शुरू से अंत तक विवरण क्रिप्टो वॉलेट से डोमेन का भुगतान करें: खाते की आवश्यकता नहीं में देखें।

नीति-नियंत्रण: वह पंक्ति जिसे पूरी श्रेणी ने अभी तक हल नहीं किया है

यही ईमानदार कमी है। खोज-योग्यता, मशीन-पठनीय दस्तावेज़, संरचित त्रुटियाँ और प्रोग्रामेटिक भुगतान ऐसी चीज़ें हैं जिन्हें रजिस्ट्रार एक बार बनाकर जारी कर सकता है। नीति-नियंत्रण — खर्च सीमाएँ, सीमा से ऊपर पुष्टि चरण, किसी एक TLD या बजट तक सीमित कुंजी — अलग हैं, क्योंकि वे अधिकार सौंपने वाले इंसान की रक्षा करते हैं, API के उपयोग की सरलता की नहीं।

Namefi के अपने दस्तावेज़ को जाँचने पर, जो सबसे सत्यापनीय मामला है: वह कुछ कार्यों को परिणामकारी के रूप में चिह्नित करता है और संरचित, मशीन-पठनीय त्रुटियों (स्थिर कोड, retryable संकेतक, संरचित विवरण) का दस्तावेज़ीकरण करता है — उस पंक्ति पर वास्तविक प्रगति। लेकिन इस लेखन तक हमें सार्वजनिक API संदर्भ में न कोई दस्तावेज़ीकृत खर्च-सीमा primitive मिला, न सर्वर-तरफ़ पुष्टि द्वार; वह सुरक्षा-कवच अभी एक स्तर ऊपर, MCP क्लाइंट पर इंसान की बनाई हुई नीति में रहता है। Cloudflare या Name.com की रजिस्ट्रार APIs में भी हमें खर्च-सीमा primitive का सार्वजनिक दस्तावेज़ नहीं मिला — यही वह पंक्ति है जिसे हर एजेंट-नेटिव रजिस्ट्रार से अगला पूरा करने की अपेक्षा की जानी चाहिए।

आज के प्लेटफ़ॉर्म का चेकलिस्ट पर आकलन

यहाँ वे तीन प्लेटफ़ॉर्म हैं जिनका इस क्षेत्र में सबसे अधिक उल्लेख होता है और वे छह-बिंदु चेकलिस्ट पर कैसा प्रदर्शन करते हैं; यह विपणन सामग्री के बजाय हर प्लेटफ़ॉर्म के अपने लाइव दस्तावेज़ को सीधे सत्यापित करने पर आधारित है:

हर जगह खाली रहने वाली एक पंक्ति — नीति-नियंत्रण — वास्तविक, उद्योग-व्यापी कमी है, किसी एक प्लेटफ़ॉर्म पर आक्षेप नहीं; और इस क्षेत्र के आगे बढ़ने पर इसे फिर से जाँचना उचित है।

अक्सर पूछे जाने वाले प्रश्न

एजेंट-नेटिव डोमेन रजिस्ट्रार क्या है?

एजेंट-नेटिव रजिस्ट्रार वह है जिसे AI एजेंट अपने दम पर खोज, समझ और लेन-देन के लिए इस्तेमाल कर सके — बिना ब्राउज़र, बिना किसी इंसान के पहले दस्तावेज़ पढ़े, और बिना किसी व्यक्ति के कार्ड नंबर दर्ज किए। वह खोज-योग्यता (llms.txt फ़ाइल या MCP सर्वर), प्राकृतिक-भाषा दस्तावेज़, मशीन-पठनीय त्रुटियाँ, ब्राउज़र-रहित खरीद और प्रोग्रामेटिक भुगतान की कसौटी पर खरा उतरता है; नीति-नियंत्रण (खर्च सीमाएँ, पुष्टि द्वार) वह हिस्सा हैं जिसे यह श्रेणी अभी विकसित कर रही है।

AI एजेंट सामान्य रजिस्ट्रार APIs का उपयोग क्यों नहीं कर सकते?

तकनीकी रूप से वे एंडपॉइंट को कॉल कर सकते हैं, लेकिन अधिकांश रजिस्ट्रार APIs मानती हैं कि मानवीय डेवलपर पहले ही दस्तावेज़ पढ़ चुका है और इंटीग्रेशन कोड पहले से लिख चुका है। बिना पूर्व इंटीग्रेशन वाले एजेंट के पास बेस URL खोजने, प्रमाणीकरण योजना सीखने या गद्य में लिखे त्रुटि संदेश की व्याख्या करने का कोई मानक तरीका नहीं होता — API केवल इसलिए काम करती है कि कोई व्यक्ति पहले ही वह व्याख्यात्मक काम कर चुका है, इसलिए नहीं कि वह कोल्ड-स्टार्ट एजेंट के लिए पठनीय है।

llms.txt और MCP में क्या अंतर है?

llms.txt ऐसी सादा-पाठ फ़ाइल है जिसे एजेंट एक बार पढ़कर सीखता है कि साइट या API क्या है और उसका उपयोग कैसे करना है — वही भूमिका जो robots.txt क्रॉलर के लिए निभाती है, लेकिन भाषा मॉडलों के लिए लिखी गई है। MCP लाइव प्रोटोकॉल कनेक्शन है जिसे एजेंट का क्लाइंट कॉल किए जा सकने वाले tools देने वाले सर्वर से खोलता है। दोनों पूरक हैं: llms.txt खोज-योग्यता है, MCP वह कनेक्शन है जिसका उपयोग एजेंट कार्य करने के लिए करता है। खोज-योग्यता वाले आधे हिस्से के बारे में अधिक जानकारी के लिए डोमेन के लिए llms.txt: ऐसी API जिसे हर AI एजेंट पढ़ सके देखें।

मैं अपनी API को एजेंट-उपयोगी कैसे बनाऊँ?

अपनी API का मॉडलों के लिए वर्णन करने वाली llms.txt प्रकाशित करें, MCP सर्वर (या कम से कम OpenAPI-दस्तावेज़ीकृत एंडपॉइंट) उपलब्ध कराएँ, गद्य के बजाय स्थिर कोड वाली संरचित त्रुटियाँ लौटाएँ, यह सुनिश्चित करें कि हर लेखन कार्य होस्टेड चेकआउट पेज के बिना पूरा हो सके, ऐसी भुगतान विधि समर्थन दें जो मानवीय कार्ड पर निर्भर न हो, और खर्च या पुष्टि सीमाएँ जोड़ें ताकि प्रमाण-पत्र रखने वाला व्यक्ति सीमित कर सके कि एजेंट क्या कर सकता है।

क्या Namefi एजेंट-नेटिव है?

ऊपर की चेकलिस्ट के अनुसार Namefi सीधे सत्यापित छह में से पाँच पंक्तियों पर हाँ में खरा उतरता है: वह llms.txt परिवार और MCP सर्वर प्रकाशित करता है, उसके दस्तावेज़ एजेंट द्वारा उपयोग के लिए व्यवस्थित हैं, उसकी आउटबाउंड API संरचित मशीन-पठनीय त्रुटियाँ लौटाती है, पंजीकरण बिना डैशबोर्ड के पूरी तरह API या x402-आधारित वॉलेट प्रवाह से पूरा होता है, और भुगतान API कुंजी या बिना खाते वाली वॉलेट-हस्ताक्षरित लेन-देन से काम करता है। नीति-नियंत्रण अभी सार्वजनिक API संदर्भ में दस्तावेज़ीकृत नहीं हैं; वह नियंत्रण वर्तमान में क्लाइंट साइड पर रहता है।

क्या MCP server होना रजिस्ट्रार को अपने आप एजेंट-नेटिव बना देता है?

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

स्रोत और आगे पढ़ें

• Wikipedia — Extensible Provisioning Protocol (EPP को Proposed Standard के रूप में मानकीकृत किया गया, मार्च 2004)
• CircleID — 2026 में डोमेन जगत: AI, सुरक्षा, बाज़ार परिपक्वता और नई gTLD सीमा (“AI एजेंट बढ़ते हुए डोमेन पुनर्विक्रेताओं के रूप में काम कर रहे हैं…”)
• webhosting.today — AI एजेंट अब बिना इंसान के डोमेन पंजीकृत कर सकते हैं (Cloudflare Registrar API beta, अप्रैल 2026)
• Name.com — पहला AI-Native डोमेन प्लेटफ़ॉर्म (“Model Context Protocol जैसे आधुनिक मानकों द्वारा समर्थित…”)
• llmstxt.org — /llms.txt फ़ाइल का प्रस्ताव
• modelcontextprotocol.io — Model Context Protocol (MCP) क्या है?
• Schema.org — FAQPage
• Cloudflare — .ai डोमेन को लागत मूल्य पर खरीदें
• Cloudflare Developers — रजिस्ट्रार दस्तावेज़ सूचकांक (llms.txt)
• Namefi — namefi.io/llms.txt (API और MCP सर्वर संदर्भ — इस लेख में Namefi उत्पाद दावों का स्रोत)
• Namefi — namefi.io/web3/llms.txt (वॉलेट-हस्ताक्षरित / x402 भुगतान प्रवाह, “Namefi account या EIP-712 signing की आवश्यकता नहीं”)