Five Files, One Pass
Probes ai-plugin.json, agent.json, ai.txt, llms.txt, and security.txt together and scores coverage across all of them.
TL;DR: AI Discovery Files Checker checks probe the well-known ai and agent discovery files a domain should expose. so you can confirm the current issue, understand when it matters, and move directly into the next fix without leaving the browser.
Find out whether AI assistants and autonomous agents can actually discover your manifest, agent card, usage policy, and security contact.
Updated
Loading tool interface...
The AI Discovery Files Checker probes the small set of well-known files an agent-ready origin is expected to publish, then reports each one's presence, HTTP status, content type, and a short validity note. It checks `/.well-known/ai-plugin.json`, `/.well-known/agent.json` (the A2A AgentCard), `/ai.txt`, `/llms.txt`, and `/.well-known/security.txt` in a single pass.
Why it matters for AI SEO: AI assistants, plugin hosts, and autonomous agents look for these files at fixed paths before they ever crawl your pages. A missing manifest or AgentCard means ChatGPT plugins and A2A-aware agents cannot discover what your service does. A missing llms.txt means answer engines have no curated map of your best pages. A wrong content type can break parsing even when the file exists.
Pre-Launch QA: Before announcing an AI integration, confirm every discovery file returns 200 with the correct content type instead of an HTML soft-404 or an SPA fallback shell that silently masquerades as a real file.
Agent Onboarding Audits: When you publish an ai-plugin.json or AgentCard, validate that required fields parse and that the api descriptor, skills, or capabilities blocks are actually present, not just that the path resolves.
Policy and Security Coverage: Verify that ai.txt states your AI training and usage stance and that security.txt carries the RFC 9116 Contact and Expires fields, so researchers and agents have a clean reporting path.
How it complements Agent Protocol Readiness: This tool focuses narrowly on the discovery files themselves, presence, status, content type, and structure. The Agent Protocol Readiness Checker goes deeper on Markdown content negotiation, MCP Server Cards, OAuth discovery, and agentic-commerce signals. Run both for full coverage.
AI Discovery Files Checker is most useful when you need a direct answer on a live URL or draft before you change templates, ship content, or rerun a wider audit.
After checking discovery files, run the Agent Protocol Readiness Checker for MCP and content-negotiation depth, then validate your llms.txt structure and AI bot access. Then move to the related checks below to confirm the fix on the live canonical page.
Probes ai-plugin.json, agent.json, ai.txt, llms.txt, and security.txt together and scores coverage across all of them.
Flags files that return the wrong content type, since a JSON manifest served as text/plain or HTML can break agent parsing.
Parses each file to confirm required fields, H1 and links for llms.txt, and Contact and Expires for security.txt, not just that the path resolves.
Answers about AI Discovery Files Checker
It probes five well-known files: /.well-known/ai-plugin.json, /.well-known/agent.json (the A2A AgentCard), /ai.txt, /llms.txt, and /.well-known/security.txt. For each one it reports presence, HTTP status, content type, and a short validity note so you can see exactly what agents will and will not find.
This tool focuses narrowly on the discovery files themselves, while the Agent Protocol Readiness Checker audits deeper protocol behavior. Use this checker to confirm each well-known file is present, valid, and served with the right content type, then use Agent Protocol Readiness for Markdown negotiation, MCP Server Cards, OAuth discovery, and agentic commerce signals.
A warning usually means the file exists and returned 200 but is served with the wrong content type or is missing recommended fields. For example, an AgentCard served as text/plain instead of application/json, or a security.txt with a Contact but no Expires field, will pass presence but warn on correctness so you can tighten the response.
Yes, the checker flags HTML responses at these paths as failures even when the status is 200. Many sites return an HTML 404 page or an SPA fallback shell with a 200 status, which would falsely look like a published file. The tool detects that pattern so an HTML page is never counted as a real discovery file.