# A2A and MCP: when your agent has to hand work to another vendor's agent inside a client's system

> When the next link in the chain is an agent from a vendor whose code, memory and tools you cannot see, three things matter: use MCP for your own tools, use A2A to hand work to the other vendor, and expect the hard part to be authentication and tracing.

Bản gốc: https://fdetimes.net/en/guides/a2a-vs-mcp-cross-vendor-agents/

In your third week on site, you have a customer-service agent running smoothly: it reads orders, looks up the returns policy and answers in the brand's voice. Then the client's product owner asks what sounds like a simple question: "The ERP vendor's refund-approval agent is already live. Can your bot call it?"

You do not have that agent's code. You do not know which model it uses, what it remembers or which APIs it calls. All you have is an endpoint and a name.

Once a client runs agents from several vendors, the job of wiring them together without punching holes in security tends to land on the FDE sitting on site. Doing it well starts with a clear distinction between two protocols that are often mentioned in the same breath: MCP and A2A.

## Calling a tool or handing work to a colleague?

MCP, according to its official documentation, is an open-source standard for connecting AI applications to external systems. Your agent uses MCP to read the orders database, call the policy API or check inventory. These are tools: you know what they do, which parameters they take and what they return.

A2A solves a different problem. Google's announcement describes A2A as an open protocol that complements MCP, designed to let agents from different vendors collaborate even when they do not share memory, tools or context.

The A2A documentation sums it up in one memorable line: A2A connects agents to each other, while MCP connects each agent to its own tools.

The test is straightforward. If you need a capability and will decide how to use it yourself, that is MCP. If you need someone to take on a job, reason about it independently and return a result, that is A2A. The A2A documentation draws the same line: A2A is about agents collaborating on tasks, while MCP is about agents using capabilities.

**Điểm mấu chốt:** If you need a capability, call a tool. If you need a partner that reasons for itself, delegate the work.

## Walking through a refund flow end to end

Back to the returns example. The scenario is hypothetical but close to real work. A customer writes: "The shirt arrived in the wrong size. I want a refund." Your agent uses MCP to read the order and check the policy. Approving the refund, however, has to pass to the ERP vendor's agent.

**Step 1: read the Agent Card.** According to the A2A documentation, an agent publishes its capabilities through a JSON Agent Card. This metadata document describes its identity, capabilities, endpoint, skills and authentication requirements. A trimmed-down version, purely for illustration, might look like this:

```json
{
"name": "erp-refund-agent",
"url": "https://agents.erp-vendor.example/a2a",
"skills": [
{ "id": "approve_refund", "description": "Duyệt hoặc từ chối yêu cầu hoàn tiền" },
{ "id": "refund_status", "description": "Tra trạng thái một yêu cầu hoàn tiền" }
],
"authentication": "OAuth bearer token"
}
```

(The descriptions read "Approve or reject a refund request" and "Look up the status of a refund request".) Real field names must follow the current spec. The lesson is in how to read it: scrutinise the Agent Card as closely as you would a client's first requirements document. Which skills are published? Is the one you need on the list? What kind of credential does it require, and who on the client side issues it?

**Step 2: create a Task, do not make a function call.** In A2A, a Task is a stateful unit of work, initiated by an agent, with a unique ID and a defined lifecycle. A refund approval may need a human to review it, so the result may not come back immediately. Your code must store the task ID, track its state and tell the customer something sensible while it waits.

**Step 3: accept the black box.** The A2A documentation is explicit that, from the client's point of view, the remote agent's internal workings, memory and tools are hidden. So you must send enough context in the Task itself, including the order number, the reason and the evidence, rather than assume the other agent can look up whatever your agent has already seen.

## Security is where the project is won or lost

Sending the first Task is only half the job. The other half, and the half worth spending more time discussing with the client, is authentication and authorisation.

On the A2A side, familiar web mechanisms apply, such as OAuth tokens or API keys carried in HTTP headers. A2A's enterprise documentation requires the server to authenticate every incoming request using the credentials in the header.

Access can also be granted per skill published in the Agent Card. In the example above, the client could perfectly well allow your agent to call `refund_status` only and keep `approve_refund` internal.

MCP has a different trap. The 2025-06-18 authorization spec requires MCP servers to validate a token's audience and forbids passing through a token received from an MCP client to downstream APIs.

Picture your MCP server inside the client's network taking a user's token and using it to call the payments system directly. The server has become a "confused deputy": an intermediary that unwittingly borrows someone else's authority.

The server must obtain its own credentials for each downstream system.

## When something breaks, the trace ID is your evidence

Sooner or later a refund will get stuck. The client will ask whose fault it is, and without data the two vendors will blame each other.

The A2A documentation recommends that both client and server take part in a distributed tracing system and log task IDs, session IDs and correlation IDs on both sides. The advice for you: build this into the design from day one rather than bolting it on after the first incident.

Every log line from your agent needs a task ID that the ERP side also records, so that when you open the two systems' logs side by side you can assemble a single timeline.

There is another reason this skill outlasts any one client. A2A has been handed to the Linux Foundation for vendor-neutral governance, with Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow as founding members. Many of the enterprise platforms your clients already use are on that list.

## Do it yourself: five steps before connecting two agents

First, map the business flow and colour each arrow: which arrows are an agent calling its own tools (MCP), and which cross the boundary between two vendors (A2A). Next, obtain the partner's Agent Card, match its skills against your needs and list the credentials you will have to request.

Then sit down with the client's security team to settle per-skill permissions and how tokens are issued, before writing code. Fourth, design the Task for slow or failed cases: store the ID, set a timeout and prepare a message for the user. Finally, agree the trace ID format with the other vendor's team in writing.

## Three common mistakes

One common mistake is wrapping the other vendor's agent as an MCP tool and calling it like a synchronous function, ignoring the fact that a Task has its own lifecycle. This can look fine in a demo but breaks when an approval needs a human and takes a long time. The second is token passthrough: quick, convenient, and exactly what the MCP spec forbids.

The third is harder to spot: believing the other agent "knows" the context. It knows nothing beyond what you send in the Task. If the results come back off-topic, check your own payload first.

## Turning this skill into a line on your CV

For developers looking to move into FDE roles, this is worth putting on a CV as one concrete sentence, such as "integrated a third-party agent over A2A, with per-skill authorisation and tracing across both systems".

When reading job descriptions, look for phrases like "multi-agent", "third-party integration" or "enterprise security". They may signal that the role needs exactly the kind of work described here, so it is worth probing in interviews.

**This week's exercise:** build two small agents locally. Agent A uses an MCP server that reads a CSV file of orders. Agent B publishes an Agent Card with two skills and lets A call only one of them. Have A delegate a Task to B, log the task ID on both sides, then deliberately make B return an error and follow the logs all the way to the cause.

If you can trace that error from the logs alone, you will have a good answer the first time a client asks which side the fault is on.

**Thử ngay tuần này:**

- Write an Agent Card for an agent you have built, listing exactly the skills it should expose to outside callers and the type of authentication it requires
- Review an MCP server you are running: does it validate the token's audience, and does it pass the client's token straight through to downstream APIs?
- Diagram a cross-vendor flow, mark where MCP and A2A are used, and note how the trace ID is passed across each boundary

## Nguồn

- [Announcing the Agent2Agent Protocol (A2A)](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/)

- [Core Concepts and Components in A2A](https://a2a-protocol.org/latest/topics/key-concepts/)

- [A2A and MCP: Detailed Comparison](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)

- [What is the Model Context Protocol (MCP)?](https://modelcontextprotocol.io/docs/getting-started/intro)

- [Enterprise Security in A2A: Credentials, Access, and Tracing](https://a2a-protocol.org/latest/topics/enterprise-ready/)

- [Authorization - Model Context Protocol (spec 2025-06-18)](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)

- [Google Cloud donates A2A to Linux Foundation](https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/)