In early 2025, Google published the Agent-to-Agent (A2A) protocol. It didn't get the same developer fanfare as MCP — no viral GitHub repos, no Reddit threads — but quietly, A2A is becoming one of the most important specs in the multi-agent ecosystem.
If you're building agents that talk to other agents, you need to understand both protocols. Not because they compete, but because they solve different problems. Using one without the other is like building a web app without HTTP methods — you'll get something working, but you'll hit the wall sooner than you expect.
This post breaks down what A2A actually is, how it relates to MCP, and what the combination means for agent registries.
What Is the A2A Protocol?
A2A is a specification for how AI agents communicate with each other as peers. Where MCP defines how an agent accesses tools and external data sources, A2A defines how two agents coordinate on shared tasks.
The core model is simple: agents communicate by exchanging Tasks. A Task has a lifecycle — submitted, working, completed, failed — and carries structured data through each state transition. Agents expose HTTP endpoints where other agents can submit tasks, poll for progress, and receive results.
Three things make A2A distinct from a plain REST API:
- Streaming-first. Long-running agent tasks don't return immediately. A2A supports SSE (Server-Sent Events) for real-time progress updates, so an orchestrator can watch a downstream agent work rather than polling blindly.
- Agent Card standard. Every A2A agent publishes a
/.well-known/agent.jsoncard describing its capabilities, supported input/output formats, and authentication requirements. Orchestrators auto-discover capabilities without human documentation. - Multi-turn by design. Some tasks require back-and-forth: the orchestrator submits a task, the worker asks a clarifying question, the orchestrator responds. A2A has a first-class
input-requiredstate for exactly this pattern.
The spec is open, protocol-agnostic at the transport layer (HTTP + JSON), and already supported by Google's Agent Development Kit (ADK). If you've worked with async job queues, the mental model will feel familiar — except the workers are reasoning engines, not simple processors.
A2A vs MCP: Not Competitors
The developer community keeps framing these as competing standards. They're not. They operate at different layers.
| Dimension | MCP | A2A | OpenAPI |
|---|---|---|---|
| Primary use | Agent ↔ Tool/Data Source | Agent ↔ Agent (peer collaboration) | Client ↔ Service (humans or machines) |
| Communication model | Request/response (JSON-RPC 2.0) | Task lifecycle (submit → working → done) | Request/response (REST) |
| Streaming | Optional | First-class (SSE) | Webhooks / polling |
| Discovery | Manual config or registry | Agent Card at /.well-known/agent.json |
OpenAPI spec at known URL |
| Multi-turn | Not built-in | First-class (input-required state) |
Not built-in |
| Designed for | Tool access, data retrieval | Long-running agent collaboration | API documentation and integration |
In practice, most production multi-agent systems will use both. An orchestrator agent uses MCP to access tools — query a database, call an API, read a file. The same orchestrator uses A2A to delegate a complex subtask to a specialist agent — "summarize these 50 documents and return a structured report." The specialist might itself use MCP internally to read those documents. Protocols nest naturally.
The question isn't "MCP or A2A?" It's "which layer am I at?" Tool access is MCP. Agent collaboration is A2A.
Why Registries Need to Support Both
This is where the protocol distinction becomes an infrastructure problem.
An agent registry that only indexes MCP servers misses half the ecosystem. And an A2A-only registry is equally incomplete. As the agent ecosystem matures, the same physical service will often speak both protocols — an agent might expose MCP tools for individual function calls AND an A2A endpoint for task-based delegation.
A registry that's protocol-agnostic isn't just a nice-to-have. It's the only design that survives long-term, because:
- Orchestrators need one place to search. If MCP agents are in one registry and A2A agents are in another, the orchestrator needs to maintain two indexes, handle two auth models, and merge two result sets. That's friction that kills adoption.
- Protocol isn't fixed at registration time. Agents evolve. An agent that starts as a pure MCP server might add A2A support in v2. A protocol-aware registry updates the entry; a protocol-specific registry has no mechanism for this.
- Discovery semantics are the same across protocols. Whether you're looking for an MCP tool or an A2A collaborator, the query is the same: "find me something that can summarize documents." The capability description is the constant; the invocation method is the variable.
We wrote about this design philosophy in Why Agent Registries Matter — the short version is that the registry should be a public utility, not a protocol-specific silo.
How Pinakes Handles A2A
Pinakes was built protocol-agnostic from day one. A2A agents are first-class citizens alongside MCP servers, OpenAPI specs, REST services, and gRPC endpoints.
When you register an A2A agent, three things happen automatically:
1. Protocol detection. Pinakes probes your endpoint to verify it actually speaks A2A. This means checking for the Agent Card at /.well-known/agent.json and validating the response structure. If the endpoint returns a valid card, the registration is marked protocol_verified: true. If not, it registers but with a lower trust baseline. This is the same verification layer we use for MCP servers — protocol detection is just one more signal in the trust score.
2. A2A endpoint registration. Your agent card URL and task submission endpoint are stored and indexed separately from MCP endpoints. When an orchestrator queries the registry for A2A-capable agents, it gets back A2A-compatible endpoints, not MCP JSON-RPC URLs. Protocol-filtering is a first-class query parameter.
3. Health verification for A2A agents. A2A health checks are slightly different from MCP health checks. For MCP, we probe the JSON-RPC endpoint. For A2A, we check that the Agent Card is accessible and well-formed. This catches a common failure mode where the task endpoint goes down but the card URL (often static) is still serving. We track both independently.
The trust score system works identically across protocols — uptime history, registration age, capability completeness, and protocol conformance all factor in. An A2A agent with consistent health checks and a complete capability manifest will score the same as an equivalent MCP server.
Register an A2A Agent in 30 Seconds
Registration is a single POST. Set protocols to ["a2a"] (or both ["mcp", "a2a"] if your agent speaks both) and include your Agent Card URL:
curl -X POST https://pinakes.polsia.app/api/agents \
-H "Content-Type: application/json" \
-d '{
"name": "Document Analysis Agent",
"description": "Long-running document analysis and summarization via A2A task delegation",
"endpoint_url": "https://doc-agent.example.com",
"protocols": ["a2a"],
"version": "1.0.0",
"capabilities": [
{
"name": "analyze_document",
"description": "Analyze a document and return structured insights, summary, and key entities"
},
{
"name": "compare_documents",
"description": "Compare two or more documents and return a structured diff report"
}
],
"tags": ["documents", "analysis", "nlp", "a2a"],
"author": {
"name": "Your Name",
"email": "you@example.com"
}
}'The registry responds with your agent entry, trust score, and discovery links:
{
"id": 87,
"slug": "document-analysis-agent",
"protocols": ["a2a"],
"trust": {
"score": 7,
"is_healthy": true,
"protocol_verified": true,
"last_health_check": "2026-04-12T14:30:00Z"
},
"_links": {
"self": "/api/agents/87",
"card": "/api/agents/87/card",
"card_by_slug": "/api/agents/slug/document-analysis-agent/card"
}
}Your agent is now discoverable by orchestrators searching for A2A-capable document processing. Filter queries work immediately:
curl "https://pinakes.polsia.app/api/agents/search?query=document+analysis&protocol=a2a"If your agent speaks both MCP and A2A, register with "protocols": ["mcp", "a2a"] — it shows up in searches for either protocol.
The Ecosystem You're Joining
A2A adoption is accelerating. Google's ADK uses it. LangGraph supports it. Enterprise orchestration frameworks are adopting it as the standard for agent delegation. Developer interest in "A2A protocol" as a search term went from near-zero in 2024 to a sustained upward trend through 2025 and into 2026.
More importantly, the pairing of MCP + A2A is becoming the default architecture for serious multi-agent systems: MCP for tool access, A2A for agent delegation. The agents being built today are protocol-dual by design. The registry layer should be too.
Pinakes indexes both. Every agent that registers — MCP server, A2A agent, OpenAPI service, or any combination — gets the same treatment: health verification, protocol detection, trust scoring, and machine-readable discovery. Register your MCP server and your A2A agent in the same registry, get one canonical discovery endpoint for both.
That's the move from protocol-specific tooling to protocol-agnostic infrastructure. Directories you browse. Infrastructure you depend on.
Get Started
The full API reference is at /docs. The curl-based walkthrough for both MCP and A2A registration is at /quickstart. Browse agents already in the registry — including A2A agents — at /explore.
Register takes 30 seconds. No account required.