A2A agent cards The Agent-to-Agent (A2A) protocol, originally proposed by Google in 2025 and donated to the Linux Foundation later that year, reached version 1.0 in March 2026, with discovery built around a single manifest at the well-known URI /.well-known/agent-card.json. The agent card is a self-describing JSON document whose required fields are name, description, version, supportedInterfaces (each with url, protocolBinding and protocolVersion), capabilities, defaultInputModes, defaultOutputModes and skills (each with id, name, description and tags); since 1.0 the protocol version lives on each supportedInterfaces entry, so a card carrying a top-level protocolVersion is following a 0.3-era example. The protocol complements the Model Context Protocol — MCP exposes tools an LLM can call, while A2A exposes a whole agent another agent can delegate to — and the guidance is to treat A2A as optional for now, useful if a product is itself an agent or wraps one and overkill for a static brochure. A2A agent cards The Agent-to-Agent A2A protocol lets an autonomous agent find another autonomous agent and call it over JSON-RPC. Discovery hinges on a single well-known file: /.well-known/agent-card.json . Relevant whenever your service exposes agentic behaviour another agent might want to delegate to. What it is The Agent-to-Agent A2A protocol is an open standard for one autonomous agent to discover and call another. It was originally proposed by Google in 2025 and donated to the Linux Foundation later that year. It complements the Model Context Protocol https://specification.website/spec/agent-readiness/mcp-and-tool-discovery/ : MCP exposes tools an LLM can call; A2A exposes a whole agent another agent can delegate to. Discovery is deliberately small. An A2A-speaking service hosts a JSON manifest at the well-known URI /.well-known/agent-card.json . The manifest is the agent card — a self-describing document that names the agent, lists its skills, declares its capabilities, and points at one or more transport endpoints that speak the A2A wire protocol JSON-RPC, gRPC, or HTTP+JSON . The minimum field set is small and stable. Required fields per the spec are name , description , version , supportedInterfaces each with url , protocolBinding , protocolVersion , capabilities , defaultInputModes , defaultOutputModes , and skills each with id , name , description , tags . Optional fields cover provider, documentation URL, security schemes, JWS signatures, and an icon URL. The card’s version is the version of your agent , not of the protocol. Since 1.0 the protocol version lives on each entry in supportedInterfaces , because one card can now offer several interfaces speaking different protocol versions. There is no top-level protocolVersion any more, and a card that still carries one is following a 0.3-era example. This site ships such a card as a worked example. The static manifest is at /.well-known/agent-card.json https://specification.website/.well-known/agent-card.json ; the JSON-RPC endpoint is at mcp.specification.website/a2a/v1 https://mcp.specification.website/a2a/v1 . It is intentionally minimal — one send-message method, no streaming, no task lifecycle — and it wraps the same search and topic-fetch logic the MCP server already exposes. It is not yet fully in line with 1.0: the endpoint answers the pre-1.0 method name message/send rather than SendMessage , and the card still carries a top-level protocolVersion next to the per-interface one. Why it matters - An agent card is the standard way for a calling agent to learn what you do, before any call is made. Without it, the calling agent has to be hard-coded against your service or guess from a UI. - A2A is transport-agnostic: a single card can advertise JSON-RPC, gRPC, and HTTP+JSON endpoints in priority order. Clients pick the binding they support. - It composes cleanly with MCP. An MCP server gives an LLM tools; an A2A card lets that whole LLM-plus-tools agent be reached by other agents. The two protocols are not alternatives. - The card is a contract. Treat changes to skills .id , supportedInterfaces .url , or capabilities as breaking, and bump version accordingly. Adoption is early but accelerating. The protocol reached version 1.0 in March 2026. Treat A2A as optional for now — useful if your product is itself an agent or wraps one, overkill if it is a static brochure. How to implement - Build the card. Author a JSON document with name , description , version , provider , supportedInterfaces each declaring its own url , protocolBinding and protocolVersion , capabilities , defaultInputModes , defaultOutputModes , and skills . Use the A2A specification https://a2a-protocol.org/latest/specification/ as the field reference. Use camelCase keys throughout. - Pick a transport. JSON-RPC over HTTPS is the lowest-friction option and is what we ship here. gRPC is appropriate when you already speak gRPC; HTTP+JSON when you have an existing REST surface to wrap. - Serve it at the canonical URI. Per RFC 8615 https://www.rfc-editor.org/rfc/rfc8615 , publish at /.well-known/agent-card.json with Content-Type: application/json and a sensible Cache-Control an hour is fine; ETag is better . - Advertise it. Add a Link: