isitagentready

Audit a repository against Cloudflare's agent-readiness checks at the requested scope, keeping runtime evidence and source inspection apart. A scoped question gets a scoped answer; write a report file only when asked. references/signal-map.md has the full signal inventory: official key, runtime expectation, where to look in a repo, applicability and score. Its keys, endpoints, weights and WebMCP examples are an April 19, 2026 baseline from https://isitagentready.com/ and https://blog.cloudflare.com/agent-readiness/ (April 17, 2026), not evergreen requirements. When guidance looks stale or conflicts, check current official Cloudflare or protocol documentation, record the version or date, and propose a sourced correction rather than editing the installed skill.

Evidence and status

Record source status and deployed status separately, for example source: pass; deployed: unknown. Use pass, partial, fail, neutral, not applicable, unknown:

A deployed pass needs runtime evidence; browser usability and WebMCP need a rendered browser session. Without one, label the claim unverified.
Absent source is not a deployed failure; present source is not a deployed pass. If runtime fails but source implements the signal, suspect deployment drift (route not deployed, CDN stripping a header, wrong content type, a rewrite shadowing the path).
Do not invent an official Cloudflare level from source alone. Without a scan, call the result a repository assessment and leave the official score unverified. A scan is authoritative only for what it reported for that URL at that time; keep disagreements with direct HTTP, browser or source evidence in the report.
Neutral and optional signals stay marked: a static content site is not penalised for lacking commerce flows or OAuth protected-resource metadata, and Web Bot Auth is neutral unless the site sends bot requests to other sites. The April 2026 post described commerce checks (x402, UCP, ACP) as evaluated but non-scoring; record the measured scan version instead of hard-coding that.
When the repo has separate web and API apps, the user's production URL is the runtime surface; backend OpenAPI or MCP config counts as source evidence only until the public site exposes or links it.
Ask for the production URL when live verification is needed and the target is missing or ambiguous; source-only work continues meanwhile. Do not guess the target.

Live checks and the scan

Capture homepage status, content type and Link headers; /robots.txt, /sitemap.xml, /llms.txt and /llms-full.txt when relevant; Accept: text/markdown behaviour on representative pages (check raw headers and returned content type); .well-known documents; auth redirects; WebMCP registration in a rendered browser. Keep verification read-only: no form submissions, mutating tools, weakened secure headers or bypassed access controls to get a pass.