Public agent discovery
Use these examples to shape the JSON that another A2A client fetches before deciding whether your agent can complete a task.
6 copy-ready JSON templates · A2A v1.0
A2A Agent Card Examples
Browse practical A2A v1.0 templates, understand their design decisions, then adapt any example for your own agent.
Marketplace submission
Adapt provider, skills, tags, capabilities, and security metadata so reviewers can understand what the agent does and who operates it.
Internal agent catalogs
Standardize endpoint, authentication, and skill descriptions across internal agents before teams integrate them into workflows.
JSON templates
Example Agent Cards for support, booking, shopping, coding, research, and workflow agents.
Filter
Customer Support Agent
Handles product questions, order lookups, returns, and escalation handoffs.
Why it is built this way
- OAuth 2.0 client credentials protect order data: the Agent Card declares the token URL and scope so clients can authenticate without out-of-band documentation.
- streaming and pushNotifications are both true because support conversations are long-running and resolution updates arrive asynchronously.
- The single skill is scoped to one task boundary (classify, resolve, escalate) instead of a vague "help customers" description, so routers can match it precisely.
{
"name": "Customer Support Agent",
"description": "Answers customer support questions, retrieves order context, and escalates unresolved issues to a human team.",
"supportedInterfaces": [
{
"url": "https://api.example.com/a2a/customer-support",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Inc.",
"url": "https://example.com"
},
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": true,
"extendedAgentCard": false
},
"defaultInputModes": [
"text/plain",
"application/json"
],
"defaultOutputModes": [
"text/plain",
"application/json"
],
"skills": [
{
"id": "resolve-customer-support-request",
"name": "Resolve customer support request",
"description": "Classifies a customer support request, gathers needed context, proposes a resolution, and escalates when confidence is low.",
"tags": [
"support",
"orders",
"returns"
],
"examples": [
"Help me return my order."
]
}
],
"securitySchemes": {
"oauth2": {
"oauth2SecurityScheme": {
"flows": {
"clientCredentials": {
"tokenUrl": "https://api.example.com/a2a/customer-support/oauth/token",
"scopes": {
"agent.invoke": "Invoke agent skills"
}
}
}
}
}
},
"security": [
{
"oauth2": [
"agent.invoke"
]
}
]
}Booking Agent
Finds available appointment slots and prepares booking confirmations.
Why it is built this way
- An API key in a header is enough here: bookings are tenant-scoped but do not carry the delegated-user consent problem OAuth solves.
- defaultOutputModes is application/json only, signaling that callers get structured reservation proposals rather than prose.
- pushNotifications is true so the agent can confirm a reservation after the slot-holding backend settles, without the client polling.
{
"name": "Booking Agent",
"description": "Searches availability, proposes booking options, and prepares appointment reservations for approval.",
"supportedInterfaces": [
{
"url": "https://api.example.com/a2a/booking",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Inc.",
"url": "https://example.com"
},
"version": "1.0.0",
"capabilities": {
"streaming": false,
"pushNotifications": true,
"extendedAgentCard": false
},
"defaultInputModes": [
"text/plain",
"application/json"
],
"defaultOutputModes": [
"application/json"
],
"skills": [
{
"id": "find-and-prepare-booking",
"name": "Find and prepare booking",
"description": "Checks resource availability, compares booking windows, and returns a structured reservation proposal.",
"tags": [
"booking",
"calendar",
"availability"
],
"examples": [
"Find a 30-minute appointment tomorrow afternoon."
]
}
],
"securitySchemes": {
"apiKey": {
"apiKeySecurityScheme": {
"location": "header",
"name": "X-API-Key"
}
}
},
"security": [
{
"apiKey": []
}
]
}Shopping Agent
Compares products, availability, prices, and purchase constraints.
Why it is built this way
- Ranked recommendations stream in as they are computed, so streaming is true while pushNotifications stays false — nothing happens after the response completes.
- The skill description commits to returning tradeoffs and rationale, which tells orchestrators this agent explains rankings instead of just listing products.
- OAuth scopes gate purchase-adjacent data; a public shopping demo could drop security entirely and stay a valid Agent Card.
{
"name": "Shopping Agent",
"description": "Compares products against user constraints and returns ranked purchase options with tradeoffs.",
"supportedInterfaces": [
{
"url": "https://api.example.com/a2a/shopping",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Inc.",
"url": "https://example.com"
},
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": false,
"extendedAgentCard": false
},
"defaultInputModes": [
"text/plain",
"application/json"
],
"defaultOutputModes": [
"application/json"
],
"skills": [
{
"id": "compare-shopping-options",
"name": "Compare shopping options",
"description": "Evaluates candidate products, filters by constraints, and returns ranked recommendations with rationale.",
"tags": [
"shopping",
"commerce",
"recommendations"
],
"examples": [
"Compare lightweight laptops under $1,200."
]
}
],
"securitySchemes": {
"oauth2": {
"oauth2SecurityScheme": {
"flows": {
"clientCredentials": {
"tokenUrl": "https://api.example.com/a2a/shopping/oauth/token",
"scopes": {
"agent.invoke": "Invoke agent skills"
}
}
}
}
}
},
"security": [
{
"oauth2": [
"agent.invoke"
]
}
]
}Coding Agent
Reviews code tasks, proposes patches, and explains implementation decisions.
Why it is built this way
- extendedAgentCard is true: the public Agent Card lists a generic "implement code change" skill, while repository-specific skills are only revealed to authenticated clients via GetExtendedAgentCard.
- Both text/plain and application/json outputs are declared because the agent returns human-readable explanations alongside machine-applyable patches.
- Streaming matters for long compile-and-test loops; clients see intermediate progress instead of a silent multi-minute call.
{
"name": "Coding Agent",
"description": "Assists with software engineering tasks by analyzing code, proposing changes, and returning implementation notes.",
"supportedInterfaces": [
{
"url": "https://api.example.com/a2a/coding",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Inc.",
"url": "https://example.com"
},
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": true,
"extendedAgentCard": true
},
"defaultInputModes": [
"text/plain",
"application/json"
],
"defaultOutputModes": [
"text/plain",
"application/json"
],
"skills": [
{
"id": "implement-code-change",
"name": "Implement code change",
"description": "Reads a coding request, inspects relevant files, returns a patch proposal, and summarizes verification steps.",
"tags": [
"coding",
"review",
"patches"
],
"examples": [
"Add pagination to the users API."
]
}
],
"securitySchemes": {
"apiKey": {
"apiKeySecurityScheme": {
"location": "header",
"name": "X-API-Key"
}
}
},
"security": [
{
"apiKey": []
}
]
}Research Agent
Collects sources, extracts evidence, and returns structured research notes.
Why it is built this way
- No securitySchemes at all: the endpoint is intentionally public, and omitting the field is the correct way to say so — an empty scheme map would be ambiguous.
- Input is text/plain only, because research briefs start from natural-language questions; structured output arrives as application/json notes.
- This is the minimal useful v1.0 Agent Card: identity, one interface, capabilities, modes, and one well-tagged skill.
{
"name": "Research Agent",
"description": "Collects source material, extracts evidence, and produces structured research notes with citations.",
"supportedInterfaces": [
{
"url": "https://api.example.com/a2a/research",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Inc.",
"url": "https://example.com"
},
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": false,
"extendedAgentCard": false
},
"defaultInputModes": [
"text/plain"
],
"defaultOutputModes": [
"text/plain",
"application/json"
],
"skills": [
{
"id": "prepare-research-brief",
"name": "Prepare research brief",
"description": "Searches approved sources, extracts claims and evidence, and returns a concise research brief.",
"tags": [
"research",
"evidence",
"citations"
],
"examples": [
"Prepare a cited brief on renewable-energy policy."
]
}
]
}Internal Workflow Agent
Coordinates approvals, status checks, and back-office workflow updates.
Why it is built this way
- application/json is the only input and output mode: this agent is called by other systems, never by people typing prose.
- OAuth 2.0 plus extendedAgentCard fits enterprise audits — security teams can see the auth requirements publicly while sensitive workflow skills stay behind authentication.
- pushNotifications is essential because approval chains take hours or days; webhooks replace polling for state changes.
{
"name": "Internal Workflow Agent",
"description": "Coordinates internal approvals, checks system status, and prepares workflow updates for operations teams.",
"supportedInterfaces": [
{
"url": "https://api.example.com/a2a/workflow",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Example Inc.",
"url": "https://example.com"
},
"version": "1.0.0",
"capabilities": {
"streaming": false,
"pushNotifications": true,
"extendedAgentCard": true
},
"defaultInputModes": [
"application/json"
],
"defaultOutputModes": [
"application/json"
],
"skills": [
{
"id": "coordinate-internal-workflow",
"name": "Coordinate internal workflow",
"description": "Receives workflow intent, checks policy requirements, gathers approvals, and reports final status.",
"tags": [
"workflow",
"operations",
"approval"
],
"examples": [
"Request approval to deploy the payroll update."
]
}
],
"securitySchemes": {
"oauth2": {
"oauth2SecurityScheme": {
"flows": {
"clientCredentials": {
"tokenUrl": "https://api.example.com/a2a/workflow/oauth/token",
"scopes": {
"agent.invoke": "Invoke agent skills"
}
}
}
}
}
},
"security": [
{
"oauth2": [
"agent.invoke"
]
}
]
}Adapt with confidence
How to adapt an Agent Card example
Each Agent Card example is intentionally complete enough to copy, but the Agent Card should not be published unchanged. Treat it as a field map for your own A2A server: replace identity, endpoint, provider, authentication, capabilities, modes, and skill details with production values.
The strongest Agent Cards explain the agent task boundary in plain language and machine-readable metadata. A client should be able to tell what the agent can do, what it cannot do, which URL to call, and whether credentials are required.
Before you publish
Replace every example.com URL with your deployed A2A endpoint and provider website.
Rewrite the skill name, description, tags (required in v1.0), and examples for the actual task boundary.
Set provider.organization and bump the top-level version whenever the Agent Card content changes.
Remove authentication fields only when the endpoint is intentionally public.
Keep defaultInputModes and defaultOutputModes aligned with what your server accepts and returns.
Validate the final JSON and publish it at /.well-known/agent-card.json on your service domain.
Ready to build
Start with an example, then make it your own.
Open any pattern in the Agent Card Generator, review the JSON, and validate it before you publish.