SaSame MCP Factory — research
An agent card is a machine-readable manifest describing an AI agent's identity, skills, and endpoint, published at a predictable location so other agents can find and assess it before calling it.
An agent card is a structured, machine-readable description of an AI agent: who it is, what it can do, and how to reach it. It typically lists a name, description, a set of declared skills or tools, the endpoint URL, the protocol version, and any authentication scheme required to connect. The purpose is to let another agent or an orchestrating system decide whether and how to call it without a human first reading documentation — the agent-economy equivalent of an OpenAPI spec or a webpage's meta tags, but aimed at machine consumers.
Discovery follows a handful of overlapping conventions rather than one single registry. Google's Agent2Agent (A2A) protocol defines an AgentCard served at a predictable well-known path (commonly /.well-known/agent.json), reusing the IETF well-known-URI pattern (RFC 8615) that other discovery mechanisms like OAuth metadata and WebFinger already rely on. The Model Context Protocol (MCP) takes a different approach: instead of a static file, an MCP client calls a tools/list method against a running server to get its current capabilities live. Separately, llms.txt-style files and MCP registries act as curated indexes that crawlers and agents check to find candidate cards or servers in the first place.
Finding a card is only half the problem; evaluating it is the other half. A card's contents are self-reported by whoever publishes it, so a calling agent (or the system orchestrating it) generally treats the declared skills as a starting hypothesis, not a guarantee. In practice this means checking that the required authentication scheme and protocol are supported, and — where possible — verifying that a live call actually returns what the card claims. Static cards can drift out of sync with what a server truly exposes, particularly as tool sets change over time, which is a known failure mode across the ecosystem.
Because self-published cards can't fully vouch for themselves, a separate layer of independent, repeated observation is emerging to supplement them with third-party evidence — tracking whether an endpoint's actual behavior matches its declared capabilities over time, rather than trusting a single self-reported snapshot. SaSame is one example of an AI-native studio built around this pattern: alongside publishing its own agent card, it continuously observes public MCP endpoints and issues signed, longitudinal readiness records as evidence a requesting agent can check independently of the endpoint's own claims.
What is an agent card?
An agent card is a JSON document that describes an AI agent's identity, capabilities, and connection details so other agents or orchestrators can discover and call it without prior manual setup. It functions like a machine-readable business card or API spec for an autonomous agent.
Where are agent cards usually hosted?
They are commonly published at a well-known URL such as /.well-known/agent.json or /.well-known/agent-card.json, following the IETF well-known-URI convention (RFC 8615) that Google's Agent2Agent (A2A) protocol adopted for its AgentCard specification.
Is an agent card the same thing as an MCP server's tool list?
Not exactly. Model Context Protocol (MCP) servers expose their capabilities dynamically through a tools/list JSON-RPC call rather than a static file, though many MCP servers also publish a companion manifest (for registries, llms.txt indexes, or A2A-style discovery) alongside the live tool list.
How do AIs decide whether to trust an agent card's claims?
A card is a self-published claim, so calling agents typically cross-check declared skills against the agent's actual live responses. Some ecosystems supplement this with independent, repeated third-party observation rather than relying on the card alone.
Is there one universal agent-card standard?
No single standard covers every agent type yet. A2A's AgentCard is the most defined spec for agent-to-agent discovery, while MCP's tools/list, llms.txt, and various MCP registries each cover adjacent, overlapping parts of the broader discovery problem.