API y MCP: qué cambia cuando tu sistema habla con un agente de IA

El problema que aparece cuando conectas un agente a tus sistemas

Imagina que tienes un agente de IA que debería poder consultar el inventario de tu empresa, crear órdenes de compra y notificar al equipo de logística. Tienes APIs para todo eso — llevan años funcionando. La pregunta natural es: ¿el agente simplemente las llama?

En teoría, sí. En la práctica, hay un problema: una API fue diseñada para que un sistema determinado la llame de una manera determinada. Un agente de IA no es un sistema determinado. Es un sistema que decide, en tiempo de ejecución, qué necesita hacer y cómo hacerlo. Y esa diferencia cambia todo.

Ahí es donde entra MCP — y entender qué resuelve (y qué no) es lo que separa una decisión de arquitectura informada de una decisión tomada por hype.

---

Qué es una API y qué problema resuelve

Una API (Application Programming Interface) es un contrato entre dos sistemas: uno expone funciones, el otro las llama siguiendo las reglas definidas. El ejemplo más común es una REST API: un sistema hace una solicitud HTTP a una URL específica con parámetros específicos, y recibe una respuesta en un formato predefinido.

La analogía más directa: una API es como el menú de un restaurante. Dice exactamente qué podés pedir, en qué formato y qué vas a recibir. El cocinero no negocia — ejecuta lo que está en el menú.

Eso funciona perfectamente cuando quien hace el pedido es otro sistema que ya sabe de memoria qué quiere pedir. Un frontend que consulta el estado de un pedido, un sistema de pagos que confirma una transacción, un servicio que actualiza un registro — todos saben exactamente qué endpoint llamar y con qué parámetros.

El problema aparece cuando quien hace el pedido es un agente de IA que está resolviendo un objetivo en tiempo real y no sabe de antemano qué va a necesitar.

---

Qué es MCP y qué agrega

MCP (Model Context Protocol) es un protocolo abierto, desarrollado por Anthropic, que define cómo un modelo de lenguaje puede descubrir y usar herramientas externas de forma estandarizada. No reemplaza a las APIs — se apoya en ellas. Lo que agrega es una capa de descripción que permite al agente entender qué herramientas tiene disponibles, qué hace cada una y cuándo tiene sentido usarlas.

Si una API es el menú del restaurante, MCP es el mozo que te explica cada plato, te dice cuáles tienen gluten, te sugiere combinaciones y te avisa si algo no está disponible hoy. El cocinero sigue siendo el mismo — pero ahora el comensal puede tomar decisiones informadas sin saber el menú de memoria.

En términos técnicos: un servidor MCP expone un conjunto de herramientas con descripciones en lenguaje natural. El agente consulta esas descripciones, decide cuál usar según el contexto de la tarea que está ejecutando, y llama a la herramienta con los parámetros correctos. Todo eso ocurre de forma dinámica, sin que nadie haya programado de antemano la secuencia exacta de llamadas.

// Ejemplo simplificado: cómo un servidor MCP expone una herramienta
// El agente recibe esta descripción y decide cuándo y cómo usarla

const tool = {
  name: "consultar_inventario",
  description: "Devuelve el stock disponible de un producto dado su SKU. Usar cuando el usuario pregunte por disponibilidad o antes de crear una orden de compra.",
  inputSchema: {
    type: "object",
    properties: {
      sku: {
        type: "string",
        description: "Código único del producto"
      }
    },
    required: ["sku"]
  }
};

Esa descripción no es para un desarrollador — es para el modelo. El agente la lee, entiende cuándo aplica y la invoca cuando lo necesita.

---

La diferencia que importa en la práctica

La distinción no es filosófica. Tiene consecuencias concretas en cómo se construye y mantiene la integración.

Esto no significa que MCP sea mejor que una API en términos absolutos. Significa que son herramientas para contextos distintos. Una API es la solución correcta cuando el sistema que llama es determinista y conoce de antemano lo que necesita. MCP es la solución correcta cuando quien llama es un agente que razona sobre qué hacer.

Usar una API clásica para conectar un agente a tus sistemas es técnicamente posible — pero requiere que alguien programe de antemano todas las secuencias de llamadas posibles. Eso convierte al agente en un flujo de automatización glorificado: puede parecer inteligente, pero en realidad está siguiendo un guión que alguien escribió.

---

Un caso concreto: el mismo sistema, dos enfoques

Supongamos que querés que un agente pueda responder preguntas sobre el estado de los clientes de tu empresa: contratos activos, facturas pendientes, historial de soporte.

Con APIs clásicas: alguien tiene que programar la lógica que decide cuándo llamar a /clientes/{id}, cuándo llamar a /facturas?cliente={id}&estado=pendiente y cuándo llamar a /tickets?cliente={id}. Si el agente necesita combinar esa información de una forma que nadie anticipó, no puede — no tiene esa lógica.

Con MCP: el servidor MCP expone tres herramientas con descripciones claras. El agente lee las descripciones, entiende qué devuelve cada una y decide, según la pregunta concreta del usuario, cuáles llamar y en qué orden. Si alguien pregunta algo que requiere combinar las tres, el agente lo resuelve sin que nadie haya programado esa combinación específica.

La diferencia no está en los datos ni en los sistemas de fondo — está en quién tiene la lógica de orquestación. Con APIs clásicas, esa lógica vive en el código. Con MCP, vive en el agente.

---

Lo que esto no resuelve

MCP no es una solución mágica. Hay cosas que no cambian:

• La calidad de los datos sigue siendo tu problema. Si tu API de inventario devuelve datos inconsistentes, el agente va a tomar decisiones basadas en datos inconsistentes. MCP no limpia datos.
• La seguridad requiere diseño explícito. Un servidor MCP que expone herramientas sensibles sin control de acceso es un riesgo. El protocolo no resuelve autenticación ni autorización por defecto.
• Las descripciones importan tanto como el código. Si la descripción de una herramienta es ambigua o incorrecta, el agente la va a usar mal. Escribir buenas descripciones es una habilidad que no es obvia.

MCP desplaza complejidad — no la elimina. La saca del código de orquestación y la pone en las descripciones y en el diseño del servidor. Eso puede ser una mejora significativa, pero requiere criterio para hacerlo bien.

---

Qué hacer ahora

• Si estás evaluando conectar un agente de IA a sistemas internos, preguntá primero si el agente necesita decidir dinámicamente qué llamar o si siempre va a seguir el mismo flujo. Si es lo segundo, una API clásica bien documentada puede ser suficiente y más simple.
• Si ya tenés APIs internas, no las tires. Un servidor MCP puede envolverlas y exponerlas con descripciones para agentes sin tocar la lógica existente. La migración no tiene que ser disruptiva.
• Antes de implementar cualquier integración con agentes, documentá qué herramientas necesita el agente y qué debería entender de cada una. Ese ejercicio — independientemente de si usás MCP o no — va a revelar ambigüedades en tus propios sistemas que conviene resolver antes de que las resuelva mal un modelo de lenguaje.