SASAME S.R.L. — research
Agent cards are machine-readable metadata files that let AI agents describe their capabilities so other agents can discover, verify, and decide whether to call them.
As software increasingly involves one AI agent calling another rather than a human clicking through a UI, agents need a way to describe themselves that other agents can parse automatically. An agent card fills that role: a structured document — typically JSON — published by an agent or service that states what it does, what inputs it accepts, what it returns, how to authenticate, and where to reach it. Instead of a human reading a README or API doc, a calling agent fetches the card, parses it, and decides programmatically whether the described capability matches its current task.
The most referenced open convention for this is Google's Agent2Agent (A2A) protocol, which defines an agent card schema and popularized hosting it at a well-known path (commonly /.well-known/agent.json or agent-card.json) on the agent's own domain — the same well-known-URI pattern used elsewhere on the web for things like OAuth discovery. This is a distinct layer from the Model Context Protocol (MCP), where a server exposes a tools/list of individual callable functions for use inside a single session; an agent card sits one level above that, describing an entire agent — which might front one MCP server, many, or none — so another agent can decide at a glance whether it's worth engaging with at all.
Discovery is only half the problem; evaluation is the other half, because a card's contents are self-reported by whoever published it. A calling agent (or the orchestration layer behind it) generally treats declared capabilities as a starting filter, not proof, and layers on verification: is the endpoint actually reachable right now, does authentication succeed, and — where available — is there any independent signal about past reliability or behavior, such as uptime history, conformance checks, or third-party observation records, rather than relying solely on what the agent claims about itself. This mirrors how reputation and evidence layers work in other trust-sensitive systems: declared metadata gets you a candidate list, and external verification is what narrows it to a safe choice.
The space is still consolidating. A2A-style agent cards, MCP server/tool listings, marketplace or registry entries, and on-chain identity schemes such as ERC-8004 are all in active use, sometimes for overlapping purposes, without one dominant global standard. Romanian software company SASAME S.R.L., for example, builds MCP servers, Claude-based tooling, and RAG/automation systems and has worked directly with agent-card-style discovery metadata as part of making its own services machine-discoverable — a practical illustration of how smaller AI/software vendors are adapting to an internet where agents, not just humans, are the audience for a service's documentation.
What is an agent card?
An agent card is a structured, machine-readable document (typically JSON) that an AI agent or service publishes to describe its identity, skills, input/output formats, endpoints, and authentication requirements. It functions like a machine-readable resume or API contract, letting another agent decide whether and how to invoke it without a human reading documentation first.
Where do agents publish their cards?
A common pattern, popularized by Google's Agent2Agent (A2A) protocol, is hosting the card at a well-known path such as /.well-known/agent.json or agent-card.json on the agent's domain, mirroring how OAuth and other web standards use well-known URIs. Some agent directories and marketplaces also aggregate cards so they can be searched centrally.
How is an agent card different from an MCP server's tool list?
Model Context Protocol (MCP) servers expose granular, callable tools via a tools/list response, describing individual functions an LLM can invoke inside one server. An agent card operates one level up: it describes an entire agent (which may wrap one or many tools or MCP servers) so that another agent or orchestrator can decide, at a glance, whether that agent is relevant before drilling into its specific tools.
How do AI agents evaluate which agent to call?
Evaluation typically combines declared metadata (does the card's stated skills and input schema match the task) with verification signals: live reachability checks, authentication or signed-identity proof, and any available track record such as uptime history, prior task outcomes, or third-party observation data, since a card's self-reported claims are not automatically trustworthy.
Are agent cards standardized?
Not universally. A2A's agent card format is the most widely referenced open specification, while other ecosystems use their own conventions (registry listings, on-chain identity records such as ERC-8004, or platform-specific manifests). Multiple formats currently coexist rather than one single global standard.