MCP & A2A: Interop Protocols

Here's the headache in plain terms: every AI app you build has to be taught, by hand, how to talk to every outside system it needs. Teach Claude Desktop how to reach GitHub. Teach Cursor how to reach GitHub. Teach your support agent how to reach GitHub. Same system, three separate integrations — and that's just one of many systems. Nobody owns the connection in common, so everyone rewrites it.

Stated precisely: with M AI applications (Claude Desktop, a Cursor IDE, your custom support agent) and N systems they need to reach (GitHub, Postgres, Google Drive, your internal ticketing API), and no standard, you need a hand-written connector for every pair — that's M × N integrations, each maintained separately, each breaking independently.

This is the same mess that plagued hardware before USB, and IDEs before the Language Server Protocol (LSP). The fix is identical in shape: define one protocol that both sides speak. Now each application implements the protocol once, and each system exposes it once. The integration count collapses from M × N to M + N.

The Model Context Protocol (MCP), announced by Anthropic in November 2024, is exactly this for AI-to-tool connections. Anthropic deliberately modeled it on LSP — both even use the same JSON-RPC plumbing. The payoff is an ecosystem: build one MCP server for your API, and every MCP-compatible client (Claude, ChatGPT, VS Code, Cursor, Gemini, Copilot) can use it with no extra work. That network effect is why MCP went from one company's release to an industry standard in roughly a year.

Think of it like a phone system. The host is your phone (the app you actually use). For each person you want to reach, the phone opens a dedicated call (a client). And on the other end, each server is a person who can do something for you. One phone, many simultaneous calls, each to a different party.

Precisely, MCP uses a client-server architecture with three distinct roles — and confusing them is the most common beginner mistake:

• Host — the AI application itself (Claude Desktop, VS Code, your agent). It holds the model and decides what to connect to.
• Client — a connector inside the host. The host spins up one client per server, each managing a single dedicated connection. One host, many clients.
• Server — a separate program that exposes capabilities. It connects to the actual system (a database, an API) and speaks MCP on the other side.

All three communicate over JSON-RPC 2.0 — structured request/response messages, the same wire format LSP and A2A use. A connection begins with an initialize handshake where both sides exchange capabilities and protocol version (the current spec is 2025-11-25).

Host (Claude Desktop)
├── Client A ──► MCP Server: GitHub  ──► GitHub API
├── Client B ──► MCP Server: Postgres ──► your database
└── Client C ──► MCP Server: Files   ──► local filesystem

This separation is the source of MCP's power: servers are independent processes you can write, deploy, and secure on their own, swappable behind a stable interface.

A server can offer the model three kinds of things, and the easiest way to keep them straight is by what the model does with each: one it runs, one it reads, and one it reuses.

Formally, an MCP server exposes capability through exactly three primitives:

1. Tools — executable functions the model can call: run a query, send an email, create a GitHub issue. These are model-controlled actions, the same idea as function calling, but discovered dynamically from the server.
2. Resources — read-only contextual data the model can load: a file's contents, a database schema, a document. Think of these as nouns the app pulls in, not actions.
3. Prompts — reusable prompt templates or few-shot examples the server offers, often surfaced as user-invokable commands (e.g. a /summarize-pr slash command).

A minimal server in Python's official SDK shows how little code this takes:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Return today's forecast for a city."""
    return fetch_weather(city)  # your real API call

@mcp.resource("config://units")
def units() -> str:
    """Read-only context: which unit system to use."""
    return "metric"

if __name__ == "__main__":
    mcp.run()  # speaks MCP over stdio by default

The decorators register each primitive; the SDK handles the JSON-RPC entirely.

Once a server decides what to offer, there's the question of how the bytes actually travel between client and server. MCP gives you two options, and the choice is basically "is the server on my machine, or across the internet?"

• Stdio — the server runs as a local subprocess; the host talks to it over standard input/output. Zero network overhead, no auth needed, perfect for local tools like a filesystem or a git server.
• Streamable HTTP — the server is a remote service reached over HTTP POST, with optional Server-Sent Events (SSE) for streaming responses back. This is how you connect to a SaaS-hosted server across the internet.

The important detail for builders and decision-makers: remote servers need real authentication. The current spec (2025-11-25) mandates OAuth 2.1 with PKCE for HTTP transports, so a remote MCP server integrates with standard identity providers rather than passing around static API keys. (This matured over time — the original 2024 release was stdio-first; robust remote auth arrived through the 2025-03-26 and 2025-11-25 spec revisions.)

Rule of thumb: stdio for local, Streamable HTTP for remote. Local stdio servers are simpler and inherit your machine's trust boundary; remote HTTP servers are shareable but demand the same security hygiene as any internet-facing API.

MCP wires an agent down to its tools. But agents increasingly need to talk sideways — to other agents. Imagine your agent needs a flight booked, and a totally separate flights agent (different team, different framework, different company) already does that well. How does your agent find it, trust it, and hand off the job? That peer-to-peer problem is outside MCP's scope, and it's exactly what the Agent2Agent (A2A) protocol solves.

A2A was announced by Google at Cloud Next on April 9, 2025, then donated to the Linux Foundation on June 23, 2025 to make it vendor-neutral. It has three core abstractions:

• Agent Card — a JSON file published at a well-known URL (/.well-known/agent.json) advertising an agent's name, skills, endpoint, and auth requirements. It's how one agent discovers what another can do.
• Task — the unit of delegated work, with an explicit lifecycle: submitted → working → input-required → completed/failed. This lets long-running, multi-turn delegation be tracked reliably.
• Transport — HTTP + SSE carrying JSON-RPC 2.0, the same wire format as MCP, so the two protocols share compatible plumbing.

Think of an Agent Card as a business card and an API spec fused together. A client agent reads it, decides this peer can help, and submits a Task — then polls or streams until the work finishes.

People often assume MCP and A2A compete and you must pick one. You don't. The simplest way to see it: MCP points down (an agent reaching its own tools) and A2A points sideways (agents reaching each other as peers). Different directions, so a serious system uses both.

• MCP is vertical: agent → tools. It's how a single agent reaches databases, APIs, and files.
• A2A is horizontal: agent ↔ agent. It's how independent agents discover and delegate to each other as peers.

Picture a travel-planning system. A top-level orchestrator agent uses A2A to delegate to a flights agent, a hotels agent, and a visa agent — each possibly owned by a different vendor. Internally, each of those agents uses MCP to reach its own tools: the flights agent calls an airline API via an MCP server; the hotels agent queries an inventory database via another.

Orchestrator ──A2A──► Flights Agent ──MCP──► Airline API
             ──A2A──► Hotels Agent  ──MCP──► Inventory DB
             ──A2A──► Visa Agent    ──MCP──► Gov Portal

Both protocols now live under the Linux Foundation umbrella — A2A was donated in June 2025, and MCP became an anchor project of the Agentic AI Foundation (AAIF) in December 2025. They share JSON-RPC plumbing by design and were built to interlock, not overlap.

First the good news: adoption has been fast, and these are now everyday infrastructure, not experiments. By early 2026 MCP saw ~97 million monthly SDK downloads and 10,000+ public servers, with first-class support in Claude, ChatGPT Desktop, VS Code, Cursor, Gemini, and Copilot (OpenAI adopted it in March 2025). A2A passed 150+ supporting organizations — AWS, Microsoft, Salesforce, SAP, ServiceNow, IBM — and is built into Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud. Both protocols now sit under the Linux Foundation: A2A as its own project (since June 2025) and MCP as an anchor project of the Agentic AI Foundation (AAIF), which was formed in December 2025 with Anthropic, OpenAI, Google, Microsoft, AWS, Block, and others as co-founders.

Now the catch, and it's a big one. Every server you plug in is code you didn't write that can feed instructions straight into your model — in other words, every MCP server you connect is new attack surface. A 2025 survey of 1,800+ servers found 30%+ had at least one exploitable vulnerability. The risks specific to this design:

• Tool poisoning — malicious instructions hidden in a tool's description, which the model reads as trusted text and obeys.
• Rug pull — an approved tool silently updates to malicious behavior; most clients never re-prompt for consent.
• Prompt injection via tool output — attacker-controlled data returned by a tool carries instructions back into the agent's context.

Real incidents bear this out: a Postmark MCP server silently BCC-exfiltrated emails (Sept 2025); a Smithery path-traversal flaw exposed API keys across 3,000+ deployments (Oct 2025).