MCP vs API REST: Cuando Usar Cada Uno en tus Proyectos de IA

TL;DR: MCP y las REST APIs no compiten — resuelven problemas distintos. Las REST APIs siguen siendo la respuesta correcta para comunicacion entre servicios. MCP es la respuesta correcta cuando el consumidor de tu API es un LLM. Este post te da el decision framework y los anti-patrones que mas cuestan tiempo en proyectos de IA.

El Error de Framing que Paraliza Proyectos

Cuando Model Context Protocol se popularizo a mediados de 2025, muchos desarrolladores lo enmarcaron como "la nueva API REST para IA". Ese framing causo meses de confusion sobre cuando usarlo y cuando no. Equipos que reescribieron APIs REST existentes como MCP servers perdieron semanas de trabajo. Otros que usaron REST APIs donde necesitaban MCP construyeron integraciones fragiles con 300 lineas de glue code.

La confusion tiene sentido: ambas tecnologias son protocolos que exponen operaciones sobre datos. Pero el consumidor es diferente, y eso cambia todo.

REST APIs: El consumidor es otro servicio o una aplicacion cliente que tiene logica programatica. El consumidor sabe exactamente que endpoint llamar, con que parametros, y como interpretar la respuesta.

MCP: El consumidor es un LLM. El modelo no sabe que herramientas existen hasta que las descubre. Elige cual usar segun la descripcion en lenguaje natural. No sigue un flujo hardcodeado — razona sobre que operaciones necesita ejecutar para responder al usuario.

Esa diferencia de consumidor determina todo lo demas: como documentar, como estructurar herramientas, como manejar errores, y como testear.

Tabla de Decision: MCP vs REST API

Cuando usar REST API (y no MCP)

Comunicacion servicio-a-servicio

Tu microservicio de pagos llama al microservicio de inventario. Ninguno involucra un LLM. REST API es la respuesta obvia — protocolo maduro, tooling excelente, comportamiento determinista.

Frontend que consume datos

Un componente React que hace fetch('/api/productos') no necesita MCP. El frontend sabe exactamente que pedir y como renderizarlo.

Webhooks y eventos

Notificaciones de pago, eventos de sistema, integraciones con terceros (Stripe, Mercado Pago, SAP). REST con firmas HMAC es el estandar y no hay razon para cambiarlo.

Cuando el flujo esta predefinido

Si el flujo de tu aplicacion es determinista — siempre pasos A, B, C — usa REST. MCP brilla cuando el LLM necesita decidir dinamicamente que hacer segun el contexto de la conversacion del usuario.

Cuando usar MCP (y no REST API)

Asistentes con acceso a sistemas internos

Tu empresa quiere que Claude pueda responder preguntas sobre el CRM, buscar en la base de clientes y crear tareas en el gestor de proyectos. Ese es exactamente el caso de uso de MCP — el patron de integracion empresarial documentado en detalle en ese post.

Herramientas de developer productivity

Querés que tu asistente de codigo pueda leer archivos del repo, buscar en documentacion interna, ejecutar queries de debug. MCP permite que Claude Code haga exactamente eso con los servers correctos.

Productos que quieren distribuirse via ecosistema de IA

Si construiste un SaaS y quieres que Claude te recomiende cuando alguien pregunta algo relacionado con tu dominio, un MCP server es la estrategia de distribucion correcta. El patron completo esta en como construir un MCP server que venda tu producto.

Cuando el usuario humano no deberia tener que saber que API llamar

Un agente de soporte que puede buscar tickets, escalar casos, y consultar el historial del cliente — el operador humano no deberia saber que endpoint llamar. El LLM razona sobre eso. MCP es el puente.

Anti-Patrones que Cuestan Semanas

Anti-patron 1: Reescribir REST APIs existentes como MCP

Si ya tienes una REST API funcionando con buenos consumidores, no la reescribas. Construye un MCP server que use tu REST API internamente. El MCP server es un thin adapter, no un reemplazo.

// MAL: Reescribir la API entera como MCP
// BIEN: El MCP server llama a tu API existente
 
class ProductosMCPServer {
  private api = new ProductosApiClient(process.env.PRODUCTOS_API_URL!);
 
  async buscarProducto(query: string) {
    // Tu API REST existente, intacta
    return this.api.get("/productos/buscar", { q: query });
  }
}

Anti-patron 2: Tools con nombres tecnicos sin descripcion util

El LLM elige herramientas basandose en las descriptions. Una herramienta mal documentada es una herramienta que el LLM no va a usar correctamente.

// MAL: Descripcion tecnica que el LLM no puede interpretar contextualmente
{
  name: "GET_PROD_BY_ID",
  description: "HTTP GET /api/v2/products/:id",
}
 
// BIEN: Descripcion que el LLM puede mapear al intento del usuario
{
  name: "obtener_producto",
  description: "Obtiene los detalles de un producto: nombre, precio, stock, descripcion y variantes disponibles. Usar cuando el usuario pregunta por un producto especifico.",
}

Anti-patron 3: Herramientas demasiado granulares o demasiado amplias

El sweet spot es 2-8 herramientas bien definidas. Menos de 2 y el server no tiene utilidad. Mas de 15 y el LLM se confunde en la seleccion.

Granularidad excesiva es crear una herramienta por endpoint de tu API. El LLM tendria que encadenar 5 llamadas para hacer algo que deberia ser 1.

Amplitud excesiva es crear una herramienta ejecutar_query que acepta SQL arbitrario. Maxima flexibilidad, minima seguridad y predictibilidad.

// MAL: Granularidad excesiva (13 herramientas para lo mismo)
"buscar_cliente_por_rut", "buscar_cliente_por_nombre",
"buscar_cliente_por_email", "buscar_cliente_por_telefono"...
 
// BIEN: Una herramienta con el parametro correcto
{
  name: "buscar_cliente",
  description: "Busca un cliente por cualquier identificador: RUT, nombre, email o telefono",
  inputSchema: {
    properties: {
      query: { type: "string", description: "RUT, nombre, email o telefono" }
    }
  }
}

Anti-patron 4: No manejar errores de forma informatica para el LLM

Cuando una herramienta falla, el LLM necesita saber por que para decidir si reintentar, usar otra herramienta, o reportarle al usuario. Un error generico bloquea al LLM.

// MAL: Error generico
throw new Error("Error en base de datos");
 
// BIEN: Error con contexto accionable
return {
  content: [{
    type: "text",
    text: JSON.stringify({
      error: "cliente_no_encontrado",
      query: query,
      suggestion: "Verifica el RUT (formato: 12.345.678-9) o prueba con el nombre completo"
    })
  }],
  isError: true,
};

Comparativa Tecnica: Implementar lo Mismo con Ambos Enfoques

Para hacer la diferencia concreta, comparemos implementar "consultar stock de un producto" con REST API vs MCP.

Con REST API

// endpoint
GET /api/v2/productos/:sku/stock
 
// respuesta
{ "sku": "PROD-001", "stock": 45, "warehouse": "Santiago" }
 
// el consumidor (frontend o servicio)
const response = await fetch(`/api/v2/productos/${sku}/stock`);
const { stock } = await response.json();

El consumidor sabe exactamente que SKU pedir porque el usuario hizo click en un producto especifico con SKU conocido.

Con MCP

// tool definition
{
  name: "consultar_stock",
  description: "Consulta el stock disponible de un producto. El usuario puede preguntar por nombre, SKU o descripcion parcial del producto.",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "Nombre, SKU o descripcion del producto. Ej: 'zapatos rojos talla 40', 'PROD-001', 'camisa lino'"
      }
    },
    required: ["query"]
  }
}
 
// el LLM usa esta herramienta cuando el usuario dice:
// "hay stock del modelo que compre el mes pasado?"
// "cuantas unidades quedan de los zapatos rojos?"
// "tengo stock para 50 unidades del PROD-001?"
// El LLM razona sobre cual de esas preguntas aplica a esta herramienta

La diferencia es el consumidor. El frontend sabe el SKU porque esta en la URL. El LLM no — tiene que resolver esa ambiguedad usando el contexto de la conversacion y posiblemente llamando primero a otra herramienta de busqueda.

Testing: Como Validar un MCP Server

El testing de MCP servers tiene dos dimensiones que no existen en REST APIs: la correctitud tecnica (la herramienta hace lo que dice) y la predictibilidad de seleccion (el LLM elige la herramienta correcta para cada consulta).

MCP Inspector para testing interactivo

npx @modelcontextprotocol/inspector node dist/server.js

El Inspector abre una UI donde puedes ejecutar herramientas manualmente, ver el schema completo y debuggear respuestas sin necesidad de un LLM real.

Evals de seleccion de herramientas

// test que valida que el LLM elige la herramienta correcta
const testCases = [
  {
    userMessage: "cual es el stock del producto A123?",
    expectedTool: "consultar_stock",
    expectedArgs: { query: "A123" }
  },
  {
    userMessage: "busca el cliente con RUT 12.345.678-9",
    expectedTool: "buscar_cliente",
    expectedArgs: { query: "12.345.678-9" }
  }
];
 
// ejecutar con el LLM real y comparar
for (const tc of testCases) {
  const response = await runWithTools(tc.userMessage, tools);
  assert(response.toolCalls[0].name === tc.expectedTool);
}

Los evals de LLM no son 100% deterministas, pero una suite de 20-30 casos representativos da confianza suficiente para ir a produccion.

Preguntas Frecuentes

Puede un mismo servidor exponer tanto REST API como MCP?

Si, y a veces es el patron correcto. Tu API REST existente sigue sirviendo a tus clientes programaticos. El MCP server es un layer adicional que usa esa API internamente y expone una interfaz optimizada para LLMs. No duplicas logica — el MCP server delega al REST API.

MCP tiene soporte para operaciones en streaming?

Si. El protocolo soporta respuestas parciales via SSE (Server-Sent Events), lo que es util para operaciones largas donde quieres que el LLM vea progreso. Para la mayoria de herramientas de consulta, respuesta completa es suficiente.

Como manejar autenticacion del usuario final en el MCP server?

El patron es pasar el contexto de autenticacion desde la aplicacion cliente hasta el MCP server. Si el usuario esta autenticado en tu app, el token de sesion se puede propagar como header en las llamadas al MCP server, que lo usa para hacer llamadas autenticadas a tus APIs internas. Nunca hardcodear credenciales en el server — usar variables de entorno o un secrets manager.

GraphQL sigue siendo relevante en el contexto de MCP?

Si, para lo que siempre fue relevante: APIs que tienen multiples consumidores con necesidades de datos distintas. Un MCP server puede hacer queries GraphQL internamente igual que hace REST. La eleccion de GraphQL vs REST para tu backend no cambia con MCP.

Cual es el overhead de latencia de MCP vs llamada REST directa?

El overhead del protocolo MCP en si es minimo (2-5ms). La latencia real esta en la llamada al LLM para decidir que herramienta usar, que puede ser 500ms-2s dependiendo del modelo. Para flujos donde la latencia es critica y el flujo es determinista, REST directo sigue siendo mas rapido. MCP es para casos donde la flexibilidad de razonamiento del LLM vale el tiempo adicional.

Recursos relacionados:

• MCP para integraciones empresariales: conecta CRM y ERP a IA
• Como construir un MCP server que venda tu producto
• Agentes de IA para empresas chilenas: casos reales 2026