Choose the Minimal Contract First

Since MCP and A2A close different boundaries, the first engineering question isn't "which protocol to take" but "what is the smallest contract that keeps the independence I need". Overpaying here is as harmful as underbuilding: an extra protocol adds discovery, versioning, and attack surface you'll have to maintain.

It helps to navigate by the character of the task. A direct API fits when the service is known and you control both sides: the contract is stable, discovery isn't needed, and plain REST, gRPC, or a library call is simpler and more reliable. MCP is needed where an AI host must discover and safely use tools, resources, and prompt templates from different providers you didn't write. A2A appears when the remote side plans long-running work on its own, may request more input, and returns artifacts - that is, when you hand over not a call but a goal.

Sorting these signals onto shelves is easier with a comparison by unit of contract, discovery, model of long work, and typical risk.

Signal · Direct API · MCP · A2A

• Unit of contract - Endpoint or function; Tool, resource, prompt; Message, task, artifact
• Discovery - OpenAPI/docs; */list; Agent Card
• Long-running work - You design it yourself; Usually request, tasks available via an extension; Base protocol model
• The executor's internals - Often known; A capability hides the implementation; The agent is deliberately opaque
• Typical risk - Homegrown incompatibility; An overly powerful tool; Ungoverned delegation

Every row of the table is not an abstraction but a question to ask about a concrete integration. The unit of contract shows what you exchange: a function, a capability, or a task. Discovery is how the other side learns what you can do. The model of long work is who owns state when the answer isn't instant. And the risk column reminds you that each level has its own typical failure: a direct API - homegrown incompatibility, MCP - an overly powerful tool, A2A - ungoverned delegation.

To feel the choice against your own inputs, run the task through the builder - it asks about the side, discovery, and duration, and suggests the minimal appropriate contract.

And a short test that almost always settles it.

A practical heuristic test. If you want to name a remote function, its arguments, and its result - look toward MCP or a plain API. If you state a goal and accept an independent course of work - look toward A2A.

Contract chosen - now implementation begins. And we'll start it not with an SDK, but with what actually goes over the wire: the message itself.