Two different pipes

For an “agentic web” to exist, an AI agent has to do two outward things: plug into tools and find other agents to collaborate with. Two protocols each own one pipe:

  • MCP (Model Context Protocol, Anthropic, 2024) handles “agent↔tool/data” — letting an AI agent plug into external tools, data sources, and services. It’s vertical: bringing outside capability into the agent.
  • A2A (Agent2Agent, Google, 2025) handles “agent↔agent” — letting agents from different sources and vendors discover, call, and divide work between each other. It’s horizontal: wiring agents into a network.

One brings the world into the agent; one wires agents into a web. Confuse the two and everything downstream goes wrong.

How MCP works

MCP uses a host–client–server architecture: the AI app you use is the host, it embeds a client, and that connects to individual MCP servers; each server exposes a set of capabilities in a standardized way. A server offers three primitives:

  • Tools: actions an agent can invoke (check stock, place an order, run a query).
  • Resources: data that can be read (files, records, structured content).
  • Prompts: pre-written interaction templates.

Underneath it’s JSON-RPC messaging over a swappable transport (local stdio, remote HTTP streaming). The point is standardization: integrating each tool used to be bespoke; after MCP, any agent speaks to any MCP server the same way. For you, exposing your site/service as an MCP server means turning your capabilities into a tool an agent can call directly — the same outlet as NLWeb’s “every instance is also an MCP server.”

How A2A works

A2A handles “how two independent agents recognize each other and hand off tasks.” Core pieces:

  • Agent Card: a capability “business card” an agent publishes — who I am, what I can do, how to call me, how to authenticate. This is the discovery entry point.
  • Task lifecycle: agents interact in units of “tasks,” supporting async, long-running execution with progress updates along the way — because cross-agent collaboration rarely ends in a single round-trip.
  • Capability negotiation: the caller reads the other’s Agent Card, confirms whether and how it can do the job, then delegates.

Put plainly: MCP makes “one agent + a bunch of tools” work; A2A lets “one agent find another agent and farm the work out.”

Why they’re complementary, not rivals

A common misread treats MCP and A2A as competitors. In fact a single agent can be both an MCP client (reaching down to tools) and an A2A peer (reaching sideways to collaborate). A travel agent might use MCP to plug into a booking tool while using A2A to hand the whole “visa question” to a specialized visa agent. Stack the two pipes and you get the agentic web: agents that can call on the world and divide work among themselves. Both are now under neutral governance at the Linux Foundation — a sign they’re positioned as infrastructure, not any one vendor’s proprietary protocol.

Why people tie it to GEO

Because “your site being used directly by agents” is the extended dream of GEO: not just being cited, but having your service called as a tool and slotted into an agent’s workflow. The MCP server and the A2A Agent Card are the interfaces for that direction — and the next step that “agent discovery” standards like DNS-AID aim to solve: letting agents find “your endpoint that can get things done” out in the open web.

In other words, GEO’s endgame may not just be “getting into AI answers” but “getting into AI’s workflow.” MCP/A2A are the substrate for the latter.

Honest: for a pure content site, it’s still one layer away

This is the caveat that matters most. MCP is relatively mature and widely adopted; A2A is still early (pre-1.0, spec and ecosystem in flux). But the more important point is who it’s for:

These protocols serve the “you have a tool/service for agents to use” scenario — e-commerce, booking, queries, transactions, functions that can be called automatically. For “content being cited by AI,” they’re still one layer away: an article isn’t a “tool,” and an agent won’t “call” an opinion piece. Treating MCP/A2A as a synonym for “being cited” is the most common confusion in this space.

What it means for you

Two kinds of sites:

  • Pure content / informational sites: know it exists, know the direction — but don’t wire it up yourself. Your priority is the site health that gets content cited (structured data, entity consistency, E-E-A-T), not packaging yourself as an MCP server — you have no “tool” to be called. Just don’t read “no need to act today” as “there’s plenty of time”: the July 2026 specification revision paved this road toward production scale, and the timeline is compressing (see MCP’s biggest rewrite yet).
  • Brands with a service or tool: this is the future interface for “being called by agents,” worth watching. But answer a prerequisite first: is your service even suited to being tool-ified, and is it worth it? A function an agent can auto-order from is a very different thing from a static info page. Nail the value and safety boundary of the service itself before picking which pipe to wire.

Direction matters; that doesn’t mean act now. For the vast majority of clients, “getting content health right” always ranks ahead of “wiring up agent protocols” — the latter is a next step for the few with a tool-ifiable service, evaluated by a specialist when the timing is right.