The Agent Card Validator checks pasted JSON, uploaded Agent Card files, and public agent URLs against A2A v1.0 discovery requirements.
Paste JSON, a public agent URL, or drag a JSON file into the editor.
Agent Card Validator coverage
The Agent Card Validator is designed for developers publishing A2A agents, internal platform teams reviewing agent metadata, and marketplace operators checking whether a submitted Agent Card contains enough information for reliable invocation.
Paste a local JSON document during development, upload an Agent Card from your repository, or use live URL validation against a deployed domain to verify public discovery paths.
Checks required fields against the v1.0 specification: name, description, version, supportedInterfaces with per-interface protocolBinding and protocolVersion, capabilities, content modes, and at least one skill with required tags.
Detects pre-1.0 structures — top-level url, preferredTransport, protocolVersion, provider.name, stateTransitionHistory — and tells you exactly where each field moved in v1.0.
Verifies securitySchemes and security requirements are declared for non-public endpoints, flags non-HTTPS URLs, and scans for values that look like embedded API keys, JWTs, or bearer tokens.
Fetches /.well-known/agent-card.json and the legacy /.well-known/agent.json from a live domain and confirms both return parseable Agent Card JSON.
Where validation fits
A Agent Card that passed review last month can still break discovery today — an endpoint moves, a skill changes, a redeploy drops the well-known route. Platform teams and marketplace reviewers treat validation as a repeatable gate, not a one-time check.
The simplest CI guard needs nothing but curl: confirm the well-known path answers with parseable JSON before traffic switches to a new deployment.
# deploy pipeline: fail if the published card breaks
curl -fsS https://your-domain/.well-known/agent-card.json \
| python3 -c '
import json, sys
card = json.load(sys.stdin)
assert card.get("name"), "name is required"
assert card.get("supportedInterfaces"), "supportedInterfaces missing"
assert card.get("skills"), "skills missing"
print("agent card OK:", card["name"])'Fix guide
Use the Agent Card Validator report to address required fields first, then improve discovery, trust, and migration details.
Replace placeholder endpoint URLs with the deployed HTTPS A2A service URL.
Move top-level url and preferredTransport into an ordered supportedInterfaces array — the first entry is the preferred interface.
Add the required top-level version field describing the agent itself, and add tags to every skill.
Rename provider.name to provider.organization and expand short descriptions so clients know when to invoke the agent.
Declare security metadata whenever the agent endpoint is not fully public — and never embed the credential itself.
Publish the same valid Agent Card at /.well-known/agent-card.json (and the legacy agent.json path while clients still check both).
FAQ
Get the essentials right before your agent reaches an A2A client.
Compare valid examplesChecks follow the A2A v1.0 Agent Card structure — supportedInterfaces, per-interface protocol versions, required skill tags, provider.organization. Pre-1.0 Agent Cards are not rejected outright: legacy fields surface as warnings with the exact v1.0 replacement.
The v1.0 spec registers /.well-known/agent-card.json, but earlier A2A implementations used /.well-known/agent.json. Checking both catches discovery gaps before clients fail.
Warnings are not blocking JSON errors, but they usually point to metadata that makes the agent easier to discover, trust, and call — or to pre-1.0 fields that newer clients will stop reading.
Three moments: while editing an Agent Card during development, as a CI gate before deployment, and after publishing — paste the live service URL to confirm what clients actually receive from both discovery paths.
Ready to validate
Paste JSON, drop in an Agent Card file, or check a public URL from the unified validator workspace.