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.
In a corpus of 8,523 sites:
/.well-known/mcp.json
/.well-known/ai-catalog.json)
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.
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.
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.
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
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