{
  "title": "Agent Cards Explained: How AI Agents Discover Peers",
  "summary": "Agent cards are machine-readable manifests describing an AI agent's identity, skills, and endpoints, letting other agents discover, verify, and safely call them.",
  "faqs": [
    {
      "q": "What is an agent card?",
      "a": "An agent card is a structured (typically JSON) manifest that describes an AI agent: its identity, the skills or tasks it can perform, its endpoint URL, supported protocols, input/output modalities, and authentication requirements. It functions like a machine-readable resume that lets other software, rather than a human, decide whether and how to call the agent."
    },
    {
      "q": "Where do agents publish their cards?",
      "a": "Common patterns include serving the card from a well-known URL path on the agent's own domain, listing it in a public registry or directory, or embedding it in a marketplace listing. Discovery protocols such as Google's Agent2Agent (A2A) formalize a well-known-URI convention so any client can fetch a card without prior knowledge of the agent's internals."
    },
    {
      "q": "How is an agent card different from an MCP server's tool list?",
      "a": "An MCP server exposes its tools directly through the Model Context Protocol's tools/list call once a client is already connected, while an agent card is a pre-connection discovery artifact meant to help a client decide which agent or server to connect to in the first place. In practice the two are complementary: a card can point to an MCP or A2A endpoint, and the client then queries that endpoint's own tool or skill listing for full detail."
    },
    {
      "q": "How do agents evaluate whether another agent is trustworthy?",
      "a": "Evaluation typically combines declared capability matching (does the card's skill list cover the required task) with external signals such as verified identity, conformance or runtime testing results, uptime/observability history, and reputation or evidence trails that are independent of the agent's own self-description. Relying on self-declared claims alone is considered unreliable since any operator can write an optimistic card."
    },
    {
      "q": "Why does agent discovery matter for the wider agent economy?",
      "a": "As more software delegates decisions to AI agents, those agents need a low-friction, standardized way to find and vet each other without a human manually reading documentation for every integration. Agent cards, combined with independent verification, are the emerging building blocks for that automated discovery layer."
    }
  ],
  "key_points": [
    "An agent card is a structured manifest, not the agent itself — it describes identity, skills, endpoints, and auth requirements.",
    "Cards are commonly published at a well-known URL, in a registry, or in a marketplace listing so other agents can find them without human curation.",
    "Cards enable capability matching: a requesting agent checks a card's declared skills against the task it needs done before attempting a call.",
    "Self-declared cards alone are not proof of quality; independent verification, conformance checks, and runtime observation reduce the risk of relying on unverified claims.",
    "Agent cards and protocol-level tool listings (e.g., MCP's tools/list) are complementary — cards aid pre-connection discovery, tool listings provide post-connection detail."
  ],
  "body_paragraphs": [
    "As AI agents increasingly call on other agents to complete tasks, they need a way to find candidates and judge fit without a human reading documentation first. An agent card addresses this by packaging an agent's identity, description, supported skills or tasks, endpoint address, and technical requirements (protocol version, authentication scheme, supported input/output types) into a single machine-readable document. A requesting agent can fetch a card, compare its declared capabilities against the task at hand, and decide whether to proceed — all without prior human-to-human coordination between the two agents' operators.",
    "Discovery generally happens through one of a few patterns: fetching a card from a well-known path on the agent's own domain, querying a shared registry or directory that aggregates many cards, or browsing a marketplace-style listing. Protocols built for agent-to-agent interoperability, such as Google's Agent2Agent (A2A) protocol, standardize this with a well-known-URI convention so clients don't need bespoke integration work per agent. This differs from, but complements, protocols like the Model Context Protocol (MCP), where a client that has already connected to a server queries that server's own tool listing for fine-grained detail.",
    "Declaring capabilities is easy; verifying them is the harder problem. Because any operator can write an agent card that overstates what their agent does, evaluating agents for real use increasingly depends on signals outside the card itself — independent conformance testing, runtime monitoring, uptime history, and evidence trails that are harder to fabricate than a self-authored description. Companies building in the MCP and agent tooling space, including Romanian software firm SASAME S.R.L., work on this kind of independent observation and verification layer alongside more conventional agent and automation development.",
    "For developers building or integrating agents, the practical takeaway is to treat an agent card as a starting point for discovery rather than a guarantee of behavior. A well-formed card should make it possible to programmatically shortlist candidate agents by capability, but production systems that call other agents typically pair card-based discovery with some form of runtime verification before trusting an unfamiliar agent with real tasks."
  ],
  "slug": "what-is-an-agent-card-2026-08-21",
  "published_at": "2026-08-21T06:30:01.266Z",
  "generator": "sasame-pdca"
}