$cat mcp-and-a2a-agentic-interfaces.md

MCP and A2A: The Protocols Powering Agentic Interfaces

June 22, 202613 min readby MDflowview as .md

Two glowing emerald wireframe AI agent cores linked horizontally by a bridge of light, each wired down into a cluster of tool and database nodes, on a dark terminal-grid background

Two acronyms now show up in almost every serious conversation about AI agents: MCP and A2A. In barely eighteen months they have gone from internal experiments at Anthropic and Google to open standards backed by the Linux Foundation and adopted by OpenAI, Microsoft, AWS, Google, and hundreds of other companies. If foundation models were the story of 2023 and 2024, the interfaces between agents and the rest of the world are the story now.

They are easy to confuse, and they are constantly pitted against each other as "MCP vs A2A." But they are not rivals. They solve different halves of the same problem, and the most interesting systems use both. Here is what each one actually is, why it matters for developers and AI agents, and where a markdown workspace like MDflow fits.

TL;DR — MCP (Model Context Protocol) connects a single AI agent down to tools, data, and context. A2A (Agent2Agent) connects agents across to one another so they can delegate and collaborate. MCP is the vertical axis, A2A the horizontal one — complementary, not competing. Both are open, both run on JSON-RPC 2.0, and both now sit under neutral governance. MDflow already ships an MCP server and publishes an A2A agent card today.

What are MCP and A2A?

MCP and A2A are two open protocols that standardize how AI agents connect — MCP to their tools, A2A to each other. Picture an agent as a worker: MCP gives it hands (the ability to use tools and read data); A2A gives it a shared language to talk to other workers. You need both to build a team.

MCP — the agent-to-tool protocol

The Model Context Protocol is an open standard introduced by Anthropic on November 25, 2024 to connect AI models to external data and tools. As Anthropic put it, even the best models are "constrained by their isolation from data — trapped behind information silos and legacy systems." MCP replaces a mess of bespoke, one-off integrations with a single protocol — which is why it is often called "USB-C for AI."

It uses a simple client–server design carried over JSON-RPC 2.0:

A host (Claude, ChatGPT, Cursor, Codex) runs one or more MCP clients.
Each client connects to an MCP server that a tool or data source exposes.
A server offers three primitives: tools (functions the agent can call), resources (data it can read), and prompts (reusable templates).

Servers run locally over stdio or remotely over Streamable HTTP. A year in, the pattern has clearly won: the MCP Registry holds close to two thousand servers, and OpenAI, Microsoft (Foundry), Google Cloud (Gemini), GitHub, AWS (Bedrock and AgentCore), Stripe, and Notion have all shipped support. The current spec is dated 2025-11-25, and in December 2025 Anthropic handed MCP to the Agentic AI Foundation, a Linux Foundation fund co-founded with Block and OpenAI — so the standard no longer belongs to any one vendor.

A2A — the agent-to-agent protocol

The Agent2Agent protocol is an open standard Google announced on April 9, 2025 at Google Cloud Next, with 50+ launch partners including Atlassian, Box, Cohere, LangChain, MongoDB, PayPal, Salesforce, SAP, and ServiceNow. It tackles the half MCP does not address: letting agents "built on diverse frameworks by different companies … communicate and collaborate as agents, not just as tools."

A2A also runs on JSON-RPC 2.0 over HTTP(S), with Server-Sent Events for streaming and push notifications for long-running work. Its core concepts:

Agent Card — public JSON metadata, served at /.well-known/agent-card.json, advertising an agent's identity, skills, endpoints, and authentication. This is how agents discover one another.
Task — a unit of work with its own lifecycle, so one agent can hand a job to another and track it to completion.
Message, Part, and Artifact — the turns of a conversation, the chunks of content inside them, and the outputs produced.

An agent card is just a small JSON file. Here is a trimmed version of the one MDflow serves:

{
  "name": "MDflow",
  "url": "https://mdflow.cz/api/mcp",
  "skills": [
    { "id": "context", "name": "Topic-based retrieval" }
  ],
  "securitySchemes": {
    "personalAccessToken": { "type": "http", "scheme": "bearer" }
  }
}

Google donated A2A to the Linux Foundation on June 23, 2025, with AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow as founding members. By its first birthday in April 2026 it had passed 150 organizations, 22,000+ GitHub stars, and a stable v1.0 spec adding signed agent cards for cryptographic identity, enterprise multi-tenancy, and multi-protocol transport.

Side by side

	MCP	A2A
Connects	An agent to tools and data	Agents to each other
Axis	Vertical (agent → tools)	Horizontal (agent ↔ agent)
Created by	Anthropic, Nov 2024	Google, Apr 2025
Discovery	Server lists its tools	Agent Card at `/.well-known/`
Core unit	Tool / resource / prompt	Task / message / artifact
Transport	JSON-RPC 2.0 (stdio, HTTP)	JSON-RPC 2.0 over HTTP, SSE
Governance	Agentic AI Foundation (LF)	Linux Foundation

The telling detail: both landed on the same wire format (JSON-RPC 2.0) and both ended up under Linux Foundation–style neutral governance within a year and a half. The agent stack is standardizing in real time.

Why MCP and A2A are useful

Together they turn agents from clever demos into composable infrastructure. Before these protocols, every agent–tool and agent–agent link was a custom integration that broke whenever either side changed. A shared protocol makes those links portable.

For developers, the win is the end of N×M glue code.

Write once, connect to everything. Expose your service as one MCP server and every MCP-capable agent can use it — no per-client SDKs. Publish one A2A agent card and any A2A client can discover and delegate to your agent.
Mix and match vendors. An agent built with one framework can call a tool server written in another and hand a subtask to an agent from a third company. No lock-in to a single platform's ecosystem.
Standard transport, standard auth. Both protocols are JSON-RPC 2.0 with bearer-token / OAuth-style authentication, so the security and plumbing you already know carry over.
Backed by neutral governance. With both standards under the Linux Foundation umbrella, you are building on infrastructure no single vendor can pull out from under you.

For AI agents, the win is reach and teamwork.

Tools on demand (MCP). An agent can discover a server's tools at runtime and call exactly the one it needs — read a file, query a warehouse, update a document — instead of being limited to what was hard-coded into its prompt.
Specialists on call (A2A). A generalist orchestrator can delegate to specialist agents — a coding agent, a research agent, a billing agent — each with its own tools, and compose their results. That is how multi-agent systems get built.
Discovery is first-class. MCP servers describe their tools; A2A agent cards describe their skills. An agent can walk into an unfamiliar environment and learn what is available rather than being told in advance.
Long-running work is a primitive. A2A tasks and MCP's newer task-based workflows both model jobs that take minutes or hours, with streaming progress — not just instant request/response.

It is worth being precise about the boundary, because "MCP vs A2A" is the wrong framing. MCP is vertical: it connects one agent to the tools and data beneath it. A2A is horizontal: it connects peer agents to one another. A single system uses MCP to give each agent its capabilities and A2A to let those agents cooperate. They stack; they do not compete.

Which applications benefit most

Multi-agent orchestration platforms. Anywhere a "manager" agent farms work out to specialists — A2A for the delegation, MCP so each specialist has real tools.
Enterprise automation across vendors. Supply chain, financial services, insurance, and IT-ops teams (A2A's earliest production verticals) stitch together agents from different software suites that would otherwise never interoperate.
Developer tools and IDEs. Cursor, Claude Code, Codex, and friends already live on MCP servers for file access, search, and execution; A2A lets them hand off to remote build, review, or deployment agents.
Data and analytics assistants. "Talk to your warehouse" copilots use MCP to reach databases and catalogs, then A2A to coordinate with downstream reporting or visualization agents.
Knowledge and content systems. Wikis, docs, and note workspaces become tool servers an agent can read and write through MCP, and discoverable participants through an A2A card — which is exactly where MDflow comes in.

The common thread: any time work spans more than one tool or more than one agent, these protocols replace brittle custom wiring with something portable.

How MDflow fits

We did not set out to chase a protocol checklist. We built MDflow on a simple bet — that knowledge should be portable markdown that people and agents can both read and write — and that bet put us on the right side of both MCP and A2A.

What already lines up today

MDflow is itself an MCP server. This is the most literal fit. MDflow exposes a hosted remote MCP server (Streamable HTTP) at /api/mcp and a local stdio server, so Claude, ChatGPT, Cursor, and Codex can connect and operate your workspace. See the MCP docs.

Real tools, not just file access. The server exposes typed tools to list, read, create, update, move, and delete documents and folders, manage sharing — and mdflow_get_context, which ranks folder descriptions first, then names and titles, and returns the most relevant markdown bodies. That is MCP's tool-and-resource model in production.

Folder descriptions as context. Every folder carries a description that defines the intended context for the documents inside it — and it is the primary ranking signal for agent retrieval. Curated context, not just a filename.

MDflow publishes an A2A agent card. At /.well-known/agent-card.json MDflow serves a standards-compliant agent card (protocol version 0.3.0) describing its skills (documents, folders, context, sharing), interfaces, and bearer-token security scheme. We are deliberately honest in the card itself: it is a discovery beacon, and the live control surface is the MCP server and REST API — not a separate A2A task endpoint. An agent can discover MDflow the A2A way and then control it the MCP way.

An HTTP API and PAT auth. Prefer plain HTTP? The same operations are available through the REST API, authenticated with a Personal Access Token (Bearer mdf_…) — the same standard bearer scheme both protocols assume.

Raw markdown twins and a full discovery surface. Append .md to any shared link to fetch the document as plain markdown with YAML frontmatter and open CORS. MDflow also ships an llms.txt index, a self-contained docs.md agent manual, and an OpenAPI 3.1 spec — discovery, transport, and content in one place. (This post has a raw .md twin too; look for the link at the top.)

Governance you can trust. Agent access runs on revocable Personal Access Tokens with server-side ownership checks, automatic version history on every write (API and MCP included), public and private email sharing, and optional client-side AES-256 encryption.

Where we are headed

The protocols are evolving fast, and so is our thinking. The following is direction, not a dated commitment:

A live A2A surface, not just a beacon. As A2A's v1.0 features mature — signed agent cards, multi-tenancy, push notifications — exposing a real A2A task endpoint would let other agents delegate work to MDflow ("summarize my research folder and share it"), not just discover it.
Streaming and richer capabilities. Turning on streaming and notifications in the agent card as long-running operations land.
Collections as agent-ready bundles. A collections API and a richer remote MCP so an agent can pull a whole curated set of cross-linked documents, not one at a time.
Stronger authorization. Following MCP's new authorization extensions beyond Personal Access Tokens, toward scoped, OAuth-style access for agents.
Verifiable identity. Adopting A2A's signed agent cards so other agents can cryptographically trust who MDflow is.

The bottom line

MCP and A2A are not competing standards to bet between — they are the two axes of the same agent stack. MCP gives an agent its tools and data; A2A lets agents find and work with each other. Both are open, both run on JSON-RPC 2.0, and both now sit under neutral, Linux Foundation–aligned governance. If you are building anything agentic, you will likely speak both.

MDflow already does: it is an MCP server today, it publishes an A2A agent card today, and its whole model — portable markdown that people and agents share — is built for exactly this world. Write in the browser, give your folders meaning, and connect your agents.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

What is the difference between MCP and A2A?

MCP (Model Context Protocol) connects a single AI agent to tools, data, and context — the vertical link between an agent and the things it uses. A2A (Agent2Agent) connects agents to each other so they can discover, delegate, and collaborate — the horizontal link between peers. MCP gives an agent capabilities; A2A lets agents form teams.

Are MCP and A2A competitors?

No. They solve different halves of the agent-interoperability problem and are designed to work together. A typical multi-agent system uses MCP to give each agent its tools and A2A to coordinate the agents. Google explicitly describes A2A as complementary to MCP, and both even share the same JSON-RPC 2.0 wire format.

Who created MCP and A2A, and who governs them now?

Anthropic introduced MCP on November 25, 2024, and donated it to the Agentic AI Foundation, a Linux Foundation fund, in December 2025. Google announced A2A on April 9, 2025, and donated it to the Linux Foundation on June 23, 2025. Both standards are now under neutral, multi-vendor governance rather than owned by a single company.

What is an agent card?

An agent card is A2A's discovery mechanism: a public JSON file, served at /.well-known/agent-card.json, that advertises an agent's identity, skills, endpoints, and authentication so other agents can find and call it. MDflow publishes one at https://mdflow.cz/.well-known/agent-card.json.

Does MDflow support MCP and A2A?

Yes. MDflow runs a full MCP server — hosted remotely over Streamable HTTP at /api/mcp and locally over stdio — so agents can read, create, update, organize, and share markdown documents. It also publishes an A2A agent card at /.well-known/agent-card.json as a discovery beacon that points agents to the MCP server and REST API as the live control surface. Agent control requires a Personal Access Token (MDflow Pro).