Every enterprise building agentic systems eventually confronts the same question: which protocol connects what to what? The answer is more nuanced than picking a single standard—because the landscape requires multiple protocols operating at different layers.
Four protocols, four purposes
The agentic protocol landscape has settled around four complementary standards. Each addresses a distinct integration challenge.
MCP (Model Context Protocol) connects AI models to tools and data sources. It standardizes how agents discover and invoke capabilities—file systems, databases, APIs—through a well-defined JSON-RPC interface. MCP is the “last mile” between a model and the things it can do.
A2A (Agent-to-Agent Protocol) enables collaboration between opaque agents. Where MCP connects an agent to a tool, A2A connects an agent to another agent. It handles capability advertisement, task delegation, and artifact exchange between systems that don’t share internal state.
OpenAPI describes RESTful HTTP APIs with machine-readable specifications. It predates the agentic era but becomes essential when agents need to consume existing enterprise APIs. The specification provides schemas, authentication requirements, and operation descriptions that agents can parse and act on.
AsyncAPI does for event-driven architectures what OpenAPI does for REST. When agents need to subscribe to message brokers, process event streams, or participate in publish-subscribe patterns, AsyncAPI provides the description language.
What each protocol covers
Understanding the coverage boundaries is critical for architecture decisions.
| Capability | MCP | A2A | OpenAPI | AsyncAPI |
|---|---|---|---|---|
| Tool/API discovery | Yes | Via Agent Cards | Via spec files | Via spec files |
| Invocation semantics | JSON-RPC 2.0 | JSON-RPC 2.0 | REST/HTTP | Broker-specific |
| Streaming | SSE, WebSocket | SSE, webhooks | Limited | Native |
| Authentication | Not specified | OAuth 2.0, OIDC | Defined in spec | Defined in spec |
| Task lifecycle | Not specified | Full (submitted → completed) | Not applicable | Not applicable |
| Agent opacity | Not applicable | Core principle | Not applicable | Not applicable |
| Schema evolution | Not specified | Not specified | Versioning support | Versioning support |
Where they overlap—and where they don’t
MCP and A2A are the most commonly confused pair. The distinction is structural: MCP connects an agent to a service that the agent controls. A2A connects an agent to another agent that operates independently. When your agent calls a database tool, that’s MCP. When your agent delegates a research task to a specialist agent from a different vendor, that’s A2A.
OpenAPI and AsyncAPI overlap with MCP at the tool layer—an MCP server might wrap an OpenAPI-described service, or expose an AsyncAPI-defined event stream. But they serve different architectural roles. OpenAPI and AsyncAPI describe what exists. MCP and A2A describe how agents interact with what exists.
What the landscape doesn’t cover
Even with all four protocols in play, significant gaps remain:
Governance. No protocol specifies how to enforce rate limits, track costs, or audit agent behavior. Governance remains an implementation concern.
Orchestration. None of these protocols define how multiple agents coordinate on complex workflows. Task decomposition, dependency management, and workflow state are out of scope.
Trust and reputation. A2A’s Agent Cards advertise capabilities, but there’s no standard way to verify claims or build trust scores based on past performance.
Discovery at scale. Both MCP and A2A assume you know where to find the servers or agents. Enterprise-scale discovery registries are still emerging.
Implementation considerations
When building your protocol strategy, consider these principles:
Start with what you have. If your enterprise has existing OpenAPI-described services, don’t rewrite them as MCP servers. Wrap them. MCP is a complement to OpenAPI, not a replacement.
Layer intentionally. A clean architecture might use OpenAPI/AsyncAPI to describe services, MCP to expose them to agents, and A2A to enable inter-agent collaboration. Each layer has a job.
Plan for the seams. The most complex engineering work happens at protocol boundaries—where an A2A task triggers MCP tool calls that invoke OpenAPI services. Design these handoffs explicitly.
Don’t wait for convergence. The protocol landscape is stable enough to build on. MCP has broad adoption. A2A is under the Linux Foundation with 150+ supporting organizations. OpenAPI and AsyncAPI are mature standards. The cost of waiting exceeds the cost of occasional protocol evolution.
The bigger picture
The protocol landscape for agentic systems is not a competition between standards. It’s a stack. Each protocol operates at a different layer of the agent interaction model, and mature architectures will use several of them together.
The organizations that succeed will be those that understand which protocol solves which problem—and resist the temptation to use one protocol for everything.