Interoperability connects capabilities; governance decides whether they should be used

MCP: application-to-capability integration

MCP uses a client-server architecture in which an AI application can connect to servers that expose resources, prompts, and tools. The specification includes capability negotiation and structured tool definitions. [S1] [S2] [S3]

The practical value is a common contract for discovering and invoking capabilities. The security boundary still resides in the host application, server, identity system, and policy layer.

A2A: agent-to-agent collaboration

A2A is designed for communication between agent systems, including capability discovery, task exchange, progress, artifacts, and longer-running collaboration. It addresses a different layer than tool access. [S4]

The A2A documentation explicitly describes A2A and MCP as complementary: one can connect agents to each other while the other connects agents or applications to tools and context. [S5]

A practical boundary

Use MCP when the interaction is fundamentally with a capability: retrieve a resource, invoke a bounded tool, or obtain a structured prompt. Use A2A when the counterparty maintains its own task state, role, capabilities, and result lifecycle.

Avoid turning every tool server into an autonomous agent or every agent into a thin wrapper around one tool. The architecture should reflect where independent planning, authority, and state truly exist.

Identity and authority travel with the task

A message needs more than a sender label. It should carry an authenticated identity, task and tenant scope, delegated authority, data-classification boundary, policy context, expiry, and evidence requirements.

Receivers should not inherit the sender's ambient credentials. Capability tokens or task-scoped identities should be as narrow and short-lived as practical.

Contracts need failure semantics

Define timeout, cancellation, retry, idempotency, partial result, refusal, and unknown states. A protocol connection can succeed while the business task fails. The sender needs to know whether work was accepted, started, partially completed, completed, rejected, or left in an uncertain state.

Observability across protocol boundaries

Correlate task identifiers, message identifiers, tool invocations, model and prompt versions, policy decisions, artifacts, and final effects. Preserve enough provenance for a reviewer to reconstruct why a capability was used and what it changed.

Trust is not transitive

An approved agent may communicate with another system that delegates again. Trust should not expand automatically through the chain. Declare delegation depth, allowed counterparties, data boundaries, and whether the original owner must approve downstream delegation.

Research boundary

Protocol specifications evolve. This page reflects the cited 2026 specifications and should be reviewed before implementation. Compatibility does not certify security, privacy, or fitness for a particular workflow.