What is an Agent Card in the A2A protocol?

In the A2A (Agent2Agent) protocol, one AI agent hands tasks to another. Before handing over anything, it has to know what the other one can do, where it listens and how to identify itself, and that is what the Agent Card holds. The protocol's documentation calls it an agent's digital business card.⁠^{[1]A2A Protocol, Linux Foundation. Agent Discovery in A2A} It is not a payment card or a credential that lets an agent buy: it carries no money and authorizes nothing. In agentic commerce, a store cares because it is the first thing an outside agent reads: if your platform or your provider publishes an A2A agent on your behalf, or your UCP (Universal Commerce Protocol) profile declares the A2A transport, the address it lists is that of an Agent Card.⁠^{[2]Universal Commerce Protocol. UCP Specification Overview (version 2026-08-25)}

What it contains

The 1.0.0 specification defines it as a manifest the agent publishes about itself, with its identity, its capabilities, its skills, the ways of communicating it supports and its security requirements.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)} These are its fields:

The interfaces come in order. The first one in supportedInterfaces is the preferred one, and the client has to pick the first it knows how to use and call the address declared for that transport.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)} In version 1.0 the possible protocol bindings are JSON-RPC, gRPC and HTTP with JSON, and each interface carries its own protocolVersion.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}

The skills are the part people read. Each skill carries an identifier, a name, a description and tags, all required, and it may carry example requests, its own input and output types and its own security requirements. The specification describes them as mostly descriptive: the set of things the agent will probably do well.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)} They are not an input-and-output contract like that of an MCP (Model Context Protocol) tool, which is why the A2A documentation only sees a fit between the two when the skill is well defined and can be called statelessly.⁠^{[4]A2A Protocol, Linux Foundation. A2A and MCP: Complementary Protocols for Agentic Systems}

How it is found, signed and maintained

Three ways to find it. At the well-known address https://{domain}/.well-known/agent-card.json, in an agent catalog or through direct configuration.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)} The first follows the convention of the .well-known directory, and the specification includes its registration as a well-known URI, with the suffix agent-card.json.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)} The second depends on whoever maintains the catalog, because the specification does not set a standard API for those catalogs.⁠^{[1]A2A Protocol, Linux Foundation. Agent Discovery in A2A}

The signature. An Agent Card can be signed with JWS (JSON Web Signature) so the client can check that it has not been altered and that it comes from whoever says so. Before signing, the JSON is put in canonical form with the JCS scheme, so any implementation computes the same signature, and the client should verify at least one signature before trusting the card.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}

The extended version. If the public card declares capabilities.extendedAgentCard, the agent offers a second version, only for clients authenticated with one of the schemes the public one declares. That version can include skills the public one does not show, usage limits or per-client configuration.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}

The cache. A card changes rarely and is requested often, so the specification asks the server for a Cache-Control header with its max-age and an ETag derived from the version or a digest of the content, and asks the client for conditional requests when its stored copy expires.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}

In a store

Here is how a store's server responds when an agent asks for its card, with the cache headers the specification recommends.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)} It is a fictitious example: the domain, the version and the skill are made up, and the card is trimmed.

GET /.well-known/agent-card.json HTTP/1.1
Host: northpack.example

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
ETag: "1.4.0"

{
  "name": "Northpack Backpacks order agent",
  "description": "Checks the status of an order and shipping times.",
  "version": "1.4.0",
  "supportedInterfaces": [
    { "url": "https://northpack.example/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": false, "extendedAgentCard": true },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "order-status",
      "name": "Order status",
      "description": "Says where an order is and when it will arrive.",
      "tags": ["orders", "shipping"],
      "examples": ["When will order 10482 arrive?"]
    }
  ]
}

A shopping agent that reads this knows three things: that it can ask about orders in text, at which address and with which version of the protocol; that the store has an extended card, so there are more skills for whoever authenticates; and that it does not need to request the card again for an hour. The full example card, with its catalog, is in the entry on A2A.

How to check it

1. Request the card. https://{domain}/.well-known/agent-card.json has to return an AgentCard object.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}
2. Go through the required fields in the table above and the protocolVersion of each interface; the current one is 1.0.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}
3. If it carries signatures, verify one: the public key is obtained with the signature's kid and jku data, over HTTPS, and an expired or revoked key is no good.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}
4. Look at the response headers: a Cache-Control with max-age and an ETag say the server follows the caching recommendation.⁠^{[3]A2A Protocol, Linux Foundation. Agent2Agent (A2A) Protocol Specification (version 1.0.0)}
5. Look for what should not be there: secrets, internal addresses or skills that only authenticated clients should see.⁠^{[1]A2A Protocol, Linux Foundation. Agent Discovery in A2A}

Related concept: the UCP profile

The UCP profile is the document a merchant publishes at /.well-known/ucp to say which purchasing services and capabilities it offers and over which transports: REST, MCP, A2A or an embedded experience.⁠^{[2]Universal Commerce Protocol. UCP Specification Overview (version 2026-08-25)} The Agent Card describes an agent and how to talk to it over A2A; the UCP profile describes a merchant and all the routes through which you can buy from it. They meet at one point: when the profile declares the a2a transport, its address is the URL of the Agent Card of the merchant's agent.⁠^{[2]Universal Commerce Protocol. UCP Specification Overview (version 2026-08-25)} A buying agent can reach the card through the profile, or directly.

To go further, the agentic commerce reading path orders the rest of the protocols, and the entry on the protocol gateway explains what happens when an A2A agent has to talk to something that only understands MCP.