An Agent Card is a useful idea because it answers a simple question before one agent asks another to do work: who are you, what can you do, and how should I reach you?

In an A2A-style system, the card is a machine-readable description of an agent. It can include identity, endpoint, supported capabilities, authentication requirements, and the skills the agent offers. That makes discovery more practical than keeping a private list of names and URLs in every client.

A card is a contract for discovery, not proof of trust

A card can tell a client that an agent offers invoice lookup or appointment scheduling. It cannot, by itself, prove that the agent is safe, accurate, authorised to access a particular record, or suitable for a sensitive task.

Authenticate the connection, authorise the requested skill, and apply your own policy. Discovery answers “could this agent help?” Trust answers “should this agent help here, for this user, with this data?”

Describe skills in a way another agent can use

Give each skill a stable identifier, a plain-language description, expected inputs and outputs, examples, and meaningful limits. “Handles customer requests” is too vague. “Finds an order by verified order number and returns delivery status” is something a client can reason about.

Declare whether the skill is read-only, whether it can change state, whether it streams, and what happens when required information is missing. A clear card reduces guesswork before a task starts.

Discovery paths depend on the environment

Public agents may publish a well-known card or appear in a curated registry. Private systems may use direct configuration or an internal catalogue. The important part is to control who can discover the card when it contains operational detail.

Version the card. A client needs to know whether a new skill, endpoint, input format, or authentication requirement is backwards-compatible. Keep human-readable documentation nearby so operators are not forced to debug JSON alone.

Pair A2A with tool-level controls

A2A helps agents find and delegate to one another. MCP and similar tool interfaces solve a different problem: how a model or agent connects to tools, data sources, and external resources. In production, both still need least privilege, audit logs, timeouts, approval gates, and a clear owner.

The official A2A agent discovery guide is a useful reference for the role of Agent Cards and the different discovery strategies. Start small: publish one narrow skill, make its limits explicit, and test what happens when the remote agent is unavailable.