MCP vs API para agentes de IA

La idea errónea

La frase MCP vs API sugiere un reemplazo, y el protocolo invita a la lectura porque se parece a una API: un endpoint HTTPS, JSON, una lista de operaciones llamables. Por debajo, es JSON-RPC 2.0 sobre HTTP Streamable, lo que significa que es una API HTTP con una forma de mensaje fija. Lo que estandariza no es cómo acceder a un sistema, sino cómo una aplicación de IA pregunta a un sistema qué puede hacer, cómo llama a esas cosas con un modelo eligiendo los argumentos, cómo se devuelven los errores para que el modelo pueda autocorregirse y cómo se autoriza a la persona detrás del modelo. Una API REST no estandariza nada de eso, porque nunca lo necesitó: sus llamadores eran programas cuyos autores leyeron la documentación una vez.

Cada servidor MCP serio para un sistema empresarial es una capa sobre la capa de servicio o API existente de ese sistema. Por lo tanto, la pregunta no es cuál construir, ya que necesitas la API de cualquier manera, sino cuál entregar a un agente.

Lo que una API le da a un agente y lo que no le da

Dale a un modelo una API REST y puede usarla, con ayuda. La ayuda es el problema. Alguien tiene que convertir los endpoints en definiciones de funciones que el modelo pueda ver, en el formato que el proveedor del modelo espera; los formatos de llamada a funciones de Claude y OpenAI son similares pero no idénticos. Alguien tiene que escribir el bucle que toma la función elegida por el modelo, llama al endpoint con las credenciales correctas y alimenta la respuesta de vuelta. Alguien tiene que decidir cómo los errores llegan al modelo, porque un 422 con un cuerpo de validación no es algo que un modelo lea bien a menos que se convierta. Y alguien tiene que resolver la autorización, porque una clave API en el entorno del agente hace que cada acción parezca la misma cuenta de servicio, no la persona que pregunta.

Nada de eso es difícil para un sistema y un agente, por lo que era el estado del arte antes del protocolo. Escala mal. Cada emparejamiento de un producto de agente y un sistema empresarial es a medida, las definiciones se desvían de la API, y no hay forma de que un usuario de Claude o ChatGPT conecte un sistema por sí mismo. La API sigue siendo excelente en lo que fue diseñada: llamadas de alto volumen, de programa a programa, operaciones masivas, webhooks e integraciones donde la lógica es fija y el llamador es código.

Lo que añade MCP

El protocolo responde a cada una de esas brechas con una regla que cada cliente implementa una vez. Descubrimiento: tools/list devuelve las herramientas con nombres, descripciones y esquemas JSON en tiempo de ejecución, por lo que el producto del agente no necesita conocimiento previo y la lista puede cambiar a medida que se instalan aplicaciones o cambian roles. Invocación: tools/call lleva un nombre y argumentos; el resultado lleva contenido que el modelo lee, contenido estructurado opcional y un isError indicador que le dice al modelo que corrija y reintente en lugar de rendirse. Autorización: OAuth 2.1 con el token vinculado al servidor y a la persona, por lo que la lista de herramientas y cada llamada pueden estar limitadas a quien está preguntando. Consentimiento: las anotaciones permiten a un servidor decir que una herramienta es de solo lectura, destructiva o idempotente, y los clientes las utilizan para decidir cuándo confirmar; un servidor también puede devolver un resultado que requiere entrada para hacerle una pregunta a la persona en medio de la llamada. Aquí hay una llamada y su respuesta, a medida que un cliente las envía y recibe.

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "recordPayment",
    "arguments": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "amount": 4850,
      "payment_date": "2026-09-18",
      "payment_reference": "BACS 41877"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 12,
  "result": {
    "content": [
      { "type": "text", "text": "Payment recorded against INV-1057. Amount paid 4850.00 of 4850.00; status is now paid." }
    ],
    "structuredContent": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "number": "INV-1057",
      "amount_paid": 4850,
      "status": "paid"
    },
    "isError": false
  }
}

Una solicitud de herramientas/llamada y resultado para una herramienta de pago de Sois. La misma operación a través de la API REST necesitaría una definición de función escrita para el proveedor del modelo, un bucle para retransmitir la llamada y una decisión sobre cómo presentar la respuesta; aquí el cliente ya sabe cómo hacer las tres cosas.

Hay un costo. El protocolo es más joven que REST y aún está en movimiento: la revisión del 28-07-2026 eliminó las sesiones a nivel de protocolo y cambió cómo los servidores piden a los clientes que proporcionen entrada, y se requiere que los clientes retrocedan para los servidores en la revisión anterior. Las listas de herramientas consumen contexto, por lo que los servidores grandes necesitan carga diferida o búsqueda de herramientas en el lado del cliente. Y un llamador impulsado por un modelo es más lento y menos predecible que un programa, que es precisamente por qué no lo usarías para una sincronización nocturna.

Cuándo es adecuado cada uno

Cómo los principales productos de agentes consumen cada uno hoy

Las APIs de los proveedores resuelven la comparación para cualquiera que esté construyendo su propio agente, porque ambos ahora aceptan un servidor MCP como una herramienta de primera clase junto con llamadas a funciones ordinarias. En el lado de Claude, los conectores personalizados en las aplicaciones web y de escritorio y Cowork toman una URL de servidor y completan OAuth en la aplicación; Claude Code agrega un servidor con un comando; y el conector MCP de la API de Mensajes (beta, detrás de la mcp-client-2025-11-20 cabezera) toma un mcp_servers entrada y un mcp_toolset, supports tool calls only, and expects you to supply the access token. On the OpenAI side, ChatGPT's developer mode connects a remote server with OAuth or no authentication and asks for confirmation on write actions by default; the Responses API takes a tool of type mcp con un }}}, a requiere aprobación configuración y opcional allowed_tools lista, devoluciones herramientas de MCP y mcp_call elementos y funciona con Streamable HTTP o el transporte SSE más antiguo.

La llamada de funciones ordinarias sigue disponible en ambas APIs, y es el camino para un sistema solo REST: defines las funciones, llamas a la API, devuelves los resultados. La diferencia radica completamente en quién mantiene el puente. Con MCP, el propietario del sistema mantiene un servidor y cada cliente se beneficia; con la llamada de funciones, cada constructor de agentes mantiene sus propias definiciones contra la API.

El patrón que funciona: API por debajo, MCP por encima

Los sistemas que lo hacen bien exponen ambos y los dirigen a través de la misma capa de permisos. Sois es una implementación del patrón. El espacio de trabajo tiene una capa de servicio que cada pantalla utiliza. Su servidor MCP publica esa capa como herramientas en una URL, filtrada por el rol del llamador y verificada nuevamente en cada llamada, con OAuth para conectores y un token de portador para scripts. El mismo espacio de trabajo acepta solicitudes en lenguaje natural en un punto final separado para llamadores sin agente, donde el propio agente del espacio de trabajo realiza el razonamiento y responde por webhook o polling. Y para la dirección saliente, su propio agente puede llamar a servidores MCP externos a través de una puerta de enlace, bajo la misma gobernanza de permitir, preguntar y denegar.

Nada en ese diseño requiere elegir. La API sirve programas, el servidor MCP sirve modelos, la puerta de enlace sirve a los llamadores sin ninguno, y un modelo de permisos gobierna los tres. Cuando alguien pregunta cuál construir, la respuesta honesta es que la API es un hecho y el servidor MCP es lo que hace que el sistema sea utilizable por los agentes que la gente ya tiene.

Preguntas que la gente hace

Este artículo se revisa cuando cambian los productos que describe. Próxima revisión programada: 4 de diciembre de 2026.