Skip to content
Agentic Engineering Fieldbook

MCP, A2A, and Agent Interoperability

Observation date and maintenance

Section titled “Observation date and maintenance”

Observed on 2026-07-23.

Applicable surfaces: Model Context Protocol specification version 2025-11-25 and current Agent2Agent Protocol specification pages available on the observation date.

Maintenance state: maintained Field Note. Revisit when either protocol publishes a stable major revision, changes authentication or security requirements, or adds compatibility requirements that affect host, server, or agent implementations.

Current observation

Section titled “Current observation”

MCP and A2A address different interoperability problems.

MCP connects a host to external context and callable capabilities. Its specification covers server capabilities such as tools, resources, and prompts, and it includes security guidance for user consent, tool descriptions, and untrusted content. It is most useful when a model host needs a common way to discover and invoke capabilities provided by external servers.

A2A addresses agent-to-agent interaction. Its specification describes agent cards, tasks, messages, parts, artifacts, and event streams so that one agent or client can discover another agent’s capabilities and exchange work. It is most useful when independently built agents need to communicate about tasks rather than when one model needs a local tool call.

These protocols can be complementary. A user-facing host could use MCP to reach tools and resources while also using A2A to delegate work to another agentic service. But the boundary matters: MCP is not “agent-to-agent” by itself, and A2A is not a tool sandbox by itself.

Durable engineering implication

Section titled “Durable engineering implication”

Protocol compatibility is only the first layer of interoperability.

The protocol can describe message shapes, discovery documents, and transport events. It cannot guarantee that two systems mean the same thing by “approve,” “complete,” “source,” “urgent,” “customer,” or “safe.” It cannot decide which principal is acting, which tenant owns the data, which authority was delegated, which result is accepted, or which organization answers for a bad outcome.

Therefore, treat a protocol adapter as an execution boundary and a trust boundary. It should preserve the initiating principal, delegated scope, task purpose, data classification, approval state, trace identifiers, and result evidence. It should fail closed when required identity, authorization, or compatibility fields are missing.

For long-running work, test lifecycle semantics directly. Can the caller cancel the task? Can it resume? Who owns partial artifacts? What happens if streaming ends but the external effect is unknown? Are duplicate task updates idempotent? Can a human take over? The protocol may provide a shape; the system must define the operating contract.

What not to generalize

Section titled “What not to generalize”

Do not infer safety from discovery. A discovered tool or agent description is untrusted input until the host validates it. Tool descriptions and agent cards can influence model behavior, so they belong inside prompt-injection and supply-chain threat models.

Do not infer semantic compatibility from syntactic compatibility. A valid A2A task message can still omit the evidence your workflow requires. A valid MCP tool can still expose too broad an action for the current user.

Do not infer ecosystem maturity from specification availability. Public specifications are important, but deployments still need conformance tests, version negotiation, fallback paths, operational telemetry, and incident plans.

Operational checklist

Section titled “Operational checklist”
  • Pin protocol version and implementation version in release records.
  • Keep an allowlist of trusted MCP servers, A2A peers, tools, resources, and agent cards; record owners and review dates.
  • Treat descriptions, prompts, resources, and peer-provided task content as untrusted context until mediated.
  • Preserve initiating principal, tenant, delegated authority, purpose, and approval state across protocol boundaries.
  • Validate tool calls, task requests, artifacts, and callbacks at local execution boundaries.
  • Test cancellation, retries, unknown outcomes, duplicate messages, stale updates, and partial artifacts.
  • Keep protocol traces connected to application traces and accepted outcomes.
  • Provide a human takeover path when the remote peer cannot complete, explain, or safely continue the task.
  • Avoid claiming interoperability until the exact peer, version, task class, and evidence requirements have been tested.

References and how they are used

Section titled “References and how they are used”