Scovant Core 0.26.0: MCP endpoint detection that reads real evidence

Scovant released Core 0.26.0, which replaces its naive MCP endpoint check with evidence-based detection after measuring 8,523 sites and finding that a 200 response at /.well-known/mcp.json rarely indicated a real server. The scanner now validates discovery files, recognizes server cards by structure, follows /.well-known/ai-catalog.json to fetch up to three listed cards, and reports 'not measured' on timeouts, 429s or 5xx errors rather than a false negative. The Technical Readiness model moves to R2.1@7b46d2ed7f8b and the MCP_ENDPOINT_ABSENT rule to version 2.0, with at most four extra passive GET requests per scan.

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 methodology changelog https://scovant.com/scoring/changelog . 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 https://github.com/Scovant/scovant-core/blob/main/CHANGELOG.md .