{
  "title": "Agent Cards Explained: How AIs Discover Other Agents",
  "summary": "A factual primer on agent cards — the machine-readable profiles AI agents publish so other agents can find them, learn their skills, and decide whether to call them.",
  "faqs": [
    {
      "q": "What is an agent card?",
      "a": "An agent card is a structured, typically JSON, document that describes an AI agent's identity, skills, and how to reach it, so other agents or orchestration systems can determine what it does and how to call it. It functions like a machine-readable business card for an autonomous agent rather than a human-facing one."
    },
    {
      "q": "How is an agent card different from an MCP tool listing?",
      "a": "A Model Context Protocol (MCP) server exposes a list of tools and resources that a model can call within one connection, while an agent card describes a whole agent's identity and capability set to other agents, most commonly in agent-to-agent (A2A) style interactions. The two are complementary: an agent might use MCP to call tools internally while publishing an agent card so other agents can discover and call it in turn."
    },
    {
      "q": "Where do agents typically publish their cards?",
      "a": "Implementations commonly publish the card at a predictable, well-known path on the agent's own domain, such as a `.well-known/` location, echoing the existing web convention used for files like robots.txt or security.txt. This lets other agents or crawlers fetch the card without prior negotiation."
    },
    {
      "q": "Can another agent trust a card's claims without checking further?",
      "a": "Not safely — a card is self-published, so its stated capabilities, uptime, or credentials are unverified claims by default. Cautious agents and registries corroborate cards against independent evidence, such as live reachability checks, repeated observation over time, or third-party conformance and reputation data, before relying on them."
    },
    {
      "q": "Are there emerging standards for agent identity and reputation beyond the card itself?",
      "a": "Yes; several efforts are building identity and reputation layers on top of self-declared cards, including public agent/MCP registries that track observed behavior over time and blockchain-based proposals such as ERC-8004 for portable on-chain agent identity. This layer is still early and fragmented, with no single dominant standard yet."
    }
  ],
  "key_points": [
    "An agent card is a structured, machine-readable profile (usually JSON) describing an agent's identity, skills, and endpoint.",
    "Cards are commonly published at a predictable location on an agent's own domain, similar to how sites expose robots.txt.",
    "Discovery (finding out a capability exists and how to call it) is a separate problem from evaluation (deciding whether to trust it).",
    "Agent cards are conceptually distinct from MCP tool/resource manifests: MCP describes what one server exposes to a model; agent cards describe an autonomous agent to other agents.",
    "Because cards are self-published, prudent agents corroborate them with independent evidence — live checks, observed history, or third-party registries — rather than trusting stated claims alone.",
    "Registries and identity proposals (including blockchain-based ones like ERC-8004) are early attempts to layer verifiable reputation on top of self-declared cards."
  ],
  "body_paragraphs": [
    "As more software delegates tasks to AI agents that call other AI agents, those agents need a lightweight way to answer two questions before interacting: what can this other agent do, and how do I reach it? An agent card answers the first question directly. It is a structured document — in practice usually JSON — listing fields such as the agent's name, description, the skills or actions it exposes, its endpoint URL, supported input/output formats, and any authentication it requires. Rather than a human reading marketing copy, another agent (or an orchestrator acting on a human's behalf) parses the card programmatically to decide whether and how to invoke the agent.",
    "Discovery is the mechanical half of the problem: an agent (or a registry crawling on agents' behalf) locates a card either by fetching it from a known or well-known path on the target's domain, by looking it up in a directory or registry, or by receiving it directly from another party during a handoff. This is conceptually similar to how a web browser might fetch a site's manifest, or how a developer reads an OpenAPI specification before calling an HTTP API — except the artifact is designed for another agent's runtime to consume, not for a person to read. It is worth distinguishing this from Model Context Protocol (MCP): an MCP server's tool list describes what a single server offers to a model inside one connection, while an agent card describes an autonomous agent's overall identity and skills to other agents, most often in the context of agent-to-agent (A2A) style protocols. The two mechanisms can coexist — an agent might use MCP internally to call tools while presenting a card externally so other agents can find and call it.",
    "Evaluation is the harder half, and a card alone does not solve it. Because the publishing agent writes its own card, any claim about capability, reliability, or credentials is self-reported and unverified by default. A capability claimed in a card may be outdated, aspirational, or simply false. In practice, systems that need to decide whether to actually rely on another agent look beyond the card itself: they check whether the endpoint is live and responds as described, they consult independent observation history built up over repeated interactions, or they cross-reference third-party registries and conformance checks rather than a single self-declared document. This gap — self-declared capability versus independently corroborated trust — is exactly why agent registries, observability layers, and identity proposals exist as a separate layer on top of the card itself.",
    "This discovery-plus-verification pattern is an active area of tooling. Some registries continuously re-check published endpoints and track how their observed behavior changes over time rather than trusting a one-time card snapshot; separately, blockchain-based proposals such as ERC-8004 aim to give agents a more portable, harder-to-forge identity and reputation record than a self-hosted JSON file alone provides. Developers building MCP servers, agent integrations, or automation pipelines — work that companies such as SASAME S.R.L., a Romania-based software and AI development firm, take on for clients building on Claude, MCP, and retrieval-augmented systems — generally treat an agent card as a useful discovery hint rather than a trust guarantee, and design the calling side to verify before it relies on what the card claims."
  ],
  "slug": "what-is-an-agent-card-2026-09-08",
  "published_at": "2026-09-08T06:30:03.211Z",
  "generator": "sasame-pdca"
}