MCP vs A2A vs ARD: How AI Agents Call Tools, Talk to Each Other, and Get Discovered

Three open specifications now define how AI agents interact with the world outside their own process: MCP (Model Context Protocol), A2A (Agent2Agent), and ARD (Agentic Resource Discovery). They are frequently mentioned in the same breath and frequently confused, but they solve three different problems at three different layers of the stack. MCP is how an agent calls a tool. A2A is how an agent talks to another agent. ARD — announced in July 2026 — is how agents find those tools and agents in the first place.

If you're deciding what your service should publish, or trying to work out which spec a vendor actually implements, this is the map.

The Three Layers at a Glance

	MCP	A2A	ARD
Solves	Agent → tool invocation	Agent → agent collaboration	Discovery of both
Steward	Anthropic (open spec)	Google, now Linux Foundation	Working group: Google, Microsoft, Hugging Face, GoDaddy
Launched	November 2024	April 2025	July 2026
Wire protocol	JSON-RPC 2.0 over stdio or Streamable HTTP	JSON-RPC 2.0 over HTTP(S), plus gRPC and REST bindings	HTTPS document fetch + registry search API
Discovery document	`/.well-known/mcp/server-card` (experimental, SEP-2127)	`/.well-known/agent-card.json`	`/.well-known/ai-catalog.json`
Unit of capability	Tools, resources, prompts	Skills on an Agent Card	Catalog entries with URN identifiers

MCP: The Tool-Calling Layer

MCP, open-sourced by Anthropic in November 2024, standardizes how an AI application connects to external capabilities. An MCP server exposes three primitive types — tools (callable functions with JSON Schema inputs), resources (read-only data), and prompts (reusable templates) — over JSON-RPC 2.0. Local servers run over stdio; remote servers use the Streamable HTTP transport, where a single endpoint accepts POST requests and can answer with plain JSON or a Server-Sent Events stream.

The session starts with an initialize handshake in which client and server exchange protocolVersion, capabilities, and serverInfo. After that, tools/list returns every available tool and tools/call invokes one. Remote servers increasingly sit behind OAuth 2.0: an unauthenticated request gets a 401 with a WWW-Authenticate header pointing at protected resource metadata (RFC 9728), which tells the client where to obtain a token.

By mid-2026 the host ecosystem includes Claude, Cursor, Cline, Zed, Windsurf, and agents built on LangGraph and the OpenAI Agents SDK. We covered the protocol in depth in our MCP explainer.

What MCP deliberately does not define is how anyone finds an MCP server. SEP-2127 — the "server card" proposal for a /.well-known/mcp/server-card document — was accepted as an experimental extension, but it describes one server on one domain. Cross-organization discovery is out of scope. That gap is where ARD comes in.

A2A: The Agent-to-Agent Layer

A2A, announced by Google in April 2025 and since donated to the Linux Foundation, is a peer protocol: both sides are agents. Instead of a fixed tool schema, an A2A server publishes an Agent Card — a JSON document at https://{domain}/.well-known/agent-card.json describing the agent's identity, service endpoint, protocolVersion, skills, input/output modes, and securitySchemes for authentication.

Where MCP calls are synchronous function invocations, A2A models tasks: a client agent sends a message, the remote agent works — possibly for minutes, possibly streaming intermediate updates — and returns artifacts. The interaction contract is negotiated from the card rather than hard-coded, which is what makes it possible for two agents built by different companies on different frameworks to cooperate.

The two protocols are complementary, and Google's own documentation frames them that way: an agent might use MCP to hit its own tools (a database, a search index) while using A2A to delegate a subtask to a partner company's booking agent.

ARD: The Discovery Layer

MCP and A2A both answer "how do I talk to this thing once I know its URL?" ARD answers the question that precedes it: "what exists?"

Announced in July 2026 by a working group that includes Google, Microsoft, Hugging Face, and GoDaddy, the Agentic Resource Discovery specification lets an organization publish a machine-readable catalog of every agentic capability it offers — MCP servers, A2A agents, plain APIs — at https://{domain}/.well-known/ai-catalog.json. Each catalog entry carries a domain-anchored URN identifier, a media type that says what kind of resource it is (an entry of type application/a2a-agent-card+json is an A2A card, embedded or linked), descriptive tags, and representativeQueries — example natural-language requests the resource can satisfy.

On top of the catalogs sit registries: services that crawl ai-catalog.json files the way search engines crawl web pages, then answer semantic queries like "book a restaurant in Lisbon" with ranked, relevance-scored entries. Because catalogs are served from the publisher's own domain, domain ownership anchors identity, and optional trust manifests add cryptographic attestations (SPIFFE workload identity, SOC 2 references) that a client can verify before invoking anything.

ARD is deliberately protocol-neutral. It doesn't compete with MCP or A2A — it's the index above both.

How the Stack Composes

A concrete flow using all three specs:

Discover (ARD). Your travel agent asks a registry: "who can book flights?" The registry returns an entry from airline.com's ai-catalog.json — an A2A agent, with a trust manifest.
Verify (ARD). The client checks that the entry's URN is anchored to airline.com and validates the attestations.
Connect (A2A). It fetches airline.com/.well-known/agent-card.json, reads the skills and securitySchemes, authenticates, and opens a task.
Execute (MCP). Internally, the airline's agent calls its own fare-search and payment systems over MCP.

The analogy to the early web is hard to miss: MCP and A2A are HTTP; agent cards and server cards are home pages; ARD catalogs are the sitemap; ARD registries are the search engine.

What Should You Publish?

If you run a service and want agents to use it:

Expose capabilities as an MCP server (tool-shaped, synchronous) or an A2A agent (task-shaped, collaborative) — or both.
Describe them with the matching discovery document: an MCP server card and/or an A2A agent card at their well-known paths.
Index them in a single /.well-known/ai-catalog.json so ARD registries can find everything you offer.

If you're building the agent side instead, the protocol layer is only half the picture — the internal wiring of a multi-agent system (which agent owns which tool, where handoffs happen) is its own problem. The Agent Workflow Visualizer maps that wiring for LangGraph, CrewAI, AutoGen, and Google ADK codebases; the discovery documents above map the public surface.

Takeaway

MCP, A2A, and ARD are not competitors on a single axis — they are the invocation, collaboration, and discovery layers of one emerging stack. MCP has two years of ecosystem momentum, A2A has the Linux Foundation and a well-specified card format, and ARD is weeks old but backed by the companies that own distribution. The practical bet: services that publish all three discovery documents now will be the ones agents can actually find when registry crawling becomes routine.