Inventory public agent-discovery files
Check whether a site exposes MCP, agent-card, llms.txt, security, and Content-Signals markers from one URL.
Agent Readiness Checker
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.
Sample report Illustrative deterministic result
For a site where /.well-known/agent-card.json contains valid JSON, /llms.txt is missing, the MCP request times out, and the remaining signals are present, the report would read:
Score 57
A2A agent card: found-valid — Found and structurally valid.
MCP manifest: not-evaluated — Fetch unavailable.
llms.txt: absent — Not found.
security.txt: found-valid — Found and structurally valid.
Content-Signals: found-valid — Found and structurally valid.
Recent Common Crawl presence: found-valid — informational, zero score weight.
The score is exactly 4 earned weight points out of 7 possible, rounded to 57. The timeout earns nothing, but it is still labelled not evaluated rather than absent.
How to use it
- Enter a complete public website URL, including
https://. - Select Check signals. The tool requests the site root and four conventional discovery paths.
- Read each state independently. Fix malformed files first; only add absent files when they serve a real interface or policy.
- Open the files directly after publishing to confirm your CDN is returning the intended content type and body.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
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.
Rate this tool
Checks run from our server; we fetch the URL you enter and don't keep the results. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
What the results mean
- found-valid — the resource returned successfully and passed the tool’s limited structural check.
- found-invalid — a resource exists but JSON parsing, llms.txt parsing, or the expected header check failed.
- absent — that exact path returned HTTP 404.
- not-evaluated — the fetch failed or returned another unusable status; investigate availability before drawing a conclusion.
How it works
The browser calls protected endpoints for the root, the A2A 1.0 path /.well-known/agent-card.json, /.well-known/mcp.json, /llms.txt, /.well-known/security.txt, and an exact-URL lookup across three recent Common Crawl indexes. JSON files must parse, llms.txt must have no parser errors, and Content-Signals must appear as a response header. The root response is also checked for RFC 9421 signature-negotiation or signed-response headers; that awareness card carries no score weight and never treats absent evidence as lack of support. A2A and MCP carry two points each; the other scored file/header signals carry one. Common Crawl presence is informational.
Features
- Five scored path/header checks plus independent Common Crawl and RFC 9421 awareness cards.
- Four-state reporting that distinguishes absence, invalid content, and unavailable evidence.
- Visible, reproducible 7-point weighting rather than a hidden model score.
- Entirely public-surface testing with no account or site integration.
Limitations
This is a discovery-signal inventory, not a protocol conformance suite or an AI visibility forecast. JSON parsing does not prove that an agent or MCP server works. The checker does not execute an agent, validate authentication, inspect robots directives, or observe which crawlers consume a file. A CDN, bot challenge, or regional block can also make a public resource not evaluated from the checker even when it works elsewhere.
Frequently asked questions
What does the Agent Readiness score measure?
It is a simple weighted inventory of five public signals: an A2A agent card, an MCP manifest, llms.txtllms.txt is a proposed (not adopted) Markdown file at /llms.txt that gives AI systems a curated map of a site's most important pages. Proposed by Jeremy Howard in 2024, it's read mostly by coding agents like Claude Code — not search crawlers — and Google ignores it., security.txt, and the Content-Signals response header. Recent Common Crawl presence is shown separately and does not change the score. The report does not measure whether an AI system will use, cite, or rank the site.
Does a missing llms.txt mean AI crawlers cannot use my site?
No. llms.txt is a proposed convention, not a required discovery mechanismURL discovery is how search engines find URLs to crawl — by pull (following links and reading sitemaps) and by push (you notify them via IndexNow, the Indexing API, or WebSub). It's the find step that comes before a page is ever fetched. or a documented access control for major crawlers. Its absence only means this optional file was not found.
Why is a signal marked not evaluated?
The checker could not obtain a usable response, for example because the request failed or returned a non-success status other than 404. Not evaluated is never treated as absent, invalid, or passed.
What makes an agent card or MCP manifest valid here?
This lightweight check only confirms that the public file returns a successful response and parses as JSON. It does not certify protocol conformance, endpoints, authentication, or operational safety.
Should every website publish all five signals?
No. Agent cards and MCP manifestsMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt. are relevant to sites that intentionally expose agent or tool interfaces. A normal editorial or commerce site can be perfectly usable without them.
Does the Web Bot Auth card prove crawler authentication works?
No. It only reports response-side RFC 9421 HTTP Message Signature evidence when present. A normal unsigned page fetch cannot prove that the edge requires or verifies signed AI-bot requests, and no observed evidence is reported as not evaluated rather than unsupported.
Feature requests for Agent Readiness Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Preflight an agent-facing launch
Verify the intended discovery endpoints are reachable and well formed before announcing an agent integration.
Find missing machine-readable signals
Turn absent or invalid markers into a focused implementation list for the site or platform team.
Recheck after deployment
Run the same public URL again to confirm that newly published discovery files can actually be observed.
Watch the full workflow
Agent Readiness Checker walkthrough
Read the transcript
Agent Readiness Checker
Agent discovery conventions can be useful, but missing optional files do not mean a site is invisible to A-I systems. I’ll show you how to check the public paths and headers, read the four signal states, reproduce the seven-point weighting, separate Common Crawl and Web Bot Auth awareness, understand protocol and visibility limits, and choose only the next steps that fit the site.
Step 1
Use this checker when a site intentionally exposes agent or tool interfaces, publishes machine-readable guidance, or needs a public-surface inventory. It checks an A-two-A card, M-C-P manifest, llms dot t-x-t, security dot t-x-t, and Content-Signals.
Step 2
Enter the full H-T-T-P-S website U-R-L and choose Check signals. The tool requests the root and four conventional paths through bounded endpoints, then performs an exact-U-R-L lookup across three recent Common Crawl indexes.
Step 3
Do not start with the score alone. Found-valid, found-invalid, absent, and not-evaluated describe different evidence. A fetch failure or unusable status never becomes a negative verdict, and a four-oh-four only means that exact optional path was absent.
Step 4
This walkthrough uses the documented fictional fifty-seven-point example and makes no live site claim. A real run fetches each public surface and keeps the engine detail and evidence source beside its state.
Step 5
A-two-A and M-C-P carry two points each. llms dot t-x-t, security dot t-x-t, and Content-Signals carry one each. Four earned points out of seven rounds to fifty-seven. Common Crawl and Web Bot Auth awareness have zero weight.
Step 6
Found-invalid means a resource exists but failed the limited parser or header check. Absent means the exact path returned four-oh-four. Not-evaluated means acquisition failed or returned unusable evidence. Investigate availability before concluding anything from not-evaluated.
Step 7
A valid agent card or M-C-P manifest here only means the response succeeded and parsed as J-S-O-N. It does not certify protocol conformance, endpoint behavior, authentication, permissions, reliability, or operational safety.
Step 8
A normal editorial or commerce site can be usable without agent cards or M-C-P. llms dot t-x-t is a proposed convention, not access control for major crawlers. Publish optional files only when their content is maintained and genuinely useful.
Step 9
Recent Common Crawl presence is informational and does not predict future crawling or A-I citation. An unsigned page fetch also cannot prove an edge requires or verifies signed bot requests, so missing RFC nine-four-two-one response evidence remains not evaluated.
Step 10
Download the result card or copy the share link for collaboration. Preserve the target, date, state details, and caveat that this is a public discovery inventory—not protocol certification, crawler access testing, or an A-I visibility prediction.
Step 11
The checker does not execute an agent, validate authentication, inspect robots directives, or observe which crawlers consume a file. C-D-N challenges and regional blocks can also produce not-evaluated results even when a resource works from another location.
Step 12
Correct malformed files, publish only purposeful missing resources, and verify each path through the production C-D-N. Test real endpoints and authentication independently. Then follow the crawler-access handoff to audit robots behavior without confusing discovery metadata with permission or visibility.
Publish signals only when they represent real capabilities.
Fix malformed resources first, then add optional discovery files only when they describe a real supported interface or policy. Open each deployed path directly, verify content type and body through the C-D-N, test agent endpoints and authentication separately, and audit crawler access without treating this inventory score as an A-I citation forecast.
Common issues & how to fix them
- Error Agent discovery file is missing Fix: Publish the A2A 1.0 /.well-known/agent-card.json resource as public valid JSON describing the agent endpoint and supported capabilities.
- Error Agent discovery JSON is malformed Fix: Fix the JSON syntax and required discovery structure in /.well-known/agent-card.json, then confirm it returns parseable JSON with a 2xx status.
- Error MCP discovery file is missing Fix: Publish /.well-known/mcp.json as public valid JSON that identifies the MCP server endpoint and supported transport.
- Error MCP discovery JSON is malformed Fix: Correct the syntax and discovery fields in /.well-known/mcp.json, then verify the file parses and its declared endpoint is reachable.
- Error Declared agent endpoint is unreachable Fix: Fix the declared endpoint URL, DNS/TLS, authentication exposure, or server response so an external client receives the expected 2xx handshake.
- Warning Discovery document omits expected capabilities Fix: Add the omitted, genuinely supported capability to the discovery document and implement it at the declared endpoint before advertising it.
- Warning Authentication requirements are unclear Fix: State the authentication scheme, token location, required scopes, and unauthenticated discovery behavior in the discovery document.