MCP & A2A: The Protocols That Connect Agents

There’s a specific moment in every agent project where someone suggests splitting the work across three or four coordinating agents because it “sounds more sophisticated.” Nine times out of ten, that’s the wrong call, made for the wrong reason, and this lesson is exactly why.

An agent is only as capable as the tools it can reach, and the other agents it can genuinely collaborate with. That connectivity in 2026 runs on two open standards — MCP and A2A — and understanding the real difference between them is what separates “I built one agent” from “I designed an ecosystem that doesn’t collapse under its own coordination overhead.”

MCP: how an agent reaches tools

MCP — Model Context Protocol — is an open standard for exposing tools and context to a model in one uniform way. Instead of hand-wiring a bespoke integration for every single capability, you run an MCP server that advertises a set of tools — each with the name, description, and JSON schema you learned to write in Lesson 7 — and any MCP-aware agent can discover and call them.

Why this matters in practical terms: build a tool once behind an MCP server, and every agent that needs it going forward reuses it, instead of every team reinventing the same integration from scratch.

Get this exactly right, because it’s a common point of confusion: MCP is open, and it is not SAP-proprietary. SAP adopts the protocol; it didn’t invent it. Inside SAP’s world, MCP is what gives Joule agents access to SAP business capabilities and the Knowledge Graph, and inside Joule Studio, external MCP servers connect via BTP destinations.

A2A: how an agent reaches other agents

A2A — Agent-to-Agent — is an open protocol for agents to collaborate: one agent delegating a sub-task to another, with a defined hand-off and a clear result contract. Like MCP, A2A is open and not SAP-invented — it originated at Google and has since seen broad adoption across the industry.

SAP’s own stance here is a genuinely useful design lesson, not just a fact to memorise: for external, vendor-to-vendor interoperability, SAP prefers A2A over directly exposing MCP servers, because agent-to-agent delegation carries identity, trust, and governance far better than simply handing an outside party raw tool access. Bidirectional A2A, announced around Sapphire 2026, is what lets third-party agents securely call Joule agents — and the reverse, Joule agents calling out to third-party agents, just as securely.

The whole distinction collapses into one sentence worth memorising: MCP connects an agent to tools. A2A connects an agent to other agents.

The multi-agent trap, and why “start single” is the correct default

Now that agents can collaborate, you face an architecture choice. Single agent, many tools — one agent with a well-stocked toolbox via MCP — is simplest, and it’s the right call whenever one coherent goal needs several capabilities under one roof. Multi-agent, an orchestrator delegating to specialist agents via A2A, only earns its complexity when sub-tasks are genuinely distinct, owned by different teams or vendors, or need real isolation from each other.

Here’s the trap, stated plainly: don’t reach for multi-agent because it sounds more advanced in a proposal. More agents means more coordination, more failure points, and more cost, every single time — with no guarantee of more capability. Add a second agent only when a real boundary — ownership, domain, trust — actually justifies paying that coordination tax. A clean single agent beats a sprawling, impressive-sounding swarm almost every time it’s actually measured.

Where this shows up in SAP — hands-on

Our Business Partner MCP tutorial builds a real MCP server exposing CRUD tools to a Joule Studio agent — the concrete, running version of everything in this lesson. The next lesson walks the full build path.

Try it yourself

1. MCP manifest sketch: define an MCP server called sales-tools, exposing two tools — reuse get_sales_order_status from Lesson 7, and add a new create_quote. Write each tool’s name, description, and parameter schema.
2. A2A scenario: sketch a two-agent flow — a Readiness agent that, on finding an issue, delegates to a Remediation agent. Define exactly what gets passed in the hand-off, and what “done” means back to the caller.

You’ve just designed both halves of a genuine agent ecosystem: tools, through MCP, and collaboration, through A2A — and you did it on paper, before writing a single line of code that would’ve been expensive to redesign later.

Key takeaways

• MCP is the open standard for exposing tools to agents — a server advertises name, description, and schema; any MCP-aware agent can use it.
• A2A is the open standard for agents to collaborate — a defined hand-off and result contract between them.
• Both protocols are open, not SAP-invented. SAP uses MCP inward, for business capabilities, and prefers A2A for external, vendor-to-vendor interop.
• Start with a single agent. Add a second only when a real ownership, domain, or trust boundary justifies the coordination cost — never because it sounds more impressive.

Next: enough theory. It’s time to build your first real SAP AI agent.