MCP vs. API: no es una pelea, es una capa nueva

El canal Google Cloud Tech publicó un video corto con un título provocador: MCP vs API: Why traditional APIs are failing AI agents. Lo vimos en el equipo y nos sirvió para ordenar una idea que usamos todos los días: el problema de conectar un agente con el mundo no se resuelve con una ventana de contexto más grande, sino con mejores protocolos.

Acá van nuestras notas, con algunos comentarios desde lo que vemos en Nerdlabs.

APIs para programas

Durante décadas, una API fue un contrato entre dos programas: un endpoint, un request con un formato fijo (casi siempre JSON) y una respuesta predecible. Funciona muy bien porque los dos lados saben de antemano qué esperar. El desarrollador lee la documentación, arma el payload y listo.

Un modelo de lenguaje no trabaja así. No llama a un endpoint aislado: encadena varios, interpreta datos sucios, decide sobre la marcha y a veces necesita preguntar algo antes de seguir. El video lo compara con un armario cerrado con llave: la API supone que sabés exactamente qué cajón abrir y qué llave usar, y el modelo llega sin etiquetas ni manual.

¿Cómo se resolvía hasta ahora? A mano. Prompts larguísimos del estilo "cuando quieras crear un ticket en Jira, llamá a este endpoint con estos campos", código de integración a medida para cada servicio, y repetirle al modelo las mismas instrucciones una y otra vez.

Qué cambia con MCP

El Model Context Protocol invierte el supuesto. En lugar de enseñarle al modelo cada endpoint, cada herramienta se describe a sí misma: qué hace, qué entradas necesita y qué devuelve, todo en un formato estándar y legible por máquina.

El ejemplo del video es bien concreto: un agente que gestiona tickets de soporte y necesita Gmail, Notion y Jira.

Con APIs: tres integraciones a medida, cada una con su autenticación, paginación, manejo de errores y rate limits, y además un prompt que le explique al modelo cómo usar cada una.
Con MCP: cada servicio expone un servidor MCP. El agente descubre las herramientas al conectarse, lee sus esquemas y decide cuál usar y cuándo.

La diferencia de fondo: una API es un contrato a nivel de código entre dos aplicaciones, mientras que MCP es un protocolo semántico entre un modelo y su entorno. La lógica de qué llamar y cuándo, que antes vivía en el código de tu app, pasa a la capa de razonamiento del modelo.

Cómo funciona por dentro

Un servidor MCP es un proceso liviano que se ubica al lado de un servicio o de una fuente de datos y publica un catálogo de lo que ofrece, con sus esquemas JSON. El cliente se conecta, recibe ese catálogo y a partir de ahí el modelo puede invocar herramientas sin adivinar: sabe qué campos son obligatorios, qué significa cada uno y qué tipo de respuesta va a recibir.

Nota técnica: el video menciona WebSocket o HTTP como transporte. En la práctica, la especificación define stdio (para servidores locales) y Streamable HTTP (para remotos), con mensajes JSON-RPC 2.0.

El resultado es lo que algunos llaman la capa plug-and-play de la IA: en vez de construir cien integraciones a medida, construís una interfaz MCP y la puede usar cualquier modelo compatible.

MCP sobre APIs

Este es, para nosotros, el punto más importante del video. Las APIs no van a desaparecer. Siguen siendo la base sobre la que funcionan tus sistemas. Lo que MCP reemplaza es el middleware entre el modelo y la API: el servidor MCP funciona como un traductor que convierte tus APIs existentes en algo que el modelo entiende sin ayuda.

Por eso conviene hablar de MCP sobre APIs y no de MCP contra APIs. Lo que cambia es quién es el cliente: con una API, del otro lado hay un programa o una persona; con MCP, el cliente es el modelo.

Esa diferencia, que parece menor, cambia cómo diseñamos integraciones. Pasamos de construir sistemas para humanos y para código a construir sistemas para modelos, y los modelos no consumen endpoints REST: consumen contexto, es decir, descripciones, esquemas y ejemplos que les permiten razonar, planificar y actuar.

No todo es magia

El video también marca los desafíos, y coincidimos con los tres:

Adopción. Un estándar sirve si todos lo usan. Servidores, clientes y herramientas tienen que hablar el mismo idioma. Hoy el ecosistema crece rápido, pero todavía hay mucho por construir.
Seguridad y control. Si un modelo puede ejecutar herramientas directamente, hacen falta permisos claros. Nadie quiere un agente que mande un mail por error, borre un archivo o toque una base de datos sin autorización. La especificación ya contempla capacidades, scopes y autenticación, y los hosts piden consentimiento explícito antes de ejecutar acciones sensibles. Aun así, el diseño de esos límites sigue siendo responsabilidad de quien construye.
El cambio de mentalidad. La mayoría aprendimos a pensar en endpoints y rutas. MCP pide pensar en capacidades y contexto: diseñar sistemas que describan qué pueden hacer, no solo cómo se hace.

El paralelo con HTTP

La analogía con la que cierra el video es buena. Antes de la web, cada servicio tenía su protocolo: FTP, Gopher, Telnet. Cuando todo convergió en HTTP, de golpe todo pasó a ser interoperable. MCP busca lo mismo para los agentes: en lugar de que cada empresa invente su propio formato de plugins, un protocolo abierto que entienda cualquier modelo. Construís el conector una vez y lo usan Gemini, Claude, GPT o el que venga.

La síntesis que nos llevamos:

Las APIs se hicieron para sistemas deterministas: un programa le pide datos a otro.
MCP se hizo para sistemas probabilísticos: un modelo que razona sobre lo que puede hacer.

MCP vive una capa por encima de las APIs y convierte rutas estáticas en interfaces sobre las que un modelo puede razonar.

Cómo lo aplicamos

Esto no es teoría para nosotros. Nuestros agentes trabajan con herramientas expuestas por MCP y, cuando armamos integraciones para clientes, la primera pregunta ya no es "¿qué endpoints necesitamos?", sino "¿qué capacidades queremos que el agente pueda descubrir y con qué permisos?".

Si estás pensando en conectar tus sistemas a un agente de IA, escribinos. Y si querés el video original, acá está: MCP vs API: Why traditional APIs are failing AI agents, de Google Cloud Tech.

Este artículo es un resumen y comentario propio del video citado. Las ideas y los ejemplos originales pertenecen a sus autores.