3 puntos por bejoyfuuul 2026-03-18 | 7 comentarios | Compartir por WhatsApp

Hola.

Mientras desarrollaba con IA y hacía cosas como revisar otros sitios, a menudo se me acababan rápidamente los tokens y tenía que esperar a que se reiniciaran.
Pensándolo bien, me di cuenta de que la IA probablemente está “mirando una pantalla que una persona puede leer con sus propios ojos”.
Así que pensé que hacía falta una alternativa estándar que redujera los tokens y acelerara la velocidad de respuesta de la IA.

Hoy en día, los agentes de IA suelen usar unas tres formas para leer servicios web:

  1. Scraping de HTML — más del 80% de lo que se devuelve es ruido de anuncios, navegación y scripts (~decenas de miles de tokens)
  2. Leer la documentación de la API y hardcodear — cada vez que el servicio cambia, todo se rompe
  3. Usar MCP — hay poquísimos servicios que lo tienen y está orientado a desarrolladores

Por eso lo hice open source para proponer la siguiente convención.

  • robots.txt (1994) → al crawler: “no vengas aquí”
  • sitemap.xml (2005) → al crawler: “esto está aquí”
  • /ai (2026) → al agente de IA: “esto es lo que podemos hacer” ← eso era lo que faltaba

(Mientras trabajaba en esto, descubrí que robots.txt también fue propuesto por primera vez por el ingeniero de software neerlandés Martijn Koster. Según entiendo, fue ideado para resolver el problema de los primeros crawlers web que generaban demasiada carga en los servidores.)

Quería que quienes son dueños de servicios web implementaran GET /ai para que

  • los agentes de IA puedan leer información estructurada de inmediato
  • y pasar a poder llamar directamente a las APIs.
  • Sin scraping. Sin parsear documentación. Sin desperdiciar tokens.

Pueden verlo aquí.

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

Hasta ahora he hecho esto (with claude, codex)

  • Especificación abierta (Apache 2.0) — https://github.com/aiendpoint/platform
  • Registro — aiendpoint.dev (registro y búsqueda)
  • Validador — aiendpoint.dev/validate (puntuación de 0 a 100)
  • Servidor MCP — búsqueda directa en el registro desde Claude/Cursor
  • Skill de Claude Code — agrega automáticamente /ai a servicios existentes (10 minutos)

Sin un servidor MCP, el registro es simplemente un sitio web.
Si hay un servidor MCP, al pedirle a Claude “encuéntrame una API del clima que pueda usarse sin autenticación”,
responde de inmediato con una respuesta estructurada.
Cerrar ese loop era lo importante.

Se agradece cualquier feedback sobre la especificación.
¿Qué haría falta para lograr que implementen /ai en sus servicios?
Me gustaría que se sumaran y que construyéramos el estándar juntos.
Así como robots.txt fue propuesto por primera vez en los Países Bajos, ¿no podríamos nosotros también crear una nueva corriente?

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

7 comentarios

 
aliveornot 2026-03-20

Ya se había propuesto llm.txt, e incluso hay un paper que estudia su validez. Según Naver, al menos por ahora, parece que los agentes tampoco lo ven muy bien.

 
aliveornot 2026-03-20

Según Naver, dicen... ¿lo escribieron dormidos...? Debería ser: "Según ese artículo".

 
bejoyfuuul 2026-03-21

Jeje, tiene toda la razón.
Si llms.txt se enfoca en explicar para que los agentes "entiendan" un servicio,
/ai está enfocado en que la IA pueda "usar" el servicio. Es para decirle: "así se llama a la API de nuestro servicio". Si aquí se usa MCP, se puede empezar primero "ojeando" cómo usar ese sitio (ahorrando tokens), ¿no?

Como de todos modos es difícil participar directamente, por ahora se dividió en versiones de "registro directo" y "comunidad", así que al usar /ai MCP, si es un sitio que "alguien ya buscó" antes, queda estructurado para poder acceder de forma un poco más ligera y rápida.

¡Gracias por el comentario~

 
vndk2234 2026-03-18

Si /ai se estandariza, ¿no podría surgir también una herramienta que, al contrario, solo raspe /ai y muestre una página agradable de ver y sin anuncios?

 
dohyun682 2026-03-18

¡Está interesante! Entonces supongo que también empezarán a meter anuncios en /ai.

 
bejoyfuuul 2026-03-18

Entonces, habrá que añadir una lógica que baje la puntuación cuando se detecte contenido publicitario.

 
bejoyfuuul 2026-03-18

Sí. Hay suficiente potencial. Además, por razones como el uso de los agentes (tráfico), el procesamiento y el costo de los tokens, también creo que la web misma podría volverse más ligera en cierto sentido, como en la época de telnet. (más enfocada en el contenido que en lo decorativo) Como el GeekNews actual, por ejemplo. (¡Es una suposición!)