AIEndpoint — padrão aberto de endpoint /ai para que agentes de IA entendam instantaneamente qualquer serviço web

Olá.

Enquanto eu desenvolvia com IA e fazia coisas como analisar outros sites, muitas vezes os tokens acabavam rapidamente e eu precisava esperar o reset.
Pensando nisso, percebi que a IA talvez esteja "olhando para uma tela que pessoas conseguem ler com os próprios olhos".
Então achei que não seria necessário surgir uma alternativa padronizada capaz de reduzir tokens e acelerar a velocidade de resposta da IA.

Hoje, os agentes de IA basicamente seguem três caminhos para ler serviços web:

1. Scraping de HTML — mais de 80% do conteúdo retornado é ruído de anúncios, navegação e scripts (~dezenas de milhares de tokens)
2. Ler documentação de API e hardcode — sempre quebra quando o serviço muda
3. Uso de MCP — pouquíssimos serviços têm isso, e é algo voltado a desenvolvedores

Por isso, transformei em open source uma proposta de convenção com o seguinte fluxo.

• robots.txt (1994) → para o crawler: "não venha aqui"
• sitemap.xml (2005) → para o crawler: "está aqui"
• /ai (2026) → para o agente de IA: "o que podemos fazer" ← era isso que faltava

(Pesquisando enquanto trabalhava nisso, descobri que o robots.txt também foi inicialmente proposto pelo engenheiro de software holandês Martijn Koster. Dizem que ele foi criado para resolver o problema de os primeiros crawlers da web gerarem carga excessiva nos servidores.)

Quero que quem possui serviços web implemente GET /ai para que

• agentes de IA possam ler informações estruturadas instantaneamente
• e passem a conseguir chamar APIs diretamente
• sem scraping, sem parsing de documentação, sem desperdício de tokens

Você pode conferir aqui.

curl https://api.aiendpoint.dev/ai | jq .  

Até agora, fiz este trabalho (with claude, codex)

• especificação aberta (Apache 2.0) — https://github.com/aiendpoint/platform
• registro — aiendpoint.dev (cadastro e busca)
• validador — aiendpoint.dev/validate (pontuação de 0 a 100)
• servidor MCP — busca direta no registro a partir do Claude/Cursor
• skill do Claude Code — adiciona /ai automaticamente a serviços existentes (10 minutos)

Sem servidor MCP, o registro é apenas um site.
Com servidor MCP, se você pedir ao Claude "encontre uma API de clima que possa ser usada sem autenticação",
ele retorna imediatamente uma resposta estruturada. Fechar esse loop era o ponto principal.

Feedback sobre a especificação é bem-vindo.
O que seria necessário para levar vocês a implementar /ai nos seus serviços?
Seria ótimo se vocês participassem e construíssemos esse padrão juntos.
Assim como o robots.txt foi inicialmente proposto na Holanda, será que nós também não poderíamos criar esse movimento?

GitHub: https://github.com/aiendpoint/platform

[aliveornot]

O llm.txt já foi proposto antes, e há até um artigo estudando sua eficácia. Segundo a Naver, pelo menos por enquanto, parece que os agentes também não o consultam muito bem.

[aliveornot]

Segundo a Naver... foi escrito dormindo?... O correto é "segundo o artigo em questão".

[bejoyfuuul]

Haha, é isso mesmo.
Se o llms.txt foca em explicar para que o agente "entenda" o serviço, o /ai é focado em como a IA vai "usar" o serviço. É para mostrar: "a API do nosso serviço é chamada assim". Se usar MCP nisso, dá para primeiro "dar uma olhada" em como usar aquele site (economizando tokens) e então começar.

Como é difícil ter participação direta de todo mundo, acabamos separando as versões de "registro direto" e de "comunidade"; assim, ao usar /ai MCP, os sites que "alguém já pesquisou" antes podem ser acessados de forma mais leve e rápida!

Obrigado pelo comentário~

[vndk2234]

Se o /ai virar algo padronizado, será que, ao contrário, também não poderiam surgir ferramentas que raspem só o /ai e mostrem uma página bonita, sem anúncios?

[dohyun682]

Interessante! Então também vai acabar surgindo gente misturando anúncios no /ai, né?

[bejoyfuuul]

Então, nesse caso, seria preciso adicionar uma lógica para reduzir a pontuação quando conteúdo publicitário for detectado!

[bejoyfuuul]

Sim. Há potencial suficiente. Além disso, por razões como uso (tráfego) pelos agentes, processamento e custo de tokens, acho que a própria web pode, de certa forma, ficar mais leve, como na época do telnet. (mais foco no conteúdo do que no visual) Como o GeekNews atual, por exemplo. (é uma suposição!)