MCP y las API suelen tratarse como rivales, pero operan en capas distintas de un conjunto de herramientas de IA. Este artículo muestra cómo funciona cada una, en qué se diferencian al listar herramientas, en el manejo del estado y en la seguridad, ejecuta la misma tarea de imagen de las dos formas y termina con una lista breve para elegir.
El trimestre pasado creaste una integración con una API REST y funciona bien. Entonces un compañero dice que el asistente debería "simplemente usar MCP", y ahora la misma tarea tiene dos nombres y dos bandos de personas muy convencidas. La versión corta es esta: una API es una puerta de entrada a un servicio, y MCP es una forma estándar de que un modelo de IA encuentre esa puerta, lea el cartel y la atraviese sin cableado a medida. Las dos no son rivales. En la mayoría de los entornos reales, una se apoya directamente sobre la otra.
Este artículo explica la diferencia en términos sencillos, ejecuta la misma tarea de las dos formas con endpoints y herramientas reales de Picasso IA y termina con una lista breve que puedes aplicar en dos minutos. Si desarrollas software que llama a servicios, creas agentes o conectas un asistente a tu propio producto, la elección entre una y otra aparecerá antes de lo que crees.
El problema que MCP quiere eliminar es fácil de imaginar. Cada aplicación de IA tiene su propia forma de llamar a herramientas, y cada servicio tiene su propia API, así que cada combinación se convierte en un trabajo a medida. Es el armario de cables de abajo: funciona, hasta que alguien tiene que cambiarlo.
Una API (interfaz de programación de aplicaciones) es un contrato entre dos programas. Uno envía una petición con una forma acordada y el otro devuelve una respuesta con una forma acordada. En la web, eso casi siempre significa HTTP y JSON: llamas a una URL, adjuntas un token secreto en una cabecera, envías un cuerpo y lees lo que vuelve.
Cada llamada sigue el mismo ritmo. Tu código construye la petición, el servidor hace el trabajo y el servidor responde. Nada en ese contrato le dice al que llama qué más puede hacer el servidor. Eso se averigua leyendo documentación escrita para personas y luego escribiendo código que encaje con ella.
Piensa en la barra de una cocina de restaurante. El ticket de la comanda tiene un formato fijo, el plato sale siempre por la misma ventanilla y el camarero ya conoce la carta porque alguien le entregó una copia impresa. Esa carta impresa es tu documentación de la API. El camarero, que es tu código, se la aprendió de antemano.
Muchos servicios de imagen y video añaden un paso más. Funcionan de forma asíncrona: creas una tarea, recibes un ID de inmediato y consultas repetidamente hasta que el resultado está listo. La API de Picasso IA funciona exactamente así: creas una predicción, la consultas y obtienes el resultado.
Las API se han ganado su lugar por buenas razones:
💡 Cuando quien llama es un programa que escribiste y los pasos nunca cambian, una API es todo lo que necesitas. Añadir otra capa solo suma más partes que pueden fallar.
MCP son las siglas de Model Context Protocol (protocolo de contexto para modelos). Anthropic lo presentó a finales de 2024 como un estándar abierto, y desde entonces otros grandes proveedores de IA lo han adoptado. Su función es acotada: definir una forma común para que una aplicación de IA hable con herramientas y datos externos, de modo que nadie tenga que escribir un conector a medida para cada combinación de modelo y servicio.
Imagina un adaptador universal de viaje. Sin él, cada aparato necesita su propio enchufe para cada país. Con él, hay un único estándar de tu lado, un único estándar en la pared y todo se carga. MCP cumple ese papel entre las aplicaciones de IA y los servicios. Las cuentas explican por qué se extendió: cinco aplicaciones de IA y diez servicios podrían necesitar hasta cincuenta integraciones a medida, mientras que un protocolo compartido exige que cada lado lo implemente una vez, lo que suma quince piezas de trabajo.
MCP define tres roles:
Los mensajes viajan como JSON-RPC 2.0. Una sesión se abre con un initialize handshake en el que ambos lados declaran lo que soportan, y por eso MCP es con estado, mientras que una llamada REST típica no lo es.
Un servidor puede ofrecer tres tipos de cosas:
| Primitiva | Qué es | Quién la activa | Ejemplo |
|---|---|---|---|
| Herramientas | Acciones que el modelo puede llamar | El modelo | Generar una imagen |
| Recursos | Datos de solo lectura que la app puede cargar | La app o el usuario | Una lista de generaciones anteriores |
| Prompts | Plantillas reutilizables | El usuario | Una plantilla de prompt para fotos de producto |
Las herramientas son las que más atención reciben, y son la parte que importa para esta comparación.
Esta es la función que realmente separa MCP de una API normal: el cliente puede preguntarle al servidor qué ofrece. Una petición tools/list devuelve todas las herramientas con un nombre, una descripción en lenguaje sencillo y un JSON Schema para sus entradas. El modelo lee esas descripciones y decide qué herramienta encaja con la petición.
Funciona como abrir el catálogo de fichas en lugar de memorizar las estanterías. Si mañana el servidor añade una herramienta, el modelo la verá en la siguiente sesión y el cliente no necesita cambios en el código. Con una API normal, un endpoint nuevo significa que alguien lee el changelog, edita el código y publica una versión.
| Aspecto | API tradicional | MCP |
|---|---|---|
| Quién hace la llamada principal | El código de un desarrollador | Un modelo de IA a través de una app host |
| Contrato escrito para | Personas y generadores de SDK | Modelos y apps host |
| Cómo descubrir capacidades | Leer la documentación y escribir código | Preguntar al servidor con tools/list |
| Protocolo | El que haya elegido el servicio (REST, GraphQL, gRPC) | Un estándar, JSON-RPC 2.0 |
| Estado | Normalmente sin estado | Sesión con estado tras un handshake |
| Cuando cambia el servidor | Hay que actualizar el código del cliente | El cliente ve las nuevas herramientas en la siguiente sesión |
| Quién decide la siguiente llamada | Tu código | El modelo, con aprobación humana opcional |
| Mejor opción | Backends, trabajos por lotes, apps móviles y web | Asistentes, agentes y editores con muchas herramientas |
Tres cosas las separan: quién decide, cómo se describen las capacidades y dónde vive el estado. Con una API, tu código decide cada paso. Con MCP, un modelo decide en tiempo de ejecución a partir de las descripciones de herramientas que recibe. Eso hace a MCP flexible, pero también menos predecible, algo que importa cuando una ejecución tiene que dar siempre el mismo resultado.
El modelo que toma esas decisiones es un modelo de lenguaje de gran tamaño, por ejemplo Claude Sonnet 5 o GPT 5.6 Sol, ambos disponibles en Picasso IA. Los modelos más avanzados eligen la herramienta correcta con más frecuencia, pero siguen leyendo descripciones, así que las descripciones vagas provocan llamadas erróneas.
La mayoría de los servidores MCP son envoltorios ligeros alrededor de una API. El servidor convierte el tools/call de un modelo en una petición HTTP normal, espera la respuesta y se la devuelve. Por eso la pregunta real rara vez es "MCP o API". Es "¿quién llama: mi código o un modelo?"
💡 Regla general: si puedes escribir de antemano la secuencia exacta de llamadas, usa la API. Si la secuencia depende de lo que decida el modelo a mitad de una conversación, usa MCP.
Los dos ejemplos hacen lo mismo: generar una foto de 16:9 a partir de un prompt de texto en Picasso IA.
La URL base es https://api.picassoia.com/v1, y cada petición lleva un token Bearer que empieza por pia_sk_. Los endpoints siguen el estilo de Replicate: creas una predicción y luego la consultas.
curl -X POST https://api.picassoia.com/v1/models/picassoia/picassoia-image/predictions \
-H "Authorization: Bearer $PICASSOIA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"input": {"prompt": "Photo of a hotel concierge handing a city map to a guest, 50mm, soft window light", "aspect_ratio": "16:9"}}'
La respuesta incluye un ID de predicción. Tu código llama entonces a GET /v1/predictions/{id} cada cierto tiempo hasta que la tarea termina y lee la URL de salida. Tú controlas la URL, las cabeceras, el bucle de consultas, los reintentos y los tiempos de espera. Ese es el precio del control total, y para un lote nocturno es exactamente lo que quieres.
Un host con el conector de Picasso IA se salta toda esa fontanería. Tras el handshake pide tools/list, y el servidor responde con herramientas para generar imágenes, editarlas, crear video y comprobar estados. Cuando una persona escribe "hazme una foto de 16:9 de un conserje de hotel", el modelo elige generate_image y el cliente envía:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "generate_image",
"arguments": {
"prompt": "Photo of a hotel concierge handing a city map to a guest, 50mm, soft window light",
"aspect_ratio": "16:9"
}
}
}
El servidor responde con un ID y una indicación de cuándo volver a comprobar. Después, el modelo llama a get_generation con ese ID hasta que el estado figura como succeeded. Nadie escribió un bucle de consultas: las descripciones de las herramientas le dijeron al modelo cómo comportarse.
El conector de Picasso IA lista herramientas como generate_image, edit_image, generate_video_picassoia, generate_video_seedance, get_generation, list_generations, cancel_generation, list_models y get_account. Cada una llega con una descripción y un esquema de entrada. Así un modelo puede encadenarlas sin que un desarrollador programe el orden: crear un borrador de imagen, revisar el resultado, pedir una edición y luego animar la ganadora.
Las dos vías llegan al mismo servicio. La correcta depende de quién camina.
La imagen mental adecuada es la de un conserje de hotel. El huésped dice lo que quiere en lenguaje sencillo, y el conserje, que conoce todos los servicios del edificio, elige el correcto. Ese es el modo MCP: la intención entra y la elección de herramienta se resuelve por ti.
La mayoría de los entornos maduros usan las dos. El servidor MCP llama a la API por debajo, y un script nocturno accede a esa misma API directamente. Un backend, dos puertas de entrada. Un diseñador pide a un asistente tres opciones de imagen principal a través de MCP, elige una, y más tarde una tarea programada redimensiona la ganadora en doce formatos a través de la API.
Un camino práctico: empieza por la API, porque es más sencilla de probar y la necesitarás de todos modos. Cuando un asistente tenga que usar la misma función, envuelve las llamadas en un servidor MCP y da a cada herramienta una descripción breve y concreta con ejemplos de entrada. Omite ese envoltorio si nadie más que tu propio código va a llamar nunca al servicio. Una herramienta que ningún modelo usará jamás es solo superficie extra que mantener.
Antes de construir nada, repasa esta lista:
Las dos vías necesitan autenticación, pero esta vive en lugares distintos. Una llamada a la API lleva un token Bearer en la cabecera de cada petición. Los tokens de Picasso IA empiezan por pia_sk_, y una cuenta puede tener dos como máximo. Con MCP, el host mantiene la conexión abierta, y los servidores remotos suelen autenticarse una vez por sesión mediante un flujo de tipo OAuth.
Dos hábitos te protegen en cualquiera de las dos vías:
MCP no elimina los límites, porque las dos vías terminan en el mismo backend. Picasso IA aplica estos límites en sus conexiones de API y MCP:
| Límite | Valor |
|---|---|
| Predicciones simultáneas | 5 por cuenta, compartidas entre tokens y conexiones MCP |
| Cuerpo de la petición | 10 MB |
| Longitud del prompt | 4000 caracteres |
| Tiempo límite de la tarea | 3 horas |
Cinco agentes en MCP más un script nocturno de API comparten las mismas cinco plazas. Planifícalo antes de lanzar un lote.
Hay otro costo que se pasa por alto con facilidad. MCP mete los nombres, las descripciones y los esquemas de las herramientas en la ventana de contexto del modelo, así que un servidor con decenas de herramientas consume tokens antes de que el usuario diga nada. Mantén pocos servidores conectados y bien enfocados. Para conocer las condiciones de acceso actuales a la API y a las conexiones MCP, consulta la página de precios de Picasso IA, porque los planes cambian.
PicassoIA Image es un modelo de texto a imagen que funciona a través de la web, la API y el conector MCP. Esta es la ruta más rápida de cero a una imagen terminada.
curl de antes.Consejos de parámetros para PicassoIA Image:
aspect_ratio acepta siete valores: 1:1, 16:9, 9:16, 4:3, 3:4, 3:2 y 2:3. Usa 16:9 para cabeceras de blog y 9:16 para historias.seed fija un resultado. Reutiliza el mismo prompt y la misma semilla para reproducir una imagen exactamente.num_outputs acepta 1 o 2, así que puedes comparar dos variaciones en una sola llamada.output_format admite jpg, png y webp, y output_quality (de 0 a 100) se aplica a jpg y webp.💡 Las dos vías usan los mismos cuatro modelos y las mismas cinco plazas simultáneas. Construye primero un prompt en el navegador y luego pásalo al código o a un asistente.
La forma más rápida de notar la diferencia es ejecutar el mismo prompt dos veces. Genera una imagen en la web, envía el mismo prompt desde un script corto a través de la API y luego pide a un asistente con el conector activado que la haga por ti. Fíjate en lo que controlas en cada versión y en lo que cedes.
Abre Picasso IA, empieza con PicassoIA Image y convierte tu mejor resultado en un clip corto con PicassoIA Video. Cambia la relación de aspecto, fija una semilla, prueba un segundo prompt y mira qué vía encaja con tu forma de trabajar. Los modelos están a un clic, y cada experimento te enseñará más sobre MCP y las API que cualquier tabla comparativa.
Elige tu idioma
