What we check

We fetch /.well-known/agent-card.json, which is the path in the current A2A specification. If that fails, we try the older /.well-known/agent.json.

A card counts as valid when it is JSON, has a name string, and has at least one of: a url string, a skills array, or a capabilities object. If the card mentions A2UI, we note it as a detail in your report.

What A2A is

A2A (Agent2Agent) is an open protocol for agents talking to other agents. It started at Google and is now run as a Linux Foundation project. If your product has its own agent, for example a support agent or a booking agent, the agent card is how another company's agent finds out what yours can do, where to send requests, and how to authenticate.

If you do not run an agent, skip this one. An MCP server card or an Agent Skills index is usually the better fit for exposing a product to agents.

An example card

{
  "name": "Acme Booking Agent",
  "description": "Checks availability and books appointments at Acme clinics.",
  "url": "https://acme.com/a2a",
  "version": "1.0.0",
  "capabilities": { "streaming": true },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "book-appointment",
      "name": "Book an appointment",
      "description": "Finds a free slot at a named clinic and books it."
    }
  ]
}

The A2A specification defines more fields, including security schemes and a signature block for signed cards. Validate against the published schema before relying on it in production.

Common reasons it fails

• The card is only at /.well-known/agent.json and that path returns HTML. Publish at agent-card.json.
• The card lists no URL, skills or capabilities, so another agent cannot tell what to do with it.
• A bot-protection rule challenges our request. Agents get the same challenge.