A2A Agent Card validator
Paste an Agent Card and check it against the A2A 1.0.0 specification tables. Errors are things the spec marks required or gets the type wrong. Warnings are recommended or ambiguous. Everything runs in your browser.
Results
What an Agent Card is
An Agent Card is the JSON manifest an A2A server publishes about itself. It says who the agent is, which interfaces it exposes, what it can do (skills), which media types it takes and returns, and how to authenticate. The specification says A2A servers MUST make an Agent Card available. Clients read it to pick an agent and to configure the connection. See What is A2A for the wider picture.
Where it lives
The spec lists three discovery mechanisms: the well-known URI
https://{server_domain}/.well-known/agent-card.json, registries or catalogs, and direct
configuration with a pre-set card URL or content. Section 14.3 registers the well-known URI with IANA.
If Fetch fails, that is usually browser CORS: many servers do not send
Access-Control-Allow-Origin, so a page on another site cannot read the response. Run
curl https://example.com/.well-known/agent-card.json and paste the output instead. This site
has no proxy on purpose.
Field reference
From specification 1.0.0, section 4.4.1. Nested objects are described in sections 4.4.2 to 4.5.
| Field | Type | Required | Notes |
|---|---|---|---|
name | string | Yes | Human readable name of the agent. |
description | string | Yes | What the agent is for. |
supportedInterfaces | array of AgentInterface | Yes | Ordered list. The first entry is preferred. Each has url, protocolBinding, protocolVersion and optional tenant. |
version | string | Yes | Version of the agent, for example "1.0.0". |
capabilities | AgentCapabilities | Yes | Optional booleans streaming, pushNotifications, extendedAgentCard, plus extensions. |
defaultInputModes | array of string | Yes | Input media types across all skills. |
defaultOutputModes | array of string | Yes | Output media types. |
skills | array of AgentSkill | Yes | Each skill needs id, name, description and tags. |
provider | AgentProvider | No | If present, url and organization are both required. |
documentationUrl | string | No | More documentation about the agent. |
securitySchemes | map of string to SecurityScheme | No | Each scheme holds exactly one variant: API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS. |
securityRequirements | array of SecurityRequirement | No | Security requirements for contacting the agent. |
signatures | array of AgentCardSignature | No | JWS signatures. Each needs protected and signature. |
iconUrl | string | No | URL of an icon for the agent. |
Cards written for older versions
The validator warns, rather than fails, on pre-1.0 top-level keys: url,
protocolVersion, preferredTransport, additionalInterfaces,
supportsAuthenticatedExtendedCard and security. In 1.0 each entry of
supportedInterfaces carries its own URL, binding and protocol version, and the extended
card flag lives at capabilities.extendedAgentCard. A card missing a required 1.0 field is
still an error.
Spec notes
Places where the specification text disagrees with itself or leaves a gap. The validator marks the related results unverified.
- securityRequirements vs security
- The AgentCard table (4.4.1) names the field securityRequirements. The text of section 9.4.8 (GetExtendedAgentCard) says AgentCard.securitySchemes and AgentCard.security. This validator accepts either and warns on security.
- supportedInterfaces: required or optional
- The AgentCard table marks supportedInterfaces as required, but section 8.3.2 tells clients to "Parse supportedInterfaces if present", and 8.3.1 says it SHOULD declare all supported combinations. The validator treats it as required, as the table says.
- transport vs protocolBinding
- Section 8.3.1 says each interface MUST declare its "transport protocol", and the AgentInterface description says "transport", but the field in the AgentInterface table is protocolBinding. The validator requires protocolBinding and warns on a transport key.
- SecurityRequirement shape is not defined in the excerpt
- The tables use array of SecurityRequirement but the excerpt does not show that object. The validator resolves references from either a schemes map or the entry keys, and cannot check scope lists.
- OAuth flow fields are cut off
- The excerpt ends in the middle of AuthorizationCodeOAuthFlow (4.5.8), so inner fields of each flow are not validated. Only the exactly-one-flow rule is checked.
- Extended card field name
- Section A.2.2 calls the old field supportsExtendedAgentCard. Earlier SDK cards often used supportsAuthenticatedExtendedCard. Both are flagged as pre-1.0 and map to capabilities.extendedAgentCard.
- AgentExtension has no required field
- AgentExtension (4.4.4) marks uri as optional even though it is described as the unique URI identifying the extension. The validator warns when uri is missing.
- Hosts in the extended card example
- In section 6.9 the public card is fetched from Host: example.com, and the extended card from Host: agent.example.com at /extendedAgentCard. The excerpt does not say whether these must match.
- A2A-Version header example
- The IANA text (14.2.1) shows A2A-Version: 0.3 as its example although the spec version is 1.0. Not a card rule, listed for completeness.
FAQ
- What is an A2A Agent Card?
- An Agent Card is the JSON manifest an A2A server publishes to describe itself: name, description, supported interfaces, version, capabilities, input and output modes, skills, and optionally security schemes and signatures.
- Where do I publish an Agent Card?
- The A2A specification lists the well-known URI https://{server_domain}/.well-known/agent-card.json as one discovery mechanism. Registries and direct configuration are the other two.
- Which Agent Card fields are required?
- In specification 1.0.0 the required fields are name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills. If you add a provider it needs url and organization.
- Why did my old Agent Card get warnings?
- Version 1.0 moved interface details into supportedInterfaces, where each entry has its own url, protocolBinding and protocolVersion. Top-level url, protocolVersion, preferredTransport and additionalInterfaces are pre-1.0 fields. The extended card flag moved into capabilities.extendedAgentCard.
- Why does Fetch fail on my agent URL?
- The browser enforces CORS. Many agent servers do not send an Access-Control-Allow-Origin header, so a page on another site cannot read the response. Open the URL in a new tab or run curl, then paste the JSON here.
- Is my Agent Card uploaded anywhere?
- No. Validation runs in your browser. The only network request is the optional Fetch button, which goes straight from your browser to the URL you typed.