MCP or A2A: which protocol, and why

Two protocols come up constantly and get blurred together in conversation. The
distinction is genuinely simple once stated, and the exam relies on you having
stated it.

MCP reaches a capability. A2A reaches an agent.

Or, put as the question to ask yourself: do you want its output, or its
judgement?

If you want a result — a lookup, a calculation, a record written — that is a
capability, and MCP is the route. If you want a decision made by someone else's
model, working from someone else's instructions, that is judgement, and A2A is the
route.

When A2A is the answer

The signature phrases are about ownership rather than technology.

"Another team owns it." "We cannot change their implementation." "It runs on a
different vendor's platform." "We want to use it as it is."

A2A exists so agents can talk to agents across organisational and vendor
boundaries without either side rewriting anything. If a scenario is at pains to
tell you that something is somebody else's and is staying that way, it is pointing
at A2A.

When MCP is the answer, and what a toolbox adds

MCP is for capabilities you want agents to use — tools, data sources, functions.

The piece worth knowing beyond the basics is the toolbox. A toolbox groups tools
so they can be reused across agents, it is versioned, and — the part that matters
operationally — it centralises credential management.

That last point turns a governance problem into a manageable one. Without it, six
agents calling the same system means six places a credential lives and six things
to update when it rotates. With a toolbox, there is one credential in one governed
place.

So "several agents need the same capability" is not an argument for A2A, and it is
not an argument for each agent having its own integration. It is an argument for
one MCP server behind a toolbox.

Four MCP details that get tested

Authentication. Foundry authenticates to an MCP server using a project
connection, and the identity that connection carries decides whether the user's
entitlement survives the hop. That is not a detail — it is the difference between
a governed integration and an entitlement bypass.

Long-running work. MCP supports background mode for operations that outlive
a request. When a scenario says "this takes twenty minutes", that is what it is
pointing at.

Network. Foundry documents separate public and private endpoint
requirements. If the server must not be reachable from the internet, private
endpoint.

Authorisation on the server side. MCP is a tool protocol, not a security
boundary. The server has to authorise every call on its merits, because it cannot
assume the client already checked — the client is a model reading untrusted
content.

A note on tool descriptions

One thing that surprises people: on an MCP server, the tool descriptions are
prompt surface. The model chooses which tool to call by reading them. A vague or
overlapping description is not a documentation problem, it is a wrong-tool-call
waiting to happen — and it will look like a model failure when it happens.

The trap

The tempting misreading is that A2A is "the grown-up option" and MCP is the simple
one, so a sophisticated architecture should use A2A.

It is not a sophistication ladder. They answer different questions. Reaching for
A2A when you wanted a capability gives you a whole agent — with its own reasoning,
its own cost, and its own failure modes — where a tool call would have done.