07-03-01 — OpenAPI vs MCP vs A2A: Decision Matrix
Os três padrões no contexto de 2026
Em 2026, uma empresa .NET enterprise normalmente precisa dos três padrões simultaneamente — em camadas diferentes. Entender qual usar onde é a habilidade central para arquitetar sistemas de IA que funcionam de verdade.
Decision Matrix por cenário
| Cenário | Use OpenAPI | Use MCP | Use A2A |
|---|---|---|---|
| App web consome uma API REST | ✅ Sim | ❌ | ❌ |
| Sistema B2B entre empresas sem IA | ✅ Sim | ❌ | ❌ |
| LLM precisa acessar banco de dados | ⚠️ Possível mas trabalhoso | ✅ Melhor opção | ❌ |
| LLM precisa chamar API de terceiros | ⚠️ Via function calling manual | ✅ MCP server wrappando a API | ❌ |
| Agente de análise delega para agente jurídico | ❌ | ❌ | ✅ Sim |
| Orquestrar agentes Salesforce + SAP + Azure | ❌ | ❌ | ✅ Sim |
| Copilot que acessa SharePoint | ❌ | ✅ MCP server SharePoint | ❌ |
| Workflow de aprovação multi-etapa com IA | ❌ | ⚠️ Parcialmente | ✅ Melhor opção |
| Migrar API REST legada para IA | ✅ Manter existente | ✅ Adicionar MCP wrapper | ❌ |
| Dev usando VS Code precisa de contexto do projeto | ❌ | ✅ MCP server local | ❌ |
O padrão mais comum em empresas maduras: você tem uma REST API com OpenAPI spec → cria um MCP server que wrappa essa API → o LLM usa o MCP server. Você mantém a API existente sem mudanças e adiciona capacidade de IA por cima.
Comparativo técnico detalhado
| Critério | OpenAPI | MCP | A2A |
|---|---|---|---|
| Quem consome | Humanos, apps, sistemas | LLMs / agentes IA | Agentes IA |
| Estilo | REST (stateless) | JSON-RPC (session) | REST + SSE (stateful) |
| Discovery | OpenAPI spec (Swagger) | tools/list | /.well-known/agent.json |
| Streaming | Parcial (SSE/WebSocket custom) | Nativo (Streamable HTTP) | Nativo (SSE) |
| Estado | Stateless | Por sessão | Por task (persistente) |
| Autonomia no server | Nenhuma (executa lógica) | Nenhuma (executa tools) | Total (tem LLM próprio) |
| Tooling Microsoft | Azure API Management | Azure Functions, Copilot Studio | Foundry Agent Service |
| Curva de adoção | Baixa (familiar) | Baixa-média | Média-alta |
| Maturidade | Alta (padrão há 10+ anos) | Média (1+ ano) | Baixa-média (1 ano) |
Fluxo de decisão
Pattern: OpenAPI → MCP wrapper
Para times que já têm APIs REST existentes, o padrão mais pragmático é criar um MCP server wrapper — sem mexer na API original:
from mcp.server import Server
from mcp.types import Tool, TextContent
import httpx
server = Server("erp-api-wrapper")
@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
"""Wrappa chamadas MCP em chamadas REST para a API legada."""
api_base = "https://erp.suaempresa.com/api/v2"
if name == "get_project_status":
async with httpx.AsyncClient() as client:
resp = await client.get(
f"{api_base}/projects/{arguments['project_id']}",
headers={"Authorization": f"Bearer {get_token()}"}
)
return [TextContent(type="text", text=resp.text)]
if name == "list_open_tickets":
async with httpx.AsyncClient() as client:
resp = await client.get(
f"{api_base}/tickets",
params={"status": "open", "limit": 20},
headers={"Authorization": f"Bearer {get_token()}"}
)
return [TextContent(type="text", text=resp.text)]
Como consultoria .NET, o path mais rápido para valor: (1) identificar 3-5 APIs internas mais usadas pelos devs; (2) criar MCP servers para cada uma; (3) configurar no VS Code dos devs. Isso transforma APIs que ninguém lembrava de usar em context automático para o Copilot. ROI em semanas, não meses.
Quando A2A vai ser necessário na Impar
A2A se torna relevante quando você precisa orquestrar workflows que cruzam os sistemas dos clientes. Exemplos reais:
- Vale: agente de análise ambiental (Azure) colaborando com agente de planejamento de mina (SAP) — A2A entre vendors
- TIM: agente de atendimento escalando para agente especialista de billing — A2A interno
- Axia: agente de triagem coordenando com agente de análise de risco — A2A no workflow de crédito