DEV Community: Sergiy Zhytanskyy

Scovant Core: open-source scanner for AI-agent readiness

Sergiy Zhytanskyy — Thu, 12 Nov 2026 20:25:57 +0000

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.

Scovant Core 0.26.0: MCP endpoint detection that reads real evidence

Sergiy Zhytanskyy — Thu, 12 Nov 2026 18:48:47 +0000

A scanner that asks "does this site expose an MCP server?" usually starts at
one URL: /.well-known/mcp.json. Many sites answer that URL with something: a
catch-all page, a JSON error, a redirect to the homepage. Until this release,
Scovant Core counted an HTTP 200 there as a sign of an endpoint. That was wrong,
so before changing it we measured how wrong.

What we measured

In a corpus of 8,523 sites:

0 published a valid /.well-known/mcp.json
239 answered that path with another document
33 published a valid AI Catalog (/.well-known/ai-catalog.json)
19 had an MCP server card we could resolve

So the one place everyone looks was, in practice, never the place a real server
was described, while the sites that did describe an MCP server mostly did it
through a catalog the old check never read.

What changes in 0.26.0

A discovery file has to be one. A 200 at /.well-known/mcp.json that is an
HTML page, or JSON without an mcpServers server, no longer counts as an
endpoint. The finding now says what was served instead, so the fix is obvious.

Server cards are recognised, not assumed. A card at the well-known card
paths counts only when it looks like a server card: a JSON object with a
non-empty name and a remotes list, a version or a $schema. A JSON error
page at those paths is no card.

The AI Catalog is followed. Core reads /.well-known/ai-catalog.json and
fetches up to three server cards it lists — https and public addresses only,
following up to five redirects on each. A card found that way counts as an MCP
surface, so a site that publishes its server through a catalog stops getting a
false "no MCP endpoint" finding.

No answer is not a "no". If the catalog or a listed card times out, answers
429 or 5xx, or is cut off at our read limit before it parses, the rule reports
not measured instead of a finding. Our failure to read a document is never
evidence about the site — the same rule Core has applied to every other
document since its first release.

What it costs

At most four more requests per scan (the catalog and up to three cards), plus
any redirect hops. Core stays passive: ordinary GETs, no authentication, and it
never calls an MCP endpoint or invokes a tool it discovers.

Model change

The Technical Readiness model id moves to R2.1@7b46d2ed7f8b, and the rule
behind this check, MCP_ENDPOINT_ABSENT, moves to rule version 2.0. Results
produced before and after the release carry different model ids, so a change
in a site's result can always be told apart from a change in how we measure.
Every model change is listed in the
methodology changelog.

Upgrade

pip install -U scovant-core
uvx --from scovant-core scovant scan https://example.com
npx @scovant/core scan https://example.com

The GitHub Action Scovant/scovant-core@v0 picks up 0.26.0 automatically; pin
@v0.26.0 for an exact version. The full list of changes is in the
changelog.