AIEndpoint — Offener /ai-Endpoint-Standard, damit AI-Agenten jeden Webservice sofort verstehen können

 (github.com/aiendpoint)
3 Punkte von bejoyfuuul 2026-03-18 | 7 Kommentare | Auf WhatsApp teilen

Hallo.

Während ich mit AI entwickelt und andere Websites überprüft habe, kam es oft vor, dass die Tokens schnell aufgebraucht waren und ich auf einen Reset warten musste.
Dabei kam mir der Gedanke, dass AI womöglich einfach „auf Bildschirme schaut, die Menschen mit ihren Augen lesen können“.
Deshalb dachte ich, es müsste eine standardisierte Alternative geben, die den Tokenverbrauch senkt und die Antwortgeschwindigkeit von AI verbessert.

Derzeit gibt es für AI-Agenten im Wesentlichen drei Wege, Webservices zu lesen:

  1. HTML-Scraping — mehr als 80 % des zurückgegebenen Inhalts sind Werbe-, Navigations- und Skript-Rauschen (~zigtausende Tokens)
  2. API-Dokumentation lesen und hart codieren — sobald sich der Service ändert, bricht es jedes Mal
  3. MCP verwenden — nur sehr wenige Services bieten das an, und es ist auf Entwickler ausgerichtet

Darum habe ich das als Open Source umgesetzt, um die folgende Konvention vorzuschlagen.

  • robots.txt (1994) → dem Crawler sagen: „Komm hier nicht hin“
  • sitemap.xml (2005) → dem Crawler sagen: „Hier ist etwas“
  • /ai (2026) → dem AI-Agenten sagen: „Das können wir tun“ ← genau das hat bisher gefehlt

(Während der Arbeit daran habe ich nachgesehen und festgestellt, dass auch robots.txt ursprünglich vom niederländischen Softwareingenieur Martijn Koster vorgeschlagen wurde. Es wurde damals entwickelt, um das Problem zu lösen, dass frühe Webcrawler Server zu stark belasteten.)

Ich wollte, dass Betreiber von Webservices GET /ai implementieren, damit

  • AI-Agenten sofort strukturierte Informationen lesen können
  • sie APIs direkt aufrufen können
  • ohne Scraping, ohne Dokumenten-Parsing, ohne Token-Verschwendung

Hier kann man es prüfen.

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

Das habe ich bisher umgesetzt (with claude, codex)

  • Open Spec (Apache 2.0) — https://github.com/aiendpoint/platform
  • Registry — aiendpoint.dev (Registrierung·Suche)
  • Validator — aiendpoint.dev/validate (Scoring von 0 bis 100)
  • MCP-Server — direkte Suche in der Registry aus Claude/Cursor
  • Claude-Code-Skill — automatisches Hinzufügen von /ai zu bestehenden Services (10 Minuten)

Ohne MCP-Server ist die Registry einfach nur eine Website.
Mit MCP-Server kann man Claude sagen: „Finde mir eine Wetter-API, die ohne Authentifizierung nutzbar ist“,
und erhält sofort eine strukturierte Antwort. Genau diese Schleife zu schließen war der Kern.

Feedback zur Spezifikation ist willkommen.
Was wäre nötig, damit ihr /ai in euren Services implementiert?
Ich würde mich freuen, wenn ihr mitmacht und wir den Standard gemeinsam gestalten.
So wie robots.txt zuerst in den Niederlanden vorgeschlagen wurde, könnten auch wir vielleicht einen neuen Ablauf etablieren.

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

Verwandte Beiträge

7 Kommentare

 
aliveornot 2026-03-20

Llm.txt wurde bereits vorgeschlagen, und es gibt auch Papers, die seine Wirksamkeit untersuchen. Laut Naver scheinen zumindest derzeit auch Agenten es kaum zu sehen.
 
aliveornot 2026-03-20

Laut Naver also … wurde das im Schlaf geschrieben? Es heißt: „Laut der betreffenden Arbeit“.
 
bejoyfuuul 2026-03-21

Haha, absolut richtig gesagt.
Wenn llms.txt den Schwerpunkt darauf legt, dass Agenten einen Service „verstehen“, dann fokussiert sich /ai darauf, dass KI einen Service „nutzen“ kann. Es teilt also mit: „So rufst du die API unseres Service auf.“ Wenn man hier MCP verwendet, kann man sich zuerst die Nutzung dieser Website „grob ansehen“ (und Tokens sparen) und dann starten.

Da eine direkte Beteiligung wohl schwierig ist, haben wir zunächst zwischen einer Version zur „direkten Registrierung“ und einer „Community“-Version unterschieden. Dadurch ist die Struktur bei der Nutzung von /ai MCP so aufgebaut, dass auf Websites, die „bereits jemand durchsucht hat“, leichter und schneller zugegriffen werden kann!

Danke für den Hinweis~
 
vndk2234 2026-03-18

Wenn /ai standardisiert wird, könnte dann nicht umgekehrt auch ein Tool entstehen, das nur /ai ausliest und eine übersichtliche, werbefreie Seite anzeigt?
 
dohyun682 2026-03-18

Interessant! Dann wird man wohl auch Werbung in /ai hineinmischen, oder?
 
bejoyfuuul 2026-03-18

Dann müsste wohl eine Logik hinzugefügt werden, die den Score senkt, wenn Werbeinhalte erkannt werden!
 
bejoyfuuul 2026-03-18

Ja, das hat durchaus Potenzial. Ich denke auch, dass das Web selbst aus Gründen wie Agent-Nutzung (Traffic), Verarbeitung und Token-Kosten in gewisser Weise wieder leichter werden könnte – ähnlich wie früher zu Telnet-Zeiten. (Mehr Fokus auf Inhalte als auf Verzierung.) So wie das aktuelle GeekNews eben. (Nur eine Vermutung!)