Say you have an inventory agent for a retail chain. It checks stock levels against a product database, spots shortfalls, and coordinates restocking with an external supplier. Two protocols handle different halves of that job. The interesting part is the seam between them.

Querying inventory through MCP

The agent connects to an MCP server wrapping the product database. It calls tools/list and gets back a catalog: tool names, descriptions, JSON Schema definitions for every argument. check_inventory takes a product_id string, returns stock counts by warehouse. Everything is declared up front.

The agent calls tools/call with:

{"name": "check_inventory", "arguments": {"product_id": "SKU-4471"}}

Back comes a content array: 12 units remaining, reorder threshold is 50. An isError flag tells the agent immediately if something broke. The tool schema is the contract. You know the shape of every request and every response before you send anything.

Now the agent needs more units from a supplier. The interaction changes shape entirely.

The boundary is application code

There's no protocol-level bridge between MCP and A2A. The developer writes the logic that says: local tools have done their job, time to reach out. That transition lives in your application, not in either protocol.

So the developer is doing translation work. MCP gave you structured fields: current_stock: 12, reorder_threshold: 50, warehouse: "WH-3". The A2A message/send call needs a different package: 38 units of SKU-4471, deliver to warehouse #3, here's our purchase authorization. Some of what MCP returned carries over directly. Some gets computed (50 minus 12). Some context gets added that MCP never knew about. You're trading visibility for reach here, and the shape of that trade is a design decision the developer owns.

Coordinating with a supplier through A2A

The supplier runs an A2A-compliant agent. Discovery starts by fetching its Agent Card from /.well-known/agent-card.json, which declares skills, supported input/output modes, and authentication requirements. Where an MCP tool listing gives you argument schemas and return types, the Agent Card tells you nothing about the agent's internals. No schema for intermediate steps. No visibility into what tools or models it uses.

That opacity makes sense. The supplier's internal process belongs to a different organization with its own systems. You don't get their tool schemas because they aren't your tools. MCP connects you to resources you control or have been granted access to. A2A is for collaborating with autonomous systems you don't.

The inventory agent sends a message/send request. Back comes a task object with an ID and a submitted status. The supplier agent now owns that task and will move it through a lifecycle: working, possibly input-required, eventually completed or failed.

The input-required state deserves attention. The supplier agent might respond: "SKU-4471 is discontinued. We have a replacement at a different price. Proceed?" Your inventory agent now has to continue a conversation it didn't fully anticipate. MCP interactions end with a parsed response. A2A interactions are negotiations you track over time, watching state transitions arrive over SSE or polling with tasks/get.

What the developer actually designs for

The supplier's internal tool calls, its reasoning, its retries are all invisible to you. You get status updates and artifacts. The execution trace stays on their side.

The design work concentrates at that asymmetry. And the most common way it breaks is treating A2A like MCP. If you fire off message/send expecting a synchronous result the way tools/call delivers one, you'll miss the input-required state entirely. The task sits in limbo. The supplier asked a question nobody heard. Half your system is deterministic and inspectable; the other half is a conversation with something that has its own process and might need things you didn't plan for. Building for that difference is most of the work.