டொமைன்களுக்கான llms.txt: எந்த AI முகவரும் படிக்கக்கூடிய API
namefi.io/llms.txt பற்றிய விரிவான விளக்கம்: ஓர் எளிய உரைக் கோப்பு, எந்த AI முகவரும் ஒரு ரெஜிஸ்ட்ராரின் முழு API-ஐக் கண்டறிந்து பயன்படுத்த எவ்வாறு உதவுகிறது, மேலும் அது MCP-உடன் எவ்வாறு இணைந்து செயல்படுகிறது.
- ai-agents
- domains
- explainer
API கொண்ட ஒவ்வொரு ரெஜிஸ்ட்ராருக்கும் அதன் ஆவணங்கள் எங்காவது இருக்கும்: ஓர் ஆவணத் தளம், ஒரு குறிப்புப் பக்கம், அல்லது உள்நுழைவுச் சுவருக்குப் பின்னால் இருக்கும் OpenAPI விவரக்குறிப்பு. இருபது ஆண்டுகளாக இது போதுமானதாக இருந்தது. ஏனெனில் அதைப் படித்தவர் ஒரு மனித டெவலப்பர்; அவர் இணைப்புகளைத் திறந்து, வழிசெலுத்தல் கூறுகளைத் தாண்டி விரைவாகப் பார்த்து, தனக்குத் தேவையான அந்த ஒரு பத்தியைக் கண்டுபிடிக்க முடியும். ஆனால் inference நேரத்தில் அதே தளத்தைப் படிக்கும் ஓர் AI முகவருக்கு அந்த வசதி இல்லை — வரையறுக்கப்பட்ட context அளவு, JavaScript மூலம் render செய்யப்படும் ஆவணத் தளத்துக்காகக் காத்திருக்க நேரமின்மை, API என்ன செய்கிறது என்பதை ஒரே முயற்சியில் புரிந்துகொள்ள வேண்டிய கட்டாயம். இல்லையெனில் அது முயற்சியைக் கைவிடலாம் அல்லது இல்லாத endpoint ஒன்றைக் கற்பனை செய்துவிடலாம்.
இந்தச் சிக்கலுக்கான தீர்வே llms.txt; Namefi தனது கோப்பை namefi.io/llms.txt-ல் வெளியிடுகிறது. அந்த வழக்கம் என்ன, அது ஏன் உருவானது, எங்கள் கோப்பில் ஒவ்வொரு பகுதியாக என்ன உள்ளது, அது எங்கு திட்டமிட்டு நிறுத்துகிறது, மேலும் Model Context Protocol (MCP)-உடன் போட்டியிடாமல் அதற்கு இணையாக எவ்வாறு செயல்படுகிறது என்பவற்றை இந்தக் கட்டுரை விளக்குகிறது. இது விவரிக்கும் விஷயத்திற்கே ஓர் எடுத்துக்காட்டாகவும் திட்டமிட்டு எழுதப்பட்டுள்ளது: ஒரு பொது API வழங்குநர், இயந்திரம் படிக்கக்கூடிய தனது கண்டறிதல் கோப்பைப் பற்றி எளிய உரைநடையில் விளக்குகிறார்.
முகவர்கள் ஏன் உங்கள் ஆவணத் தளத்தை அப்படியே crawl செய்ய முடியாது?
llms.txt-க்கான காரணம் ஊகம் அல்ல — அதன் முன்மொழிவிலேயே அது நேரடியாகக் கூறப்பட்டுள்ளது. Jeremy Howard-ன் அசல் விளக்கம், இதை உருவாக்கத் தூண்டிய கட்டுப்பாட்டிலிருந்து தொடங்குகிறது: “பெரிய மொழி மாதிரிகள் இணையதளத் தகவல்களை மேலும் மேலும் சார்ந்திருக்கின்றன. ஆனால் அவை ஒரு முக்கியமான வரம்பை எதிர்கொள்கின்றன: பெரும்பாலான இணையதளங்களை முழுமையாகக் கையாள அவற்றின் context window-கள் மிகச் சிறியவை. வழிசெலுத்தல், விளம்பரங்கள், JavaScript ஆகியவற்றைக் கொண்ட சிக்கலான HTML பக்கங்களை LLM-க்கு ஏற்ற எளிய உரையாக மாற்றுவது கடினமும் துல்லியமற்றதுமாகும்.”
இங்கு இரண்டு சிக்கல்கள் ஒன்றின் மேல் ஒன்று சேர்ந்துள்ளன. உண்மையான ஓர் ஆவணத் தளத்தில் இருக்கும் வழிசெலுத்தல், மாற்றப் பதிவு, சந்தைப்படுத்தல் உரை, cookie அறிவிப்பு ஆகியவற்றில் பெரும்பாலானவை, ஒரு பணிக்காக முகவருக்குத் தேவையான சில பத்திகளுடன் ஒப்பிடும்போது தேவையற்ற இரைச்சலே. மேலும் அந்த இரைச்சலின் பெரும்பகுதி JavaScript-க்குப் பின்னால் இருக்கும்; headless fetch அதை இயக்காது. ஆகவே முகவரின் HTTP client காண்பது, மனிதர் காணும் பக்கமாகக்கூட இருப்பதில்லை. llms.txt இரு சிக்கல்களையும் தவிர்க்கிறது: crawl செய்து சுருக்குவதற்குப் பதிலாக முழுமையாகப் படிக்கப்பட வேண்டிய, ஒரே எளிய உரை Markdown கோப்பு.
robots.txt ஒப்புமையும் அது பொருந்தாத இடமும்
இணையக் கட்டமைப்பை அறிந்த ஒருவருக்கு llms.txt-ஐ விரைவாகப் புரியவைக்க robots.txt-உடன் ஒப்பிடலாம்; ஓர் அளவுவரை அது பொருத்தமானதும் கூட. வலை crawler-களுக்கு அறிவுறுத்தல்களை வழங்கவே robots.txt உள்ளது — அந்தத் தளத்தின் சொற்களில், “தங்களது தளத்தைப் பற்றி web robot-களுக்கு அறிவுறுத்துவதற்கு இணையதள உரிமையாளர்கள் /robots.txt கோப்பைப் பயன்படுத்துகிறார்கள்; இதற்கு The Robots Exclusion Protocol என்று பெயர்.” இரண்டு கோப்புகளும் முன்கூட்டியே அறியக்கூடிய root பாதையில் உள்ளன, இரண்டும் எளிய உரை, இரண்டுமே மனிதர்களுக்குப் பதிலாக தானியங்கி வாசிப்பவர்களை நோக்கமாகக் கொண்டவை.
ஆனால் அவற்றின் நோக்கத்தில் இந்த ஒப்புமை பொருந்தாது. robots.txt பெரும்பாலும் எதிர்மறையான அறிவுறுத்தல் — Disallow: /some-path என்பது crawler எதைத் தொடக்கூடாது என்று கூறுகிறது. llms.txt நேர்மறையானது: இந்தத் தளம் என்ன, இதில் படிக்கத் தகுந்த பகுதிகள் எங்கே உள்ளன என்பதைக் கூறுகிறது. முழுப் புத்தகத்தையும் விரைவாகப் புரட்டிப் பார்க்க முடியாத வாசகருக்கு இது வேலியைவிட உள்ளடக்க அட்டவணையைப் போன்றது. இரண்டும் ஒன்றுக்கொன்று துணையானவை; Namefi தளத்தில் இரண்டுமே செயல்படுகின்றன.
விவரக்குறிப்பு உண்மையில் என்ன கோருகிறது?
llms.txt கட்டுப்பாடற்ற வடிவமல்ல. அதன் முன்மொழிவு குறிப்பிட்ட Markdown கட்டமைப்பை இந்த வரிசையில் வரையறுக்கிறது: விருப்பமான byte-order mark, தளத்தின் பெயரைக் கொண்ட கட்டாய H1, blockquote வடிவிலான சுருக்கம், தலைப்பில்லாத பூஜ்ஜியம் அல்லது அதற்கு மேற்பட்ட விவரப் பகுதிகள், மேலும் [name](url): notes இணைப்புகளைக் கொண்ட H2-ஆல் பிரிக்கப்பட்ட பூஜ்ஜியம் அல்லது அதற்கு மேற்பட்ட “கோப்புப் பட்டியல்” பகுதிகள். ஒரு H2 தலைப்புக்கு மட்டும் சிறப்புப் பொருள் உள்ளது: Optional என்ற பகுதி, “உங்களுக்கு இன்னும் குறுகிய context தேவைப்பட்டால் இங்குள்ள URL-களைத் தவிர்க்கலாம்” என்பதைக் குறிக்கிறது. Namefi-ன் கோப்பும் இதே தலைப்பை, விவரக்குறிப்பு கூறும் அதே பொருளில் பயன்படுத்துகிறது.
namefi.io/llms.txt கோப்பின் ஒவ்வொரு பகுதியும்
Namefi-ன் API மற்றும் அங்கீகார விருப்பங்கள் வளரும்போது இந்தக் கோப்பும் மாறுகிறது. கீழுள்ள அட்டவணை 2026-07-14 அன்று சரிபார்க்கப்பட்ட சுருக்கமான snapshot; செயல்படுவதற்கு முன் முகவர்கள் தற்போதைய நேரடிக் கோப்பை fetch செய்ய வேண்டும்.
| கோப்பில் தோன்றும் பகுதி | அதில் கூறப்படுவது | ஏன் இவ்வாறு அமைக்கப்பட்டுள்ளது? |
|---|---|---|
| H1 + blockquote | # Namefi API / > Namefi lets you register traditional domains as NFTs and manage their DNS records via API. | விவரக்குறிப்பு கோரும் கட்டாயத் தொடக்கம் — வேறு எதையும் படிக்காவிட்டாலும் முகவர் செயல்பட உதவும் ஒரே வரி. |
| சுருக்கத்துக்குள் உள்ள MCP சுட்டி | MCP server (every operation below as MCP tools): https://api.namefi.io/mcp — discovery descriptor at https://namefi.io/.well-known/mcp/servers.json | எளிய உரை வழிக்கு முன்னதாக, நேரடி protocol இணைப்பான அதிவேகப் பாதையை முதல் மூன்று வரிகளிலேயே வைக்கிறது. |
## Base URLs | https://api.namefi.io/v-next/ | ஒரே வரி, விளக்க உரை இல்லை — raw HTTP call-களை உருவாக்கும் முகவருக்கு இதுதான் துல்லியமாகத் தேவை. |
## Agent policy (mandatory) | client-ஆல் இணைக்க முடிந்தால் MCP-க்கு முன்னுரிமை கொடுக்க வேண்டும்; MCP கிடைக்காதபோது, நிறுவல் தோல்வியடைந்தபோது அல்லது raw HTTP-ஐப் பயனர் வெளிப்படையாகக் கோரும்போது மட்டுமே REST அல்லது curl பயன்படுத்த வேண்டும் | திறனுள்ள முகவர்களை வகையறுக்கப்பட்ட MCP பாதையில் வைத்திருப்பதோடு, தெளிவான REST மாற்று வழியையும் பாதுகாக்கிறது. |
## MCP Server (for AI agents) | https://api.namefi.io/mcp-உடன் இணைய வேண்டும்; வாசிப்புச் செயல்களுக்கான கருவிகளுக்கு அங்கீகாரம் தேவையில்லை; API key இல்லையெனில் OAuth 2.1 + PKCE பயன்படுத்தலாம், இல்லையெனில் ஏற்கெனவே உள்ள key-ஐ x-api-key-ல் அனுப்பலாம் | ஒவ்வொரு முகவரிடமும் ஏற்கெனவே சேமிக்கப்பட்ட secret உள்ளது என்று கருதாமல், browser மூலம் அங்கீகரிக்கப்படும் OAuth பாதையையும் API-key பாதையையும் ஆவணப்படுத்துகிறது. |
## Authentication | API key-கள் x-api-key மூலம் செயல்படும்; ஒவ்வொரு /v-next endpoint-உம் OAuth bearer token-ஐயும் ஏற்கிறது. headless client-களுக்கான device authorization, redirect செய்யக்கூடிய app-களுக்கான authorization code + PKCE, dynamic client registration, access-token ஆயுட்காலம், சுழற்சி முறையிலான refresh token-கள் ஆகியவற்றை இந்தக் கோப்பு ஆவணப்படுத்துகிறது | அங்கீகாரம் இனி API-key மட்டும் சார்ந்ததல்ல; நேரடி REST caller-களும் MCP இல்லாமல் OAuth பயன்படுத்தலாம். |
## Buy a domain (MCP-first happy path) மற்றும் REST மாற்று வழி | MCP-உடன் இணைந்து, வகையறுக்கப்பட்ட கருவிகளால் தேடி, பதிவுசெய்து, நிலையை poll செய்ய வேண்டும்; MCP கிடைக்காவிட்டால் ஆவணப்படுத்தப்பட்ட மூன்று-படி curl தொடரைப் பயன்படுத்த வேண்டும் | விருப்பமான கருவிப் பாதையையும் raw-HTTP மாற்று வழியையும் நீக்காமல், இரண்டையும் தெளிவாகப் பிரிக்கிறது. |
## DNS Record Management | /v-next/dns/records, /v-next/dns/park, /v-next/dns/forwarding போன்றவற்றில் செய்யப்படும் பதினொரு endpoint-களின் (GET/POST/PUT/DELETE) method, path, auth மற்றும் ஒரு-வரி விளக்கத்தைக் கொண்ட அட்டவணை | ஒரே மாதிரியான பல endpoint-களைக் குறிக்கும் குறிப்புத் தரவு பதினொரு பத்திகளுக்குப் பதிலாக அட்டவணையில் வழங்கப்படுகிறது. |
| சிக்கல் தீர்க்கும் குறிப்பு | “UNAUTHORIZED (401): Your API key is invalid, expired, or not associated with the domain owner's wallet… Record validation errors: Check that zoneName has no trailing dot, rdata for CNAME/MX/NS types has a trailing dot…” | முகவர் முதலில் சந்திக்கக்கூடிய தோல்விகளைப் பொதுவான status அட்டவணையாக அல்லாமல், காரணமும் தீர்வும் சேர்ந்த வடிவில் முன்கூட்டியே விளக்குகிறது. |
## Optional | TypeScript SDK ஆவணங்கள், @namefi/api-client npm package, இயந்திரம் படிக்கக்கூடிய OpenAPI 3 விவரக்குறிப்பு, outbound-agent வழிகாட்டி, signer சார்பற்ற உதவி script-களைக் கொண்ட GitHub repo ஆகியவற்றுக்கான இணைப்புகள் | “குறுகிய context தேவைப்பட்டால் இதைத் தவிர்க்கலாம்” என்ற விவரக்குறிப்பின் சொந்தப் பகுதி — அடிப்படைச் செயல்முறைக்கு முன்நிபந்தனைகள் அல்லாத ஆழமான ஆதாரங்கள். |
கோப்பின் இறுதியில் namefi.io/llms-full.txt சுட்டப்படுகிறது. root கோப்பு இணைப்புகளாக மட்டும் வழங்கும் Web3 பணம் செலுத்தும் செயல்முறைகளையும் outbound வழிகாட்டியையும் உள்ளடக்கி, அதே உள்ளடக்கத்தை ஒரே ஆவணமாக அது வழங்குகிறது. இந்தப் பிரிப்பு விவரக்குறிப்பின் இரு-அடுக்கு முறையையே பிரதிபலிக்கிறது: entry point-ஐ context-க்குள் வசதியாகப் பொருந்தும் அளவு குறுகியதாக வைத்திருந்து, மேலும் தேவைப்படும் முகவர் ஒரே இணைப்பைப் பின்தொடரச் செய்வது.
துணைக் கோப்புகள்: Web3 மற்றும் MCP கண்டறிதல்
பொதுவான entry point-இல் சேராத API பகுதிகளுக்கான துணைக் கோப்புகளை root கோப்பு சுட்டுகிறது. API key-க்குப் பதிலாகப் பணப்பை வைத்திருக்கும் முகவருக்குத் தேவையான பணம் செலுத்தும் பாதைகளை namefi.io/web3/llms.txt ஆவணப்படுத்துகிறது: GET /x402/domain/{domainName} கோரிக்கைக்குக் கையொப்பமிட்ட X-PAYMENT header இணைக்கப்படும் வரை விலைத் தகவலுடன் 402 Payment Required திருப்பும் x402 செயல்முறை, mppx CLI மூலம் கையொப்பமிடப்படும் MPP (Machine Payable Protocol) சவால்-பதில் முறை, smart-contract பணப்பைகளை உள்ளடக்கும் manual EIP-712 கையொப்பமிடும் பாதை ஆகியவை அதில் உள்ளன. x402 பதிவு செய்ய “No Namefi account or EIP-712 signing required — the buyer's wallet signs an EIP-3009 transferWithAuthorization” என்று கோப்பு தெளிவாகக் கூறுகிறது. வழக்கமான MCP, OAuth அல்லது API-key பாதையைப் பயன்படுத்தும் முகவர் இந்தப் பணப்பை-பணம் செலுத்தும் வழிகாட்டியை ஏற்றத் தேவையில்லை.
MCP-க்கும் llms.txt-இலிருந்து முற்றிலும் தனியான தனது கண்டறிதல் கோப்பு உள்ளது: namefi.io/.well-known/mcp/servers.json. இது Markdown அல்ல, JSON விவரிப்பு. 2026-07-14 அன்று சரிபார்க்கப்பட்ட அதன் சுருக்கமான snapshot இதோ:
{
"servers": [
{
"name": "namefi-api",
"description": "Preferred interface for Namefi...",
"version": "next",
"transport": "streamable-http",
"url": "https://api.namefi.io/mcp",
"websiteUrl": "https://namefi.io",
"authentication": {
"type": "apiKey",
"in": "header",
"name": "x-api-key",
"description": "Read-only tools need no auth; prefer OAuth when no API key is available."
},
"oauth": {
"type": "oauth2",
"protectedResourceMetadata": "https://api.namefi.io/.well-known/oauth-protected-resource",
"authorizationServerMetadata": "https://api.namefi.io/.well-known/oauth-authorization-server",
"grantTypes": ["authorization_code", "refresh_token", "device_code"],
"codeChallengeMethods": ["S256"],
"dynamicClientRegistration": true
},
"documentation": "https://namefi.io/llms.txt"
}
]
}
இயந்திரம் கண்டறியக்கூடிய metadata-வை வெளியிட /.well-known/security.txt பயன்படுத்தும் அதே மரபின்படி, இந்த விவரிப்பு .well-known/-ன் கீழ் உள்ளது — llms.txt-ன் Markdown உரைநடை முறையைவிடக் குறுகிய நோக்கம் கொண்ட, JSON வகையிலான துணைக் கோப்பு. இது PKCE மற்றும் dynamic client registration உட்பட API-key மற்றும் OAuth கண்டறிதல் metadata இரண்டையும் அறிவிக்கிறது; அதன் documentation புலம் மீண்டும் llms.txt-ஐச் சுட்டுகிறது.
எவை சேர்க்கப்பட்டுள்ளன, எவை விடப்பட்டுள்ளன, ஏன்?
சில தேர்வுகள் திட்டமிட்டவை என்று தெளிவாகத் தெரிகிறது. REST செய்முறைகளுக்கு முன் கட்டாய முகவர் கொள்கையும் MCP அமைப்பும் வருகின்றன; எனவே திறனுள்ள client முதலில் வகையறுக்கப்பட்ட கருவி இடைமுகத்தைக் கண்டறிகிறது. MCP-உடன் இணைய முடியாத client-களுக்கும் raw HTTP-ஐ வெளிப்படையாகக் கோரும் பயனர்களுக்கும் மாற்று வழியாக இயக்கக்கூடிய curl எடுத்துக்காட்டுகள் தொடர்ந்து உள்ளன. root கோப்பு அனைத்தையும் சேர்க்காமல் இணைப்புகளை வழங்குகிறது; llms-full.txt துணைக் கோப்புகளின் உள்ளடக்கத்தை ஒரே இடத்தில் சேர்க்கிறது. ## Optional பகுதியில் Markdown-உடன் முழுமையான OpenAPI 3 விவரக்குறிப்பும் இணைக்கப்பட்டுள்ளது; பணப்பை சார்ந்த x402, MPP, EIP-712 பணம் செலுத்தும் செயல்முறைகள் தனிக் கோப்பிலேயே உள்ளன.
llms.txt மற்றும் MCP: கண்டறிதலும் இணைப்பும்
ஒவ்வொரு பகுதியும் என்ன செய்கிறது என்பதைத் துல்லியமாகப் புரிந்துகொள்வது முக்கியம். llms.txt ஓர் ஆவணம் — முகவர் அதை ஒருமுறை fetch செய்து, API என்ன, ஆழமான ஆதாரங்கள் எங்கே உள்ளன என்பவற்றை அறிந்துகொள்கிறது; அதன் தகவலை யாராவது செயல்படுத்தும் வரை அது செயலற்ற உரையே. protocol-ன் சொந்த விளக்கத்தில் MCP என்பது “AI பயன்பாடுகளை வெளிப்புற அமைப்புகளுடன் இணைப்பதற்கான திறந்த மூலத் தரநிலை” — client ஒன்று server-உடன் திறக்கும் நேரடி session; அதன்மூலம் அழைக்கக்கூடிய கருவிகளைப் பட்டியலிட்டு இயக்குகிறது.
Namefi-ன் கோப்பே இந்த உறவை நேரடியாகக் காட்டுகிறது: api.namefi.io/mcp-ல் MCP server இருப்பதை முகவருக்கு llms.txt தெரிவித்து, இணைவதற்கான claude mcp add கட்டளையையும் வழங்குகிறது. கோப்பைப் படித்ததும் நேரடிக் கருவி இடைமுகம் இருப்பதை அறிந்து, அதனுடன் இணைந்து செயல்படலாம். நேரடியாக MCP-க்குச் செல்லும் முகவரும் .well-known/mcp/servers.json மூலம் server-ஐக் கண்டறிய முடியும் — ஆனால் அந்த விவரிப்பின் documentation புலம் மீண்டும் llms.txt-ஐச் சுட்டுவதால், இரண்டும் உண்மையில் முற்றிலும் தனித்தனியாகச் செயல்படுவது அரிது.
பிற API வழங்குநர்களுக்கான வழிகாட்டுதல்
செயல்படும் llms.txt ஒன்றை வெளியிட உங்கள் ஆவணங்களை முழுவதும் புதிதாகக் கட்டமைக்க வேண்டியதில்லை:
- H1, சுருக்கம், அதிவேக இணைப்பு முறை ஆகியவற்றை முதலில் வையுங்கள் — சிறிய context கொண்ட முகவர் முதல் சில வரிகளுக்கு அப்பால் படிக்காமல் போகலாம்.
- ஆதரிக்கப்படும் அதிவேக இணைப்பை முதலில் காட்டி, இயக்கக்கூடிய மாற்று வழியை அடுத்ததாக வழங்குங்கள். MCP வழங்கினால் வகையறுக்கப்பட்ட பாதையை முதலில் ஆவணப்படுத்துங்கள்; அதனுடன் இணைய முடியாத client-களுக்குத் துல்லியமான HTTP எடுத்துக்காட்டுகளை வைத்திருங்கள்.
- குழுவின் அமைப்பின்படி அல்ல, அளவின்படி பிரியுங்கள். குறுகிய root கோப்பு, விரிவான முழுப் பதிப்பு, பணம் செலுத்துதல் போன்ற தனிக் கவலைகளுக்கான தனிக் கோப்புகள் ஆகியவை பொதுவான பாதையைக் குறுகியதாக வைத்திருக்கும்.
- status code-களை மட்டும் அல்ல, உண்மையான தோல்வி நிலைகளையும் ஆவணப்படுத்துங்கள் — ஒரு call ஏன் 401-ஐத் திருப்புகிறது, ஏன் 403-ஐத் திருப்புகிறது என்பது அந்த எண்களைவிட முக்கியம்.
- தவிர்க்கக்கூடிய எதற்கும் விவரக்குறிப்பின் மரபுப்படி
## Optionalதலைப்பைப் பயன்படுத்துங்கள். - MCP server இயக்கினால், llms.txt-உடன் MCP கண்டறிதல் விவரிப்பையும் வெளியிடுங்கள் — server URL-ஐ மட்டும் அல்லாமல், தற்போதைய அங்கீகாரம் மற்றும் OAuth கண்டறிதல் metadata-வையும் சேருங்கள்.
அடிக்கடி கேட்கப்படும் கேள்விகள்
llms.txt என்றால் என்ன?
ஓர் இணையதளத்தின் root-ல், அந்தத் தளம் அல்லது API என்ன, கூடுதல் விவரங்கள் எங்கே உள்ளன என்பவற்றை AI முகவருக்குத் தெரிவிக்கும் எளிய உரை Markdown கோப்பை வெளியிடுவதற்கான முன்மொழியப்பட்ட வழக்கம் — இது IETF அல்லது W3C-ன் அதிகாரப்பூர்வத் தரநிலை அல்ல. H1 தலைப்பு, blockquote சுருக்கம், விருப்பமான விவரப் பத்திகள், H2-ஆல் பிரிக்கப்பட்ட இணைப்புப் பட்டியல்கள் என்ற குறிப்பிட்ட வரிசையை இது வரையறுக்கிறது; தவிர்க்கக்கூடிய உள்ளடக்கத்திற்காக “Optional” தலைப்பு ஒதுக்கப்பட்டுள்ளது.
llms.txt, robots.txt-இலிருந்து எவ்வாறு வேறுபடுகிறது?
Robots Exclusion Protocol-ன் கீழ் வலை crawler-கள் எதை index செய்யக்கூடாது என்பதைக் கூறும் எதிர்மறையான அறிவுறுத்தலே robots.txt. ஒரு தளம் என்ன, அதில் படிக்கத் தகுந்தவை எவை என்பதைக் கூறும் நேர்மறையான அறிவுறுத்தலே llms.txt. அவை வெவ்வேறு தானியங்கி வாசிப்பவர்களுக்காக உருவாக்கப்பட்டவை; பொதுவாக ஒரே தளத்தில் இணைந்து செயல்படுகின்றன.
llms.txt, MCP-க்கு மாற்றாகுமா?
இல்லை. API என்ன செய்கிறது என்பதைப் புரிந்துகொள்ள முகவர் ஒருமுறை படிக்கும் ஆவணமே llms.txt; அந்த API-ன் செயல்பாடுகளை உண்மையில் அழைப்பதற்காக அதன் client திறக்கும் நேரடி protocol இணைப்பே MCP. Namefi இரண்டையும் வெளியிடுகிறது; MCP server இருப்பதை முகவருக்கு முதலில் தெரிவிப்பதும் llms.txt-தான்.
Namefi-ன் llms.txt கோப்பில் என்ன உள்ளது?
base URL, கட்டாயமான MCP-first முகவர் கொள்கை, MCP நிறுவல் எடுத்துக்காட்டுகள், API-key மற்றும் OAuth அங்கீகாரம், வகையறுக்கப்பட்ட டொமைன்-பதிவுப் பாதையும் REST மாற்று வழியும், DNS மற்றும் டொமைன்-அமைப்பு endpoint-கள், சிக்கல் தீர்க்கும் பகுதி, SDK, OpenAPI விவரக்குறிப்பு மற்றும் துணைக் கோப்புகளுக்கான இணைப்புகளைக் கொண்ட “Optional” பகுதி ஆகியவை உள்ளன.
AI முகவர் இல்லாமலும் llms.txt-ஐ நான் படிக்கலாமா?
ஆம் — இது எளிய Markdown; model மட்டுமல்ல, மனிதரும் படிக்கலாம். namefi.io/llms.txt சுருக்கமான API விரைவுக் குறிப்பைப் போலப் படிக்கிறது; ஒரு மனிதர் விரைவாகப் புரிந்துகொள்ள உதவும் அதே தெளிவு, model-ம் அதைச் சரியாகப் புரிந்துகொள்ள உதவுகிறது.
ஆதாரங்களும் மேலதிக வாசிப்பும்
- llmstxt.org — /llms.txt கோப்பு: பின்னணி, முன்மொழிவு மற்றும் வடிவ விவரக்குறிப்பு
- robotstxt.org — /robots.txt பற்றி: “சுருக்கமாக”
- modelcontextprotocol.io — Model Context Protocol (MCP) என்றால் என்ன?
- Namefi — namefi.io/llms.txt (இந்தக் கட்டுரையில் குறிக்கப்பட்ட ஒவ்வொரு பகுதியின் முதன்மை ஆதாரம்)
- Namefi — namefi.io/web3/llms.txt (x402, MPP மற்றும் EIP-712 பணப்பை-பணம் செலுத்தும் செயல்முறைகள்)
- Namefi — namefi.io/.well-known/mcp/servers.json (MCP கண்டறிதல் விவரிப்பு)
- Namefi — namefi.io/llms-full.txt (Web3 மற்றும் outbound துணைக் கோப்புகளை ஒரே இடத்தில் சேர்க்கும் முழுப் பதிப்பு)
- IETF — RFC 8615, Well-Known Uniform Resource Identifiers (
.well-known/மரபு)
கோப்பை நீங்களே படியுங்கள்
llms.txt-ஐப் புரிந்துகொள்ள அதிவேகமான வழி, ஒரு கோப்பைத் திறந்து படிப்பதுதான். namefi.io/llms.txt பொதுவாக அணுகக்கூடியது, அங்கீகாரம் தேவையில்லை, மேலும் இந்தக் கட்டுரையைப் படித்த நேரத்திற்குள் படித்து முடிக்கும் அளவுக்குக் குறுகியது — Namefi-உடன் இணையும் ஒவ்வொரு AI முகவரும் முதலில் படிக்கும் அதே கோப்பு. அதன் பின்னால் உள்ள MCP கருவிகள் உண்மையில் என்ன செய்கின்றன என்பதை அறிய Namefi MCP Server: AI முகவர்களுக்கான டொமைன் கருவிகள் கட்டுரையைப் பாருங்கள்; editor-இலிருந்து இணைவதற்கு MCP விரைவுத் தொடக்கம்; முகவர் முழுச் செயல்முறையையும் நடத்துவதைப் பார்ப்பதற்கு Namefi-ல் உங்கள் AI முகவர் மூலம் ஒரு டொமைனைப் பதிவுசெய்வது எப்படி கட்டுரையைப் படியுங்கள்.
பங்களிப்பாளர்கள்
Aileen Wright நியூயார்க் நகரில் வசிக்கும் இருபதுகளில் உள்ள மாணவி. அங்கு ஓர் அருங்காட்சியகச் சுவருக்கும் நூலக வாசிப்பறைக்கும் இடையிலான தூரம் ஒரு சிறிய நடைதான்; ஆனால் அது ஒரு நீண்ட பிற்பகலையும் நிறைக்கக்கூடும். கலை மற்றும் வரலாறு வழியாகவே அவர் பெயர்களைப் பற்றி எழுதத் தொடங்கினார்: ஓர் உருவப்படம், நாணயம் அல்லது கையெழுத்துப் பிரதியின் ஓரம் ஒரு பெயரைப் பல நூற்றாண்டுகள் கடந்து எடுத்துச் சென்று, வழியில் அதன் பொருளையும் மாற்றக்கூடும்.
பெரும்பாலான வாரங்களில், கையில் ஒரு மென் அட்டைப் புத்தகத்துடன் சென்ட்ரல் பார்க்கிலோ, பெயர்ப் பட்டியல் கூறும் பொருளை ஏற்றுக்கொள்ளாமல் ஒரு பெயரின் உண்மையான தோற்றத்தைத் தேடும் அமைதியான பொது வாசிப்பறையிலோ அவரைக் காணலாம். அவர் தானாகவே நிரலாக்கத்தையும் கற்றுவருகிறார். அதனால் எழுத்துக்கூட்டல், வரிசைப்படுத்தல், ஒரு பெயர் காலத்தை வென்று நிலைப்பதைத் தீர்மானிக்கும் சிறு விவரங்கள் ஆகியவற்றில் எதிர்பாராத அளவு துல்லியமானவராகியுள்ளார்.
Namefi-க்காக, டொமைன் பெயர்களுக்குப் பின்னுள்ள வரலாறும் பண்பாடும், பெயரை மாற்றும்போது பிராண்டுகள் தம்முடன் எடுத்துச் செல்லும் கதைகளும், ஒரு நல்ல கதைக்கும் சரிபார்க்கப்பட்ட ஆதாரத்துக்கும் உள்ள வேறுபாடும் குறித்து அவர் எழுதுகிறார்.
Victor Zhou டிஜிட்டல் அடையாளம் மற்றும் நம்பிக்கையில் கவனம் செலுத்தும் தொழில்நுட்ப நிறுவனர் மற்றும் தரநிலைத் தொகுப்பாசிரியர். Namefi-ஐ நிறுவிய அவர், Ethereum மேம்பாட்டு முன்மொழிவுகளைத் தொகுக்கிறார்; இதற்கு முன்பு Google Labs-இல் ஸ்மார்ட் கான்ட்ராக்ட் கட்டமைப்புப் பணியை வழிநடத்தினார்.
பெயரிடல், உரிமை, மக்கள் இணையத்தில் தங்கள் அடையாளத்தை நிலைநாட்டப் பயன்படுத்தும் அமைப்புகள் ஆகியவை சந்திக்கும் இடத்தில் அவரது பணி உள்ளது. பெயர்கள் தனிப்பட்ட பொருள், பொது அங்கீகாரம், டிஜிட்டல் உள்கட்டமைப்பு ஆகியவற்றுக்கு இடையே நகரும் விதத்தில் இந்தப் பார்வை அவருக்குச் சிறப்பு ஆர்வத்தை ஏற்படுத்துகிறது.
Namefi-க்காக, நீடித்த டிஜிட்டல் அடையாளமாக டொமைன்களைப் பற்றி Victor எழுதியும் தொகுத்தும் வருகிறார்: பெயர்கள் எவ்வாறு சொந்தமாக்கக்கூடிய ஆன்-செயின் சொத்துகளாகின்றன, டோக்கனைசேஷன் காவலையும் நம்பிக்கையையும் எவ்வாறு மாற்றுகிறது, இணையத்தில் அடையாளத்தை நிலைநாட்ட மக்கள் பயன்படுத்தும் அமைப்புகளிலிருந்து பெயரிடல் என்ன கற்றுக்கொள்ளலாம் ஆகியவற்றை அவர் ஆராய்கிறார்.
Arivu Iyandhiran (அறிவு இயந்திரன்) கோயம்புத்தூரைத் தளமாகக் கொண்ட, இருபதுகளின் இறுதியில் உள்ள மொழிபெயர்ப்பாளர். ஒரு ஜவுளி ஆலையின் உற்பத்தித் தளத்தில் தானியக்கத் தொழில்நுட்ப வல்லுநராகப் பணியைத் தொடங்கினார். பின்னர் தமிழ் மற்றும் ஆங்கிலத்தில் தொழில்நுட்பம் பற்றி வலைப்பதிவு எழுதத் தொடங்கி, அதையே முழுநேர உள்ளூர்மயமாக்கல் பணியாக மாற்றினார்.
தமிழ் எழுத்துகளைப் போர்த்திய ஆங்கிலமாக அல்லாமல், தமிழாகவே வாசிக்கப்படும் தமிழை அவர் முக்கியமாகக் கருதுகிறார். ஒலிபெயர்ப்பு, எழுத்துமுறை, மொழிநடை ஆகிய தேர்வுகளே ஒரு தொழில்நுட்பக் கட்டுரை இயல்பானதாகத் தோன்றுமா அல்லது இறக்குமதி செய்யப்பட்டதாகத் தோன்றுமா என்பதைத் தீர்மானிக்கின்றன என்பதிலும் கவனம் செலுத்துகிறார். ஃபில்டர் காபி, கர்நாடக இசைப் பட்டியல்கள், வார இறுதிக் கபடி ஆகியவை அவரது வாரத்தை நிறைவு செய்கின்றன.
Namefi-க்காக, டொமைன்கள் மற்றும் பெயரிடல் குறித்த கட்டுரைகளைத் தமிழுக்கு உள்ளூர்மயமாக்குகிறார். தமிழ் எழுத்து IDN-கள், ஒலிபெயர்ப்பு, பிராந்தியப் பெயர்வெளிகள் ஆகியவற்றைக் கையாள்வதன் மூலம் ஒரு பெயர் தமிழிலும் ஆங்கிலத்திலும் ஒரேபோல் நன்றாக வாசிக்கப்படுவதை உறுதிசெய்கிறார்.
தொடர்புடைய வழிகாட்டிகள்
- AI முகவர்களை மையமாகக் கொண்ட டொமைன் ரெஜிஸ்ட்ரார் என்றால் என்ன?ரெஜிஸ்ட்ரார்களிடம் பல தசாப்தங்களாக API-கள் உள்ளன; ஆனால் ஓர் API மட்டும் இருந்தால் அது முகவர்-நேட்டிவ் ஆகிவிடாது. கண்டறிதல், ஆவணங்கள், பிழைகள், பணம் செலுத்துதல், கொள்கைக் கட்டுப்பாடுகள் ஆகியவற்றுக்கான சரிபார்ப்புப் பட்டியல் இது.
- மனிதர் இல்லாமல் AI முகவர்கள் டொமைன்களை எப்படி வாங்குகின்றன? (2026)ஏப்ரல் 2026-இல், டொமைன் பதிவு முகவர் அடுக்கிற்குள் நுழைந்தது. AI முகவர்கள் டொமைன்களைத் தேடி, விலையைச் சரிபார்த்து, பதிவுசெய்வது எப்படி — இன்னும் முக்கியமான பாதுகாப்பு வரம்புகள் என்ன?
- 2026-இல் "AI டொமைன் தேடல்" என்பது இரண்டு வேறுபட்ட விஷயங்களைக் குறிக்கிறது"AI டொமைன் தேடல்" என்பது பெயர்களைப் பரிந்துரைக்கும் உதவியாளரையோ, வாங்கும் முகவரையோ குறிக்கலாம். உங்களுக்கு எது தேவை, இரண்டையும் எங்கே பெறலாம் என்பதை அறிய உதவும் இரு-நெடுவரிசைச் சோதனை.
- AI டொமைன் பெயர் ஜெனரேட்டரைத் தாண்டி: முகவர்களின் சகாப்தம்AI பெயர் ஜெனரேட்டர்கள் பரிந்துரைகளுடன் நின்றுவிடுகின்றன. பரிந்துரைத்தல் முதல் தேடுதல், கட்டமைத்தல், பரிவர்த்தனை செய்தல், நிர்வகித்தல் வரையிலான திறன் ஏணி — ஒவ்வொரு படியையும் வழங்குவது யார் என்பதும்.