ACP Check

Methodology

Validated against the published ACP spec, version 2026-04-17.

We don't just check your discovery document's shape, we validate your agentic endpoints to confirm they actually exist and respond.

  1. 1

    Discovery

    We fetch the URL you provide, parse the response as JSON, and confirm it looks like an ACP discovery document. If we can't reach or parse it, the check stops here and tells you why.

  2. 2

    Schema validation

    We validate the discovery document against the vendored ACP schema, surfacing every structural error – missing required fields, wrong types, and malformed values – with the exact path that failed.

  3. 3

    Capabilities

    We walk your declared transports (REST, MCP) and services (checkout, orders, delegate payment, carts), flag any that aren't recognized ACP values, check support for ISO 4217 codes, and summarize each declared extension.

  4. 4

    Endpoint probes

    For each service, we HEAD/OPTIONS-probe each expected endpoint to confirm the URL is live. Extension spec and schema URLs get a HEAD probe.

  5. 5

    Hygiene

    We confirm the basics an agent depends on: the discovery URL and the declared base URL are both served over HTTPS, so the surface an agent reads and transacts against is delivered with integrity.

How ACP validation works

We check a brand's published discovery document against the ACP specification. But the phase most validators skip is the one that matters most in practice.

A discovery document can be perfectly well-formed and still point at endpoints that 404, time out, or were never deployed. This is why we don't stop at the document's shape, and we query the spec expected endpoints based on your declared services to confirm they exist and respond.

We send a side-effect-free HEAD or OPTIONS request against the base URL. Extension spec and schema URLs are HEAD-probed against their doc hosts. MCP transport is intentionally skipped rather than failed, because ACP's discovery document has no standardized field for an MCP endpoint URL — there is nothing the spec tells us to probe. The result tells you not just "your document is valid" but "an agent that reads it can actually reach you."

What we intentionally don't check

This is a conformance and reachability check, not an end-to-end purchase test. We confirm your endpoints are present and responsive; we do not place test orders, exercise full checkout or delegated-payment flows, or verify the business correctness of the data behind each endpoint.

Endpoints that require authentication are reported as reachable rather than fully exercised.