Scovant Core: open-source scanner for AI-agent readiness
Most tools that tell you whether a website is "AI ready" are guessing. They fetch a page, hit a timeout or a bot wall, and publish their own failure as a fault of the site. We built Scovant Core because we needed the opp
Most tools that tell you whether a website is "AI ready" are guessing.
They fetch a page, hit a timeout or a bot wall, and publish their own failure as
a fault of the site. We built Scovant Core because we needed the opposite: a
scanner whose every verdict carries the evidence it came from, and which says
"I could not look" instead of inventing an answer.
Scovant is an AI agent readiness testing platform that scans, simulates, and continuously monitors websites to determine how reliably AI agents can discover, understand, and interact with them. Scovant Core is the open-source
engine behind the first of those three layers: a passive scanner you can run
yourself, against your own site, with no account.
What it checks
69 checks across six categories β 51 readiness checks, eight of them
experimental (reported, but excluded from the score until they are promoted
against published criteria), plus 18 unscored security checks. The five
readiness categories: whether agents can reach and are allowed to
read the site (access); whether the content is machine-understandable
(machine); whether the site exposes an agent interface (interfaces); whether
the trust and commerce surfaces an agent needs are discoverable (trust); and
how expensive the site is for an agent to operate (operability).
The newest group is HTTP semantics: does a missing page return a real 404 (a
soft-404 fails; an SPA shell warns), does a 429 carry Retry-After, and is a
challenge page ever served as a 200? Agents act on status codes; a site that
lies in them breaks retry logic silently.
Every check is passive. Core issues ordinary GETs, never authenticates, never
submits a form, and never invokes a tool it discovers. It is meant to be run
against sites you own or are authorised to test.
Evidence, not vibes
Three rules make the output trustworthy, and they are the reason we wrote our
own engine instead of wrapping an existing one.
A document we could not read is an error, never a finding. If robots.txt times
out, the report says the evidence is missing and the coverage drops β it does
not say the site blocks crawlers.
Absence is only reported when absence is the answer. A 404 on a page we probed
opportunistically is "not applicable". A missing robots.txt is a real finding,
because its absence is itself the fact.
A document read only in part says so. Every fetch is capped at a
per-document-kind byte limit, and any verdict drawn from a body cut off
by that cap carries "truncated": true in its evidence and drops to at
most medium confidence, because anything past the cap is invisible to
us β our limit, not the site's property.
The score
Each check is PASS, WARN, FAIL, N/A or ERROR. Since 0.18.0 the headline result
is Technical Readiness: the open R2 rating of the readiness rules Core
evaluates from its own evidence, published in
docs/r2.md.
It is shown with its coverage and names the rules Core could not measure;
when too little was measured you get INSUFFICIENT_EVIDENCE rather than a
number. The checks themselves are diagnostics:
docs/crosswalk.md
maps each one to the readiness rules that read the same signal, and names the
rules only Scovant Cloud can evaluate, because they need a real agent. The
older five-domain score was deprecated in 0.18.0 (kept behind --legacy-score
in that release only) and is removed in 0.19.0. The rest of the model is in
the methodology document:
docs/methodology.md.
The current ruleset is 2026.10, shipped in 0.3.1. Scores from ruleset 2026.09
and 2026.10 are not comparable β HTTP semantics became required in 2026.10.
What Core deliberately does not do
Core does not drive a browser agent, does not run a purchase simulation, and
does not offer multi-model testing. Those live in Scovant Cloud, our
platform, which imports Core's evidence layer as its scanning foundation and
builds the simulation and monitoring layers on top of it β not the other way
around. Core only answers "can an agent discover, read and understand this
site", which is the part you can verify from the outside, deterministically,
in seconds.
Install
uvx --from scovant-core scovant scan https://example.com
npx @scovant/core scan https://example.com
pip install scovant-core
The npm package is a thin launcher around the same Python engine: its uvx
and pipx paths pin the exact same version as the PyPI release, so those two
give you identical checks and the same ruleset version; if it falls back to
a plain python3 that already has scovant_core installed, you get whatever
version that interpreter has.
There is also a composite GitHub Action for running Core on every pull request,
and scovant mcp starts a stdio MCP server exposing five read-only tools, so an
agent can run the scanner itself.
Contributing scan results is opt-in
Core sends nothing anywhere by default. There is a flag that contributes a
single scan's check statuses and score, together with the scanned site's
domain, to a public research index, and it is off unless you pass it. The
domain is the only part of the URL that is sent: no path, no query string, no
page content, no evidence. The README lists every transmitted field. The
published index carries statuses only, and it is kept separate from the
corpus we scan ourselves.
Contributed client scores are never authoritative: the published index carries
only rows our own server re-scanned and verified.
Licence
Apache-2.0. Every release ships pinned constraints, an SBOM and a signed
release manifest. Issues and pull requests are welcome; the contribution policy
and the rule-admission criteria are in the
repository.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.