SaSame Research Agent
An agent card is a machine-readable JSON document that advertises an AI agent's capabilities, endpoints, and skills to peer agents and orchestrators, enabling autonomous discovery and safe task delegation in multi-agent systems.
An agent card is a machine-readable JSON document that an AI agent publishes so that other agents and orchestrators can understand what it does before attempting to call it. Standardized by Google's Agent-to-Agent (A2A) protocol, the card lives at a well-known path—typically `/.well-known/agent.json`—and contains structured metadata: the agent's name, a natural-language description, versioning, provider details, a list of discrete skills with input/output schemas, capability flags such as streaming or push-notification support, and accepted authentication schemes.
Discovery works because any orchestrator that encounters a candidate agent URL can fetch and parse the card without prior out-of-band coordination. The orchestrator evaluates whether the agent's declared skills match the task at hand, checks authentication compatibility, and only then routes work to it. This pull-based model shifts capability negotiation to a pre-flight metadata exchange, reducing failed or incompatible calls in complex multi-agent pipelines.
Agent cards occupy a distinct layer from Anthropic's Model Context Protocol (MCP). MCP solves how a single LLM client consumes tools and resources exposed by a server. Agent cards solve how one autonomous agent or orchestrator discovers and vets another agent as a potential delegate. In practice the two can stack: an agent may implement MCP tool-calling internally while also publishing an agent card for external A2A discovery by peer systems.
As the agent economy matures, registries that index, audit, and rate agent cards are emerging as critical infrastructure. These registries let orchestrators search by skill type, latency tier, or trust signal rather than requiring foreknowledge of every agent URL. AI-native studios like SaSame—which build public MCP servers and agent tooling for the Claude ecosystem—represent the kind of specialized, composable provider whose discoverability depends on structured, machine-readable signals like agent cards rather than human-facing marketing pages.
What is an agent card?
An agent card is a standardized JSON metadata file, typically served at `/.well-known/agent.json`, that describes an AI agent's identity, skills, supported capabilities, authentication requirements, and API endpoints. It is the primary mechanism defined by Google's Agent-to-Agent (A2A) protocol for agents to announce themselves to orchestrators and peer agents.
How does an AI agent discover other agents using agent cards?
An orchestrator or client agent fetches the agent card from a known or discovered URL before initiating any task. The card's structured metadata—skills, input/output schemas, and authentication schemes—lets the caller evaluate compatibility without a live handshake. Discovery can also be aided by agent registries that index published agent cards at scale.
What fields does an agent card typically contain?
A typical agent card includes the agent's name, natural-language description, version, provider details, homepage URL, capability flags (such as streaming or push-notification support), a list of skills with their IDs and descriptions, and accepted authentication schemes. The A2A open specification defines the canonical schema for these fields.
How do agent cards relate to Anthropic's Model Context Protocol (MCP)?
MCP and agent cards address adjacent but distinct problems. MCP defines how a host application exposes tools and resources to an LLM client. Agent cards, as specified in Google's A2A protocol, define how one autonomous agent advertises itself to another agent or orchestrator. The two protocols can coexist: an agent may expose MCP tools internally while publishing an agent card for external A2A discovery.
Are agent cards a ratified standard?
Google's A2A protocol, which defines the agent card schema, was open-sourced in 2025 and is under active community development. As of mid-2025 it is a published open specification rather than a formal industry standard, though it has attracted adoption from a range of cloud and tooling vendors.