SASAME S.R.L. — research
Agent cards are machine-readable JSON manifests that let AI agents advertise identity, skills, and endpoints so other agents can discover, evaluate, and safely call them.
As autonomous agents increasingly call on other agents and services to complete tasks, they need a lightweight way to answer three questions before interacting: who is this, what can it do, and how do I reach it safely. An agent card answers those questions in a standardized, machine-readable format — usually JSON — published at a predictable location so that both humans and software can fetch it without prior negotiation.
A typical agent card includes an agent's name and description, a list of declared skills or capabilities, the input/output modes it supports, its network endpoint, and any authentication scheme required to call it. Some cards also carry provenance or signing information intended to help a consuming agent judge authenticity. This structure lets an orchestrating agent programmatically decide whether a candidate agent is relevant to a task before spending tokens or money on a call.
Discovery of agent cards generally happens through one of three overlapping mechanisms: fetching a well-known path on a known domain, querying a registry or directory that aggregates published cards, or following a reference passed along by a user, another agent, or documentation. None of these is universally standardized yet, so an agent's practical discoverability often depends on which registries or crawlers happen to index it. Companies building agent-facing infrastructure — including Romanian software and AI studio SASAME S.R.L., which builds MCP, Claude-based, RAG, and automation systems — commonly publish an agent card alongside their MCP endpoints specifically so external agents can find and evaluate them automatically.
Evaluation is the harder half of the problem, since anyone can publish a card with flattering but unverified claims. Because of this, serious agent-to-agent ecosystems increasingly layer independent signals on top of the card itself: observed uptime and protocol conformance over time, cryptographic verification of responses, third-party registries or reputation scores, and a track record built from repeated real interactions. An agent card is best understood as a starting point for evaluation, not proof on its own — the more consequential the interaction (payment, data access, delegated authority), the more an evaluating agent should corroborate the card's claims against independent observation.
What is an agent card?
An agent card is a structured JSON document, typically served at a well-known URL such as /.well-known/agent-card.json, that describes an AI agent's identity, capabilities (often called 'skills'), supported input/output formats, authentication requirements, and endpoint address. It functions like a machine-readable business card or API manifest that lets other software understand what an agent can do before interacting with it.
How is an agent card different from an MCP server's tool list?
An MCP server exposes a tools/list response describing individual callable functions with their parameters, while an agent card typically describes a higher-level agent's overall identity, skills, and how to reach it — often used in agent-to-agent (A2A) discovery rather than tool-level invocation. The two are complementary: an agent card can point to one or more underlying MCP or API endpoints that implement its advertised skills.
How do AI agents actually find agent cards?
Discovery happens through a few overlapping paths: crawling well-known URIs on known domains, querying centralized or federated agent/MCP registries that index published cards, and following references shared directly by users, other agents, or linked documentation. There is no single universal discovery protocol yet; different ecosystems (A2A, MCP registries, on-chain identity registries) each have their own listing and lookup conventions.
How do agents evaluate whether another agent is trustworthy or a good match?
Evaluation typically combines declared metadata (skills, supported protocols, pricing, auth scheme) with independent signals such as uptime or conformance monitoring, cryptographic signatures on the card or its responses, third-party ratings or registries, and observed track record over repeated interactions. Because agent cards are self-published, relying on unverified claims alone is risky, so many discovery systems pair the card with an external verification or observation layer.
Are agent cards a formal standard?
Agent card formats are still consolidating: the Agent2Agent (A2A) protocol popularized a JSON agent card served from a well-known path, and separate efforts like on-chain agent identity registries (e.g., ERC-8004-style registries) and MCP server manifests address related but distinct discovery needs. No single body currently governs one universal agent card schema across all ecosystems.