API vs MCP vs A2A: The Three Layers of the Modern AI Agent Stack

The Easy Explanation First

Start with an API. It is a fixed contract between two programs — call this exact endpoint, send these exact fields, and you get back an exact, predictable shape. That works beautifully when a human developer wrote the code on both ends. But hand that same job to a language model and a new problem appears: the model has to know precisely which endpoint to call, which fields to send, which credentials to use, and what to do when something breaks. It is like handing a talented new employee a wall of control panels with no labels — intelligence alone does not create an interface, and someone still has to write custom, brittle glue code for every single service the model might need to touch.

MCP (Model Context Protocol) is the fix for that wall of unlabeled panels. Think of it as a USB-C port for AI applications: one standard connector that any tool can plug into, instead of a different custom cable for every device. An MCP server sits in front of a service — Slack, a calendar, an internal database — and hands the model a short, readable menu of actions it can take: "search a channel," "read messages," "send a message." The model does not read API docs or construct a raw request; it picks an item off the menu, and the MCP server handles the authentication, the pagination, and the messy plumbing underneath. Like USB-C, standardizing the connector does not automatically make what is plugged into it safe — that part still has to be checked.

A2A (Agent-to-Agent Protocol) solves a different problem again: not a model calling a tool, but one agent calling another agent. A generalist agent planning a hiring campaign does not know how to score a resume the way a dedicated screening agent does, so it needs a way to find that specialist and hand off the work. Every A2A agent publishes an Agent Card — a short, structured profile listing what it claims to do, what formats it accepts, and how to reach it. Think of it as a service card, not a verified résumé: it tells a calling agent what to expect, but trusting it is a separate decision the system still has to make.

Now, Technically: What Each One Actually Standardizes

API — the foundation everything else sits on

An API is a contract between two pieces of software: a fixed set of endpoints, request formats, and response shapes, documented for a human developer to read and code against. GET /users/123 returns a predictable JSON payload, and the developer who wrote the calling code decides what to do with it, handles authentication, retries, and error cases explicitly. Nothing about an API is dynamic from the caller's point of view — you write code once, against docs, and it either matches the contract or it does not.

This assumption — a human developer reads documentation and writes matching code — is exactly what breaks when the caller is a language model instead of a person. A model has no persistent code, cannot store a secret safely, and cannot be trusted to construct a raw HTTP request correctly and safely every time. APIs are not going away — MCP and A2A are both built on top of them, not instead of them — but a model calling a raw API directly is a security and reliability problem, not a solved one.

MCP — the tool-access layer for AI agents

MCP, introduced by Anthropic in late 2024, standardizes how an AI application connects to external tools, data sources, and workflows. It follows a client–server model: an MCP client (the agent runtime) connects to an MCP server, which exposes a set of tools with typed, self-describing schemas. The model asks "what tools do you have?", receives a structured list back, and calls one by name with typed parameters — it never sees a URL, a header, or an API key.

from mcp.server.fastmcp import FastMCP
import requests

mcp = FastMCP(name="hr-tools")

@mcp.tool()
def get_employee(employee_id: str):
    """Fetch an employee record from the HRIS"""
    url = f"https://api.internal-hr.com/employees/{employee_id}"
    return requests.get(url, headers=AUTH_HEADERS).json()

mcp.run()

The model never holds AUTH_HEADERS. It just says "call get_employee with employee_id=E4471" and the server does the rest — validating input, applying rate limits, logging the call, and returning only the data the model is allowed to see. This is the core insight: MCP separates reasoning from execution. The model decides what to do; the MCP server decides how it is safely done. That separation is what makes a single tool integration reusable across GPT, Claude, Gemini, or any other MCP-compatible model without rewriting it for each one.

What MCP deliberately does not standardize: human-approval workflows, multi-tenant isolation policy, or delegation between agents. It operates at one layer only — tool discovery and invocation.

A2A — the agent-coordination layer

A2A, introduced by Google and now under the Linux Foundation, standardizes something MCP does not touch at all: how one autonomous agent discovers, talks to, and delegates work to another autonomous agent — often built by a different team, on a different framework, sometimes in a different organization entirely.

Every agent publishes an Agent Card — a structured declaration of what it can do. Other agents read that card, construct a Task, hand it over, and track it through a defined lifecycle (created → in progress → completed, with structured artifacts as the output) rather than a single request/response.

{
  "name": "candidate-screening-agent",
  "description": "Screens resumes and ranks candidates",
  "capabilities": [
    {
      "action": "rank_candidates",
      "input_schema": {
        "job_description": "string",
        "candidate_profiles": "array"
      }
    }
  ]
}

A planning agent reads this card, decides the screening agent is the right specialist for the job, and sends it a task rather than trying to rank resumes itself. That is the fundamental shift: MCP connects an agent to systems; A2A connects an agent to other agents.

Side-by-Side: What Each Layer Owns

None of this makes API "obsolete" — MCP servers and A2A agents both eventually bottom out in an API call to a real system. The layering is additive: API moves data between systems, MCP lets a model safely decide which API to call, and A2A lets one agent delegate an entire piece of reasoning — including its own MCP tool calls — to a specialist agent better suited for it.

How Industry Is Actually Using MCP and A2A

This is not a future-tense technology. Enterprise teams are deploying both protocols today, and the pattern that keeps showing up is: MCP for reaching into systems, A2A for splitting work across specialists.

The consistent lesson across every one of these: teams that start with a single monolithic "do everything" agent hit a wall in complexity fairly fast. The ones that scale cleanly separate system access (MCP) from task delegation (A2A) early, so each layer can be secured, monitored, and scaled on its own terms.

The Shared Security Risk: Neither Was Built for Adversarial Input

This is where "technically strong" actually matters, and it is the part most explainer content skips. Neither MCP nor A2A was designed with adversarial input as a first-class concern, and OWASP ranks indirect prompt injection as the #1 risk for LLM applications. The attack surface differs between the two protocols, but the underlying vulnerability does not.

In MCP, the attack is static: a poisoned tool response contains hidden instructions that persist in the agent's context once delivered. A hidden display:none block in an email returned by a Gmail MCP tool can instruct the agent to forward sensitive data before a human ever sees the message. In A2A, the attack is stateful — multi-turn agent sessions give an attacker room to manipulate context gradually across a delegated task, a pattern security researchers call session smuggling.

Decision Framework: Which One Do You Actually Need?

Key Takeaways

The question was never "which one wins." APIs, MCP, and A2A sit at three different altitudes of the same stack — data movement, tool access, and agent coordination. The systems that hold up in production are the ones that keep those three concerns cleanly separated instead of collapsing them into one oversized agent that tries to do everything itself.