SystemsMcp

MCP and A2A Are Layers, Not Rivals

The consolidation under open standards settled the protocol question. MCP solves tool access; A2A solves agent collaboration. Here is how they stack in production.

Kushan Manahara

February 25, 2025 · 4 min read

00
MCP and A2A Are Layers, Not Rivals

The AI agent ecosystem has transitioned over the past year from wild fragmentation toward layered standardization. In early 2024, if you wanted an autonomous agent to read a production Postgres table, query GitHub pull requests, and hand off tasks to a specialized verification agent, you had to write custom glue code for every model provider and every tool.

For a while, two emerging standards seemed to compete for mindshare: Anthropic's Model Context Protocol (MCP) and agent communication protocols such as IBM's ACP and Google's A2A (Agent-to-Agent). The industry debated which protocol would win.

That debate is over because it was based on a category error. MCP and A2A operate on orthogonal axes. MCP is the vertical plane (model-to-tool), while A2A is the horizontal plane (agent-to-agent). High-scale enterprise agentic systems do not pick between them; they use MCP at the bottom of the stack and A2A at the top.

The Layered Agent Architecture

architecture.txt
┌─────────────────────────────────────────────────────────────┐
│                     AGENT ORCHESTRATION LAYER               │
│             A2A Protocol (REST / SSE / Asynchronous)        │
│   • Capability discovery (Agent Cards)                      │
│   • Cross-organization task delegation                      │
│   • Human-in-the-loop approvals & long-running sessions     │
└──────────────┬───────────────────────────────┬──────────────┘
               │ Task Delegation               │ Task Delegation
               ▼                               ▼
┌──────────────────────────────┐ ┌─────────────────────────────┐
│    SPECIALIZED AGENT A       │ │     SPECIALIZED AGENT B     │
│    (e.g., Code Reviewer)     │ │     (e.g., Deploy Master)   │
└──────────────┬───────────────┘ └─────────────┬───────────────┘
               │ MCP (JSON-RPC 2.0)            │ MCP (JSON-RPC 2.0)
               ▼                               ▼
┌──────────────────────────────┐ ┌─────────────────────────────┐
│     MCP TOOL SERVERS         │ │      MCP TOOL SERVERS       │
│   • Git / GitHub API         │ │   • Kubernetes Cluster API  │
│   • Static Analysis Engine   │ │   • Cloudflare DNS          │
└──────────────────────────────┘ └─────────────────────────────┘

MCP: The Vertical Tool Plane

MCP solves the N×M integration problem between models and external resources. Instead of every tool author writing custom SDK wrappers for LangChain, LlamaIndex, Claude, and OpenAI, MCP establishes a clean, type-safe client-server contract over JSON-RPC 2.0 (via stdio or Server-Sent Events).

MCP is strictly stateless and synchronous. A tool call is an atomic query: the model issues a request, the server executes the tool locally, and returns the structured payload. Here is what a raw MCP tool invocation looks like on the wire:

mcp-call.json
// Client -> MCP Server
{
  "jsonrpc": "2.0",
  "id": "req-42",
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT id, status, total FROM orders WHERE customer_id = $1 LIMIT 5",
      "params": ["cust_9821"]
    }
  }
}

// MCP Server -> Client
{
  "jsonrpc": "2.0",
  "id": "req-42",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "[{\"id\":\"ord_1\",\"status\":\"shipped\",\"total\":149.50}]"
      }
    ],
    "isError": false
  }
}

A2A: The Horizontal Collaboration Plane

While MCP connects a model to a database, it has no semantics for long-running workflows, multi-agent negotiations, or inter-service trust. If an agent needs to delegate a task to an agent hosted by a third-party vendor (e.g. an external logistics provider), MCP is the wrong protocol.

A2A (Agent-to-Agent) operates over HTTPS/REST and WebSockets. It introduces:

  • Agent Discovery: Agents publish machine-readable capability cards declaring their domains, input schemas, and authentication requirements.
  • Asynchronous State Machines: Tasks can remain in pending_approval or in_progress for hours while waiting for human sign-off or external batch completions, without holding open synchronous socket connections.
  • Organizational Boundaries: Built-in OAuth2 and mTLS mechanisms allow agents across different companies to collaborate with auditability.
a2a-task-delegation.json
// Orchestrator -> Compliance Audit Agent (A2A)
POST /v1/agents/compliance-auditor/tasks
Host: agent.enterprise-audit.com
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{
  "task_id": "task_audit_2026_09",
  "intent": "evaluate_pull_request_compliance",
  "payload": {
    "repository": "space/backend-api",
    "pr_number": 342,
    "compliance_frameworks": ["SOC2", "HIPAA"]
  },
  "callback_url": "https://orchestrator.internal.net/webhooks/a2a-results",
  "async": true
}

How They Stack Together

Consider a concrete production scenario: An incident response orchestrator receives an alerting webhook. The orchestrator uses A2A to assign a diagnosis task to a Site Reliability Agent. That SRE Agent boots up, uses MCP to query Datadog logs and inspect Kubernetes pods, determines that a memory leak occurred, and uses MCP to restart the deployment.

Once mitigated, the SRE Agent uses A2A to reply back to the orchestrator with the incident timeline. The orchestrator then delegates to a Comms Agent via A2A to draft the customer-facing post-mortem.

Written by

Kushan Manahara

Responses (0)

Verified name, role, and email required before posting.

No responses yet

Be the first to share your thoughts, benchmarks, or feedback above.