API vs MCP: cuándo una empresa necesita cada una para vender a agentes

Comparativa entre API REST y MCP (Model Context Protocol) para que un agente de IA pueda interactuar con tu negocio. Diferencias técnicas, cuándo usar cada una, cuándo combinarlas y casos concretos.

API vs MCP: cuándo una empresa necesita cada una para vender a agentes

La diferencia en una oración

API REST: un contrato entre tu sistema y cualquier cliente que quiera usarlo (otro sistema, una app, un sitio web, un agente).

MCP (Model Context Protocol): un protocolo que estandariza cómo un modelo de IA descubre y usa herramientas externas. Un servidor MCP es, en esencia, un wrapper sobre tu API que la presenta en un formato que los modelos entienden nativamente.

Si tu API es el menú del restaurante, MCP es el mesero que le lee la carta al cliente en su idioma.

Qué es una API REST (lo que ya conocés)

Una API REST es una forma estándar de exponer funcionalidad de un sistema a través de HTTP. Endpoints con métodos (GET, POST, PUT, DELETE), payloads en JSON, autenticación con tokens. Si tu sistema tiene una API, cualquier cosa que sepa hacer HTTP puede hablar con él.

Para qué sirve en el contexto agéntico:

• Un agente que necesita consultar stock puede hacer GET /api/catalog?sku=ABC123.
• Un agente que necesita agendar puede hacer POST /api/appointments con el payload correspondiente.
• Un agente que necesita confirmar un pago puede hacer GET /api/payments/{id}.

La API REST es agnóstica al cliente. El mismo endpoint lo puede usar un agente, una app móvil, un sitio web o un sistema interno.

Limitaciones para el caso agéntico:

• El agente tiene que saber qué endpoints existen, qué parámetros aceptan y qué formato tienen. Si tu API tiene 200 endpoints, el agente no puede adivinar cuál usar.
• El agente necesita que le pases la documentación (OpenAPI, Postman, etc.) en el prompt o que la descubra por otro medio.
• Si la API cambia, el prompt que el agente tiene cargado queda desactualizado. Hay que actualizarlo.

Para resolver esto aparece MCP.

Qué es MCP (lo nuevo)

MCP (Model Context Protocol) es un protocolo abierto, presentado por Anthropic en noviembre de 2024 y adoptado rápidamente por la industria, que estandariza cómo un modelo de IA se conecta a herramientas externas.

En la práctica, un servidor MCP:

• Declara qué herramientas expone (con nombre, descripción y esquema de parámetros).
• Declara qué recursos provee (datos que el modelo puede leer).
• Declara qué prompts pre-armados ofrece.
• Maneja la autenticación con el sistema externo.

El modelo no necesita conocer tu API REST. Conoce el servidor MCP, le pregunta qué herramientas tiene, y las usa como si fueran funciones nativas.

Analogía: tu API REST es como un sitio web que cualquier navegador puede abrir, pero cada uno tiene que aprender la navegación. MCP es como un plugin estándar que el navegador reconoce automáticamente y te ofrece una interfaz consistente.

La tabla resumen

Cuándo una empresa necesita una API

Siempre que quiera ser operable por cualquier sistema externo, no solo por humanos. Eso incluye:

• Integración con plataformas de terceros (marketplaces, agregadores, comparadores).
• App móvil o web app que consume datos del backend.
• Automatización interna entre sistemas.
• Operación por agentes (de IA o automatizados tradicionales).

Cuándo NO necesitás una API todavía:

• Si tu negocio es 100% offline y no vende nada digitalizable.
• Si tu volumen de operaciones es tan bajo que el costo de mantener una API no se justifica.
• Si ya tenés una forma de operar con terceros (EDI, planillas, email) que escala a tu ritmo.

Para la mayoría de las empresas que quieren ser agentic-ready, la API es el primer paso y el más importante. Sin API, no hay forma de que un agente opere con tu sistema.

Cuándo una empresa necesita un servidor MCP

Cuando ya tenés una API y querés que los agentes la usen sin fricción.

Los criterios concretos:

• Tus clientes empiezan a preguntar "¿tienen MCP?" Si te lo preguntan, lo necesitás. Si nadie te lo pregunta todavía, esperá.
• Tu API es estable y bien documentada. MCP wrappea tu API. Si tu API cambia seguido, vas a estar manteniendo dos cosas a la vez.
• Tu caso de uso principal es consulta + operación, no solo consulta. MCP brilla cuando el agente necesita encadenar varias llamadas a herramientas. Si solo es "leer un catálogo", una API pública bien documentada alcanza.
• Tenés recursos para mantener un servidor MCP. Un servidor MCP no es un script de 10 líneas. Es un servicio que tiene que estar disponible, autenticado, y versionado.

Cuándo NO necesitás un servidor MCP todavía:

• Si recién estás armando la API, esperá. Sin API sólida, MCP no resuelve nada.
• Si tu público objetivo todavía no usa agentes, esperá. La inversión se justifica cuando hay adopción.
• Si tu API es muy simple (5 endpoints o menos), la documentación pública alcanza.

El error más común: empezar por MCP

Muchas empresas que escuchan sobre agentes y MCP se quieren lanzar directo a armar un servidor MCP. El error: sin una API sólida, el MCP es un cascarón vacío. Tenés que wrappear algo, y si ese algo no está bien armado, el agente no puede operar.

El orden correcto:

1. API REST documentada (OpenAPI), autenticada, estable.
2. Documentación accesible para máquinas (/llms.txt, OpenAPI en /api/openapi.yaml).
3. Endpoints clave accesibles y testeables.
4. Recién después: servidor MCP que wrappea la API.
5. Monitoreo de uso de MCP y ajustes.

Cómo se ve un sistema agentic-ready completo

Una empresa que ya pasó por las 5 etapas tiene un stack así:

• Backend: tu sistema de siempre (CRM, ERP, ecommerce, etc.).
• API REST: expone las operaciones clave (consultar catálogo, cotizar, reservar, pagar). Documentada en OpenAPI.
• Servidor MCP: wrappea la API. Los agentes lo descubren automáticamente, leen qué herramientas hay, y las usan.
• Documentación para máquinas: /llms.txt, /catalog.json, /.well-known/agent-skills/SKILL.md, /auth.md, /.well-known/mcp.json.
• Webhooks: notifican al agente cuando algo cambia (estado de pedido, confirmación, etc.).
• Logs auditables: cada operación del agente queda registrada con qué herramienta se usó, con qué parámetros, y qué resultado dio.

Con este stack, cualquier agente de los principales (Claude con MCP, GPT con function calling, Gemini con tool use) puede operar tu sistema sin código custom.

Caso aplicado: una agencia de marketing con API + MCP

Imaginemos una agencia que vende campañas. Para ser agentic-ready, expone:

API REST:

• GET /api/services - lista de servicios con descripción y precio desde.
• GET /api/cases?industry=fintech - casos de éxito filtrados.
• POST /api/quotes - solicitud de cotización con datos del cliente.
• GET /api/quotes/{id} - estado de la cotización.
• POST /api/projects/{id}/messages - agregar un mensaje al proyecto.

Servidor MCP:

• Tool listar_servicios() - devuelve los servicios con descripción.
• Tool buscar_casos(industria, presupuesto) - busca casos relevantes.
• Tool cotizar(servicios, cliente) - genera una cotización.
• Tool estado_cotizacion(id) - consulta el estado.
• Tool agendar_reunion(fecha, motivo) - agenda en el calendario del equipo.

Cuando un agente de un cliente potencial quiere investigar la agencia y contratar, el flujo es:

1. El agente pregunta a su modelo: "¿Cuál es la mejor agencia de marketing digital en Argentina para una campaña de Google Ads?"
2. El modelo cita a la agencia (gracias al trabajo de citabilidad).
3. El agente abre el servidor MCP de la agencia, ve las tools disponibles.
4. Llama a listar_servicios() y buscar_casos(industria='fintech') para entender la oferta.
5. Llama a cotizar() con los datos del cliente.
6. Recibe la cotización y la presenta al humano dueño del agente.
7. Si el humano aprueba, el agente llama a agendar_reunion() para empezar.

Todo el flujo pasa sin que un humano de la agencia intervenga hasta la reunión.

Eso es lo que abre tener API + MCP. Sin las dos, el agente choca en el paso 4 y tiene que volver a su dueño humano, que probablemente elija otra agencia.

El futuro inmediato

MCP está en una fase de adopción temprana pero acelerada. Los principales modelos (Claude, GPT, Gemini) ya lo soportan o están por soportarlo. Las herramientas de desarrollo (Claude Code, Cursor, Windsurf) lo usan para acceder a sistemas externos.

Lo razonable para una empresa que se está preparando:

• 2026: tener API sólida, documentación accesible, OpenAPI en el sitio.
• 2026-2027: evaluar MCP cuando el primer cliente pregunte o cuando los frameworks de agentes lo hagan accesible sin desarrollo custom.
• 2027 en adelante: MCP como commodity, foco en la calidad de las tools expuestas y en la observabilidad de uso.