Protocol Ecosystem Overview: MCP vs A2A vs OpenAPI

Chapter 42: Protocol Landscape — MCP vs A2A vs OpenAPI

Introduction

Between 2025 and 2026, the AI agent protocol space experienced its own Cambrian explosion. Anthropic introduced the Model Context Protocol (MCP), Google proposed Agent-to-Agent Protocol (A2A), and OpenAPI — with over a decade of history — remained the de facto standard for describing REST services. This coexistence is not chaos; each protocol occupies a distinct ecological niche. Understanding their fundamental differences is the foundation for building sustainable AI systems.

This chapter analyzes the design philosophy behind each protocol, provides concrete decision guidance for specific scenarios, and forecasts where the protocol ecosystem is heading in 2026.

42.1 The Core Positioning of Each Protocol

One-Line Definitions

Protocol Layer Model

┌──────────────────────────────────────────────────┐
│               Application Layer                   │
└───────────────┬──────────────────────────────────┘
                │
    ┌───────────┴──────────┐
    │                      │
┌───▼────────┐    ┌────────▼───────┐
│ A2A        │    │ MCP            │
│ Agent↔Agent│    │ Model↔Tool     │
└───┬────────┘    └────────┬───────┘
    │                      │
    └──────────┬───────────┘
               │
    ┌──────────▼───────────┐
    │  HTTP / WebSocket     │
    │  (described by        │
    │   OpenAPI spec)       │
    └──────────────────────┘

Key insight: OpenAPI is not a competitor to MCP or A2A. It is the interface description language that underlies both. MCP and A2A compete at the semantic (behavior) layer; OpenAPI operates at the structural (description) layer and serves both.

42.2 Deep Comparison

Full-Dimension Comparison Table

Design Philosophy

MCP: Standardizing Tool Access

MCP's core assumption: AI models need a secure, standardized way to access external tools and data sources. Rather than every AI vendor implementing tool calling differently, MCP abstracts "tool invocation" into a protocol layer.

Mental model: plug and socket. Tools (MCP Servers) are sockets; AI models (MCP Clients) are plugs; the protocol defines the connector specification.

A2A: Orchestrating Agent Collaboration

A2A's core assumption: complex tasks require multiple specialized agents to collaborate. It abstracts "task delegation" — with task state machines, Agent Cards for capability description, and bidirectional communication — into a protocol layer.

Mental model: organizational hierarchy. There are orchestrators (manager agents), workers (specialist agents), task assignments, and results reports.

OpenAPI: Documenting Interface Contracts

OpenAPI's core assumption: consumers and providers of services need a machine-readable contract. It does not prescribe communication behavior; it only describes interface shape — what endpoints exist, what parameters they accept, and what they return.

42.3 When to Use Each Protocol

Decision Tree

What are you building?
│
├─► AI model needs to access tools/data sources?
│     └─► Use MCP
│           • Standard use: Claude/Hermes accessing filesystem, database
│           • Advantage: mature ecosystem, native Claude Code support
│           • Example: hermes-agent + filesystem-mcp + database-mcp
│
├─► Multiple AI agents need to collaborate on complex tasks?
│     └─► Use A2A
│           • Standard use: research agent delegates to writing agent
│           • Advantage: task state tracking, dynamic agent discovery
│           • Example: Hermes Orchestrator → N specialist agents
│
├─► Exposing capabilities to human developers or non-AI programs?
│     └─► Use OpenAPI
│           • Standard use: Hermes reasoning wrapped as REST API
│           • Advantage: mature toolchain (Swagger UI, Postman, SDK gen)
│           • Example: FastAPI + Hermes → external REST interface
│
└─► Mixed scenario (most common)?
      └─► Combine protocols (see Section 42.4)

Scenario Selection Matrix

42.4 Interoperability Strategies

Strategy 1: OpenAPI-to-MCP Bridge

The most common hybrid pattern: automatically convert existing OpenAPI services into MCP Servers.

# openapi_to_mcp_bridge.py
import httpx
import yaml
import json
from mcp.server import Server
from mcp import types

async def build_mcp_from_openapi(spec_url: str) -> Server:
    """Dynamically generate an MCP Server from an OpenAPI Spec URL."""
    async with httpx.AsyncClient() as client:
        response = await client.get(spec_url)
        spec = yaml.safe_load(response.text)

    app = Server(f"openapi-bridge-{spec['info']['title']}")
    tools = []

    for path, path_item in spec.get("paths", {}).items():
        for method, operation in path_item.items():
            if method not in ["get", "post", "put", "patch", "delete"]:
                continue
            tool_name = operation.get("operationId", f"{method}_{path.replace('/', '_')}")
            description = operation.get("summary") or operation.get("description", "")
            input_schema = _build_input_schema(operation, method)
            tools.append({
                "name": tool_name,
                "description": description,
                "inputSchema": input_schema,
                "meta": {
                    "path": path,
                    "method": method,
                    "base_url": spec.get("servers", [{}])[0].get("url", "")
                }
            })

    @app.list_tools()
    async def list_tools():
        return [
            types.Tool(name=t["name"], description=t["description"], inputSchema=t["inputSchema"])
            for t in tools
        ]

    @app.call_tool()
    async def call_tool(name: str, arguments: dict):
        meta = next((t["meta"] for t in tools if t["name"] == name), None)
        if not meta:
            return [types.TextContent(type="text", text=f"Unknown tool: {name}")]
        result = await _call_api(meta, arguments)
        return [types.TextContent(type="text", text=json.dumps(result))]

    return app


def _build_input_schema(operation: dict, method: str) -> dict:
    properties, required = {}, []
    for param in operation.get("parameters", []):
        properties[param["name"]] = {
            "type": param.get("schema", {}).get("type", "string"),
            "description": param.get("description", "")
        }
        if param.get("required"):
            required.append(param["name"])
    if method in ["post", "put", "patch"]:
        body = operation.get("requestBody", {}).get("content", {}).get("application/json", {}).get("schema", {})
        for k, v in body.get("properties", {}).items():
            properties[k] = v
        required.extend(body.get("required", []))
    return {"type": "object", "properties": properties, "required": list(set(required))}


async def _call_api(meta: dict, arguments: dict) -> dict:
    url = meta["base_url"] + meta["path"]
    for k, v in arguments.items():
        url = url.replace(f"{{{k}}}", str(v))
    async with httpx.AsyncClient() as client:
        if meta["method"] == "get":
            r = await client.get(url, params=arguments)
        else:
            r = await client.request(meta["method"].upper(), url, json=arguments)
        return r.json()

Strategy 2: MCP + A2A Layered Architecture

User Request
    │
    ▼
Hermes Orchestrator  ◄── receives via MCP
    │
    ├── A2A → Research Agent    (information gathering)
    ├── A2A → Writing Agent     (content generation)
    └── A2A → QA Agent          (quality checking)
         │
         ▼
    Each agent uses MCP to access its own tools
    (filesystem / database / web-search)

The key principle: user-facing interfaces use MCP; agent-to-agent coordination uses A2A; underlying services are described by OpenAPI.

Strategy 3: A2A Agent Card Registration

# a2a_agent_card.py
from dataclasses import dataclass, asdict
import json

@dataclass
class AgentCapability:
    name: str
    description: str
    input_schema: dict
    output_schema: dict

@dataclass
class HermesAgentCard:
    """Published at /.well-known/agent.json for A2A discovery."""
    id: str
    name: str
    description: str
    version: str
    capabilities: list
    endpoint: str
    auth_methods: list

    def to_json_ld(self) -> dict:
        return {
            "@context": "https://schema.a2aprotocol.org/v1",
            "@type": "Agent",
            "id": self.id,
            "name": self.name,
            "description": self.description,
            "version": self.version,
            "endpoint": self.endpoint,
            "capabilities": [asdict(c) for c in self.capabilities],
            "authMethods": self.auth_methods
        }

hermes_card = HermesAgentCard(
    id="https://ai.mycompany.com/agents/hermes-70b",
    name="Hermes Code Analysis Agent",
    description="Deep code analysis powered by Hermes 4 70B",
    version="1.0.0",
    capabilities=[
        AgentCapability(
            name="analyze_code",
            description="Analyze code for bugs, security issues, and performance",
            input_schema={"type": "object", "properties": {"code": {"type": "string"}}},
            output_schema={"type": "object", "properties": {"issues": {"type": "array"}}}
        )
    ],
    endpoint="https://ai.mycompany.com/a2a/hermes",
    auth_methods=["oauth2", "api_key"]
)

42.5 2026 Protocol Ecosystem Predictions

Prediction Matrix

Analysis

MCP's moat is deepening. Claude Code, Cursor, and Zed have native MCP support. This creates a network effect: tool developers prioritize MCP support because that is where the users are; more MCP tool support attracts more MCP users. Prediction: over 10,000 MCP Servers will exist by end of 2026.

A2A will reshape enterprise AI architecture. The core pain point in enterprise AI is not model capability but system integration — how to coordinate multiple AI services into a reliable workflow. A2A directly addresses this with task lifecycle management, dynamic agent discovery, and cross-organization collaboration.

OpenAPI will transform, not disappear. Its role shifts from "the primary interface standard" to "the description language underlying AI protocols." Increasing numbers of OpenAPI services will auto-generate MCP Servers, giving OpenAPI renewed relevance.

Convergence is the most likely future. Rather than one protocol winning, expect a cross-protocol interoperability layer to emerge. Both Anthropic and Google have incentives to avoid protocol fragmentation.

Chapter Summary

The three protocols standardize three different dimensions:

They are complementary, not competing. Mature AI systems typically use all three: OpenAPI describes underlying services, MCP gives AI access to them, A2A coordinates collaboration between AI agents.

2026 keywords: MCP ubiquity, A2A enterprise adoption, protocol convergence.

Review Questions

1. If you need to integrate Hermes with a legacy system that has 50 existing REST APIs, which path do you prioritize — manually creating MCP Servers for each, or deploying an OpenAPI-to-MCP bridge? What are the trade-offs of each approach?

2. A2A introduces agent identity via DID; MCP currently relies on HTTP authentication. When a Hermes Agent needs to prove its identity to an agent at a different organization, which authentication mechanism should it use, and why?

3. If MCP and A2A were to merge into a single protocol, which features from each would you retain, and which would be expendable? Justify your choices.