MCP vs API: por qué el nuevo protocolo extiende las interfaces en lugar de reemplazarlas

A medida que MCP ganaba popularidad, un eslogan audaz comenzó a circular: las API ya no son necesarias. El video ancla esta pregunta en el comercio electrónico. Cuando un cliente abre la página de pedidos, la aplicación llama a una interfaz de pedidos y muestra el registro devuelto en pantalla. La pregunta es por qué nació MCP si esta configuración funciona.

El flujo de pago se lee como un resumen del modelo tradicional. La aplicación primero llama a una interfaz de pago, luego emite una actualización de inventario y finalmente llega a una interfaz de correo electrónico para el mensaje de confirmación. El desarrollador decide qué llamada ocurre, cuándo y en qué orden. Como el flujo está integrado en el código, llega predefinido y rígido.

El panorama se rompe en cuanto el usuario formula una frase en lugar de pulsar botones. El modelo puede comprender una solicitud como busca mi último pedido y envíame los detalles de seguimiento, pero no tiene ningún mapa de las interfaces disponibles. No puede decir cuál se ejecuta primero ni qué entradas espera cada una. Alimentar al modelo con toda la documentación de las interfaces no tiene sentido para nadie.

Dos conceptos se aclaran en este punto. Una herramienta es una acción única que una aplicación de IA puede realizar: buscar, redactar y enviar en el lado del correo, o consultar el historial y abrir registros en el lado del repositorio. Un servidor MCP es el programa que publica dichas capacidades a través del protocolo de contexto de modelo: herramientas portadoras de acciones junto a recursos portadores de información como archivos, documentos o registros.

De vuelta en el ejemplo del comercio electrónico, el panorama encaja en su sitio. Las interfaces de cliente, pedidos y correo permanecen exactamente donde están; nada se reemplaza. Un servidor MCP superpuesto sobre ellas ofrece tres herramientas: obtener el cliente, obtener el último pedido, enviar un correo. Cuando llega una solicitud, la aplicación se conecta al servidor y conoce el catálogo de herramientas, con cada entrada explicando su propósito y las entradas esperadas.

Al leer la solicitud, el modelo alinea las herramientas: primero el cliente, luego el último pedido, al final el correo. Tras el telón, cada herramienta llama a su interfaz correspondiente, recoge el resultado y lo devuelve a la aplicación. Los sistemas existentes siguen funcionando intactos. MCP presenta las capacidades actuales como herramientas aptas para la IA.

La distinción final forma la columna vertebral del artículo. Con las interfaces clásicas, los desarrolladores definen el flujo y lo congelan en el código; en el esquema MCP, los desarrolladores publican las capacidades como herramientas y el modelo elige. El descubrimiento difiere de la misma manera: los desarrolladores leen documentos y buscan endpoints, mientras que el servidor MCP difunde definiciones de herramientas estándar. Cuando mañana aparece una herramienta de cancelación de pedidos, la siguiente conexión simplemente la descubre.