A2A Check

Methodology

Validated against the published A2A spec, version 1.0.1.

We don't stop at the Agent Card – we send side-effect-free requests to the JSON-RPC and HTTP+JSON interfaces it declares and check that the agent answers with the errors A2A defines.

  1. 1

    Discovery

    We fetch the Agent Card from /.well-known/agent-card.json at the domain root, and fall back to the legacy /.well-known/agent.json with a warning. We then detect the A2A version the card declares. Both A2A 1.0 and 0.3 cards are validated; a 0.3-only agent gets an upgrade-to-1.0 warning, and 0.2.x is out of range.

  2. 2

    Schema validation

    We validate the card against the schema for its version: A2A 1.0 (we validate against the 1.0.1 release of the specification, using a schema derived from its a2a.proto), or 0.3, validated against its published JSON Schema.

  3. 3

    Skills & capabilities

    We check that each interface URL is absolute and https, that its binding is a known one (JSONRPC, HTTP+JSON, or GRPC), and that its version is Major.Minor. Skill ids must be unique, security requirements must reference schemes the card actually declares, and we list its extensions and capability flags. Card signatures are reported, not verified.

  4. 4

    Endpoint probes

    We probe up to three declared interfaces, 1.x ones first; any others are reported as not probed. On a 1.x JSON-RPC interface we send five requests that cannot change anything: an unknown method, a lookup of a task that does not exist, the extended-card call when the agent does not offer one, a call with an unsupported A2A-Version, and a malformed request. A 0.3 JSON-RPC interface gets the unknown-method and nonexistent-task probes. A 1.x HTTP+JSON interface gets the nonexistent-task lookup, the extended-card check, and a content-type check. 0.3 HTTP+JSON and gRPC interfaces are declared, not probed. If the card does offer an extended card, a separate check confirms it requires authentication. An optional bearer token is sent only to the agent's own origin.

  5. 5

    Hygiene

    We check that the card is served over HTTPS with a JSON content type, whether it sets Cache-Control max-age and an ETag (both SHOULDs in the spec), and whether CORS lets browser-based clients read it.

  6. 6

    Commerce

    We report whether the card carries the UCP commerce extension and AP2, exactly as declared. This is informational, not a compliance gate – A2A itself does not require commerce capabilities.

How A2A validation works

We check a live agent against the published A2A specification. But the phase most validators skip is the one that matters most in practice.

We validate the Agent Card, then call the interfaces it declares. A published card can claim anything; a live response confirms the agent is up and speaking A2A correctly. Each probe has a defined correct answer: a task that does not exist should produce a task-not-found error, an unsupported A2A-Version a version-not-supported error, and a malformed request a parse error.

Severity follows the spec's wording: MUST misses are errors, SHOULD misses are warnings, and where the spec is silent we only report what we saw. An agent that answers every probe with an authentication challenge is reported as auth-gated, not failed.

What we intentionally don't check

This is a conformance and reachability check, not an end-to-end test of your agent's work. We never call SendMessage or any other call that creates a task. We do not probe gRPC interfaces, only validate that they are declared well. We do not verify Agent Card signatures, only report them. And without a credential we cannot see an extended card's contents, only how the agent responds to asking for one.