API o MCP: cuándo usar cada uno

Las API REST exponen recursos. MCP expone capacidades a los agentes. Es el criterio más sencillo que he encontrado para decidir cuál usar.

Ambos pueden servir los mismos datos, pero están diseñados para consumidores distintos. Una API sirve a un programa que ya sabe lo que quiere. MCP sirve a un agente de IA que necesita decidir qué capacidad le ayuda a resolver la tarea del usuario.

Para qué sirve bien una API

Una API funciona mejor cuando el cliente conoce exactamente lo que necesita: el endpoint, los parámetros y qué hará con el resultado.

Por ejemplo:

• un panel que consulta /api/v1/products;
• un script que obtiene /api/v1/notes;
• un índice de búsqueda que lee /api/v1/projects;
• una aplicación móvil que solicita /api/v1/me;
• una tarea del servidor que sincroniza datos públicos estructurados.

En estos casos, REST suele bastar.

La petición es explícita:

GET /api/v1/projects?tag=ai&status=active

La respuesta es un JSON previsible y el cliente se ocupa del resto.

Para qué sirve bien MCP

MCP es útil cuando el cliente es un agente de IA.

El agente hace más que obtener un recurso conocido. Interpreta la petición del usuario, elige entre las herramientas disponibles, decide qué argumentos enviar y usa el resultado dentro de un proceso de razonamiento más amplio.

Por ejemplo:

• «Resume los productos activos de Orlando».
• «¿Qué proyectos muestran experiencia con backend y API?».
• «Encuentra notas sobre agentes de IA y conviértelas en un resumen para un reclutador».
• «¿Qué ha construido Orlando con TypeScript?».
• «Compara ResistGate y Amethyst como productos».

Son tareas expresadas en lenguaje natural. El usuario no especificó un endpoint, así que el agente necesita capacidades entre las que elegir. Ahí encaja MCP.

Un ejemplo real de mi sitio

Mi sitio personal ofrece ambos:

GET /api/v1/projects
POST /api/mcp

La API expone recursos:

/me
/projects
/products
/notes

El servidor MCP expone herramientas:

get_orlando_bio
get_projects
get_project
get_products
get_product
get_product_status
get_notes
get_note

Ambos pueden devolver los mismos datos, pero se consultan de formas muy distintas. Si un script quiere todas las notas, la API es más directa. Si un agente quiere responder una pregunta sobre mi trabajo, MCP le facilita elegir qué consultar.

Ventajas de una API

Una API encaja bien cuando necesitas:

• URL previsibles;
• caché sencilla;
• integración entre aplicaciones;
• acceso a datos públicos;
• contratos de respuesta estables;
• compatibilidad con herramientas existentes;
• depuración sencilla desde el navegador o la terminal.

También es más fácil documentarla para desarrolladores que no trabajan dentro de un entorno de agentes.

No todo necesita convertirse en una herramienta MCP.

Ventajas de MCP

MCP encaja bien cuando necesitas:

• herramientas seleccionadas por el modelo;
• flujos iniciados en lenguaje natural;
• argumentos estructurados elegidos por un agente;
• descripciones que expliquen la intención de cada herramienta;
• una interfaz compartida entre clientes de IA;
• acceso de los agentes a datos o acciones sin una integración específica para cada cliente.

La capacidad del modelo para decidir es lo que distingue este uso de MCP.

El modelo puede inspeccionar la lista de herramientas y decidir:

• cuál llamar;
• cuándo llamarla;
• qué argumentos pasar;
• cómo combinar los resultados.

Un cliente convencional, en cambio, llama a un endpoint que ya conoce.

Dónde aparece la confusión

Tanto las API como las herramientas MCP pueden devolver JSON. Eso hace que parezcan lo mismo. La diferencia está en quién decide qué operación ejecutar.

Con una API, el desarrollador decide:

Call /api/v1/products, parse the response, render a list.

Es decir: llama a /api/v1/products, interpreta la respuesta y muestra una lista.

Con MCP, el agente decide:

The user is asking about shipped products, so I should call get_products.

El modelo reconoce que el usuario pregunta por productos publicados y elige get_products.

Esa capa de decisión cambia el diseño. Las herramientas MCP necesitan descripciones, esquemas y límites que ayuden al modelo a elegir. Las API necesitan rutas de recursos, parámetros y contratos de respuesta que permitan integrar software de forma fiable.

Cuándo usaría una API

Usa una API cuando:

• conoces al cliente que la consumirá;
• el flujo de trabajo es previsible;
• la caché importa;
• distintos tipos de software deben poder consumir el resultado;
• el consumidor es un script, una aplicación, un índice de búsqueda, un panel o un servicio de backend.

En mi sitio personal, /api/v1 es la interfaz adecuada para los datos públicos estructurados. Es una solución sencilla y conocida, y eso me sirve.

Cuándo usaría MCP

Usa MCP cuando:

• el consumidor es un asistente o agente de IA;
• el usuario pide algo en lenguaje natural;
• el modelo necesita elegir la capacidad adecuada;
• la herramienta debe poder descubrirse desde clientes de agentes;
• el flujo se beneficia de nombres que describen el propósito de cada herramienta.

En mi sitio personal, /api/mcp es la interfaz adecuada para preguntas como:

Which of Orlando's projects best demonstrate AI product engineering?

La pregunta pide identificar qué proyectos demuestran mejor mi experiencia construyendo productos de IA. El agente debe resolver esa tarea, incluida la selección de los datos que necesita.

A menudo conviene ofrecer ambos

Para un sitio personal que los agentes puedan consultar, usaría ambos. La API aporta una interfaz estable para el software y el servidor MCP ofrece herramientas orientadas a la intención del usuario. Comparten la misma fuente de verdad, pero sirven a consumidores distintos.

Es el patrón por el que apostaría a largo plazo:

Website  →  for humans
API      →  for software
MCP      →  for AI agents

El sitio sirve a las personas, la API al software y MCP a los agentes de IA. Elige la interfaz según quién la vaya a leer.