Agent Communication Protocols (MCP and A2A)

"I learned to speak forty bespoke integration dialects, one per tool. Then someone handed me a single protocol, and forty of my forty translators quietly retired."

An Agent That Finally Got a Standard Port

In Section 29.4 we met the agent communication languages of classical multi-agent systems, KQML and FIPA-ACL, which defined a shared vocabulary of speech acts (inform, request, propose) so that agents built by different groups could in principle understand each other. Those standards were ahead of the systems that needed them; an open marketplace of interoperable agents did not yet exist, so the protocols mostly stayed on paper. The arrival of capable LLM agents changed the economics overnight. Suddenly there are thousands of useful tools (databases, search, code execution, internal company APIs) and a growing population of agents that want to call them, plus agents from different vendors that need to delegate work to one another. The communication-language idea has returned, this time with an ecosystem hungry for it, and it has returned as a concrete wire protocol rather than a vocabulary specification.

This is a distributed-systems story end to end. Connecting an agent to a tool on another process or another machine is remote procedure call. Letting an agent find which other agent can perform a task is service discovery. Doing this across vendors and frameworks raises interoperability, versioning, and authentication, the same questions HTTP, gRPC, and DNS answer for ordinary services. Treating each tool and each agent as a networked service with a published capability description, then standardizing how you list and invoke those capabilities, is precisely what lets the ecosystem grow without every integration being a special case.

1. The Integration Wall, and Why a Protocol Is the Way Through Beginner

Before a standard exists, every connection is bespoke. To let an agent query your database you write a database adapter shaped to that one agent's tool-calling format; to let a second agent framework use the same database you write it again, differently. The cost is multiplicative. With $n$ agent frameworks and $m$ tools, the naive world needs on the order of $n \times m$ integrations, each separately built, tested, and maintained. Add a tool and you owe $n$ new connectors; add a framework and you owe $m$. This is the same $O(nm)$ wall that point-to-point integration always hits, and it is why the industry kept rebuilding the same connectors with subtle incompatibilities.

A protocol collapses the product into a sum. If every tool exposes itself through one standard server interface, and every agent speaks one standard client interface, then a tool needs a single implementation to reach all agents, and an agent needs a single implementation to reach all tools. The integration count drops from $n \times m$ to $n + m$. This is exactly what HTTP did for documents and services: a web server does not implement a separate protocol per browser, it implements HTTP once. The popular framing for the Model Context Protocol captures the idea: it is "USB-C for tools", one physical standard that any compliant device can plug into, replacing a drawer full of proprietary cables.

2. The Model Context Protocol: A Standard Port for Tools and Context Beginner

The Model Context Protocol (MCP), introduced by Anthropic in late 2024 and rapidly adopted across the industry, is an open standard for connecting an LLM or agent to tools, data sources, and context. It is a client-server protocol. The architecture has three roles. The host is the application the user interacts with (a chat client, an IDE, an agent runtime); it embeds one or more clients, and each client maintains a one-to-one connection to a server. A server is a small program that exposes some capability: a filesystem server, a database server, a search server, an internal-API server. Crucially the server is written once by whoever owns the tool, and any MCP-compliant host can use it without custom glue.

Servers advertise three kinds of capability. Tools are functions the model can invoke (run a query, send an email), each described by a name and an input schema so the agent knows how to call it. Resources are readable data the host can pull into context (a file, a record, a document). Prompts are reusable templated interactions the server offers. The interaction is a structured request-and-response over a transport: typically standard input/output for a local server running as a subprocess, or HTTP with server-sent events for a remote one. The messages themselves follow JSON-RPC, so MCP is, quite literally, remote procedure call with a capability-discovery handshake bolted to the front. The agent first asks "what can you do?" (a tools/list request), receives schemas, and then issues typed calls (tools/call). This discovery-then-invoke pattern is the heart of the protocol and the thing our demo in Section 5 reproduces from scratch.

3. Agent-to-Agent Protocols: Each Agent a Networked Service Intermediate

MCP connects an agent to its tools. The complementary problem is connecting agents to each other across vendor and framework boundaries: an agent built on one stack needs to discover, authenticate, and delegate to an agent built on another. The Agent2Agent protocol (A2A), announced by Google in 2025 and later contributed to the Linux Foundation, standardizes exactly this. Its central object is the agent card, a machine-readable description (conventionally served as JSON at a well-known URL) that states who the agent is, what skills it offers, what endpoint to reach it at, and how to authenticate. The card is the service-discovery record for an agent, the analogue of a DNS entry plus an API schema, and it is what turns "find me an agent that can translate" into a lookup rather than a hard-coded address.

With cards in hand, the protocol defines how one agent sends a task to another and streams back results, treating the remote agent as a long-running networked service rather than a single function call. This is the modern, ecosystem-scale descendant of the contract-net protocol from Section 27.5: announce a task, find a capable contractor by its advertised abilities, delegate, and collect the result. Contract-net assumed agents that already knew how to speak to each other; A2A supplies the missing standard wire format and discovery layer, so the contractors no longer have to be built by the same team. The two protocols compose cleanly: an agent uses MCP to reach its private tools and A2A to reach its peer agents, and a peer it delegates to may itself fan out over MCP to tools the first agent never sees.

4. Versioning, Authentication, and the New Attack Surface Intermediate

Because these are real distributed protocols, they inherit the distributed concerns. Versioning: every message in the demo below carries a protocol identifier, and a client must refuse or downgrade gracefully when a server speaks a version it does not understand, exactly as HTTP and gRPC negotiate versions. A capability schema is a contract, and contracts evolve, so backward compatibility (additive changes, deprecation windows) is a first-class design problem rather than an afterthought. Authentication and authorization: a tool server may expose a company's database and an agent card may front a billable service, so both protocols define how the caller proves identity and how the callee scopes what that caller may do. An open ecosystem without authentication is an open ecosystem of anyone calling anything.

Most important, a tool-and-agent protocol is an attack surface, and a large one. The data a tool returns flows straight into the agent's context, which means a malicious or compromised server can attempt prompt injection: hiding instructions inside a tool result that hijack the agent into exfiltrating data or calling other tools destructively. A malicious agent card can advertise a skill it does not safely provide. The defenses are the ordinary ones of untrusted distributed systems, applied to a new layer: authenticate servers and agents, sandbox tool execution, constrain what a tool result is allowed to trigger, and treat every external response as untrusted input rather than trusted instruction. We name these threats now and develop the guardrails and isolation machinery in the MLOps security section Section 26.9 and, in full, in the reliable-and-secure infrastructure chapter Chapter 35.

5. From Scratch: A Tiny MCP and A2A in One File Intermediate

Nothing about these protocols requires a framework to understand. The demo below implements both in pure Python with no dependencies. The MCP half defines a single message envelope carrying a protocol version, a server that answers tools/list (discovery) and tools/call (invocation), and a generic client that speaks only the envelope, never the servers. We then build two completely independent servers (a weather service and a calculator) and show the one client discovering and calling both with no server-specific code. The A2A half gives each agent a capability card, registers the agents, and lets an orchestrator discover a capable agent by skill and send it a task. The point is interoperability between independently built components that share only the protocol.

import json, uuid

# ---------- A shared, versioned message envelope (the "protocol") ----------
PROTOCOL = "demo-mcp/0.1"

def envelope(method, params):
    return {"protocol": PROTOCOL, "id": str(uuid.uuid4())[:8],
            "method": method, "params": params}

# ===================== MCP-style tool server =====================
class MCPServer:
    """A server that advertises tool capabilities and executes calls."""
    def __init__(self, name):
        self.name = name
        self._tools = {}

    def tool(self, name, schema, fn):
        self._tools[name] = {"schema": schema, "fn": fn}

    def handle(self, msg):
        if msg["protocol"] != PROTOCOL:
            return {"error": "protocol mismatch"}          # version negotiation
        m = msg["method"]
        if m == "tools/list":                              # capability discovery
            return {"tools": [{"name": n, "schema": t["schema"]}
                              for n, t in self._tools.items()]}
        if m == "tools/call":                              # standardized invocation
            t = self._tools.get(msg["params"]["name"])
            if t is None:
                return {"error": "unknown tool"}
            return {"result": t["fn"](**msg["params"]["arguments"])}
        return {"error": "unknown method"}

# two independently built servers, sharing only the envelope above
weather = MCPServer("weather-co")
weather.tool("get_temp", {"city": "string"},
             lambda city: {"city": city, "celsius": 21 if city == "Oslo" else 30})
mathsrv = MCPServer("calc-inc")
mathsrv.tool("add", {"a": "number", "b": "number"},
             lambda a, b: {"sum": a + b})

class MCPClient:                                            # speaks only the protocol
    def discover(self, server):
        reply = server.handle(envelope("tools/list", {}))
        return [t["name"] for t in reply["tools"]]
    def call(self, server, tool, **args):
        reply = server.handle(envelope("tools/call",
                                       {"name": tool, "arguments": args}))
        return reply["result"]

client = MCPClient()
print("== MCP: one client, any compliant server ==")
for srv in (weather, mathsrv):
    print(f"  discovered on {srv.name:11s}: {client.discover(srv)}")
print("  call weather.get_temp(Oslo):", client.call(weather, "get_temp", city="Oslo"))
print("  call calc.add(2,40)        :", client.call(mathsrv, "add", a=2, b=40))

# ===================== A2A-style agent cards =====================
class Agent:
    """A networked agent that publishes a capability card and answers tasks."""
    def __init__(self, name, skills, handler):
        self.card = {"protocol": PROTOCOL, "name": name,
                     "url": f"a2a://{name}", "skills": skills}
        self._handler = handler
    def get_card(self):                                    # service discovery
        return self.card
    def send_task(self, task):                             # standardized exchange
        if task["protocol"] != PROTOCOL:
            return {"error": "protocol mismatch"}
        return {"from": self.card["name"], "result": self._handler(task["text"])}

translator = Agent("translator-bot", ["translate"], lambda t: f"[fr] {t}")
summarizer = Agent("summarizer-bot", ["summarize"],
                   lambda t: t.split(".")[0] + " (summary)")

class Orchestrator:
    """Discovers agents by card, then routes a task to a matching skill."""
    def __init__(self, registry):
        self.registry = registry
    def find(self, skill):
        return [a for a in self.registry.values()
                if skill in a.get_card()["skills"]]
    def delegate(self, skill, text):
        matches = self.find(skill)
        if not matches:
            return {"error": f"no agent advertises '{skill}'"}
        task = {"protocol": PROTOCOL, "skill": skill, "text": text}
        return matches[0].send_task(task)                  # contract-net delegation

registry = {a.card["name"]: a for a in (translator, summarizer)}
orch = Orchestrator(registry)
print("\n== A2A: discover by capability card, then message ==")
for name, a in registry.items():
    print(f"  card {name:15s} skills={a.get_card()['skills']}")
print("  delegate 'translate':", orch.delegate("translate", "scale out"))
print("  delegate 'summarize':", orch.delegate("summarize",
                                                "Agents talk. They use protocols."))
print("  delegate 'paint'    :", orch.delegate("paint", "anything"))

== MCP: one client, any compliant server ==
  discovered on weather-co : ['get_temp']
  discovered on calc-inc   : ['add']
  call weather.get_temp(Oslo): {'city': 'Oslo', 'celsius': 21}
  call calc.add(2,40)        : {'sum': 42}

== A2A: discover by capability card, then message ==
  card translator-bot  skills=['translate']
  card summarizer-bot  skills=['summarize']
  delegate 'translate': {'from': 'translator-bot', 'result': '[fr] scale out'}
  delegate 'summarize': {'from': 'summarizer-bot', 'result': 'Agents talk (summary)'}
  delegate 'paint'    : {'error': "no agent advertises 'paint'"}

The whole demo is a few dozen lines and yet it exhibits every property that matters: discovery before invocation, a versioned envelope that rejects mismatches, capability-based routing, and graceful failure when no provider exists. Real MCP and A2A add JSON-RPC framing, streaming, transports over stdio and HTTP, and authentication, but the skeleton you see is the skeleton they ship. The reference to Output 32.6.1 makes the contrast concrete: the calculator and weather servers share nothing but the envelope, and the client never imported either of them.

# pip install "mcp[cli]"
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-co")          # names the server; SDK builds the JSON-RPC layer

@mcp.tool()                          # registers the tool AND publishes its schema
def get_temp(city: str) -> dict:
    """Return the current temperature for a city."""
    return {"city": city, "celsius": 21 if city == "Oslo" else 30}

if __name__ == "__main__":
    mcp.run()                        # serves tools/list and tools/call over a transport

6. Why Protocols Are What Make Multi-Agent Ecosystems Scale Intermediate

Everything in this chapter so far (planners, critics, parallel workflows) lived inside one builder's system, where you control every component and can wire them however you like. The leap to an open ecosystem, where a tool you did not write and an agent another company deployed must interoperate with yours, is the leap that bespoke integration cannot make. It is the difference between a private network and the internet. Standard protocols are what turned a handful of incompatible networks into one web, and they are the same lever for agents: only when any compliant agent can use any compliant tool, and discover and message any compliant peer, does the population of agents and tools start to compound instead of fragmenting into walled gardens.

The reason is the network effect a protocol creates. Each new MCP server is instantly usable by every existing host; each new A2A agent is instantly discoverable by every orchestrator. Value grows superlinearly in the number of participants precisely because no participant needs custom work to reach the others. That is why the standardization of 2024 to 2026 matters beyond any single tool: it is the substrate on which a genuinely distributed, multi-vendor agent ecosystem can be built, with the next section's shared state and distributed memory as the layer agents coordinate over once they can talk at all.