AIEndpoint — AI agents के लिए हर web service को तुरंत समझने योग्य बनाने वाला /ai endpoint open standard
(github.com/aiendpoint)नमस्ते।
AI के साथ development करते समय, जब दूसरे sites के review वगैरह करने पड़ते थे, तो अक्सर tokens जल्दी खत्म हो जाते थे और reset का इंतज़ार करना पड़ता था।
सोचने पर लगा कि AI शायद "ऐसी screen देख रहा है जिसे इंसान अपनी आँखों से पढ़ने के लिए देखते हैं"।
इसलिए लगा कि tokens कम करने और AI की response speed तेज़ करने के लिए कोई standard alternative आना चाहिए।
अभी AI agents web services को पढ़ने के लिए लगभग तीन तरीकों का इस्तेमाल करते हैं:
- HTML scraping — लौटने वाली सामग्री का 80% से अधिक ads·navigation·script noise होता है (~दसियों हज़ार tokens)
- API docs पढ़कर hardcoding — service बदलते ही हर बार टूट जाता है
- MCP का उपयोग — ऐसी services बहुत कम हैं, और यह केवल developers के लिए है
इसीलिए मैंने नीचे दिए गए flow के रूप में एक convention प्रस्तावित करने के लिए इसे open source बनाया।
- robots.txt (1994) → crawler को "यहाँ मत आओ"
- sitemap.xml (2005) → crawler को "यहाँ हूँ"
- /ai (2026) → AI agent को "हम क्या कर सकते हैं" ← यही चीज़ नहीं थी
(काम करते हुए पता चला कि robots.txt भी सबसे पहले Netherlands के software engineer Martijn Koster ने प्रस्तावित किया था। उस समय शुरुआती web crawlers से servers पर बहुत ज़्यादा load पड़ने की समस्या को हल करने के लिए इसे बनाया गया था।)
मैं चाहता था कि web service मालिक GET /ai implement करें ताकि
- AI agents तुरंत structured information पढ़ सकें
- और सीधे API call कर सकें
- scraping के बिना। docs parsing के बिना। tokens की बर्बादी के बिना।
इसे यहाँ देखा जा सकता है।
curl https://api.aiendpoint.dev/ai | jq .
अब तक मैंने यह काम किया है (with claude, codex)
- open spec (Apache 2.0) — https://github.com/aiendpoint/platform
- registry — aiendpoint.dev (registration·search)
- validator — aiendpoint.dev/validate (0~100 score)
- MCP server — Claude/Cursor में registry को सीधे search करना
- Claude Code skill — मौजूदा service में /ai अपने आप जोड़ना (10 मिनट)
अगर MCP server नहीं है, तो registry बस एक website है।
अगर MCP server है, तो Claude से "ऐसा weather API ढूँढो जिसे बिना authentication के इस्तेमाल किया जा सके" कहने पर
वह तुरंत structured answer देता है। इस loop को बंद करना ही मुख्य बात थी।
spec पर feedback का स्वागत है।
आपकी services में /ai implement करवाने के लिए क्या चाहिए होगा?
अच्छा होगा अगर आप साथ जुड़ें और इस standard को मिलकर बनाएँ।
जैसे Netherlands में robots.txt पहली बार प्रस्तावित किया गया था, क्या हम भी ऐसा एक flow नहीं बना सकते?
7 टिप्पणियां
llm.txtपहले से प्रस्तावित किया जा चुका है, और उसकी प्रभावशीलता पर शोध करने वाला पेपर भी है। Naver के मुताबिक, कम-से-कम अभी तक एजेंट भी इसे ज़्यादा अच्छी तरह नहीं देख पाते लगते हैं।Naver के अनुसार, ऐसा कहते हैं.. क्या यह सोते-सोते लिखा था... "उस शोधपत्र के अनुसार" है।
हाँ, बिल्कुल सही बात है.
अगर
llms.txtका फोकस एजेंट को सेवा को 'समझने' के लिए विवरण देने पर है,तो
/aiका फोकस AI को सेवा का 'इस्तेमाल' करने पर है। यानी यह बताता है, "हमारी सेवा का API इस तरह कॉल करो"। यहाँ अगर mcp का उपयोग किया जाए, तो उस साइट को इस्तेमाल करने का तरीका पहले 'स्कैन' करके (टोकन बचाते हुए) शुरू किया जा सकता है.सीधी भागीदारी मुश्किल होने की वजह से हमने पहले 'direct registration' और 'community' वर्ज़न अलग किए हैं, इसलिए
/ai mcpइस्तेमाल करते समय जिन साइटों पर 'किसी ने पहले से searching' करके देखा है, उन तक थोड़ा हल्के और तेज़ तरीके से पहुँचा जा सकता है!कहने के लिए धन्यवाद~
अगर /ai मानकीकृत हो जाता है, तो क्या इसके उलट सिर्फ /ai को स्क्रैप करके बिना विज्ञापनों वाला, देखने में अच्छा पेज दिखाने वाला कोई टूल भी बन सकता है?
मज़ेदार है! तो फिर /ai में ads मिलाने जैसी चीज़ें भी होने लगेंगी, है न?
तो फिर, अगर विज्ञापन वाला कंटेंट मिलता है, तो score को घटाने वाला logic जोड़ना पड़ेगा!
हाँ, इसमें काफ़ी संभावना है। साथ ही agent के उपयोग (traffic), processing, token cost आदि कारणों से मुझे लगता है कि वेब खुद भी एक तरह से पहले के telnet दौर की तरह light हो सकता है। (सजावट से ज़्यादा सामग्री पर फ़ोकस) ठीक अभी के GeekNews की तरह। (यह अनुमान है!)