MCP vs API: cuándo usar cada uno en agentes de IA

MCP y API: dos capas distintas, no competidores

El Model Context Protocol (MCP) y las APIs tradicionales resuelven problemas diferentes, y la confusión entre ambos cuesta tiempo y dinero a los equipos técnicos. La fuente original del blog de n8n lo resume así: una API es un conjunto de endpoints fijos que dos programas usan para intercambiar datos; un MCP es una capa estandarizada que permite a un agente de IA descubrir y utilizar herramientas dinámicamente, sin código a medida por cada conexión.

La analogía más repetida — USB-C para IA — sirve para entenderlo rápido: cuando todos los dispositivos y todos los cargadores hablan el mismo protocolo, no necesitas un cable nuevo por cada combinación. Sin un estándar común, conectar M modelos con N servicios implica mantener hasta M × N integraciones a medida; con un protocolo compartido, el trabajo baja a M + N. Para un founder, eso se traduce en semanas de ingeniería ahorradas y en menos deuda técnica cada vez que sumas una herramienta nueva al stack.

Qué cambió en el estándar desde su lanzamiento

MCP no es una idea nueva ni marginal. Anthropic lo presentó como proyecto open source el 25 de noviembre de 2024, según reportó SiliconANGLE. Menos de un año después fue donado a la Agentic AI Foundation, un fondo dirigido de la Linux Foundation que cuenta entre sus miembros platino con Anthropic, OpenAI, Block, Google y Microsoft. A mediados de 2026, OpenAI, Google DeepMind, Microsoft y AWS ya lo habían adoptado, junto con cientos de proveedores de software empresarial.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El 28 de julio de 2026 se publicó la mayor actualización del protocolo hasta la fecha. Los mantenedores eliminaron el handshake de inicialización y la cabecera Mcp-Session-Id, lo que vuelve a MCP stateless en la capa de protocolo por primera vez en su historia. En la práctica, esto significa que un servidor MCP puede correr detrás de un balanceador round-robin simple, sin sticky sessions ni Redis compartido. GitHub anunció el 23 de julio que su GitHub MCP Server soportaría la nueva especificación desde el primer día.

Para los equipos que hoy mantienen un MCP server en producción, el alcance del cambio depende de cuánta lógica dependía del session ID. TechRepublic reportó además que, en noviembre de 2025, Anthropic documentó un caso real de uso malicioso: un grupo estatal chino usó Claude Code orquestado vía MCP para intentar infiltrar alrededor de 30 organizaciones (tecnológicas, financieras, químicas y gubernamentales), ejecutando entre el 80% y el 90% del trabajo táctico de forma autónoma. Es el primer ciberataque a gran escala confirmado con intervención humana mínima, y deja una lección clara: habilitar MCP sin un gateway gobernado es abrir un canal de ataque.

Las cuatro diferencias clave entre MCP y una API

El blog de n8n organiza las diferencias en cuatro ejes, útiles para decidir arquitectura:

Qué debe lograr la interfaz. Una API ejecuta llamadas predecibles y bien tipadas; un MCP expone un catálogo de herramientas que el agente descubre y combina en tiempo de ejecución.
Quién es el consumidor. En una API el consumidor es un desarrollador que escribió código contra un endpoint documentado. En un MCP el consumidor es un modelo de lenguaje que lee un esquema y decide qué herramienta invocar.
Cómo se descubren las capacidades. Las APIs requieren documentación o un spec OpenAPI leído por una persona; los MCP servers publican su catálogo como un esquema que el modelo interpreta directamente.
Persistencia de estado. Las APIs stateless devuelven el resultado en la respuesta; los MCP servers, hasta la versión 2026-07-28, mantenían sesión a nivel de transporte. Con el cambio a stateless, el estado se traslada a handles explícitos (como un basket_id o workflow_run_id) que el propio modelo puede razonar, componer y pasar entre pasos.

Esta última diferencia es la más relevante para founders: pasar de estado oculto en metadata a handles visibles para el modelo abre patrones multi-agente que antes eran imposibles, según los mantenedores David Soria Parra y Den Delimarsky.

Cuándo usar cada uno (y por qué casi siempre se usan juntos)

La regla práctica del artículo original es directa: MCP no reemplaza a las APIs, las orquesta. La mayoría de servidores MCP en producción tienen una API REST por debajo que hace el trabajo real y aplica los rate limits. La decisión de arquitectura es qué partes del flujo son deterministas y cuáles son agentic.

Conviene una API directa cuando:

La secuencia de llamadas es conocida y fija, como un nightly sync que trae los pedidos del día a un warehouse.
Necesitas latencia mínima y cero costo de tokens.
El log debe ser legible para un humano sin parsear intención.

Conviene MCP cuando:

No puedes predecir el orden de las llamadas. Un agente de soporte puede necesitar consultar el pedido, luego el estado de envío, luego iniciar un reembolso, según lo que diga el cliente.
Hardcodear ese árbol de decisiones implica mantener cada rama para siempre.
El valor está en dejar que el modelo elija la herramienta adecuada a cada contexto.

El patrón híbrido más robusto: pasos deterministas en los extremos y ejecución agentic en el medio. Un ejemplo clásico es el workflow de reembolso: una API fija valida el pedido, el agente decide si corresponde reembolsar, y una segunda API fija ejecuta la operación. Este enfoque limita al agente a un conjunto explícito de herramientas y reduce el riesgo de acciones fuera de política.

n8n: cómo encajan MCP y API en una sola plataforma

n8n es una plataforma de orquestación de workflows source-available que ahora forma parte del stack de SAP. En septiembre de 2026, SAP anunció una inversión estratégica que valoró a n8n en US$5.200M, más del doble de los US$2.500M que tenía menos de un año antes, según Yahoo Finance y Pulse 2.0. El acuerdo incluye la integración nativa del canvas de n8n dentro de Joule Studio, el entorno de construcción de agentes de SAP Business AI Platform.

La plataforma reporta 1,7 millones de desarrolladores activos mensuales y más de 1.400 clientes empresariales, desde Fortune 500 hasta startups individuales. Opera bajo licencia fair code y permite automatizaciones con modelos como los de OpenAI, Anthropic o self-hosted, sin quedar atado a un proveedor.

Para conectar ambos mundos, n8n expone tres nodos relevantes:

HTTP Request node. Llama cualquier endpoint REST. Puedes pegar un curl de la documentación del vendor y el sistema completa los campos. Soporta autenticación básica, por headers y Google OAuth2, y maneja paginación para volúmenes grandes.
MCP Client Tool node. Se conecta a un MCP server externo y entrega a un AI Agent node el catálogo completo de herramientas, sin configuración por herramienta. Permite restringir allow/deny list.
MCP Server Trigger node. Publica un workflow propio como servidor MCP, exponiendo una URL que clientes externos pueden consumir. Soporta autenticación por bearer o headers y transporta sobre SSE o streamable HTTP.

Qué significa esto para tu startup

Si tu equipo está construyendo un agente de IA, la decisión no es MCP o API, sino cuántas llamadas agentic quieres permitir y qué capas gobernadas las custodian. La nueva especificación 2026-07-28 reduce la complejidad operativa del lado servidor, pero el caso del ciberataque documentado por Anthropic en noviembre de 2025 dejó en evidencia que el cuello de botella de seguridad ya no está en el modelo, sino en el servidor MCP que decide qué puede invocar.

Acciones concretas que puedes tomar esta semana:

Audita qué agentes están tocando datos productivos hoy. No solo los oficiales: incluye coding assistants, conectores browser, automatizaciones de workflow y cuentas personales de IA con acceso a sistemas de la empresa. El reporte 2026 de DTEX/Ponemon estima un costo anual promedio de US$19,5M por organización por incidentes internos vinculados a shadow AI.
Inserta una capa gobernada entre cada agente y cada fuente de datos. Un gateway que autentique, evalúe contra la misma política que aplicaría un humano, encripte en tránsito y deje un log reconstruible por un auditor. La etiqueta varía (governed MCP gateway, secure MCP server, policy-enforcement layer), pero el requisito no: ninguna operación llega a datos de producción sin pasar por un punto de control que no confíe ciegamente en el juicio del agente.
Define un dueño de negocio, uno técnico y uno de seguridad para cada agente en producción. El informe de TechRepublic lo plantea como punto de partida no negociable, junto con un proceso de apagado que el equipo sepa ejecutar antes del primer incidente.

Si todavía no estás en producción, el orden de adopción razonable es: API determinista para los pasos que conoces, MCP server propio para los pasos donde delegas al modelo, y HTTP Request + MCP Client Tool en n8n como camino más corto para prototipar esa arquitectura sin escribir un SDK a medida.