AI முகவர்களை மையமாகக் கொண்ட டொமைன் ரெஜிஸ்ட்ரார் என்றால் என்ன?

டொமைன் ரெஜிஸ்ட்ரார்களிடம் பயன்பாட்டு நிரலாக்க இடைமுகங்கள் (API-கள்) நீண்ட காலமாகவே உள்ளன. ரெஜிஸ்ட்ரார்கள் பதிவகங்களுடன் இயந்திரம்-இயந்திரமாகத் தொடர்புகொள்ளப் பயன்படுத்தும் மொழியான Extensible Provisioning Protocol (EPP), மார்ச் 2004-இல் முன்மொழியப்பட்ட தரநிலை நிலையை எட்டியது — அது இருபது ஆண்டுகளுக்கும் முன்பு. அதன் மேல் கட்டமைக்கப்பட்ட ஒவ்வொரு ICANN அங்கீகாரம் பெற்ற ரெஜிஸ்ட்ராரிடமும், டொமைன் கிடைப்பதைச் சரிபார்க்கவும், பதிவைச் சமர்ப்பிக்கவும், பதிவுகளைப் புதுப்பிக்கவும் ஏதாவது ஒரு வகை REST அல்லது SOAP API இருந்து வந்துள்ளது. எனவே “இந்தப் ரெஜிஸ்ட்ராரிடம் API உள்ளதா?” என்ற கேள்விக்குச் சந்தையில் உள்ள கிட்டத்தட்ட ஒவ்வொரு ரெஜிஸ்ட்ராருக்குமான நேர்மையான பதில்: ஆம், பல ஆண்டுகளாகவே உள்ளது.

ஆனால் அது தவறான கேள்வி என்பது தெரியவருகிறது. உங்கள் சார்பாக ஒரு டொமைனைப் பதிவுசெய்ய முயலும் AI முகவர், ரெஜிஸ்ட்ராரிடம் API இல்லாததால் தோல்வியடைவதில்லை. ஆவணங்களை ஒருமுறை படித்து, ஒருங்கிணைப்புக் குறியீட்டைத் தானே எழுதி, அதை வெளியிடும் ஒரு டெவலப்பருக்காக அந்த API உருவாக்கப்பட்டிருப்பதால்தான் அது தோல்வியடைகிறது — இயக்க நேரத்தில் API-ஐக் கண்டறிந்து, JSON பதிலிலிருந்து என்ன நடந்தது என்பதைத் தீர்மானித்து, checkout பக்கத்தை ஒருவர் பார்த்துக்கொண்டிருக்காமல் வாங்குதலை முடிக்க வேண்டிய அமைப்புக்காக அது உருவாக்கப்படவில்லை. இவை வெவ்வேறு தேவைகள்; இரண்டாவது தேவைகளின் தொகுப்பை நிறைவேற்றுவதைத்தான் இந்தக் கட்டுரை முகவர்-நேட்டிவ் (agent-native) என்று குறிப்பிடுகிறது.

இந்தப் பதிவு அந்தச் சொல்லைத் துல்லியமாக வரையறுக்கிறது; எந்தப் ரெஜிஸ்ட்ராரையும் (அல்லது எந்த API-யையும்) மதிப்பிடுவதற்கான சரிபார்ப்புப் பட்டியலை அளிக்கிறது; பின்னர் Namefi உட்பட 2026-இல் பயன்பாட்டில் உள்ள தளங்களுக்கு அந்தப் பட்டியலை நேர்மையாகப் பயன்படுத்துகிறது. வரையறைக்குப் பதிலாகத் தளம் வாரியான ஒப்பீட்டைப் பார்க்க, Cloudflare vs Name.com vs Namefi: முகவர்-நேட்டிவ் ரெஜிஸ்ட்ரார்கள் அல்லது விரிவான AI முகவர் சார்ந்த டொமைன் தளங்கள் வழிகாட்டி ஆகியவற்றைப் பாருங்கள். “AI மற்றும் டொமைன்கள்” என்பது பிராண்டாகப் பயன்படுத்தத்தக்க பெயர்களைப் பரிந்துரைக்கும் பெயர் உருவாக்கி மட்டுமே என்று நீங்கள் இன்னும் நினைத்தால், முகவர்-நேட்டிவ் தகுதிநிலை அதைவிட எவ்வளவு உயர்ந்தது என்பதை கீழே உள்ள பட்டியல் காட்டுகிறது — அந்த இடைவெளியை முழுமையாக அறிய AI டொமைன் பெயர் உருவாக்கியைத் தாண்டி: முகவர்களின் காலம் என்பதைப் பாருங்கள்.

“API உள்ளது” என்பதும் “முகவர்-நேட்டிவ்” என்பதும் ஏன் ஒரே கூற்று அல்ல

ஒரு வழக்கமான ரெஜிஸ்ட்ரார் API, வடிவமைப்பு நேரத்தில் மனிதர் செயல்முறையில் இருப்பார் என்று கருதுகிறது; இயக்க நேரத்தில் அல்ல. ஒரு டெவலப்பர் கணக்கைத் தொடங்கி, மனிதர்கள் படிப்பதற்காக எழுதப்பட்ட குறிப்பு பக்கத்தைப் படித்து, குறியீட்டு மாதிரியை நகலெடுத்து, endpoint, auth header, எதிர்பார்க்கப்படும் பதில் வடிவம் ஆகியவற்றைத் தனது பயன்பாட்டில் நேரடியாகப் பதித்துவிடுகிறார். அது முடிந்ததும் ஒருங்கிணைப்பு மனிதத் தலையீடின்றி இயங்கும் — ஆனால் அதற்கு முன்பே ஒரு மனிதர் பொருளுணர்ந்து செயல்படும் பணியைச் செய்துவிட்டதால்தான். முன் ஒருங்கிணைப்பு எதுவுமின்றி புதிதாக வந்து, என்னென்ன செயல்பாடுகள் உள்ளன, அவற்றை எப்படி அழைப்பது என்று சூழலிலிருந்தே கண்டறிய வேண்டிய ஓர் அமைப்புக்கு, API தானாகவே புரிந்துகொள்ளத்தக்கதாக இருப்பதில்லை.

ஒரு முகவர் ஒவ்வொரு முறையும் புதிதாகத்தான் வருகிறது. குறியீட்டு முகவருடனான ஒவ்வொரு உரையாடலும், ஒவ்வொரு புதிய MCP client-உம், உங்கள் API-ஐ இதுவரை பார்த்திராத ஒரு டெவலப்பர் போன்றதே; அதை எப்படிப் பயன்படுத்துவது என்று கண்டுபிடிக்க அதற்கு சில வினாடிகளுக்கான context budget மட்டுமே இருக்கும். “இந்த API-ஐ எப்படிப் பயன்படுத்துவது என்று முகவர் எவ்வாறு கற்றுக்கொள்கிறது?” என்ற கேள்விக்கான பதில், “பல ஆண்டுகளுக்கு முன்பு ஒரு மனிதர் ஆவணங்களைப் படித்து, இணைப்புக் குறியீட்டை எழுதினார்” என்பதாக இருந்தால், வாங்கும் நேரத்தில் யாரும் எதையும் சொடுக்காவிட்டாலும் அந்த API-யின் செயல்பாட்டுப் பாதையில் ஒரு மனிதர் நிரந்தரமாகப் பதிந்திருக்கிறார். புதிதாகத் தொடங்கும் முகவர் வெற்றிபெற, ரெஜிஸ்ட்ரார் தரப்பிலேயே எவை உண்மையாக இருக்க வேண்டும் என்பதே இந்தப் பதிவின் பொருள் — இதே ஒப்படைப்பை வாங்குபவரின் கோணத்தில் பார்க்க, மனித உதவியின்றி AI முகவர்கள் டொமைன்களை வாங்குவது எப்படி (2026) என்பதைப் பாருங்கள்.

முகவர்-நேட்டிவ் சரிபார்ப்புப் பட்டியல்

ஒரு AI முகவர் எந்த browser-உம் இல்லாமல், மனிதர் முன்கூட்டியே ஆவணங்களைப் படிக்காமல், ஒருவர் அட்டை எண்ணைத் தட்டச்சு செய்யாமல், தானாகவே கண்டறிந்து, புரிந்துகொண்டு, பரிவர்த்தனை செய்யக்கூடிய ரெஜிஸ்ட்ராரே முகவர்-நேட்டிவ் ரெஜிஸ்ட்ரார். இதற்கு வெறும் “API இருப்பது” மட்டுமல்ல, குறிப்பிட்ட ஆறு அம்சங்கள் உண்மையாக இருக்க வேண்டும்:

வரையறையின் சுருக்கமான வடிவம் இதுதான்: கண்டறியும் வசதி, இயல்பான மொழி ஆவணங்கள், இயந்திரம் வாசிக்கக்கூடிய பிழைகள், browser இல்லாத வாங்குதல், நிரலாக்க முறையிலான பணம் செலுத்துதல் ஆகியவற்றில் “ஆம்” என மதிப்பெடுக்கும் ரெஜிஸ்ட்ராரே முகவர்-நேட்டிவ் ரெஜிஸ்ட்ரார் — கொள்கைக் கட்டுப்பாடுகள் மட்டும் இந்த முழுத் துறையும் இன்னும் தீர்வு காண முயலும் அம்சமாக உள்ளது.

கண்டறியும் வசதி: llms.txt மற்றும் MCP ஆகியவை முகவர்களுக்கான sitemap

ஒரு மனித டெவலப்பர் தேடுவதன் மூலமோ docs தளத்தில் இணைப்புகளைச் சொடுக்குவதன் மூலமோ ஓர் API-ஐக் கண்டறிகிறார். ஒரு முகவருக்கு, ஒரே முயற்சியில் பெற்று வாசிக்கக்கூடிய கோப்பு அல்லது கிடைக்கக்கூடிய செயல்பாடுகளை வினவக்கூடிய protocol இணைப்பு தேவை. இன்று இரண்டு அம்சங்கள் அந்தப் பங்கை நிறைவேற்றுகின்றன.

llms.txt என்பது, அந்த முன்மொழிவின் சொந்த வார்த்தைகளில், “inference நேரத்தில் ஓர் இணையதளத்தை LLM-கள் பயன்படுத்த உதவும் தகவலை வழங்க /llms.txt கோப்பைப் பயன்படுத்துவதைத் தரப்படுத்துவதற்கான முன்மொழிவு”. இது robots.txt போன்ற அதே கருத்து; ஆனால் crawler எதை index செய்யலாம் என்று சொல்வதற்குப் பதிலாக, மொழி மாதிரிக்கு ஒரு தளம் என்ன, அதை எவ்வாறு பயன்படுத்துவது என்று சொல்கிறது. ஒரு ரெஜிஸ்ட்ரார் அத்தகைய கோப்பை வெளியிடும்போது அது எப்படி இருக்கும் என்பதை அறிய, டொமைன்களுக்கான llms.txt: எந்த AI முகவரும் படிக்கக்கூடிய API என்பதைப் பாருங்கள்.

MCP (Model Context Protocol) இதை ஒட்டிய இன்னொரு சிக்கலைத் தீர்க்கிறது: இது “AI பயன்பாடுகளை வெளிப்புற அமைப்புகளுடன் இணைப்பதற்கான open-source தரநிலை”. llms.txt என்பது ஒரு முகவர் திசையறிய ஒருமுறை படிக்கும் ஆவணம்; MCP என்பது அழைக்கக்கூடிய குறிப்பிட்ட tools தொகுப்பை வழங்கும் server-உடன் முகவரின் client திறக்கும் நேரடி இணைப்பு. இவை ஒன்றுக்கொன்று துணையானவை; போட்டியானவை அல்ல: ஒரு ரெஜிஸ்ட்ரார் இருப்பதையும், அது தோராயமாக என்ன செய்ய முடியும் என்பதையும் முகவர் அறிய llms.txt உதவுகிறது; முகவரின் client உண்மையில் இணைந்து செயல்பாடுகளை அழைக்க MCP உதவுகிறது.

Namefi இரண்டையும் வெளியிடுகிறது. namefi.io/llms.txt-இல் உள்ள நுழைவுப் பக்கம், api.namefi.io/mcp-இல் உள்ள MCP server, namefi.io/.well-known/mcp/servers.json-இல் உள்ள MCP discovery file, wallet வழி பணம் செலுத்துதல் மற்றும் வெளிச்செல்லும் முகவர் workflow-களுக்கான துணைக் கோப்புகளுடன் கூடிய முழுமையான REST reference ஆகியவற்றை ஆவணப்படுத்துகிறது. இரண்டு முன்னணி நிறுவனங்களை நேரடியாகச் சரிபார்த்தபோது: Cloudflare-இன் ரெஜிஸ்ட்ரார் ஆவணங்கள் தங்களின் llms.txt-ஐ developers.cloudflare.com/registrar/llms.txt-இல் வெளியிடுகின்றன; ஆனால் ரெஜிஸ்ட்ரார் தயாரிப்புக்கென தனிப்பட்ட MCP server-ஐ Cloudflare இயக்குவதாக அதன் பொது ஆவணங்களில் எதுவும் கூறவில்லை — செய்தி அறிக்கையின்படி, இந்த beta-வின் வாக்குறுதி “டெவலப்பர்கள் ஏற்கெனவே செயல்படும் tools-க்குள்ளேயே இயங்குமாறு இந்த API வடிவமைக்கப்பட்டுள்ளது: Cursor, Claude Code போன்ற MCP ஆதரவு கொண்ட code editor-கள்” என்பதே; இது குறுகிய வரம்புடையது — editor-க்கு MCP திறன் உள்ளது, Cloudflare-இன் ரெஜிஸ்ட்ராருக்கே அது இருக்கவேண்டும் என்பதில்லை. நேரடியாகச் சரிபார்க்கப்பட்ட GoDaddy-இன் developer portal, மனித டெவலப்பருக்கான REST endpoints-ஐ ஆவணப்படுத்துகிறது; இந்தக் கட்டுரை எழுதப்படும் நேரத்தில் llms.txt அல்லது MCP server குறிப்பு எதையும் காட்டவில்லை.

பணம் செலுத்துதல்: சேமிக்கப்பட்ட அட்டை ஏன் முகவர்களுக்குப் பொருந்தாது, அதற்குப் பதிலாக எது வருகிறது

மனிதரைச் செயல்முறையிலிருந்து நீக்குவது மிகக் கடினமான இடம் வாங்குதல் படிதான். ஏனெனில் நுகர்வோர் இணையப் பணப்பரிவர்த்தனை அமைப்பு ஒரு நபரை மையமாகக் கொண்டு உருவாக்கப்பட்டது: சேமிக்கப்பட்ட அட்டை, billing address, சில நேரங்களில் மனிதர் அல்லாத எதையும் வடிகட்டவே வடிவமைக்கப்பட்ட CAPTCHA. ஒரு முகவரால் அட்டைப் படிவத்தை நிரப்ப முடியாது; தொழில்நுட்ப ரீதியாக முடிந்தாலும், மனிதரைப் போல நடிப்பதற்காக அவரின் மூல அட்டை எண்ணை முகவரிடம் கொடுப்பது மோசமான பாதுகாப்பு முறை.

இரண்டு மாற்று முறைகள் பயன்பாட்டுக்கு வந்துள்ளன. முதலாவது API-key billing: ரெஜிஸ்ட்ரார் முன்கூட்டியே நிதியளிக்கப்பட்ட அல்லது invoice செய்யப்படும் கணக்குடன் இணைக்கப்பட்ட credential-ஐ வழங்குகிறார்; அட்டைக்குப் பதிலாக ஒவ்வொரு call-ஐயும் அந்த key மூலம் முகவர் authenticate செய்கிறது. namefi.io/api-key-இல் இந்த key-ஐ உருவாக்கி, ஒவ்வொரு request-இலும் அதை x-api-key header ஆக அனுப்புவதை Namefi-இன் ஆவணங்கள் விவரிக்கின்றன — browser session-உம் அட்டைப் படிவமும் தேவையில்லை. Cloudflare-இன் .ai விலை நிர்ணயமும் அதே அடக்க விலை அணுகுமுறையைப் பின்பற்றுகிறது: கூடுதல் விலை உயர்வு எதுவுமின்றி, “.ai டொமைன் பதிவுகளையும் புதுப்பிப்புகளையும் மொத்த விலையில்” வழங்குகிறது — விளம்பரச் சலுகைக்கேற்ப மாறும் விலையைவிட, நிலையானதும் முன்கூட்டியே கணிக்கக்கூடியதுமான விலையை ஒரு முகவர் எளிதாகப் புரிந்துகொள்ள முடியும்.

இரண்டாவது மாற்று wallet கையொப்பமிட்ட பணம் செலுத்துதல்; இது அட்டையை மட்டுமல்ல, கணக்கையே தேவையற்றதாக்குகிறது. HTTP 402 status code மற்றும் x402 முறையின் மேல் கட்டமைக்கப்பட்ட ஓர் இயக்கத்தை Namefi-இன் web3 ஆவணங்கள் விவரிக்கின்றன: பணம் செலுத்தாமல் ஒரு டொமைனைக் கோரும் request-க்கு 402 response-இல் விலைத் தகவல் வரும்; அழைப்பவரின் wallet ஓர் EIP-3009 authorization-இல் கையொப்பமிடும்; கையொப்பமிட்ட authorization-ஐ header ஆக மீண்டும் அனுப்பி, பதிவையும் settlement-ஐயும் ஒரே படியில் முடிக்கலாம் — வெளிப்படையாகவே “Namefi account அல்லது EIP-712 signing தேவையில்லை”. இங்கு கவனிக்க வேண்டிய கருத்து குறுகியது — சேமிக்கப்பட்ட credit card-ஆல் கட்டமைப்பிலேயே முடியாத ஒன்றான, software தானாக வைத்துப் பயன்படுத்தக்கூடிய பணம் செலுத்தும் முறை இது. முழு இயக்கத்தையும் தொடக்கம் முதல் முடிவு வரை அறிய, கிரிப்டோ wallet மூலம் டொமைன்களுக்கு பணம் செலுத்துங்கள்: கணக்கு தேவையில்லை என்பதைப் பாருங்கள்.

கொள்கைக் கட்டுப்பாடுகள்: முழுத் துறையும் இன்னும் தீர்க்காத அம்சம்

இது உண்மையான குறைபாடு. கண்டறியும் வசதி, இயந்திரம் வாசிக்கக்கூடிய ஆவணங்கள், கட்டமைக்கப்பட்ட பிழைகள், நிரலாக்க முறையிலான பணம் செலுத்துதல் ஆகியவற்றை ஒரு ரெஜிஸ்ட்ரார் ஒருமுறை உருவாக்கி வெளியிடலாம். ஆனால் கொள்கைக் கட்டுப்பாடுகள் — செலவு உச்சவரம்புகள், ஒரு வரம்புக்கு மேல் உறுதிப்படுத்தல் படி, குறிப்பிட்ட ஒரு TLD அல்லது budget-க்கு வரையறுக்கப்பட்ட key — வேறுபட்டவை; ஏனெனில் API-ஐ எளிதாகப் பயன்படுத்த உதவுவதற்குப் பதிலாக, அதிகாரத்தை ஒப்படைத்த மனிதரை அவை பாதுகாக்கின்றன.

மிகவும் சரிபார்க்கக்கூடிய எடுத்துக்காட்டான Namefi-இன் சொந்த ஆவணங்களைப் பார்த்தபோது: சில செயல்பாடுகள் முக்கிய விளைவுகளை ஏற்படுத்துபவை என்று அது குறிக்கிறது; மேலும் கட்டமைக்கப்பட்ட, இயந்திரம் வாசிக்கக்கூடிய பிழைகளை (நிலையான codes, retryable flag, கட்டமைக்கப்பட்ட விவரம்) ஆவணப்படுத்துகிறது — இந்த அம்சத்தில் அது உண்மையான முன்னேற்றம். ஆனால் இந்தக் கட்டுரை எழுதப்படும் நேரத்தில், பொது API reference-இல் ஆவணப்படுத்தப்பட்ட செலவு-உச்சவரம்பு primitive-ஐயோ server-side confirmation gate-ஐயோ நாங்கள் காணவில்லை; இப்போது அந்தப் பாதுகாப்பு ஒரு படி மேலே, மனிதர் MCP client-இல் அமைக்கும் கொள்கையில்தான் உள்ளது. Cloudflare அல்லது Name.com-இன் ரெஜிஸ்ட்ரார் API-களிலும் செலவு-உச்சவரம்பு primitive குறித்த பொது ஆவணத்தை நாங்கள் காணவில்லை — ஒவ்வொரு முகவர்-நேட்டிவ் ரெஜிஸ்ட்ராரும் அடுத்ததாகத் தீர்க்கும் என்று எதிர்பார்க்க வேண்டிய அம்சம் இதுதான்.

இன்றைய தளங்களைச் சரிபார்ப்புப் பட்டியலின்படி மதிப்பிடுதல்

விளம்பர உரைகளைச் சார்ந்திருக்காமல், ஒவ்வொரு தளத்தின் சொந்த நேரடி ஆவணங்களுடன் நாங்கள் சரிபார்த்தவற்றின் அடிப்படையில், இந்தத் துறையில் அதிகம் குறிப்பிடப்படும் மூன்று தளங்கள் ஆறு அம்சப் பட்டியலில் பெறும் மதிப்பீடு இதோ:

அனைத்துத் தளங்களிலும் இன்னும் நிறைவேறாமல் இருக்கும் ஒரே அம்சம் — கொள்கைக் கட்டுப்பாடுகள் — எந்த ஒரு தளத்தையும் குறை கூறுவது அல்ல; அது உண்மையான, துறை முழுவதற்குமான இடைவெளி. இந்தத் துறை வளரும்போது அதை மீண்டும் சரிபார்ப்பது பயனுள்ளதாக இருக்கும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

முகவர்-நேட்டிவ் டொமைன் ரெஜிஸ்ட்ரார் என்றால் என்ன?

ஒரு AI முகவர் எந்த browser-உம் இல்லாமல், மனிதர் முன்கூட்டியே ஆவணங்களைப் படிக்காமல், ஒருவர் அட்டை எண்ணை உள்ளிடாமல், தானாகவே கண்டறிந்து, புரிந்துகொண்டு, பரிவர்த்தனை செய்யக்கூடிய ரெஜிஸ்ட்ராரே முகவர்-நேட்டிவ் ரெஜிஸ்ட்ரார். கண்டறியும் வசதி (llms.txt கோப்பு அல்லது MCP server), இயல்பான மொழி ஆவணங்கள், இயந்திரம் வாசிக்கக்கூடிய பிழைகள், browser இல்லாத வாங்குதல், நிரலாக்க முறையிலான பணம் செலுத்துதல் ஆகியவற்றில் அது “ஆம்” என மதிப்பெடுக்கும்; கொள்கைக் கட்டுப்பாடுகள் (செலவு உச்சவரம்புகள், உறுதிப்படுத்தல் தடுப்புகள்) மட்டும் இந்தத் துறை இன்னும் உருவாக்கி வரும் அம்சமாக உள்ளது.

சாதாரண ரெஜிஸ்ட்ரார் API-களை AI முகவர்களால் ஏன் பயன்படுத்த முடியாது?

தொழில்நுட்ப ரீதியாக அவற்றின் endpoints-ஐ அவற்றால் அழைக்க முடியும். ஆனால் பெரும்பாலான ரெஜிஸ்ட்ரார் API-கள், ஒரு மனித டெவலப்பர் ஆவணங்களை ஏற்கெனவே படித்து, ஒருங்கிணைப்புக் குறியீட்டை முன்கூட்டியே எழுதியிருப்பார் என்று கருதுகின்றன. முன் ஒருங்கிணைப்பு இல்லாத முகவருக்கு base URL-ஐக் கண்டறியவோ, auth முறையை அறியவோ, உரை வடிவிலான பிழைச் செய்தியைப் புரிந்துகொள்ளவோ நிலையான வழி இல்லை — ஒரு மனிதர் அந்தப் பொருளுணரும் பணியை ஏற்கெனவே செய்திருப்பதால்தான் API இயங்குகிறது; புதிதாகத் தொடங்கும் முகவருக்கு அது தானாகப் புரியக்கூடியதாக இருப்பதால் அல்ல.

llms.txt-க்கும் MCP-க்கும் என்ன வேறுபாடு?

llms.txt என்பது ஒரு தளம் அல்லது API என்ன, அதை எவ்வாறு பயன்படுத்துவது என்பதை அறிய முகவர் ஒருமுறை படிக்கும் plain-text கோப்பு — crawler-களுக்கு robots.txt ஆற்றும் அதே பங்கு, ஆனால் மொழி மாதிரிகளுக்காக எழுதப்பட்டது. MCP என்பது அழைக்கக்கூடிய tools-ஐ வழங்கும் server-உடன் முகவரின் client திறக்கும் நேரடி protocol இணைப்பு. இவை ஒன்றுக்கொன்று துணையானவை: llms.txt கண்டறிதலுக்கானது; MCP என்பது செயல்பட முகவர் பயன்படுத்தும் இணைப்பு. கண்டறிதல் பகுதியைப் பற்றி மேலும் அறிய, டொமைன்களுக்கான llms.txt: எந்த AI முகவரும் படிக்கக்கூடிய API என்பதைப் பாருங்கள்.

எனது சொந்த API-ஐ முகவர்கள் பயன்படுத்தத்தக்கதாக எவ்வாறு மாற்றுவது?

உங்கள் API-ஐ மாதிரிகளுக்கு விவரிக்கும் llms.txt-ஐ வெளியிடுங்கள்; MCP server ஒன்றை வழங்குங்கள் (அல்லது குறைந்தபட்சம் OpenAPI ஆவணப்படுத்தப்பட்ட endpoints-ஐ வழங்குங்கள்); உரைக்குப் பதிலாக நிலையான codes உடன் கட்டமைக்கப்பட்ட பிழைகளைத் திருப்புங்கள்; hosted checkout பக்கம் இல்லாமல் தரவை மாற்றும் ஒவ்வொரு செயல்பாடும் முடியுமாறு உறுதிசெய்யுங்கள்; மனிதரின் அட்டையைச் சாராத பணம் செலுத்தும் முறையை ஆதரியுங்கள்; credentials வைத்திருப்பவர் முகவருக்கு அனுமதிக்கப்பட்ட செயல்களின் எல்லையை வரையறுக்கச் செலவு அல்லது உறுதிப்படுத்தல் வரம்புகளைச் சேருங்கள்.

Namefi முகவர்-நேட்டிவ் தளமா?

மேலுள்ள சரிபார்ப்புப் பட்டியலின்படி, நேரடியாகச் சரிபார்க்கப்பட்ட ஆறு அம்சங்களில் ஐந்தில் Namefi “ஆம்” என மதிப்பெடுக்கிறது: அது llms.txt கோப்புத் தொகுப்பையும் MCP server-ஐயும் வெளியிடுகிறது; முகவர்கள் பயன்படுத்துவதற்கேற்ப அதன் ஆவணங்கள் கட்டமைக்கப்பட்டுள்ளன; அதன் outbound API கட்டமைக்கப்பட்ட, இயந்திரம் வாசிக்கக்கூடிய பிழைகளைத் திருப்புகிறது; dashboard தேவையின்றி API அல்லது x402 சார்ந்த wallet இயக்கம் வழியாகவே பதிவு முழுமையாக முடிகிறது; கணக்கு தேவையின்றி API key அல்லது wallet கையொப்பமிட்ட பரிவர்த்தனை மூலம் பணம் செலுத்தலாம். பொது API reference-இல் கொள்கைக் கட்டுப்பாடுகள் இன்னும் ஆவணப்படுத்தப்படவில்லை; தற்போது அந்தக் கட்டுப்பாடு client தரப்பில்தான் உள்ளது.

MCP server இருந்தாலே ஒரு ரெஜிஸ்ட்ரார் தானாக முகவர்-நேட்டிவ் ஆகிவிடுமா?

இல்லை. MCP ஆதரவு கண்டறியும் வசதியையும் browser இல்லாத வாங்குதலையும் நிறைவேற்றுகிறது. ஆனால் ஒரு ரெஜிஸ்ட்ரார் MCP server-ஐ வழங்கியும் கட்டமைக்கப்படாத பிழைகளைத் திருப்பலாம், சேமித்த அட்டையை இன்னும் கோரலாம் அல்லது செலவு-உச்சவரம்பு அமைப்பே இல்லாமல் இருக்கலாம். முகவர்-நேட்டிவ் என்பது முழுச் சரிபார்ப்புப் பட்டியல்; அதில் எந்த ஒரு அம்சமும் மட்டும் அல்ல.

ஆதாரங்களும் மேலதிக வாசிப்பும்

• Wikipedia — Extensible Provisioning Protocol (EPP, மார்ச் 2004-இல் முன்மொழியப்பட்ட தரநிலை நிலையைப் பெற்றது)
• CircleID — 2026-இல் டொமைன் உலகம்: AI, பாதுகாப்பு, சந்தை முதிர்ச்சி மற்றும் புதிய gTLD எல்லை (“AI முகவர்கள் அதிகளவில் டொமைன் மறுவிற்பனையாளர்களாகச் செயல்படுகின்றன...”)
• webhosting.today — AI முகவர்கள் இப்போது மனித உதவியின்றி டொமைன்களைப் பதிவுசெய்யலாம் (Cloudflare Registrar API beta, ஏப்ரல் 2026)
• Name.com — முதல் AI-நேட்டிவ் டொமைன் தளம் (“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 server குறிப்பு — இந்தக் கட்டுரையில் உள்ள Namefi தயாரிப்பு குறித்த கூற்றுகளுக்கான முதன்மை ஆதாரம்)
• Namefi — namefi.io/web3/llms.txt (wallet கையொப்பமிட்ட / x402 பணம் செலுத்தும் இயக்கம், “Namefi account அல்லது EIP-712 signing தேவையில்லை”)