A2A vs MCP, Agent Communication Protocols Explained for DevOps

On July 28, 2026, the Model Context Protocol publishes its largest revision since launch, tearing out the stateful core and replacing it with one that scales across ordinary HTTP load balancers. Two weeks from now, the way you deploy MCP servers changes. Meanwhile A2A reached v1.0 with cryptographically signed Agent Cards, more than 150 organizations run it in production, and both protocols now sit under the same Linux Foundation body. If you are trying to decide between them, you are asking the wrong question. They operate on different axes, and the most common architecture mistake in 2026 is treating one as a substitute for the other.

The distinction that actually matters

MCP is vertical. It standardizes how a single agent reaches down into the world: calling tools, reading data, invoking APIs. The agent stays in charge and the things it touches are passive. An MCP server that wraps kubectl does not think, negotiate, or push back. It exposes capabilities and waits.

A2A is horizontal. It standardizes how one agent asks another agent to do work on its behalf. The far side is not a passive tool but an autonomous system with its own model, its own tools, and its own judgment. It can accept the task, ask a clarifying question, run for six hours, or refuse.

That difference in what sits on the other end drives every design choice in both specs. MCP optimizes for fast, structured, request and response tool calls. A2A optimizes for long running, stateful negotiation between systems that do not trust each other and do not share memory. If you remember one thing, remember that MCP gives your agent hands, and A2A gives it colleagues.

Why the question got urgent in 2026

Both protocols spent 2025 as vendor projects and 2026 turning into infrastructure. The Linux Foundation stood up the Agentic AI Foundation in December 2025 and both specs moved under it, with a founding roster that reads like a truce: Anthropic and Google, the two originators, sitting alongside OpenAI, Microsoft, AWS, and Block. By May 2026 the foundation counted 190 member organizations. The practical effect for you is that neither protocol is now a single vendor's roadmap risk, and the two specs are being pulled toward each other rather than apart.

Adoption followed. MCP passed roughly 97 million monthly SDK downloads, and public registries index close to twenty thousand servers, up from about a hundred at launch. A2A absorbed its closest rival when IBM folded its own Agent Communication Protocol into the standard in August 2025, and by the protocol's one year mark in April 2026 more than 150 organizations were running it in production, including Microsoft, AWS, Salesforce, SAP, and ServiceNow, with the repository past twenty two thousand stars.

The reason this lands on your desk rather than a data scientist's is that both protocols are network protocols. They need gateways, identity, mTLS, rate limits, tracing, and rollout plans. That is platform engineering work, and it does not look like anything in a model card.

How MCP works

MCP defines a client and server relationship carried over JSON-RPC 2.0. The host application, such as a coding assistant or an agent runtime, runs an MCP client. The client connects to one or more MCP servers, each of which wraps some capability.

Servers expose three primitives, and the distinction between them matters when you are designing one:

• Tools are functions the model chooses to call, such as restarting a deployment or querying Prometheus.
• Resources are data the application pulls in as context, such as a config file or a log excerpt.
• Prompts are reusable templates that a user explicitly invokes, such as a canned incident triage workflow.

Transport is either stdio for a local process or Streamable HTTP for a remote one. A minimal server exposing a read only cluster tool looks like this:

from mcp.server.fastmcp import FastMCP
import subprocess

mcp = FastMCP("k8s-readonly")

@mcp.tool()
def get_pod_status(namespace: str) -> str:
    """List pods and their status in a namespace. Read only."""
    out = subprocess.run(
        ["kubectl", "get", "pods", "-n", namespace, "-o", "wide"],
        capture_output=True, text=True, timeout=15,
    )
    return out.stdout or out.stderr

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

Note the docstring. That text is not a comment for you. It is the description the model reads to decide whether and how to call the tool. Hold that thought, because it is also the protocol's biggest security liability.

What changes on July 28

The 2026-07-28 revision is the largest since MCP launched, and it is worth reading as an operations document rather than a spec. As of blog published date, the stable revision is 2025-11-25, and the release candidate has been available since May, so implementers have had a validation window.

Four changes matter for a platform team:

1. The protocol core becomes stateless. Sessions were the thing that made MCP awkward to run behind a load balancer, because every request had to return to the instance holding the session. Removing that lets MCP servers scale horizontally on ordinary HTTP infrastructure and survive pod restarts.
2. Application state becomes explicit. A server that needs to remember which repository an agent is analyzing now returns a handle that the client passes back, rather than hiding that state inside the transport. State that is visible is state you can log, scope, and audit.
3. W3C Trace Context propagation is standardized in the _meta field under SEP-414, fixing the traceparent, tracestate, and baggage key names. A trace can now start in your host application, follow a tool call into the server, continue on to whatever that server touches, and arrive in your OpenTelemetry backend as one span tree instead of three disconnected fragments.
4. An extensions framework and a deprecation policy arrive together. Capabilities like Tasks and MCP Apps ship as opt in extensions carrying reverse DNS identifiers, which keeps them out of the core, and every feature now carries a lifecycle label so that anything headed for removal gets a minimum twelve month runway first.

That last point has teeth immediately. Three long standing features, Roots, Sampling, and Logging, are marked deprecated in the release candidate. If your servers depend on them, you have a runway, but you also have a migration on the backlog.

How A2A works

A2A treats the far side as opaque. The remote agent does not expose its tools, its memory, or its reasoning, only a contract for what it can accomplish. That opacity is deliberate, because it is what lets a vendor's agent collaborate with yours without either side surrendering its internals.

Discovery begins with an Agent Card, a JSON manifest published at /.well-known/agent-card.json that advertises identity, skills, endpoints, and authentication requirements:

{
  "protocolVersion": "1.0",
  "name": "incident-diagnostics-agent",
  "description": "Correlates traces, metrics, and recent deploys to explain an alert.",
  "url": "https://diagnostics.internal.example/a2a",
  "preferredTransport": "JSONRPC",
  "skills": [
    {
      "id": "root_cause_analysis",
      "name": "Root cause analysis",
      "description": "Given an alert ID, returns probable cause with evidence.",
      "inputModes": ["text/plain"],
      "outputModes": ["application/json"]
    }
  ],
  "securitySchemes": {
    "oauth2": {
      "type": "oauth2",
      "flows": { "clientCredentials": { "tokenUrl": "https://idp.internal.example/token" } }
    }
  },
  "capabilities": { "streaming": true, "pushNotifications": true }
}

The unit of work is a Task, and it moves through a defined state machine: submitted, working, input required, completed, failed, and canceled. The input required state is the one that has no equivalent in MCP, and it is the whole point. A remote agent can pause mid task and ask a question, which is how long running collaboration works.

Transports are JSON-RPC 2.0 over HTTPS, gRPC, or HTTP and REST, with streaming updates over SSE and webhook push notifications for tasks that outlive a connection. Security schemes mirror OpenAPI, so API keys, OAuth 2.0, OpenID Connect, and mTLS all slot in.

What v1.0 changed

A2A reached v1.0 in early 2026, and the release turned a promising spec into something you can defend in a design review. Signed Agent Cards are the headline. A card now ships with a JSON Web Signature taken over a canonical serialization of its own contents, which lets a receiving agent confirm that the domain claiming to own the card actually issued it. Before this, anyone could publish a card asserting any capability and quietly collect work that was meant for someone else. Strip the signatures out and decentralized discovery has no floor to stand on.

Three more changes matter. Multi tenancy lets one endpoint host many agents, which is how SaaS providers serve a different agent per customer. Multi protocol bindings let the same logical agent answer over both JSON-RPC and gRPC. Version negotiation gives you a supported path from v0.3 to v1.0 instead of a rewrite.

Side by side

Where each fits in a real DevOps stack

Take an incident. An alert fires at 3am for elevated checkout latency.

A triage agent picks it up. To do anything useful it needs to query Prometheus, pull recent traces, list recent deploys from your Git provider, and check pod status. Every one of those is a tool call against a passive system, so every one of them is MCP. The triage agent connects to a Prometheus MCP server, a GitHub MCP server, and a Kubernetes MCP server. There is no negotiation here, only capability.

Now the triage agent decides the latency correlates with a deploy forty minutes earlier, and it wants a second opinion from the diagnostics agent that the observability team owns. That agent runs in a different namespace, was built with a different framework, has its own tools and its own model, and the triage agent has no visibility into any of it. The triage agent reads its Agent Card, verifies the signature, opens a Task, and streams updates while the diagnostics agent works. That is A2A.

The diagnostics agent comes back with a probable cause and evidence. The triage agent then delegates to a remediation agent owned by the platform team, which drafts a rollback PR and waits for a human to approve it. Also A2A. That remediation agent, internally, uses its own MCP servers to open the PR.

Both protocols run in the same incident, at different layers. The triage agent used MCP four times and A2A twice, and it never once needed the two to overlap.

Running both in Kubernetes

Here is where most teams get surprised: your existing API gateway cannot govern this traffic.

Traditional gateways route on headers and paths. They were built for stateless REST, where a request arrives, a backend is chosen, and a response goes out. Agent protocols break that model in a specific way. The name of the tool being called lives inside the request body, not in a header or a path. A conventional proxy sees a POST to a single endpoint and has no idea whether the agent just listed pods or deleted a namespace. It cannot authorize an individual tool call, and it cannot filter a tool listing response to hide a dangerous tool from one caller, because it never parses what it is forwarding.

What agent traffic needs instead is a data plane fluent in the protocols themselves. Two Linux Foundation projects have become the common answer.

agentgateway is an AI native proxy written in Rust that collapses LLM, MCP, A2A, gRPC, and plain HTTP into a single data plane. On Kubernetes it sits on the Gateway API, so Gateway and HTTPRoute behave the way you already expect, with a couple of extra custom resources covering the agent aware pieces. It federates several backend MCP servers behind one endpoint, enforces JWT authentication and RBAC down to the individual tool, and negotiates protocol upgrades so a version bump does not break your clients.

The highest value thing it does is simpler than any of that. It holds the credentials. The agent never gets your LLM provider key or your GitHub token. The agent calls the gateway, and the gateway attaches the real credential on the way out. A compromised agent leaks nothing worth having.

kagent is the Kubernetes native runtime. Agents, sessions, and tool connections become CRDs, which means they deploy through kubectl and GitOps exactly like every other workload, with Argo CD or Flux managing them. It speaks MCP and A2A natively, emits OpenTelemetry traces and Prometheus metrics for every prompt and tool call, and runs on top of Istio so mTLS and policy driven egress apply to agent traffic the way they already apply to your services.

A declarative agent looks like any other manifest:

apiVersion: kagent.dev/v1alpha1
kind: Agent
metadata:
  name: triage-agent
  namespace: sre
spec:
  systemMessage: |
    You triage production alerts. Investigate, do not remediate.
    Never call a write tool. Escalate to a human for any change.
  modelConfig: claude-sonnet
  tools:
    - type: McpServer
      mcpServer:
        name: prometheus-mcp        # read only metrics
        toolNames: ["query_range", "list_alerts"]
    - type: McpServer
      mcpServer:
        name: k8s-mcp
        toolNames: ["get_pod_status", "get_events"]   # no delete, no scale
  a2aConfig:
    skills:
      - id: triage_alert
        description: Investigate an alert and produce a findings artifact.

Two details in that manifest do the real work. The toolNames allowlist means the agent cannot call a tool you did not name, even if the MCP server exposes fifty. The a2aConfig block is what publishes this agent's Agent Card so other agents can find and delegate to it. Same object, both protocols, one review.

Course | KodeKloud

KodeKloud

The threat models are not the same

This is the section that will save you an incident, and it is where the two protocols diverge most sharply.

MCP's dominant risk is tool poisoning. A hostile or compromised server buries an instruction in the description field of a tool, which is prose your model consumes and your team never reads. The model obeys the buried instruction and returns a result that looks entirely normal. Two properties make this worse than a one off injection: the instruction persists across every session, and it arrives already authorized, because a connected tool is generally trusted from the moment you wire it in. Microsoft's incident response and Defender teams warned in late June 2026 that poisoned tool descriptions can drive enterprise agents into leaking data, a technique researchers first demonstrated in April 2025 and now see used against a widening range of production systems. The supporting numbers are not comfortable either. Trend Micro counted 492 internet facing MCP servers running with authentication switched off entirely. BlueRock Security swept more than 7,000 servers and flagged roughly 37% as carrying server side request forgery exposure. Researchers at SentinelOne, Snyk, Trail of Bits, and CyberArk jointly maintain a vulnerability index that now catalogs over fifty MCP flaws, thirteen of them rated critical.

A2A's dominant risk is identity. An agent is only as trustworthy as its Agent Card, and before v1.0 anyone could publish a card claiming any capability. A forged card redirects delegated work to an attacker, or smuggles injected content into the victim agent's context. This is why signed cards are not an optional hardening step but the trust model itself. Verify the signature against the issuer's key before you trust a card, and reject unsigned cards outright in production.

Both protocols share one inheritance. They move untrusted text into a model that can act, which means everything you know about prompt injection applies to both. The controls that work are the boring ones: allowlist tools rather than trusting a server wholesale, pin tool descriptions so a silent change to a description fails a check rather than executing, keep credentials at the gateway, and require human approval for anything irreversible.

How to choose, and what to do this month

The decision is usually simpler than the discourse suggests.

Start with MCP. If you have one agent that needs to reach your systems, you need MCP and you do not need A2A. It is more mature, more widely supported, and it is where the tools live. A single agent with well scoped MCP tools solves a large share of real DevOps use cases, and multi agent designs cost more to run, take longer to answer, and are markedly harder to debug.

Add A2A when you cross a boundary. Reach for it when agents owned by different teams, built on different frameworks, or supplied by different vendors need to delegate work to each other without exposing their internals. If you find yourself building an MCP server whose job is to coordinate other agents, stop. That is A2A's job, and you are about to write technical debt.

For the next two weeks, the concrete work is version readiness. Find every place your MCP servers keep state between tool calls, because the stateless core is a clean break and hidden session dependencies are the thing that will break first. Check whether you use Roots, Sampling, or Logging, since all three are deprecated in the new revision. On the A2A side, if you are still serving cards at the old path or running v0.3, plan the move to v1.0 and turn on signature verification.

Where this is heading

The two specs are converging under shared governance, which is the strongest signal in the ecosystem right now. MCP's 2026 roadmap explicitly names agent communication as a priority area, and A2A is layering extensions like the Agent Payments Protocol onto the same core. Expect the seam between them to get thinner, and expect registries, identity, and trust scoring to be the next battleground, because discovery is where both protocols are still weakest.

What will not change is the shape of the problem. Agents need hands and agents need colleagues, and those are different pieces of infrastructure.

Conclusion

MCP and A2A are not rivals competing for the same slot in your architecture. MCP is how one agent reaches tools and data, A2A is how agents delegate to each other, and a serious production system in 2026 runs both at different layers. Get the layering right and the rest is familiar work: a gateway that speaks the protocol, credentials that never reach the agent, tools scoped by allowlist, cards verified by signature, and traces that follow a request all the way down.

FAQs