ARS 3.2 · Methodologyscore_version ars-3.2.0129 registered checks

How the Agent Readiness Score is computed.

Exactly what the Glintbase scanner checks, how points become a score, and what the score does not claim. Every number on this page comes from the open-source scanner engine and its methodology document.

Last updated 2026-10-12 · score_version ars-3.2.0 · Markdown version

01 / Scope

What ARS measures, and what it does not

ARS 3.2 measures which agent-readiness signals a product publicly exposes, and whether they work when probed: machine-readable docs, specs, MCP servers, auth metadata, and content that agents can read without a browser.

ARS is not validated as a predictor of agent task success. No study correlates ARS with measured agent outcomes yet. Read a score as “readiness signals present and verified”, not “agents will succeed”.

02 / Core Rule

Points only for observed evidence

Every check ends in one of five states. The registry fixes each check's points and whether it is a base or bonus check; the probes only decide the state.

Status	Meaning	Effect on score
`pass`	The scanner observed the evidence	Earns the check's full registry points
`warn` / `fail`	Checked, and the evidence was missing or wrong	Earns 0. Base checks still count in the layer's denominator; bonus checks have no effect
`na`	The surface the check inspects does not exist (e.g. no MCP server, no OpenAPI)	Excluded
`skip`	The surface exists but this scan could not verify the check	Excluded

No check may pass because a related file merely exists, or by assumption.
No partial credit: warn earns 0.
Absent surfaces are penalised once, by their existence check (mcp-server-manifest, openapi-spec, llms-txt-exists, ...). Quality checks for an absent surface are na, so a missing MCP server is not counted again for every MCP quality check.

03 / Scoring

From checks to a 0–100 score

1. Archetype. The site is classified into one of four archetypes, which sets each layer's weight. In a URL scan the classifier sees only the URL: docs., /docs, /documentation or /kb point to docs; /api or api. to API / devtool; /shop, /store, /cart, /checkout or /pricing to e-commerce; /blog, /news or /article to content / media. Anything else defaults to API / devtool. A scan can also be run with an explicit archetype; such scans are stored as history only and never replace a company's latest score.

Layer weights by archetype

Archetype	Discovery	Access	Usability	Payments	Denominator
API / devtool	20	30	35	0	85
Docs / knowledge base	20	30	35	0	85
E-commerce	20	30	40	10	100
Content / media	20	30	0	0	50

2. Layer base score. For each layer, only base checks with a verdict (pass, warn or fail) are “verifiable”:

layer base = round(passed base points ÷ verifiable base points × layer weight)

3. Bonus. Bonus = registry points of passed bonus checks. Payments checks are excluded from the bonus: the Payments layer uses its own OR-scoring. In a URL scan it is scored only for the e-commerce archetype (weight 10), where any one verified payment protocol (ACP, UCP, AP2 or x402) earns the full 10 points; otherwise the layer earns 0.

4. Final score. Bonus points are added to both the numerator and the denominator, so a bonus can raise a score but a missing bonus never lowers one:

score = min(100, round((Σ layer base + bonus) ÷ (denominator + bonus) × 100))

Illustrative example (API / devtool, denominator 85)

Discovery: 4 of 6 verifiable base pts passed → round(4/6 × 20) = 13

Access: 40 of 50 → round(0.8 × 30) = 24

Usability: 10 of 30 → round(10/30 × 35) = 12

Bonus: 6 pts from passed bonus checks

score = round((13 + 24 + 12 + 6) ÷ (85 + 6) × 100) = round(60.4) = 60 → grade C

Grades and bands are defined once; bands are groups of grades, so the two can never disagree.

Score	Grade	Band
95–100	A+	Agent-Native
86–94	A	Agent-Native
70–85	B	AI-Friendly
48–69	C	AI-Capable
28–47	D	Legacy
0–27	F	Legacy

04 / Evidence

Evidence coverage

Because unverifiable checks are excluded, a layer with few verifiable checks rests on little evidence. Every scorecard therefore reports how much evidence the score stands on, and the web report, CLI and Markdown report show it alongside the score:

Field	Meaning
`checksEvaluated` / `checksRegistered`	Checks that reached a verdict (pass, warn or fail) vs. the 129 registered checks
`baseCoverage`	Verified base points ÷ registered base points, across the scored layers (Payments excluded)
`layers.<id>.coverage`, `lowConfidence`	Per-layer share of registered base points that could be verified; the layer is flagged low evidence below 50% (MIN_LAYER_COVERAGE)

Publish the number of checks a scan actually measured, not the registry size. 26 of the 129 registered checks are not probed yet (they report na or skip, or, for mpp-support, can never pass), so no scan evaluates all 129.

Registered base points of unprobed checks still count in the coverage denominator. On a remote URL scan this caps coverage below 100%:

Registered base points a remote URL scan cannot verify (derived from the registry and probe code)

Layer	Registered base pts	Never verifiable	Why
Discovery	21	15	14 pts in unprobed checks (brand-search-accuracy, agentic-search-specific, mcp-registry-listed, skills-sh-listed, agentic-search-usecase); agent-rules-repo (1 pt) is checked only for local codebases
Access	54	7	Seven 1-pt checks not probed yet (e.g. http2-support, dns-caa-record, image-alt-prose)
Usability	41	1	api-sdk-documentation (not probed yet). Docs archetype: mcp-tools-breadth (3 pts) is also skip

As a consequence, Discovery can verify at most 6 of its 21 registered base points on a URL scan (29%), so it is always flagged low evidence there, and its 20-point weight rests on four checks: registry-branding, ard-catalog, npm-sdk-package and robots-ai-policy-quality.

05 / Probes

What each layer probes

Registry at ars-3.2.0: 129 checks

Layer	Checks	Base (points)	Bonus (points)	Not yet probed
Discovery	17	10 (21)	7 (14)	6
Access	45	37 (54)	8 (14)	7
Usability	61	24 (41)	37 (68)	12
Payments	6	0	6 (16)	1

Discovery

robots.txt AI-crawler policy (ClaudeBot, GPTBot, PerplexityBot, Google-Extended, anthropic-ai, cohere-ai, OAI-SearchBot), ARD / AI catalog files (/.well-known/ard.json, /.well-known/ai-catalog.json, /ai-catalog.json), MCP manifest branding, a Wikidata official-website claim (P856, matched on the registrable domain) and an npm package under the brand name that links back to the brand's domain or GitHub org. The brand is derived from the registrable domain (docs.stripe.com → stripe). An HTML page served at /robots.txt counts as no robots.txt, and # comments are stripped before directives are read. Agent rules files are only checked for local codebases (skip on URL scans).

Access

Zero-JS content, a soft-404 canary (a random path that must return 404 or 410), llms.txt (exists, formatting, and up to 8 declared links actually fetched; at least 80% must resolve), llms-full.txt, markdown content negotiation, OpenAPI at 13 standard paths (JSON specs are parsed), HTTP hygiene headers, sitemap, security.txt, and bot challenges (challenge-page markers or cf-mitigated: challenge, re-reading 403 / 429 / 503 bodies).

If the homepage cannot be fetched (no successful response and no body), every check derived from its HTML or response headers is skip (“Homepage could not be fetched”), and anti-crawler-challenge-free is skip unless a challenge was actually observed. If the soft-404 canary request does not complete, anti-spa-404 is skip.

Usability

MCP discovery tries standard paths on the site, the docs. / api. / mcp. subdomains of the registrable domain (so www.acme.co.uk probes docs.acme.co.uk), and the root plus standard paths of mcp. subdomains. A 401/403 only counts as an MCP server on an MCP-like path or host and when the response is a JSON-RPC envelope or carries an RFC 9728 WWW-Authenticate: ... resource_metadata= challenge. A generic 401 is not MCP evidence. When several candidates respond, the first to answer is used.
Live MCP probe: initialize on the 2026-07-28 and legacy wire forms (2026-07-28 support requires the server to answer with that version), tools/list (carrying the session id), schema strictness and readOnlyHint / destructiveHint annotations read from the real tool definitions, capabilities (prompts, resources, logging) from the initialize result, and an unknown-tool canary call that must be answered with an in-channel error.
Safety rule: the prober calls a real tool only if the server annotates it readOnlyHint: true and it takes no required arguments. Unannotated tools are never called. SSRF behaviour is not probed.
Transports: Streamable HTTP is a base check; legacy SSE is bonus only.
auth.md stage checks are bonus only (an emerging proposal) and each stage must appear in the file. OAuth protected-resource (RFC 9728) and authorization-server (RFC 8414) metadata must be valid JSON with the expected fields; the bearer and scope checks read them.
OpenAPI inspection of the parsed spec: unique operationIds, JSON request schemas, typed error responses (on at least 50% of operations), Idempotency-Key, rate-limit headers, versioned URIs, search, cursor pagination, webhooks, problem+json, OpenAPI 3.1. YAML specs are detected but not parsed (skip).
WebMCP (bonus): modelContext tool registration or declarative form tool attributes in the homepage HTML.

Payments

Only for the e-commerce archetype, or local codebase scans with commerce signals: ACP (/checkout_sessions, /agentic_commerce/delegate_payment), UCP (/.well-known/ucp), AP2 (/.well-known/ap2), x402 (HTTP 402 at /api/payment) and MPP. MPP detection is not implemented yet, so mpp-support never passes. For other archetypes all six checks are skip.

06 / Safety

Safety and etiquette

What the scanner does, and does not do

Read-only probing. Pages, files and metadata are fetched with GET (the unscored surface inventory also sends HEAD requests). The only POST requests are MCP JSON-RPC messages: initialize, tools/list, one call to a non-existent canary tool, and at most one tools/call with empty arguments.
Tool calls. That one call goes only to a tool the server itself annotates readOnlyHint: true and that declares no required arguments. Unannotated tools are never called.
No SSRF probing. The scanner does not send private-network URLs to MCP servers; mcp-ssrf-guard is reported as skip.
Private-network targets are refused. Loopback, private, link-local, shared (CGNAT), reserved and cloud-metadata addresses and host names (localhost, *.local, *.internal), URLs with embedded credentials and non-standard ports are rejected before the scan starts. In the scored probes the policy is applied to every request and re-checked on every redirect hop (up to 5). The policy checks host names and IP literals; it does not resolve DNS.
Unreachable sites are not scored. If the homepage never answers (no HTTP response at all, after one retry), the scan stops with TARGET_UNREACHABLE instead of producing a score. If the probe suite itself fails, the scan fails with PROBES_FAILED; there is no fallback score.
Bounded requests. Every scored probe request has a timeout (1.5 to 15 seconds) and a response size cap (2 MB by default; up to 12 MB for OpenAPI specs). MCP endpoint candidates and OpenAPI paths are tried four at a time and probing stops at the first hit; at most 8 llms.txt links are fetched. The unscored surface inventory that runs alongside the probes has a 25-second budget.
Rate limits. The hosted scanner accepts 5 scans per hour per IP on /api/scan, and the hosted MCP endpoint 60 requests per minute.
Identification. Scored probe requests carry a desktop browser User-Agent string; the unscored surface inventory sends Glintscanner-V2/2.0, and MCP initialize requests name the client glintbase-live-probe or glintbase-audit. Discovery also queries two third parties by brand name: the Wikidata API and the npm registry.

07 / Registry

All 129 checks

The complete registry at ars-3.2.0: 71 base checks (116 points) and 58 bonus checks (112 points). Descriptions are the registry's own. “Not yet probed” marks the 26 checks the current probe code can never pass; they are excluded from scoring (or, as bonus checks, never add points).

Showing 129 of 129 checks

CheckLayerTypePoints

08 / Limitations

Known limitations

No outcome validation. ARS is not yet shown to predict agent task success.
Single-sample measurements. Latency and availability come from one request per URL.
Keyword heuristics. auth.md stage detection and WebMCP detection match keywords and can be gamed.
Fixed paths. OpenAPI is only found at standard paths; it is not followed from links, headers or llms.txt.
Endpoint choice. When several MCP candidates respond, the first to answer is used.
Auth-gated MCP without RFC 9728. A gated MCP server that answers 401 with neither a JSON-RPC body nor resource_metadata= is not detected.
Absent MCP weighs heavily. For API and docs archetypes, a site without an MCP server or OpenAPI spec typically scores 0 on most of the 35-point usability layer. This is intended by the current weights but is a policy choice worth revisiting.
Archetype drives rubric. A docs host whose MCP server is a product (action) server is judged by the docs rubric (e.g. auth-gated MCP is a warn).
Unprobed registry checks. 26 registered checks are not probed yet; on URL scans the Discovery layer is always low evidence (see Evidence coverage).

09 / Changelog

Changes from ARS 3.1 to 3.2

Checks pass only on observed evidence; MCP, OpenAPI, auth.md, llms.txt link and bot-challenge checks were rewritten accordingly.
The registry owns points and bonus flags; no partial credit for warn.
Legacy SSE transport and the 8 auth.md stage checks moved to bonus.
mcp-inchannel-signalling removed (duplicate of mcp-error-reporting); the registry is 129 checks.
2026-07-28 wire-form support requires the server to negotiate that version.
MCP servers at the root of mcp. subdomains are discovered.
Evidence coverage and low-evidence layers are reported on every scan.
Grades and bands unified.
Auth-gated MCP detection requires a JSON-RPC envelope or an RFC 9728 resource_metadata challenge.
Unreachable homepages and incomplete soft-404 canaries produce skip, not fail / warn / pass.
A failed probe suite fails the scan (PROBES_FAILED) instead of falling back to a discovery-only score.
Scans run with an explicit archetype override are stored as history only and never replace a company's latest score.

ARS 3.1 and earlier scores are not comparable with 3.2. Scorecard pages flag older scans and offer a rescan. Every scan is stamped with its score_version; compare scores only within the same version.

10 / Sources