ALPICScanner New scan

What the scanner checks.

From the basics that let agents read your website to the tools that help them act. Explore each check, why it matters, and the module it belongs to.

84 of 84 checks · Foundations first

Website foundations38

Access and readable content come first, followed by navigation and guidance.

Public content access

Agents need the public content that your site advertises to be reachable. We check whether required public resources are available without a login wall, bot challenge or soft error.

HTTP Access & RecoveryAccessMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

The starting page, canonical homepage and required public pages linked from llms.txt. Their collected responses must avoid authentication walls, bot challenges and soft errors that advertise success without delivering the public content.

Method

Inspected core and llms.txt-linked public responses for authentication walls, challenges and soft errors.

Passing criteria

Assessed public core pages and llms.txt-declared pages must provide substantive unauthenticated content without a definitive challenge, login wall or soft error.

Sources

RFC 9110: HTTP authentication (opens in a new tab)

access.public-surface-availability

robots.txt access policy

Agents need clear rules before retrieving public paths. We check whether robots.txt establishes an interpretable access policy, including default access when absent.

Access PolicyAccess
How we check it

What we look for

A /robots.txt response with matching plain-text content and parseable RFC 9309 directives. An absent policy or HTML fallback establishes default access; a present malformed policy cannot establish clear rules.

Method

Inspected the /robots.txt response, media type and parsed directives under RFC 9309.

Passing criteria

All origins. Absent RFC 9309 policy establishes the default; a present policy must have a valid media/body pair and deterministically parse.

Sources

RFC 9309: Robots Exclusion Protocol (opens in a new tab)

policy.robots-determinability

Agent crawler reachability

A permission declaration alone does not ensure the server will provide a readable response. We check whether configured agents allowed by robots policy can retrieve useful content.

HTTP Access & RecoveryAccessMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Collected responses for each configured named-agent User-Agent allowed by robots.txt. Successful access requires substantive static content without a definitive block, login wall or challenge. A robots policy denial excludes that identity from this retrieval check.

Method

Inspected responses for policy-permitted agent identities for substantive content, blocks and challenges.

Passing criteria

For each configured identity whose effective policy permits retrieval; substantive response passes, definitive block/challenge fails, policy denial is N/A.

Sources

RFC 9309: Robots Exclusion Protocol (opens in a new tab)RFC 9110: HTTP Semantics (opens in a new tab)

access.permitted-agent-retrieval

Content behind auth

Unexpected access barriers interrupt agents following links to content presented as public. We check whether sampled pages advertised through the public sitemap return a login wall.

HTTP Access & RecoveryAccess
How we check it

What we look for

Sampled representative pages advertised only by the public sitemap. A recognizable login wall or challenge is a failure. Core pages and required llms.txt links are assessed separately under public content access.

Method

Inspected sampled sitemap-only pages for recognizable login walls or challenge responses.

Passing criteria

When a sitemap advertises an assessed representative page, it must not resolve to a definitive login wall. Public core pages are evaluated by the public-access check.

Sources

Sitemaps XML format (opens in a new tab)RFC 9110: HTTP authentication (opens in a new tab)

access.declared-page-login-wall

Content without JavaScript

HTML, Markdown or structured alternatives can let agents read the page without running JavaScript. We check whether sampled pages expose useful content in a static response.

Content & MarkdownAccess
How we check it

What we look for

For each sampled page, useful static HTML, Markdown or a collected alternate. Text needs at least 500 letters or digits outside boilerplate to be conclusive; 100–499 is ambiguous. Structured JSON/XML/YAML needs valid parsing, at least five scalar values and 100 bytes. Empty shells and access challenges do not qualify as readable text.

Method

Inspected each sampled page and its collected alternate representations for substantive static content.

Passing criteria

Retain substantive/ambiguous/near-empty thresholds, but resolve per-page alternative qualifying HTML, Markdown, or structured representations before assigning points; do not fail an HTML shell if its declared static alternate supplies the content.

Sources

HTML Living Standard: Semantics, structure, and APIs (opens in a new tab)

representation.substantive-static

Static navigation structure

Parseable sections and links help agents locate content and choose their next resource. We check static titles and navigation structure in sampled pages or their alternatives.

Site NavigationDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Sampled HTML needs a title or H1 plus a main/article landmark, usable heading hierarchy or internal link. Markdown needs an H1 plus a section heading or link. A parseable, nonempty JSON/XML/YAML representation is also accepted; collected alternates can satisfy the check for the same page.

Method

Inspected static titles, headings, landmarks and links, including collected alternate formats.

Passing criteria

Retain the format-neutral structure rule and alternative representations. This answers finding onward resources, hence Discover.

Sources

HTML Living Standard: Links (opens in a new tab)

representation.parseable-navigation

Redirect hygiene

Valid chains help agents reach the intended content without loops or unsafe downgrades. We check recorded redirects for core public URLs against accepted redirect and origin rules.

HTTP Access & RecoveryAccess
How we check it

What we look for

Recorded HTTP redirects for the starting URL and canonical homepage. Chains must avoid loops, HTTPS downgrades, missing or invalid Location targets and rejected canonical origins. Redirect issues on secondary artifacts remain supporting findings rather than core failures.

Method

Inspected recorded core redirect chains for loops, invalid targets, HTTPS downgrades and identity violations.

Passing criteria

Starting Resource and distinct Canonical Origin homepage redirect chains; accepted HTTP chain and canonical identity rules pass. A core failure changes Stable Addressability and a Starting Resource failure invokes the baseline gate. Invalid redirects on secondary artifacts remain supporting URL-level evidence and never fail the baseline by themselves.

Sources

RFC 9110: HTTP Semantics (opens in a new tab)

address.redirect-chain-validity

Consistent agent access

Every permitted agent needs useful public content, even if formats differ. We compare responses for at least two identities for substantive content and access barriers.

HTTP Access & RecoveryAccessMust-have · missing = 0 pointsMaximum tier C unless passed
How we check it

What we look for

Responses for at least two policy-permitted configured User-Agent identities. Each must contain substantive static content without a login wall, challenge or soft error. Different bytes or representation formats are allowed; fewer than two permitted identities leaves nothing to compare.

Method

Compared substantive-content and challenge checks across responses for permitted agent identities.

Passing criteria

For two or more permitted identities, all compared public responses are substantive and free of definitive challenge/login/error regressions. Different bytes or formats alone do not fail.

Sources

RFC 9110: HTTP Semantics (opens in a new tab)

access.user-agent-parity

Static document structure

Headings and landmarks help agents distinguish main content from navigation. We inspect server-returned HTML for these cues as a static approximation of document structure.

HTML Structure & ControlsAccess
How we check it

What we look for

Substantive server-returned HTML with headings or a main/article landmark. A page fails only when both are absent. Multiple or missing H1s, heading-level jumps and a missing landmark are reported as advisories; JavaScript-generated structure is not inspected.

Method

Inspected substantive server HTML for headings and main/article landmarks, recording structural advisories.

Passing criteria

Substantive server HTML; fail only when both headings and a main/article landmark are absent. H1 count, heading jumps, and a missing landmark remain URL-level advisories. Label as static approximation.

Sources

W3C WAI: Page sections (opens in a new tab)

html.static-document-structure

Static names on controls

Text and labels help agents understand intended actions; JavaScript behavior and runtime accessibility are not evaluated. We check static HTML for a name source on native controls.

HTML Structure & ControlsUse
How we check it

What we look for

Native controls in substantive server HTML with direct text, an associated label, aria-label or aria-labelledby pointing to retained text. The scanner evaluates static name sources, not names computed by the browser after JavaScript runs.

Method

Inspected server-rendered native controls for text, label, aria-label and aria-labelledby name sources.

Passing criteria

Server-rendered native controls; require direct text, associated label, aria-label, or resolvable aria-labelledby. Static approximation only.

Sources

W3C WAI: Providing accessible names and descriptions (opens in a new tab)

html.static-accessible-name-source

Static form field labels

Labels help agents understand expected inputs; the scanner does not fill in or submit forms. We check server-rendered form fields for associated labels or ARIA name sources.

HTML Structure & ControlsUse
How we check it

What we look for

Non-hidden form fields in substantive server HTML. Each needs a label with matching for/id, a wrapping label, aria-label or resolvable aria-labelledby. Placeholder text alone does not qualify, and the scanner does not fill or submit the form.

Method

Inspected server-rendered fields for label[for], wrapping labels, aria-label and aria-labelledby.

Passing criteria

Server-rendered non-hidden form fields; require a matching label[for], wrapped label, aria-label, or resolvable aria-labelledby.

Sources

W3C WAI: Labeling controls (opens in a new tab)

html.static-form-label-association

Consistent robots.txt agent rules

Consistent allow or deny instructions help agents interpret your policy without guessing your intent. We check named-agent rules for malformed or contradictory declarations.

Access PolicyAccess
How we check it

What we look for

User-agent groups and Allow/Disallow directives in /robots.txt. Rules must parse without malformed lines or conflicting declarations for the same agent and path. Explicit allow, explicit deny and inherited default access are equally valid policy outcomes.

Method

Parsed robots.txt agent groups and checked for malformed or contradictory allow/disallow declarations.

Passing criteria

Parsed robots policy and pinned identity set; rules must resolve without invalid syntax or contradictory authoritative declarations. Allow and deny are equal-quality outcomes.

Sources

RFC 9309: Robots Exclusion Protocol (opens in a new tab)

policy.named-agent-consistency

robots.txt agent-user policy

Allowing those visits lets people ask an agent to read public content; training crawlers are separate. We check effective access for configured agents acting on a user's request.

Access PolicyAccess
How we check it

What we look for

Effective /robots.txt rules for ChatGPT-User, Claude-User and Perplexity-User on the assessed public core URLs. Each must be allowed, including default permission when no policy is published. Training-crawler rules do not determine this check.

Method

Resolved robots.txt rules for ChatGPT-User, Claude-User and Perplexity-User against public core URLs.

Passing criteria

For the pinned user-initiated identities, effective policy permits the assessed public core URLs (including default permission). Training-crawler policy is excluded. Denial is a scored access limitation, not invalid robots syntax.

Sources

RFC 9309: Robots Exclusion Protocol (opens in a new tab)

policy.agent-user-effective-access

Content-Signal syntax

Machine-readable preferences help agents interpret intended content uses, whether allowed or denied. We check published Content-Signal headers for recognized, well-formed directives.

Access PolicyAccess
How we check it

What we look for

Content-Signal response headers already collected during the scan. Each comma-separated directive must use a recognized name—ai-train, search or ai-input—and an explicit yes or no value. Missing headers are outside this check; either preference is valid.

Method

Parsed retained Content-Signal headers for recognized directive names and yes/no values.

Passing criteria

Applies only when Content-Signal occurs; validate known directives/scopes and contradictions, never preference yes over no.

Sources

Content Signals (opens in a new tab)

policy.content-signals-validity

Agent-friendly 404s

A broken URL should leave agents a route back to useful content. We inspect a safe missing-path response for HTTP 404 or 410 and a static guidance link.

HTTP Access & RecoveryAccessMust-have · missing = 0 pointsMaximum tier C unless passed
How we check it

What we look for

The response to a randomized, safe missing path. It must return HTTP 404 or 410 and contain a static HTML anchor or Markdown link to useful public content, instead of HTTP 200 with an app shell or a dead-end error page.

Method

Inspected the randomized missing-path response for HTTP 404/410 and a static guidance link.

Passing criteria

The randomized safe missing path returns HTTP 404 or 410 and a usable route back to public content.

Sources

RFC 9110: 404 Not Found (opens in a new tab)

recovery.not-found-guidance

Sitemap exists

A usable sitemap gives agents a list of page locations to explore without guessing URLs. We check that published sitemaps can be parsed as Sitemap 0.9 XML.

Site NavigationDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Sitemaps declared by robots.txt Sitemap directives, or qualifying XML at /sitemap.xml. Each applicable document must resolve and parse as Sitemap 0.9 XML; an undeclared missing file or HTML fallback does not count as a published sitemap.

Method

Inspected declared sitemaps and /sitemap.xml responses for qualifying Sitemap 0.9 XML.

Passing criteria

Applies when declared or when /sitemap.xml returns non-fallback XML; parse Sitemap 0.9 within fixed budgets. Absence is N/A.

Sources

Sitemaps XML format (opens in a new tab)

discovery.sitemap-validity

Sitemap dates (lastmod)

Valid dates help agents interpret your metadata; this check does not reward recent content. We check the syntax of update dates published in sampled sitemap entries.

Site NavigationDiscover
How we check it

What we look for

The lastmod fields in sampled entries from valid sitemap XML. Every published value must parse as a valid W3C date or datetime. Omitting lastmod is outside this check, and no recent-update requirement is applied.

Method

Validated published sitemap lastmod values against W3C datetime syntax.

Passing criteria

When lastmod is published, every sampled value is a valid W3C datetime. Missing lastmod is N/A; no age/freshness preference.

Sources

Sitemaps XML format (opens in a new tab)Google Search Central: Build and submit a sitemap (opens in a new tab)

sitemap.lastmod-observation

Typed discovery links

A recognized relation tells agents whether a target is documentation, a contract or another declared resource. We check typed discovery links in HTTP headers and HTML.

Site NavigationDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

HTTP Link headers or typed HTML links with recognized relations, such as service-desc, service-doc, describedby, agent-card, agent-skills, api-catalog or alternate. Targets must parse into absolute HTTP(S) URLs; the target artifact has its own validity check.

Method

Inspected parsed HTTP and HTML links for recognized relations and resolved HTTP(S) targets.

Passing criteria

Starting/home/page HTTP and HTML typed links; parse RFC 8288 and resolve recognized relations. The discovered artifact's own Check decides module credit.

Sources

RFC 8288: Web Linking (opens in a new tab)

discovery.typed-link-validity

DNS-AID record validity

DNS-AID records give agents a discovery route to your published capabilities. We validate collected record syntax and service fields without contacting the advertised endpoints.

Site NavigationDiscoverMust-have · missing = 0 points
How we check it

What we look for

SVCB/HTTPS answers for _index._agents, _a2a._agents and _mcp._agents on the domain, plus the _index._agents TXT answer. Matching records need valid service targets and parameters; cap/policy URLs must use HTTPS. No DNSSEC requirement or advertised-endpoint request is made.

Method

Inspected bounded DNS-AID query responses and validated advertised record names and service parameters.

Passing criteria

When an authoritative DNS-AID record is declared, its pinned record syntax and target fields validate. No DNSSEC-presence requirement. Unknown discovery is unresolved; collection work required.

Sources

RFC 9460: Service Binding and Parameter Specification via the DNS (opens in a new tab)

discovery.dns-aid-observation

llms.txt exists

An llms.txt guide tells agents where to start and which content to explore. We inspect /llms.txt and /.well-known/llms.txt for a qualifying non-HTML document.

llms.txtDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Either /llms.txt or /.well-known/llms.txt containing non-HTML text with at least 100 normalized characters and no soft-error response. An absent file or HTML fallback is not an agent index; a recognizable but too-short text file is invalid.

Method

Inspected /llms.txt and /.well-known/llms.txt responses for non-HTML, substantive agent-index content.

Passing criteria

The two settled locations; any qualifying representation is an alternative path. Both absent is N/A; a recognizable non-fallback malformed file fails only this path.

Sources

The llms.txt proposal (opens in a new tab)

discovery.llms-file

llms.txt formatting

A predictable index makes it easier for agents to navigate your selected resources. We check whether a qualifying llms.txt follows the supported heading and linked-list structure.

llms.txtDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

A qualifying llms.txt with exactly one Markdown H1, at least one H2 section and a Markdown list containing links. A free-form file without these structural signals does not satisfy the supported index format.

Method

Inspected qualifying llms.txt files for one H1, section headings and Markdown lists of links.

Passing criteria

Qualifying file; apply the pinned proposal structure.

Sources

The llms.txt proposal (opens in a new tab)

discovery.llms-structure

llms.txt links resolve

Working references make the index useful for agents looking for documentation and other relevant content. We evaluate all declared llms.txt links against the responses collected by the scan.

llms.txtDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Every unique Markdown link from qualifying llms.txt files is evaluated against retained responses. Retrieved targets must resolve to public resources. Invalid or broken links fail; uncollected or incomplete targets remain unverified. Scan request limits still apply.

Method

Evaluated all unique llms.txt links against retained responses and counted passed, failed and unverified targets.

Passing criteria

File with eligible links; evaluate every unique declared link against retained collection evidence. Uncollected or incomplete targets remain unverified; this check does not expand the collection budget.

Sources

The llms.txt proposal (opens in a new tab)

discovery.llms-reference-integrity

Section-level llms.txt files

Scoped indexes help agents explore one part of a site without searching the entire domain. We check explicitly linked section-level llms.txt files for retrieval and document structure.

llms.txtDiscoverMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

Explicitly linked section indexes such as /docs/llms.txt. Each collected file must resolve as non-HTML text with at least 100 normalized characters, one H1, an H2 section and a Markdown linked list. The scanner does not require undeclared section indexes.

Method

Inspected explicitly linked scoped llms.txt responses, text length, headings and linked lists.

Passing criteria

When scoped files are explicitly linked, all eligible sampled files resolve and satisfy the pinned llms document rules. No scoped files means N/A.

Sources

The llms.txt proposal (opens in a new tab)

discovery.llms-scoped-file-observation

Agent usage instructions

Clear instructions help agents choose a resource; the scanner detects declared signals rather than grading meaning. We check agent-facing documents for explicit purpose or usage guidance.

Agent GuidanceUse
How we check it

What we look for

Qualifying llms.txt, agents.md, SKILL.md or declared agent/documentation Markdown with an explicit Purpose, When to use, Usage, How to use, Routing, For agents or Getting started heading/label, or a Use … when instruction. SKILL.md also needs name and description frontmatter.

Method

Inspected qualifying agent documents for explicit purpose, usage or when-to-use headings and labels.

Passing criteria

Qualifying llms.txt, root /agents.md, valid declared SKILL.md, or explicitly declared Markdown agent/documentation resource. Require one finite explicit signal: Purpose, When to use, Usage, How to use, Routing, For agents/For AI agents, or Getting started heading/label; a “Use … when” instruction also qualifies. No semantic grading.

Sources

The llms.txt proposal (opens in a new tab)

docs.agent-usage-instructions

Markdown agent docs

Supporting this format can reduce page markup and give agents a simpler representation to read. We check whether a requested Markdown representation contains useful Markdown content.

Content & MarkdownAccess
How we check it

What we look for

Collected requests with Accept: text/markdown. A qualifying response must contain actual substantive Markdown rather than HTML mislabeled as Markdown; text needs at least 500 letters or digits to be conclusive. The default HTML representation is evaluated separately.

Method

Inspected collected Accept: text/markdown responses for matching media types and substantive Markdown.

Passing criteria

Starting Resource, Canonical Origin homepage, and every Representative Page with Accept: text/markdown; a valid substantive Markdown response is an alternative representation for that page, and a page that negotiates while another does not is recorded for B-MC-3 consistency. No negotiated variant is N/A.

Sources

RFC 9110: Content Negotiation (opens in a new tab)The llms.txt proposal (opens in a new tab)

representation.markdown-negotiation

Markdown negotiation caching

Correct cache separation helps agents receive the representation they requested. We check Vary headers when a collected response changes format based on Accept.

Content & MarkdownAccess
How we check it

What we look for

A default response and its Accept: text/markdown variant for the same URL. If the successful responses use different media types and the variant is Markdown, its Vary header must include Accept so caches distinguish the formats.

Method

Compared collected default and Markdown response formats and inspected Vary: Accept headers.

Passing criteria

When representation selection depends on Accept, Vary includes Accept. No Accept selection means N/A.

Sources

RFC 9110: Vary (opens in a new tab)

address.negotiation-vary

Markdown URL fallback

A usable twin gives agents another way to read the page and fulfills the alternate representation you advertise. We check published Markdown copies for useful Markdown content.

Content & MarkdownAccess
How we check it

What we look for

Declared or recognizable Markdown-twin responses, such as a page's .md copy. Each assessed twin must resolve to substantive Markdown. A missing promised twin fails; an undeclared absent path or HTML fallback is not treated as an advertised copy.

Method

Inspected declared or recognizable Markdown-twin responses for format and substantive content.

Passing criteria

Evaluate only authoritative twin declarations or recognizable non-fallback Markdown. Each assessed twin is substantive Markdown. An undeclared absent/HTML fallback probe is excluded; known declared missing twin fails.

Sources

The llms.txt proposal (opens in a new tab)

representation.markdown-twin-observation

Markdown alternate link

Reliable alternate links let agents discover and retrieve the format your site promises. We check whether declared Markdown alternate links lead to substantive Markdown.

Content & MarkdownAccess
How we check it

What we look for

HTTP or HTML rel=alternate links whose target is a .md/.markdown URL or a recognized Markdown response. Every assessed target must resolve to substantive Markdown; a declaration pointing at HTML, an empty file or a broken resource does not qualify.

Method

Resolved typed Markdown alternate links against collected responses and checked their content.

Passing criteria

Typed rel=alternate with Markdown media type; resolve and validate the declared representation.

Sources

HTML Living Standard: Link type alternate (opens in a new tab)RFC 8288: Web Linking (opens in a new tab)

discovery.markdown-alternate

Markdown frontmatter validity

Predictable metadata helps agents distinguish document attributes from its main content. We check published Markdown frontmatter for valid, bounded YAML and supported value shapes.

Content & MarkdownAccess
How we check it

What we look for

Markdown beginning with a --- frontmatter delimiter. The block must close within 65,536 characters and parse as a YAML mapping with at most 1,000 keys and supported scalar, scalar-array or scalar-map values. Frontmatter is validated when present, not required on every document.

Method

Parsed leading Markdown frontmatter as bounded YAML and checked metadata value shapes.

Passing criteria

Markdown beginning with a frontmatter delimiter; require bounded valid YAML and syntactically valid scalar metadata. Absence is N/A.

Sources

representation.markdown-frontmatter-validity

Agent-specific representations

Correct variants let agents read your content without receiving another client's cached format. We check usable content and cache separation when responses are selected by agent identity.

Content & MarkdownAccess
How we check it

What we look for

Named-agent response variants where Vary: User-Agent or differing media types establishes User-Agent-based selection. Every assessed variant must be substantive and declare Vary: User-Agent. Byte differences alone do not establish agent-specific formatting.

Method

Inspected agent-selected response formats for substantive content and Vary: User-Agent.

Passing criteria

When the server selects representations by agent User-Agent, all eligible variants are usable and Vary includes User-Agent. No selection by User-Agent means N/A; arbitrary hash variance alone does not establish selection.

Sources

RFC 9110: Vary (opens in a new tab)

representation.agent-ua-variant-observation

Page token budget

Compact content leaves agents room to reason; this budget is a scanner preference. We check whether each sampled page has a useful representation within 32,000 approximate tokens.

Content & MarkdownAccess
How we check it

What we look for

For every sampled page, at least one qualifying collected representation at or below 32,000 approximate tokens, estimated as normalized characters divided by four. A smaller Markdown or structured alternate can qualify; truncated or unavailable alternatives remain unresolved.

Method

Estimated tokens from normalized text and selected the smallest qualifying representation per page.

Passing criteria

For every assessed page, at least one qualifying static representation fits 32,000 approximate tokens. No qualifying content is handled by substantive-content checks; missing evidence is unresolved. Proposed product budget, not a standard.

Sources

representation.context-size-observation

Code fence validity

Balanced blocks help agents separate examples from surrounding instructions and interpret the rest of the document. We check whether published Markdown code fences close correctly.

Content & MarkdownAccess
How we check it

What we look for

Backtick or tilde code fences in collected Markdown. Each opening fence must close with the same marker, at least the opening length and no trailing non-whitespace text, following CommonMark fence rules. Documents without fenced blocks are outside this check.

Method

Inspected Markdown fence markers and closing lengths using CommonMark fence rules.

Passing criteria

Markdown containing fenced code; require every fence to close under CommonMark 0.31.2.

Sources

CommonMark 0.31.2: Fenced code blocks (opens in a new tab)

representation.markdown-fence-validity

JSON-LD validity

Structured records help agents extract published facts without inferring them from the page layout. We check inline JSON-LD blocks for parseable JSON and a compatible root.

JSON-LDDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Inline script elements with type=application/ld+json in collected HTML. Every block must parse as JSON with an object or array root. This checks readable JSON-LD structure, not completeness of every schema.org property or truth of the published facts.

Method

Parsed inline application/ld+json blocks and checked their JSON-LD root shapes.

Passing criteria

HTML containing application/ld+json; require valid JSON/JSON-LD syntax using only inline or already-retrieved contexts.

Sources

W3C Recommendation: JSON-LD 1.1 (opens in a new tab)

structured-data.jsonld-validity

JSON-LD identity completeness

A complete identity tells agents who you are and what you offer. We look for a typed organization, product or application with a name, description, URL and supporting details.

JSON-LDDiscover
How we check it

What we look for

At least one Organization, Product or SoftwareApplication with @type, name, description, absolute url and one supporting field. Organization: logo, sameAs, contactPoint, email, telephone or address. Product: image, brand, offers, sku, gtin or mpn. SoftwareApplication: applicationCategory, operatingSystem, offers, downloadUrl or screenshot. Empty supporting values do not count; their content is not verified.

Method

Inspected collected JSON-LD identities for four core fields and type-specific supporting details; listed missing fields.

Passing criteria

At least one Organization, Product or SoftwareApplication in inspected JSON-LD has @type, nonempty name and description, an absolute HTTP(S) url and one nonempty supporting field relevant to its type. This is a scanner completeness rule, not a Schema.org requirement or truth verification.

Sources

Schema.org: Organization (opens in a new tab)Schema.org: Product (opens in a new tab)Schema.org: SoftwareApplication (opens in a new tab)

structured-data.identity-completeness

JSON-LD identity links (sameAs)

Clear identity references help agents locate related profiles; URL validity does not prove they represent the same entity. We check whether JSON-LD sameAs values are absolute HTTP(S) links.

JSON-LDDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Every sameAs value in valid collected JSON-LD, including arrays. Values must be absolute http:// or https:// URLs. The scanner validates the link syntax; it does not prove that the linked profiles represent the same person or organization.

Method

Inspected JSON-LD sameAs values for absolute HTTP(S) URL syntax.

Passing criteria

JSON-LD node with sameAs; every value must be an absolute HTTP(S) URL. No identity-equivalence claim.

Sources

Schema.org: sameAs (opens in a new tab)

structured-data.same-as-validity

JSON-LD type validity

Recognizable types tell agents what records describe; the number or variety of types does not earn extra credit. We check whether declared JSON-LD types expand to absolute identifiers.

JSON-LDDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Declared JSON-LD @type values. Each must already be an absolute IRI or expand through a local @context, prefix or recognized vocabulary such as schema.org. Unavailable remote context leaves the type unresolved; publishing more types does not earn more credit.

Method

Expanded JSON-LD type identifiers using declared local contexts and recognized vocabularies.

Passing criteria

When JSON-LD nodes declare @type, each type is a valid absolute IRI or expands through a retained context/vocabulary to one. Do not reward the number or breadth of types; no external context retrieval just to award points.

Sources

W3C Recommendation: JSON-LD 1.1 (opens in a new tab)Schema.org data model (opens in a new tab)

structured-data.type-inventory

Organization schema identity

A company name and website URL help agents identify who is behind the content. We inspect Organization records for those fields and validate contact details when present.

JSON-LDDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

JSON-LD nodes whose @type identifies Organization. Each needs a nonempty name and absolute HTTP(S) url. If email, telephone, contactPoint or address is published, its value must have a supported nonempty shape. Optional contact fields do not need to be added solely for this check.

Method

Inspected Organization nodes for names, absolute website URLs and published contact/address field shapes.

Passing criteria

When an Organization is declared, it has a nonempty name and absolute HTTP(S) url; present contact/address fields have valid declared shapes. These minimum identity fields are a proposed product preference, not Schema.org required properties.

Sources

Schema.org: Organization (opens in a new tab)

structured-data.organization-field-observation

Page metadata validity

Valid fields help agents identify and interpret the page. We check metadata already published in HTML for usable language tags, canonical URLs and Open Graph values.

Page MetadataDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

Present html lang, canonical link and Open Graph metadata in collected HTML. Language tags must match the supported syntax; canonical and Open Graph URL fields must be absolute HTTP(S) URLs; other published values cannot be empty. Missing optional metadata is outside this validity check.

Method

Inspected html lang, rel=canonical and Open Graph fields in collected HTML for valid values.

Passing criteria

HTML with any canonical/lang/Open Graph metadata; validate present values and report absent fields without scoring readiness.

Sources

HTML Living Standard: Document metadata (opens in a new tab)The Open Graph protocol (opens in a new tab)

html.metadata-validity

Declared capabilities46

Additional checks for the APIs, tools and protocols your website offers.

Public API documentation

A discoverable guide helps agents understand the published API before preparing requests. We check whether first-party API documentation is linked or published at a conventional location, and whether it is substantive.

APIDiscoverMust-have · missing = 0 pointsMaximum tier C unless passed
How we check it

What we look for

First-party service-doc or describedby links to public API documentation, or conventional locations: docs., developers. and api. subdomains and the /docs, /developers, /api-docs, /reference and /api paths. Targets must contain at least 200 visible characters; conventional locations must also mention API, SDK, endpoint, developer, reference, authentication or webhook terms. Unrelated publishers do not count.

Method

Inspected first-party API documentation links and conventional documentation locations, and the visible text of their collected public responses.

Passing criteria

An explicit first-party API/developer documentation claim, or a retrieved conventional documentation location (docs, developers or api subdomain; /docs, /developers, /api-docs, /reference or /api path) activates this check; the documentation must contain substantive public content, and conventional locations must also mention API or developer terms.

Sources

OpenAPI Specification (opens in a new tab)

api.public-documentation-discovery

OpenAPI spec discovery

A clear first-party pointer helps agents find the intended contract instead of guessing a specification URL. We check whether an API description has an authoritative declaration.

APIDiscoverMust-have · missing = 0 pointsMaximum tier C unless passed
How we check it

What we look for

An authoritative first-party OpenAPI declaration, such as a typed service-desc/describedby link or accepted API catalog entry. A guessed specification URL alone does not establish authoritative discovery; document parsing is checked separately.

Method

Inspected first-party API claims and declaration provenance for an authoritative OpenAPI target.

Passing criteria

Activated API Description; validate declaration source separately from accepted-version parsing, reference resolution, and internal identity.

Sources

OpenAPI Specification (opens in a new tab)

api-description.authoritative-discovery

OpenAPI spec validity

A parseable contract gives agents a machine-readable starting point for understanding your API. We check the API description for a supported OpenAPI version and basic document structure.

APIUse
How we check it

What we look for

The discovered API description parsed as JSON or YAML, with an accepted OpenAPI/Swagger version and a paths object. Supported versions include 2.0, 3.0, 3.1 and 3.2.0. More detailed input, response and reference checks are evaluated separately.

Method

Parsed the API description JSON/YAML and inspected openapi/swagger version and paths fields.

Passing criteria

Activated API Description; validate declaration source separately from accepted-version parsing, reference resolution, and internal identity.

Sources

OpenAPI Specification (opens in a new tab)

openapi.document-validity

API catalog (RFC 9727)

Catalog entries help agents discover the APIs your site offers. We check a published API catalog for a recognized representation and a valid service-description target.

APIDiscoverMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

A declared API catalog or a non-HTML response at /.well-known/api-catalog. The response needs an accepted catalog/linkset/JSON media type and at least one service-description item with a public HTTPS target, including recognized linkset entries.

Method

Parsed the API catalog, inspected its response media type and checked service-description URLs.

Passing criteria

Applies when declared or non-fallback /.well-known/api-catalog exists; require RFC 9727/9264 media/profile and at least one valid service-description item.

Sources

RFC 9727 — api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs (opens in a new tab)

api-catalog.validity

Sandbox environment declaration

Distinguishable endpoints help agents prepare test requests without confusing them with production. We check declared sandbox and production URLs for clear environment labels.

APIUse
How we check it

What we look for

OpenAPI servers entries that explicitly identify a sandbox, test environment or staging environment. A qualifying declaration needs a public HTTPS sandbox URL and a separate public HTTPS server labeled production. Neither environment is invoked.

Method

Inspected OpenAPI server URLs and descriptions for distinct public sandbox and production labels.

Passing criteria

Explicit sandbox declaration; require public documentation and unambiguous sandbox/production URL labelling. Absence is N/A.

Sources

OpenAPI Specification — Server Object (opens in a new tab)

api.sandbox-declaration-validity

JSON error response contracts

Resolvable JSON schemas help agents interpret failed requests and understand the returned error data. We check whether each applicable operation documents a structured error response.

APIUse
How we check it

What we look for

Every applicable OpenAPI operation needs a default or 4xx error response with a resolvable application/json or +json schema. Missing definitions fail; references to uncollected documents remain unresolved. Live endpoints are not called to generate errors.

Method

Inspected each OpenAPI operation for a resolvable JSON or +json error-response schema.

Passing criteria

Pass only when every applicable operation documents a resolvable structured JSON/+json error response; retain existing response exemptions. Otherwise fail; raw coverage remains visible.

Sources

RFC 9457 — Problem Details for HTTP APIs (opens in a new tab)OpenAPI Specification — Responses Object (opens in a new tab)

openapi.structured-error-response-coverage

REST typed error model

Stable error shapes help agents interpret failures and choose a suitable next step. We check structured error schemas for recognizable problem fields or a code and message pair.

APIUse
How we check it

What we look for

Resolved OpenAPI JSON error schemas with either type and title plus detail or status, or a code plus message or detail. At least one stable declared error shape must be found. This inspects published schema fields, not real error responses.

Method

Inspected resolved error schemas for problem-detail fields or a stable code and message/detail pair.

Passing criteria

Structured non-success schema; require RFC 9457 fields or a stable code plus human-readable message/detail shape.

Sources

RFC 9457 — Problem Details for HTTP APIs (opens in a new tab)

openapi.typed-error-model

REST response schema coverage

Clear output shapes help agents interpret returned values and prepare subsequent steps without guessing the response format. We check applicable successful responses for resolvable schemas.

APIUse
How we check it

What we look for

Applicable 2xx response media types in OpenAPI must have complete, resolvable schemas. Bodyless 204/205 responses and supported image/audio/video, binary or event-stream media are exempt. References whose source was not collected remain unresolved.

Method

Resolved applicable OpenAPI success-response schemas, excluding bodyless and supported binary/stream formats.

Passing criteria

Pass only when every applicable successful response has a resolvable schema; retain 204/304/binary/streaming exemptions. Zero eligible responses is N/A.

Sources

OpenAPI Specification — Response Object (opens in a new tab)

openapi.success-response-schema-coverage

API input and security integrity

Consistent contracts help agents prepare valid requests; action descriptions and IDs are also recorded as advisories. We check operation inputs and security references for resolvable definitions.

APIUse
How we check it

What we look for

OpenAPI operation parameters, requestBody schemas and security requirements. Input schema references must resolve and security scheme names must exist. Missing or duplicate operationId values and missing action descriptions are recorded separately as advisories.

Method

Resolved operation input and security references and recorded action-metadata coverage.

Passing criteria

Unresolvable input schemas or security references fail contract integrity. Unique operation IDs, operation descriptions, and parameter-description coverage remain measured advisories. No generic “LLM compatible” claim.

Sources

OpenAPI Specification (opens in a new tab)

openapi.action-input-and-security-integrity

API parameter descriptions

Clear explanations help agents choose appropriate values and understand what each input controls. We check declared API parameters for descriptions after reference resolution.

APIUse
How we check it

What we look for

Every applicable parameter declared at the OpenAPI path or operation level must have a nonempty description after reference resolution. Zero parameters makes this check inapplicable; an uncollected external definition leaves its description unresolved.

Method

Resolved OpenAPI operation parameters and counted those with nonempty descriptions.

Passing criteria

All applicable operation parameters have nonempty descriptions after reference resolution. Zero parameters is N/A. This is an explicit documentation preference.

Sources

OpenAPI Specification — Parameter Object (opens in a new tab)

openapi.parameter-description-coverage

API schema reference integrity

Resolvable definitions help agents interpret the contract; depth and unions are reported without a complexity penalty. We check API schema references for valid targets under the published dialect.

APIUse
How we check it

What we look for

OpenAPI $ref declarations must resolve to valid retained schema targets under the document's dialect. Uncollected external targets remain unresolved. Maximum depth and union counts are recorded, but complex or recursive schemas do not fail solely for their complexity.

Method

Walked OpenAPI references and resolved retained schema targets while recording depth and union counts.

Passing criteria

All schema references in the published contract resolve to valid schema targets under the pinned OpenAPI dialect. Cycles/unions/depth remain descriptive and do not fail by themselves. Rename to schema-reference integrity; do not score complexity.

Sources

OpenAPI Specification — Handling Reference Cycles (opens in a new tab)

openapi.schema-complexity-observation

REST deprecation guidance

A documented successor helps agents move away from retired functionality without guessing a replacement. We check deprecated operations and schema records for nearby migration guidance.

APIUse
How we check it

What we look for

OpenAPI operation or schema records with deprecated: true. Nearby description, summary or x-deprecation-message text must include replacement, migration or equivalent successor guidance. Documents with no deprecated records are outside this check.

Method

Inspected deprecated OpenAPI records for adjacent replacement or migration guidance.

Passing criteria

Any deprecated operation/schema; require adjacent replacement or migration guidance. Report version/server facts regardless.

Sources

OpenAPI Specification — Operation Object (opens in a new tab)

openapi.deprecation-guidance

REST pagination contracts

Clear paging instructions help agents request subsequent results and know when they are done. We check declared pagination contracts for inputs, continuation data and a stopping condition.

APIUse
How we check it

What we look for

Operations explicitly declaring pagination via x-pagination or their description. Contracts need a typed, described paging input; a described continuation output/header; and a completion signal such as hasMore, hasNextPage, totalPages or an explicit stopping condition.

Method

Inspected explicitly paginated operations for typed inputs, continuation outputs and completion guidance.

Passing criteria

Only explicitly paginated operations: declared pagination inputs, continuation output/header, and completion conditions have consistent typed contracts. Unpaginated bounded collections are N/A; do not infer pagination from an array alone.

Sources

OpenAPI Specification — Parameter Object (opens in a new tab)

openapi.pagination-shape-observation

REST async-job contracts

Agents need a handle and a status route to track work that takes time. We inspect declared background-job responses for a schema, a job handle and a described status operation.

APIUse
How we check it

What we look for

OpenAPI operations declaring HTTP 202. Each needs a response schema, a Location/job/status handle signal and a described or linked GET status operation. The scanner checks the published contract without submitting work or polling a job.

Method

Inspected OpenAPI 202 responses for schemas, job/status handles and described status operations.

Passing criteria

Operation declaring 202; require a response schema and Location or typed job/status identifier plus a described status operation.

Sources

RFC 9110 — HTTP Semantics, 202 Accepted (opens in a new tab)

openapi.async-job-contract

REST batch contracts

Bounded contracts help agents prepare groups of requests and interpret their results. We check declared batch operations for typed items, per-item results and size limits.

APIUse
How we check it

What we look for

Operations explicitly declaring x-batch or batch/bulk behavior. Request and success schemas must expose typed item arrays, with a positive maxItems, a documented maximum size or an explicit limit-policy link. An array alone does not activate the check.

Method

Inspected declared batch contracts for typed input/result arrays and an explicit size or limit policy.

Passing criteria

Only declared batch operations: typed item inputs/results and an explicit bounded size rule or documented limit policy. No batch declaration is N/A, not failed.

Sources

OpenAPI Specification — Schema Object (opens in a new tab)

openapi.batch-operation-observation

Action retry guidance

Clear retry rules help agents avoid repeating an action unintentionally. We check action documentation for a replay strategy, such as idempotency semantics or reconciliation guidance.

APIUse
How we check it

What we look for

Non-read-only POST/PATCH operations in OpenAPI. Each must document an idempotency key with replay semantics, intrinsic idempotence, or explicit do-not-retry/reconciliation guidance. Merely naming an Idempotency-Key header is insufficient; no action is executed.

Method

Inspected applicable POST/PATCH documentation for idempotency-key semantics or explicit retry guidance.

Passing criteria

For declared non-idempotent POST/PATCH operations, document a replay strategy: an idempotency key with semantics, intrinsic idempotence, or explicit unsafe-retry/reconciliation guidance. A header name alone is insufficient; safe/read-only operations are excluded.

Sources

The Idempotency-Key HTTP Header Field (Internet-Draft) (opens in a new tab)RFC 9110 — HTTP Semantics, Idempotent Methods (opens in a new tab)

openapi.idempotency-observation

Rate-limit recovery guidance

Retry guidance helps agents recover from throttling without guessing when to try again. We inspect declared rate-limit headers and policies without sending traffic to trigger a limit.

APIUse
How we check it

What we look for

OpenAPI operations declaring HTTP 429 or an explicit rate-limit policy. Each needs declared retry guidance such as Retry-After, RateLimit fields or a policy reference. The scanner reads the contract and does not induce throttling to inspect live behavior.

Method

Inspected declared 429 responses and rate-limit policies for retry headers or policy guidance.

Passing criteria

Operation declaring 429 or an explicit rate-limit policy; require declared retry guidance (Retry-After, current RateLimit fields, or a policy link). Never induce 429.

Sources

RateLimit Header Fields for HTTP (Internet-Draft) (opens in a new tab)RFC 9110 — HTTP Semantics, Retry-After (opens in a new tab)

openapi.rate-limit-recovery-guidance

Official npm package

Agents need to identify your official package among similarly named alternatives. We check published npm metadata against first-party documentation, homepage and repository signals.

Developer toolsDiscover
How we check it

What we look for

A published npm package with metadata corroborated by first-party documentation and a matching homepage, or an exact repository linked by the product. Similar names or search results alone do not establish an official package.

Method

Compared npm package metadata with first-party documentation, homepage and repository identity signals.

Passing criteria

Activates only for a published npm package corroborated by first-party documentation plus a matching homepage, or an exact repository linked by the product. Search-name similarity alone never activates the module. Confirms identity and metadata availability, not SDK behavior.

Sources

npm package metadata (opens in a new tab)

npm.official-package-discovery

CLI entry points

Clear executable metadata helps agents prepare a terminal command; the scanner does not run it. We check declared command names, package paths and invocation ambiguity.

Developer toolsUse
How we check it

What we look for

For an official package advertising a CLI: a nonempty package.json bin mapping with valid command names and relative paths inside the package. Documented npx, npm exec, pnpm dlx or yarn dlx commands must select an executable unambiguously. Libraries without a CLI claim are outside this check.

Method

Inspected package bin mappings and documented invocation syntax without installing or running the package.

Passing criteria

For confirmed packages with a bin declaration or a documented npx/npm exec/pnpm dlx/yarn dlx invocation, npm metadata declares non-empty executable entries with valid command names and relative paths inside the package. A documented implicit npx invocation must resolve unambiguously. Libraries without a CLI claim are N/A. No package is installed or executed.

Sources

npm package.json: bin (opens in a new tab)npm exec (opens in a new tab)

npm.cli-declaration-validity

OAuth server metadata

Published server metadata helps agents find the right sign-in service without guessing endpoints. We inspect issuer and authorization/token URLs for valid public HTTPS declarations.

AuthorizationUse
How we check it

What we look for

Collected metadata at a derived /.well-known/oauth-authorization-server or /.well-known/openid-configuration location. The document needs a public HTTPS issuer and at least one public HTTPS authorization_endpoint or token_endpoint. No sign-in flow is executed.

Method

Parsed issuer, authorization_endpoint and token_endpoint fields from collected OAuth server metadata.

Passing criteria

Activated Authorization; derive RFC 8414/OIDC location and require issuer plus syntactically valid public HTTPS metadata endpoints.

Sources

RFC 8414 — OAuth 2.0 Authorization Server Metadata (opens in a new tab)RFC 9700 — Best Current Practice for OAuth 2.0 Security (opens in a new tab)

authorization.server-metadata-validity

OAuth protected-resource metadata

Clear metadata helps agents understand which sign-in service protects a declared capability. We check protected-resource metadata for the resource identity and its authorization servers.

AuthorizationUse
How we check it

What we look for

Collected metadata at a derived /.well-known/oauth-protected-resource location. The JSON must declare a public HTTPS resource and a nonempty authorization_servers array of public HTTPS URLs. Token requests and authorization flows are not tested.

Method

Parsed resource and authorization_servers fields from collected protected-resource metadata.

Passing criteria

Activated protected resource; derive RFC 9728 location and validate resource/auth-server fields and origin relationships.

Sources

RFC 9728 — OAuth 2.0 Protected Resource Metadata (opens in a new tab)

authorization.resource-metadata-validity

OAuth scope consistency

Matching permission names help agents prepare authorization requests for the intended capability. We check that OAuth scopes referenced by OpenAPI security requirements are defined.

AuthorizationUse
How we check it

What we look for

OAuth scope names referenced by OpenAPI security requirements. Each referenced name must be defined in the corresponding security scheme's flows/scopes mapping. This checks name consistency rather than permission breadth or least-privilege quality.

Method

Compared referenced OpenAPI OAuth scope names with definitions in the corresponding security schemes.

Passing criteria

Security requirements reference scopes; require non-empty defined scopes and consistent descriptions across OpenAPI/server/resource metadata.

Sources

RFC 6749 — The OAuth 2.0 Authorization Framework (opens in a new tab)RFC 8414 — OAuth 2.0 Authorization Server Metadata (opens in a new tab)

authorization.scope-consistency

auth.md exists

Reachable sign-in instructions help agents understand the authorization steps before requesting credentials. We check a promised or recognizable auth.md guide for readable content.

AuthorizationUse
How we check it

What we look for

An explicitly declared auth.md document, or a recognizable non-fallback auth.md artifact. It must return Markdown/plain text with an H1 and at least 200 trimmed characters. A promised missing document fails; an undeclared missing convention is outside this check.

Method

Inspected the auth.md response for Markdown media, an H1 and substantive content.

Passing criteria

Apply only to an explicitly declared auth.md path or detected non-fallback auth.md artifact, not to all Authorization modules. Missing promised artifact fails; absent undeclared convention is N/A.

Sources

RFC 8414 — OAuth 2.0 Authorization Server Metadata (opens in a new tab)

authorization.auth-markdown-presence

auth.md structure

Organized instructions help agents understand how authorization is intended to work. We check auth.md for sections covering discovery, credentials, use, errors and token lifecycle.

AuthorizationUse
How we check it

What we look for

Headings in the discovered auth.md covering five groups: method/discovery, credentials/registration, use/requests, errors/troubleshooting and token expiry/refresh/revocation. This checks explicit sections, not the semantic completeness or successful execution of the walkthrough.

Method

Inspected auth.md headings for discovery, credentials, use, errors and token-lifecycle guidance.

Passing criteria

Apply to declared auth.md; missing promised artifact fails presence and leaves unknowable structure unresolved. Otherwise use the existing pinned structure criterion.

Sources

RFC 6749 — The OAuth 2.0 Authorization Framework (opens in a new tab)

authorization.auth-markdown-structure

WWW-Authenticate metadata hint

A usable discovery pointer helps agents locate the information needed to prepare authorization. We check whether an authorization challenge points to collected resource metadata.

AuthorizationUse
How we check it

What we look for

WWW-Authenticate headers already retained from protected-resource responses. A resource_metadata parameter must resolve to a URL matching a retrieved protected-resource metadata document. The scanner does not send new requests solely to force an authorization challenge.

Method

Parsed retained WWW-Authenticate challenges and matched resource_metadata targets to retrieved documents.

Passing criteria

Already-retrieved protected-resource response; parse challenge and require its resourcemetadata target to match retrieved RFC 9728 metadata.

Sources

RFC 9728 — OAuth 2.0 Protected Resource Metadata (opens in a new tab)

authorization.challenge-resource-metadata

Agent Skills discovery

A first-party entry point helps agents distinguish your published skills from unrelated resources. We check whether an Agent Skills index is discoverable and belongs to the scanned origin.

Agent SkillsDiscoverMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

An index at /.well-known/agent-skills/index.json, the legacy /.well-known/skills/index.json, or a typed agent-skills declaration from the scanned site. The index itself must be on the same origin as the scanned site; an unrelated third-party index does not qualify.

Method

Inspected the discovered Agent Skills index URL and its declaration for same-origin binding.

Passing criteria

Check /.well-known/agent-skills/index.json, the legacy /.well-known/skills/index.json, or a typed agent-skills declaration made by the scanned origin; the index itself must be same-origin to pass origin binding. For activated Agent Skills, respectively validate v0.1/v0.2 index + skill identity and selected artifact/digest/reference integrity. Never execute content.

Sources

Agent Skills Discovery via Well-Known URIs (opens in a new tab)

agent-skills.discovery-origin

Agent Skills index validity

Identifiable entries and resource locations give agents a predictable list of available skills to explore. We check the declared skills index against the supported structural profile.

Agent SkillsUse
How we check it

What we look for

The discovered Agent Skills index JSON with a recognized v0.1/v0.2 version and a nonempty skills array. Every entry needs a name or id and a url, href or path. Discovery may use /.well-known/agent-skills/index.json, /.well-known/skills/index.json or a typed agent-skills link.

Method

Parsed the Agent Skills index version and skills entries for name/id and url/href/path fields.

Passing criteria

Check /.well-known/agent-skills/index.json, the legacy /.well-known/skills/index.json, or a typed agent-skills declaration made by the scanned origin; the index itself must be same-origin to pass origin binding. For activated Agent Skills, respectively validate v0.1/v0.2 index + skill identity and selected artifact/digest/reference integrity. Never execute content.

Sources

Agent Skills Discovery via Well-Known URIs (opens in a new tab)Agent Skills Specification (opens in a new tab)

agent-skills.index-validity

Agent Skills resource integrity

Working links and matching bytes help agents retrieve the instructions promised by the index. We check selected skill references and declared digests against collected files.

Agent SkillsUse
How we check it

What we look for

Selected url, href, path and files references from a valid Agent Skills index. Collected targets must resolve; published SHA-256 digests must be correctly formed and match the exact collected bytes. References excluded by the collection budget are not claimed as verified.

Method

Resolved selected skill references and compared declared SHA-256 digests with collected artifact bytes.

Passing criteria

Check /.well-known/agent-skills/index.json, the legacy /.well-known/skills/index.json, or a typed agent-skills declaration made by the scanned origin; the index itself must be same-origin to pass origin binding. For activated Agent Skills, respectively validate v0.1/v0.2 index + skill identity and selected artifact/digest/reference integrity. Never execute content.

Sources

Agent Skills Discovery via Well-Known URIs (opens in a new tab)

agent-skills.resource-integrity

A2A card discovery

A first-party card gives agents a reliable starting point for understanding the agent you publish. We check whether an A2A agent card is discoverable on the scanned origin.

A2ADiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

An A2A card at /.well-known/agent-card.json or a typed agent-card declaration from the scanned site. The card itself must be on the same origin as the site. This establishes a discoverable first-party card, not a live connection to its agent interface.

Method

Inspected the discovered agent-card.json or typed agent-card target for same-origin binding.

Passing criteria

Check /.well-known/agent-card.json or a typed agent-card declaration made by the scanned origin; the card itself must be same-origin to pass origin binding. For activated A2A, respectively validate accepted-version JSON/identity and every eligible declared static reference. Never contact the declared agent interface, so a pass does not prove runtime A2A behavior.

Sources

A2A Protocol Specification — Agent Discovery (opens in a new tab)

a2a.discovery-origin

A2A agent-card validity

Clear declarations help agents prepare a connection; the scanner does not contact the declared agent interface. We check an A2A card for accepted version, identity and interface fields.

A2AUse
How we check it

What we look for

The discovered A2A card JSON with nonempty name and version plus a url or supportedInterfaces entry. It must use an accepted 0.3/1.0 protocol version or supported legacy URL shape, and skills must be an array if present. The declared agent interface is not contacted.

Method

Parsed A2A card name, version, protocolVersion and url/supportedInterfaces declarations.

Passing criteria

Check /.well-known/agent-card.json or a typed agent-card declaration made by the scanned origin; the card itself must be same-origin to pass origin binding. For activated A2A, respectively validate accepted-version JSON/identity and every eligible declared static reference. Never contact the declared agent interface, so a pass does not prove runtime A2A behavior.

Sources

A2A Protocol Specification — Agent Discovery (opens in a new tab)

a2a.card-validity

A2A reference integrity

Working supporting links help agents explore documentation and identify the advertised agent. We check eligible static references in an A2A card, excluding agent interfaces.

A2AUse
How we check it

What we look for

Eligible documentationUrl, iconUrl and href references in the discovered A2A card. Selected static targets must resolve within the collected evidence. The card's url and supportedInterfaces endpoints are excluded, so a pass does not prove runtime A2A behavior.

Method

Resolved A2A documentationUrl, iconUrl and href references, excluding declared agent-interface URLs.

Passing criteria

Check /.well-known/agent-card.json or a typed agent-card declaration made by the scanned origin; the card itself must be same-origin to pass origin binding. For activated A2A, respectively validate accepted-version JSON/identity and every eligible declared static reference. Never contact the declared agent interface, so a pass does not prove runtime A2A behavior.

Sources

A2A Protocol Specification — Agent Discovery (opens in a new tab)

a2a.reference-integrity

ARD discovery

Publisher binding helps agents associate the directory with the site being assessed. We check whether an ARD directory is discoverable through an accepted location or declaration.

ARDDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

An ARD directory at /.well-known/ard.json or a typed ard declaration from the scanned site. The directory must be bound to the site's origin. Entry structure and local trust metadata are checked separately.

Method

Inspected the discovered ard.json or typed ard target and its same-origin binding.

Passing criteria

Activated ARD; require typed declaration or the pinned well-known path and publisher-domain binding.

Sources

Agentic Resource Discovery Specification (opens in a new tab)

ard.discovery-origin

ARD entry validity

Consistent entries tell agents what each directory resource describes and where to find it. We check ARD entries for supported catalog structure and resource identity fields.

ARDDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

The discovered ARD catalog with accepted specVersion/version 0.9 or 1.0 and nonempty entries. Each entry needs a urn:air identity, a media type and exactly one of an absolute HTTP(S) url or embedded data.

Method

Parsed the ARD version and inspected urn:air identities, media-type fields and exclusive url/data entries.

Passing criteria

Activated ARD under the pinned v0.9 draft; accept catalog specVersion 0.9 or 1.0 and validate URN identity and entry shape.

Sources

Agentic Resource Discovery Specification (opens in a new tab)

ard.entry-validity

ARD trust metadata validity

Well-formed claims are easier to interpret; this does not verify signatures or establish external trust. We check local ARD trust metadata syntax, including publisher binding and digest fields.

ARDDiscoverMaximum tier A unless passed
How we check it

What we look for

Published trustManifest, trust_manifest or trust objects in the ARD directory. Optional domain/publisher/origin must match the publisher, digests must have SHA-256 syntax and embedded signature/JWS values need three parts. These checks do not verify a signature or external trust claim.

Method

Inspected ARD trust objects for publisher binding, SHA-256 syntax and three-part signature/JWS values.

Passing criteria

ARD entry declaring trust metadata; validate local syntax, domain binding, digests, and embedded signature shape. No external key resolution or trust claim.

Sources

Agentic Resource Discovery Specification (opens in a new tab)Common AI Catalog and Registry Standard (opens in a new tab)

ard.trust-manifest-local-validity

AI Catalog validity

A structured resource list helps agents discover the AI capabilities your site declares. We check an AI Catalog for identifiable typed entries with a URL or embedded data.

AI CatalogDiscoverMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

An AI Catalog at /.well-known/ai-catalog.json or an authoritative ai-catalog declaration. JSON needs a version/schema identifier and nonempty entries with identity, media type and exactly one of an absolute HTTP(S) url or embedded data.

Method

Parsed the AI Catalog and inspected version, entry identities, media types and exclusive URL/data fields.

Passing criteria

Recognized AI Catalog; validate pinned schema, entry identity/type, and exclusive url/data. Each recognized entry supports only its target subfamily's discovery outcome.

Sources

Common AI Catalog and Registry Standard (opens in a new tab)

ai-catalog.discovery-validity

MCP well-known discovery

A standard discovery path helps agents find your server description before considering a connection. We check the supported well-known location for an MCP server-card declaration.

MCPDiscoverMust-have · missing = 0 pointsMaximum tier B unless passed
How we check it

What we look for

A non-HTML MCP server-card declaration at /.well-known/mcp/server-card.json on the canonical origin. Missing or fallback HTML does not establish a card. The card's schema, protocol and endpoint fields are assessed in separate checks.

Method

Inspected /.well-known/mcp/server-card.json for a non-HTML MCP card declaration.

Passing criteria

The pinned /.well-known/mcp/server-card.json location, already collected as a fixed discovery artifact; a valid or recognizably malformed non-HTML card activates MCP Declaration and is an alternative discovery path to F01. Absence with no other claim is N/A. Card validity and consistency remain D09.

Sources

SEP-1649 — MCP Server Cards: HTTP Server Discovery via .well-known (opens in a new tab)

mcp.well-known-card-discovery

MCP server-card validity

A usable static description helps agents prepare a connection without proving runtime compatibility. We check an MCP server card for identity and supported schema and protocol declarations.

MCPUse
How we check it

What we look for

The discovered static MCP card with nonempty server name and version, $schema=https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json and a recognized declared protocol version. This validates the static profile, not a handshake with the MCP server.

Method

Parsed MCP card identity, schema URL and declared protocol versions against the supported profile.

Passing criteria

An activated MCP card follows the pinned experimental schema and declares a supported protocol version. Only static document validity is assessed.

Sources

MCP Server Card Schema (opens in a new tab)

mcp.card-validity

MCP card consistency

Clear connection metadata helps agents interpret the intended endpoint without invoking it. We check MCP card identity, public HTTPS URLs and eligible references for static consistency.

MCPUse
How we check it

What we look for

The discovered MCP card's server identity, at least one public HTTPS endpoint, public HTTPS authorization URLs when declared, and eligible documentation/icon references. Supporting resources must resolve; the scanner never connects to the MCP endpoint.

Method

Inspected MCP identity, endpoint/auth URL syntax and eligible documentation or icon references.

Passing criteria

An activated MCP card has usable identity, a public HTTPS endpoint, consistent authorization, and valid eligible references. The scanner never connects to the MCP endpoint.

Sources

MCP Server Card Discovery and Runtime Consistency (opens in a new tab)

mcp.card-static-consistency

MCP card declaration

An authoritative description helps agents locate the intended connection metadata without guessing. We check whether MCP declarations identify one static server card unambiguously.

MCPDiscoverMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

Authoritative static MCP declarations, including recognized AI Catalog entries, typed card links or embedded card data. They must identify one unique card target or data object. A first-party MCP claim without a card fails; a runtime endpoint alone is not a static card.

Method

Inspected authoritative MCP declarations and counted unique static card targets or embedded data objects.

Passing criteria

Recognized AI Catalog/static-card declaration; require a unique declared card target/data object. Report “declared,” never “working.”

Sources

MCP Server Card discovery (opens in a new tab)

mcp.static-card-discovery

WebMCP tool declarations

Names and input contracts help agents prepare interactions; dynamic registration and tool execution are not tested. We check first-party source for complete WebMCP tool declarations.

WebMCPUse
How we check it

What we look for

Complete first-party WebMCP tool declarations in collected page or script source. Each needs nonempty name and description, plus a statically resolvable object inputSchema with typed properties and valid required-field names. Dynamic registrations remain unresolved.

Method

Inspected collected first-party source for named WebMCP tools, descriptions and static input schemas.

Passing criteria

In an active WebMCP module, retrieve at least one first-party tool declaration with nonempty name/description and a statically resolvable input contract under the pinned draft. Bare API strings never pass. Dynamic declarations are unresolved, not proof of unsupported runtime behavior.

Sources

WebMCP draft specification (opens in a new tab)

webmcp.source-marker-observation

pricing.md validity

Clear pricing sections help agents interpret the costs you publish without relying on page layout. We check an explicitly declared pricing Markdown document for readable structure.

CommerceAccess
How we check it

What we look for

An explicitly declared pricing.md resource with Markdown or plain-text media, an H1 and at least one section heading or list. A conventional path alone does not activate this check; the scanner assesses document structure rather than the prices themselves.

Method

Inspected the declared pricing.md response for Markdown media, an H1 and section or list structure.

Passing criteria

Only an explicitly declared pricing Markdown resource for an activated commerce family; validate retrieval and Markdown structure.

Sources

CommonMark Specification (opens in a new tab)

commerce.pricing-markdown-validity

MPP payment offer declarations

Clear method and amount metadata help agents interpret published payment options without making a payment. We check declared MPP payment offers and their HTTP response contract.

CommerceUse
How we check it

What we look for

OpenAPI 3.x operations with x-payment-info and a declared HTTP 402 response. Each offer needs intent=charge or session, a valid method name, and amount=null or a nonnegative integer string; optional currency/description must be strings. No payment is made.

Method

Inspected OpenAPI x-payment-info offers for intent, method, amount and a declared HTTP 402 response.

Passing criteria

Only active MPP: published payment-auth metadata conforms to the pinned declaration schema and declares valid method/transport fields. A marker string alone does not pass; no payment execution.

Sources

The "Payment" HTTP Authentication Scheme (opens in a new tab)

commerce.mpp-marker-observation

UCP commerce profile

A readable profile helps agents understand advertised commerce capabilities without invoking them. We check a UCP commerce profile for the supported version and required structural declarations.

CommerceUse
How we check it

What we look for

A declared or non-fallback JSON profile at /.well-known/ucp. The ucp object or root needs version=2026-08-25, services, capabilities and handlers/payment_handlers collections, with public HTTPS references. The scanner does not invoke a shopping capability.

Method

Parsed UCP version, services, capabilities and handlers/payment_handlers fields and inspected HTTPS references.

Passing criteria

Explicit declaration or non-fallback /.well-known/ucp; validate UCP 2026-08-25 profile version, services, capabilities, handlers, and public HTTPS references without invocation.

Sources

UCP 2026-08-25 REST discovery profile (opens in a new tab)

commerce.ucp-manifest-validity

ACP checkout contract

Clear contracts help agents understand the checkout interface without executing a purchase. We check published ACP discovery or checkout contracts for supported structure and endpoint declarations.

CommerceUse
How we check it

What we look for

An authoritative ACP declaration or /.well-known/acp.json. It must match the supported ACP discovery shape or a pinned OpenAPI 3.1.0 checkout contract with version 2026-04-17, public HTTPS servers and POST /checkout_sessions plus its completion operation. No checkout is executed.

Method

Parsed ACP discovery or checkout contracts and inspected version, operation and public HTTPS declarations.

Passing criteria

Only active ACP: declared contract/extension validates its pinned schema/version and public HTTPS endpoint fields. A marker alone does not pass; no checkout execution.

Sources

Agentic Commerce Protocol introduction (opens in a new tab)Agentic Commerce Protocol architecture (opens in a new tab)

commerce.acp-declaration-observation

AP2 extension declaration

Payment role and constraint metadata help agents interpret a declared AP2 extension. We inspect A2A card content for its URI, version and static metadata signals.

CommerceUse
How we check it

What we look for

Collected A2A agent-card.json content declaring AP2 with a public HTTPS extension URI, v0.2.0 version and static role, constraint, mandate or payment metadata signals. This checks declaration signals only, not mandate signatures or payment execution.

Method

Inspected A2A card content for the AP2 extension URI, v0.2.0 version and static metadata signals.

Passing criteria

Valid A2A card declaring the pinned AP2 v0.2.0 extension; validate extension URI/version and static role/constraint metadata only.

Sources

Agentic Payment Protocol v0.2 specification (opens in a new tab)

commerce.ap2-extension-validity

Web Bot Auth directory

A public signing-key directory describes your outbound bot identity. We validate its public key declarations without verifying signatures or claiming that inbound access works.

Bot IdentityDiscoverMust-have · missing = 0 pointsMaximum tier A unless passed
How we check it

What we look for

A declared bot-identity/signing directory or /.well-known/http-message-signatures-directory. Its JSON keys array must contain 1–100 importable public signing JWKs with unique nonempty kid values and no private-key fields. Optional use must be sig; signatures are not verified.

Method

Parsed the signing-directory keys array, imported public JWKs and checked kid uniqueness and private-field absence.

Passing criteria

When a signing directory is declared, validate its pinned directory schema and public JWK fields. No signature verification or inbound-access claim. Requires collection implementation.

Sources

HTTP Message Signatures for Automated Traffic (Internet-Draft) (opens in a new tab)

bot-identity.web-bot-auth-directory-observation