En pocas palabras: MCP no reemplaza a las API: las envuelve. Anthropic liberó el protocolo en noviembre de 2024 para que un modelo de IA lea el esquema de una herramienta y decida solo cuándo usarla, sin que un desarrollador mapee cada parámetro a mano como exige una API tradicional.
El Model Context Protocol (MCP) es un estándar abierto que Anthropic liberó en noviembre de 2024. Permite a un modelo de lenguaje leer la descripción de una herramienta externa (una API de reservas, una base de datos, un buscador de vuelos) y decidir por sí mismo cuándo y cómo usarla, sin que un programador tenga que mapear cada parámetro a mano como pasa con una API tradicional. La discusión API vs MCP no es sobre cuál gana, sino sobre qué problema resuelve cada uno.
En este artículo:
- En 30 segundos
- ¿Qué problema resuelve MCP que las APIs no resolvían?
- ¿Cómo funciona una API tradicional paso a paso?
- ¿Qué es el Model Context Protocol (MCP) de Anthropic?
- API vs MCP: ¿cuáles son las diferencias clave?
- ¿MCP reemplaza a las APIs?
- ¿Cómo se resuelve la misma tarea con API y con MCP?
- Ejemplo real de un servidor MCP en producción
- Errores comunes al elegir entre API y MCP
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- Anthropic abrió el código de MCP en noviembre de 2024, según la guía de dev.to que compara ambos enfoques.
- Con una API, el desarrollador traduce la intención del usuario a parámetros fijos; con MCP, la IA lee el esquema de la herramienta y decide sola.
- MCP no reemplaza las APIs, las envuelve: cada herramienta MCP sigue llamando a una API por debajo.
- RollingGo Hotel MCP, de Dida Holdings, conecta más de 200 millones de hoteles con autenticación OAuth 2.1 y capa gratuita permanente, según su documentación oficial.
- Si el usuario cambia de idea a mitad de la consulta, MCP ajusta el llamado a la herramienta sin tocar código; con una API tradicional, hay que reescribir.
¿Qué problema resuelve MCP que las APIs no resolvían?
Todo modelo de lenguaje queda congelado en la fecha de corte de su entrenamiento. Puede describirte un hotel lindo en París, pero no sabe la tarifa de esta noche ni si quedan habitaciones. Ese hueco entre lo que el modelo sabe y lo que pasa en tiempo real es el problema de fondo, y tanto las API como MCP existen para taparlo, según plantea la nota de dev.to que originó esta comparación.
¿Y por qué no alcanzaba con una API? Porque conectar un modelo a una API sigue exigiendo que un humano escriba el código puente cada vez que algo cambia.
Ese código puente es el desarrollador parado en el medio: interpreta lo que pide el usuario, lo convierte en parámetros exactos, llama al endpoint correcto y después traduce el JSON de vuelta a algo legible. Funciona, pero no escala cuando tenés que integrar diez sistemas distintos, cada uno con su propia forma de pedir las cosas.
¿Cómo funciona una API tradicional paso a paso?
Una API (Application Programming Interface) es la interfaz que permite que dos programas se hablen, con un desarrollador humano en el medio traduciendo la intención del usuario a parámetros exactos que el servidor espera recibir. Cubrimos ese tema en detalle en la comparativa entre Claude y Gemini 2.5.
Pensalo con la analogía del mozo de restaurante: vos leés la documentación como quien lee el menú, escribís el código que llama al endpoint como quien le pide al mozo, el servidor procesa la orden como la cocina, y la respuesta en JSON llega como el plato, listo para que vos mismo lo traduzcas en algo legible para el usuario final.
El problema es que cada plataforma tiene su propio menú. Booking usa nombres de parámetros distintos a los de Ctrip. Expedia ordena los campos distinto que Amadeus. Si querés buscar hoteles en tres plataformas a la vez, escribís tres integraciones separadas, cada una con su propio flujo de autenticación, sus propias reglas de límite de consultas, su propio formato de error y su propia forma de paginar resultados.
Ojo con esto: el LLM nunca ve la API directamente. El desarrollador sigue siendo el traductor. Si cambia un solo parámetro del lado del proveedor, hay que reescribir el código.
¿Qué es el Model Context Protocol (MCP) de Anthropic?
MCP es un protocolo abierto que Anthropic liberó en noviembre de 2024 para estandarizar cómo un modelo descubre y usa herramientas externas, en vez de depender de una integración a medida por cada sistema.
La analogía que mejor lo explica es la del USB-C. Antes cargábamos cada dispositivo con su cable propietario. MCP hace lo mismo que hizo el USB-C con los cargadores: un solo estándar de conexión, y el modelo descubre solo qué herramienta tiene enchufada.
El cambio es estructural. Con una API, el desarrollador lee la documentación, escribe código de conexión y define a mano el mapeo de parámetros. Con MCP, la herramienta se autodescribe: el modelo lee el esquema, entiende qué hace y la llama por su cuenta cuando la intención del usuario coincide. Sobre eso hablamos en el enfrentamiento entre Claude y GPT-4o.
API vs MCP: ¿cuáles son las diferencias clave?
La diferencia central es quién interpreta la intención del usuario. En la era API, el humano sirve a la máquina, traduciendo intención en código. En la era MCP, la máquina sirve al humano, entendiendo la intención y orquestando las herramientas sola.
| Dimensión | API tradicional | MCP |
|---|---|---|
| Quién interpreta la intención | El desarrollador | El modelo de IA |
| Qué ve el LLM | Nunca la API directamente | El esquema de la herramienta |
| Formato de integración | Código glue a medida | Config JSON declarativa |
| Si el usuario cambia de idea | Hay que reescribir código | El modelo ajusta el llamado |
| Escala a múltiples sistemas | Una integración por sistema | Un protocolo común |
¿MCP reemplaza a las APIs?
No. MCP no reemplaza a las APIs, las envuelve. Por debajo, cada herramienta MCP sigue llamando a una API real; lo que cambia es la superficie de integración.
Es la diferencia entre darle a alguien una caña con una carnada específica para pescar una sola especie (la API) y darle una caja de aparejos con compartimentos etiquetados donde esa persona elige sola la carnada correcta (MCP). El pez es el mismo. La experiencia de pescarlo, no.
En vez de N integraciones a medida que el equipo de desarrollo tiene que mantener, se obtiene un protocolo estandarizado que el modelo navega por su cuenta.
¿Cómo se resuelve la misma tarea con API y con MCP?
Con una API tradicional, la cadena es larga: usuario, desarrollador, código, API, servidor, JSON, desarrollador, usuario de nuevo. Con MCP, la cadena se acorta a usuario, IA, herramienta MCP, sistema real, dato en vivo, IA, usuario. Tema relacionado: cómo se posiciona GPT-5 frente a Claude.
Tomemos el ejemplo de la guía original: un usuario pide “un hotel cinco estrellas cerca del West Lake en Hangzhou, entrando pasado mañana, por menos de 1500 la noche”. Con una API, un desarrollador o product manager tiene que descomponer eso en parámetros estructurados (ciudad, punto de referencia, fecha, categoría, precio máximo), escribir el código que llama a la API del sistema hotelero según su documentación, recibir el JSON crudo y transformarlo en algo legible.
¿Y si el usuario cambia de idea y pide “que sea family-friendly”? Con API, se vuelve al paso de reanalizar parámetros y reescribir código. Con MCP, la IA llama de nuevo a la herramienta searchHotels con la intención original del usuario, la herramienta consulta el sistema hotelero real y devuelve tarifas y disponibilidad en vivo, sin que nadie toque una línea de código.
Ejemplo real de un servidor MCP en producción
RollingGo Hotel MCP, de Dida Holdings, es un servidor MCP de hotelería que ya está en producción y conecta más de 200 millones de hoteles en más de 100 países, según su propia documentación.
Dida Holdings se fundó en 2012 y trae 14 años de experiencia en distribución de viajes. Su CEO, Daryl Lee, lo resumió así: “Las conversaciones no generan ingresos. Las reservas sí”. RollingGo Hotel MCP está pensado para cerrar ese círculo, convirtiendo una recomendación de IA en una reserva real y confirmable.
Los números concretos, según esa misma documentación: más de 110.000 propiedades con contrato directo, más de 500 proveedores, herramientas como searchHotels, getHotelDetail, getHotelSearchTags, searchAirports y searchFlights, autenticación OAuth 2.1 sin necesidad de credenciales enterprise, capa gratuita con cuota permanente de llamados, y un setup que la guía original describe en menos de 5 minutos, solo con un archivo de configuración JSON, sin escribir código. Ya lo cubrimos antes en precios y benchmarks de Google contra Claude.
Errores comunes al elegir entre API y MCP
- Pensar que MCP elimina la necesidad de una API real. No es así: MCP es una capa sobre la API existente, no un sustituto. Si el sistema de origen no tiene API o no expone datos en vivo, ningún servidor MCP los va a inventar.
- Meter MCP en un caso de integración única. Si vas a conectar un solo sistema, una vez, con parámetros que no van a cambiar, una llamada directa a la API sigue siendo más simple que montar un servidor MCP entero.
- No revisar el esquema de la herramienta antes de dársela a un agente. Si el modelo llama herramientas por su cuenta, el esquema mal descrito o demasiado permisivo puede hacer que ejecute acciones que no correspondían.
- Confundir MCP con un simple wrapper de autenticación. El valor de MCP está en que el modelo entiende qué hace la herramienta y cuándo usarla, no solo en que haya un token de por medio.
Preguntas Frecuentes
¿Qué es MCP en términos simples?
MCP (Model Context Protocol) es un estándar abierto de Anthropic que deja que un modelo de IA lea la descripción de una herramienta externa y la use por su cuenta, en vez de depender de código de integración escrito a mano para cada sistema.
¿Cuándo conviene usar una API en vez de MCP?
Cuando la integración es puntual, con un solo sistema y parámetros estables, una llamada directa a la API sigue siendo la opción más simple. MCP suma valor cuando un mismo agente tiene que orquestar varias herramientas distintas según lo que pida el usuario en cada momento.
¿MCP es gratis o de pago?
–>¿MCP es gratis o de pago?
Depende del servidor MCP que uses, no del protocolo en sí (que es abierto y gratuito). RollingGo Hotel MCP, por ejemplo, ofrece una capa gratuita con cuota permanente de llamados y autenticación por OAuth 2.1.
¿MCP funciona solo con Claude o también con otros modelos?
MCP es un protocolo abierto, no una función cerrada de un solo modelo. Desde que Anthropic lo liberó en noviembre de 2024, otros clientes y modelos de IA fueron sumando soporte para el mismo estándar, en lugar de quedar atado a un único proveedor.
¿Qué limitaciones tiene MCP hoy?
MCP sigue dependiendo de que exista una API real detrás de cada herramienta, y de que esa herramienta esté bien descrita para que el modelo la use como corresponde. Un esquema mal escrito o demasiado abierto es tan riesgoso en MCP como una API mal documentada lo es en el modelo tradicional.
Conclusión
La discusión API vs MCP no termina en un ganador. Las API siguen siendo la base: MCP les agrega una capa donde el modelo entiende qué herramienta tiene disponible y la usa solo, sin que un desarrollador reescriba código cada vez que el usuario cambia de idea.
Si estás armando un agente que tiene que combinar varias herramientas según el contexto de la conversación, vale la pena probar MCP: la configuración es más corta que escribir la integración a mano. Si el caso es una conexión puntual a un solo sistema, la API directa sigue alcanzando.