Prüfer für Agentenbereitschaft

Free, no signup. Inventory the public files and headers that can describe an agent-capable site. Every signal keeps a visible state, and a failed fetch never becomes a negative verdict.

Built by Patrick Stox

Public website URL

Signal evidence

Next steps

Check AI crawler access
Test robots directives and crawler-specific access separately.
Build llms.txt
Create the optional discovery file when it fits the site.

Die Prüfungen laufen auf unserem Server. Wir rufen die von dir eingegebene URL ab und speichern die Ergebnisse nicht. Anonyme Ergebniszähler auf Ausführungsebene können für aggregierte Forschung verwendet werden; URLs, Domains, IP-Adressen und Kennungen werden nie einbezogen, und Statistiken werden erst ab 100 Ausführungen veröffentlicht.

Rückmeldung

Über dieses Werkzeug

Erfasse öffentliche Erkennungssignale für agentenfähige Websites: A2A Agent Card, MCP-Manifest, llms.txt, security.txt und den HTTP-Header Content-Signals. Jeder Fund erhält einen klaren Status: gefunden und gültig, gefunden und ungültig, nicht vorhanden oder nicht bewertet. Ein fehlgeschlagener Abruf führt niemals zu einem negativen Urteil.

Dies ist eine Prüfung sichtbarer Signale, keine umfassende Prüfung der Protokollkonformität und keine Prognose der KI-Sichtbarkeit.

Funktionen

Fünf gewichtete Prüfungen von Pfaden und Headern sowie unabhängige Hinweise aus Common Crawl und RFC 9421
Vier Zustände zur Unterscheidung von Abwesenheit, ungültigem Inhalt und nicht verfügbaren Nachweisen
Sichtbare, reproduzierbare Gewichtung mit sieben Punkten statt einer verborgenen Modellbewertung
Prüfung öffentlicher Oberflächen ohne Kontointegration oder Installation auf der Website

So funktioniert es

Gib eine vollständige öffentliche HTTPS-URL ein und wähle „Signale prüfen“. Der Prüfer ruft die Startseite, die A2A Agent Card, das MCP-Manifest, llms.txt und security.txt sowie eine aktuelle Common-Crawl-Abfrage über geschützte Endpunkte ab. Lies jeden Status unabhängig, behebe zuerst fehlerhafte Dateien und veröffentliche fehlende Dateien nur, wenn tatsächlich eine entsprechende Schnittstelle oder Richtlinie benötigt wird. Prüfe nach der Veröffentlichung Content-Type und Inhalt direkt.

Einschränkungen

Die Prüfung von JSON, llms.txt und Headern beweist weder Protokollkonformität noch funktionsfähige Endpunkte oder Authentifizierung.
Der Prüfer führt keinen Agenten aus, validiert keine robots-Direktiven und beobachtet nicht, welche Crawler eine Datei verwenden.
CDN-Sperren, Bot-Prüfungen oder regionale Beschränkungen können einen Fund als nicht bewertet erscheinen lassen, obwohl die Ressource an anderer Stelle funktioniert.

Häufig gestellte Fragen

Was misst die Bewertung der Agentenbereitschaft?

Sie ist ein einfach gewichtetes Inventar aus fünf öffentlichen Signalen: einer `A2A Agent Card`, einem `MCP`-Beschreibungsdokument, `llms.txt`, `security.txt` und der Antwortkopfzeile `Content-Signals`. Eine aktuelle Präsenz in `Common Crawl` wird separat angezeigt und verändert die Bewertung nicht. Der Bericht misst nicht, ob eine KI-Anwendung die Website nutzt, zitiert oder einstuft.

Bedeutet eine fehlende `llms.txt`, dass KI-Crawler meine Website nicht nutzen können?

Nein. `llms.txt` ist eine vorgeschlagene Konvention, kein erforderlicher Entdeckungsmechanismus und keine dokumentierte Zugriffskontrolle für große Crawler. Ihr Fehlen bedeutet lediglich, dass diese optionale Datei nicht gefunden wurde.

Warum ist ein Signal als nicht bewertet markiert?

Der Prüfer konnte keine brauchbare Antwort abrufen, etwa weil die Anfrage fehlschlug oder einen nicht erfolgreichen Status ungleich 404 zurückgab. „Nicht bewertet“ wird niemals als nicht vorhanden, ungültig oder bestanden behandelt.

Was macht eine `Agent Card` oder ein `MCP`-Beschreibungsdokument hier gültig?

Diese einfache Prüfung bestätigt nur, dass die öffentliche Datei erfolgreich zurückgegeben wird und sich als JSON parsen lässt. Sie zertifiziert weder die Protokollkonformität noch Endpunkte, Authentifizierung oder Betriebssicherheit.

Sollte jede Website alle fünf Signale veröffentlichen?

Nein. `Agent Cards` und `MCP`-Beschreibungsdokumente sind für Websites von Bedeutung, die bewusst Agenten- oder Werkzeugschnittstellen bereitstellen. Eine normale redaktionelle oder kommerzielle Website kann auch ohne sie vollkommen nutzbar sein.

Beweist die Karte zur Webcrawler-Authentifizierung, dass die Crawler-Authentifizierung funktioniert?

Nein. Sie meldet lediglich serverseitige Evidenz für `RFC 9421 HTTP Message Signatures`, sofern diese vorhanden ist. Ein normaler unsignierter Seitenabruf kann nicht beweisen, dass der Randserver signierte Anfragen von KI-Crawlern verlangt oder verifiziert. Wenn keine Evidenz beobachtet wurde, lautet das Ergebnis „nicht bewertet“ statt „nicht unterstützt“.

Nächster SchrittSEO-MCP-Server — run the full end-to-end workflow. Anleitung auf Englisch verfügbar.

Häufige Probleme und ihre Behebung

Fehler Die Datei zur Agentenerkennung fehlt Lösung: Veröffentliche die Ressource A2A 1.0 unter /.well-known/agent-card.json als öffentlich zugängliches, gültiges JSON, das den Agenten-Endpunkt und die unterstützten Fähigkeiten beschreibt.
Fehler Das JSON zur Agentenerkennung ist fehlerhaft Lösung: Korrigiere die JSON-Begriff und die erforderliche Erkennungsstruktur in /.well-known/agent-card.json. Bestätige anschließend, dass die Ressource parsbares JSON mit einem 2xx-Status zurückgibt.
Fehler Die Datei zur MCP-Erkennung fehlt Lösung: Veröffentliche /.well-known/mcp.json als öffentlich zugängliches, gültiges JSON, das den MCP-Server-Endpunkt und den unterstützten Begriff angibt.
Fehler Das JSON zur MCP-Erkennung ist fehlerhaft Lösung: Korrigiere die Begriff und die Erkennungsfelder in /.well-known/mcp.json. Prüfe anschließend, ob sich die Datei parsen lässt und der angegebene Endpunkt erreichbar ist.
Fehler Der angegebene Agenten-Endpunkt ist nicht erreichbar Lösung: Korrigiere die angegebene Endpunkt-URL, DNS/TLS, die Zugänglichkeit der Authentifizierung oder die Serverantwort, damit ein externer Begriff die erwartete 2xx-Bestätigung erhält.
Warnung Im Erkennungsdokument fehlen erwartete Fähigkeiten Lösung: Ergänze die fehlende und tatsächlich unterstützte Fähigkeit im Erkennungsdokument und implementiere sie am angegebenen Endpunkt, bevor du sie bewirbst.
Warnung Die Anforderungen an die Authentifizierung sind unklar Lösung: Gib im Erkennungsdokument das Authentifizierungsverfahren, die Position des Tokens, die erforderlichen Berechtigungsbereiche und das Verhalten bei einer nicht authentifizierten Erkennung an.