What is Agent Card?
An agent card is a machine readable metadata document that describes an AI agent to other agents, listing its name, address, capabilities, supported input and output formats, and how to authenticate with it. The term comes from the A2A protocol, where cards are published at a well known path on the agent's own domain so that clients can discover them automatically.
A card is a JSON document. Beyond identity fields it declares skills, meaning the discrete things the agent can be asked to do, each with a description and often example prompts. It also declares transport details, whether streaming is supported, and which authentication schemes a caller must satisfy. A client reads the card before sending any task.
Publishing at a conventional well known location under the domain root makes discovery mechanical rather than manual. A client that knows only the domain can find the card without documentation or a central registry. Registries and catalogs may aggregate cards for search, but the copy served from the agent's own domain remains the authoritative one.
The card is public metadata, not an access control mechanism. Listing a skill does not grant it, and authentication still happens on every call. Some designs also serve an extended card to callers who have already identified themselves, revealing additional skills, so a publicly readable card is not always the full picture of what an agent can do.
Conceptually a card plays the role that a service description file plays for traditional web services, and the role a tool schema plays inside a single application. Because anyone can publish one, its contents are self asserted claims rather than proof. An unfamiliar agent's card deserves the same scrutiny as any unverified third party service description.
Key points
- JSON document describing an agent's identity, skills, and authentication.
- Served from a well known path on the agent's own domain.
- Read by client agents before any task is sent.
- Metadata only: it advertises capability and grants no access.
- Claims are self asserted and should not be trusted blindly.
In practice
A support agent publishes a card at its company domain. The card names the agent, gives its endpoint, declares one skill for refund eligibility checks with a short description, states that it accepts text and returns text or JSON, and requires a bearer token. A partner's agent fetches the card once, caches it, and from then on knows exactly how to ask for a refund check.