MCP vs API: ¿qué protocolo usar en agentes?

Las APIs llevan décadas haciendo posible que una aplicación consulte datos o ejecute operaciones en otra. Gracias a ellas, una tienda puede cobrar mediante una pasarela de pago, un ERP puede sincronizar pedidos con un CRM y una aplicación móvil puede consultar la previsión meteorológica.

La llegada de los agentes de inteligencia artificial plantea un reto adicional. Ya no siempre hay un desarrollador que programa de antemano cada llamada y cada transición: un modelo puede decidir qué herramienta necesita, seleccionar una operación, construir sus argumentos e interpretar el resultado durante una conversación.

Aquí entra en juego MCP, siglas de Model Context Protocol. MCP es un estándar abierto para conectar aplicaciones de IA con sistemas externos, ya sean archivos locales, bases de datos, servicios remotos o flujos de trabajo. Su propuesta es crear una interfaz común entre los agentes y las capacidades que pueden utilizar.

La pregunta parece inevitable: si ya tenemos APIs, ¿para qué necesitamos MCP? La respuesta corta es que no solucionan exactamente el mismo problema.

Antes de comparar: una API no es un protocolo concreto

Aunque solemos hablar de “API” como sinónimo de una API REST sobre HTTP, una API es, en realidad, una interfaz mediante la que un componente de software ofrece datos o funciones a otro. Puede implementarse con REST, GraphQL, gRPC, SOAP, una biblioteca local o muchos otros estilos.

OpenAPI, por ejemplo, no define el comportamiento de todas las APIs: proporciona una descripción estándar e independiente del lenguaje para APIs HTTP. Esa descripción permite que personas y herramientas conozcan rutas, operaciones, parámetros, respuestas y mecanismos de seguridad sin inspeccionar el código fuente. Así lo establece la propia especificación OpenAPI.

MCP sí es un protocolo concreto. Define una arquitectura cliente-servidor, mensajes basados en JSON-RPC 2.0, mecanismos de descubrimiento y un conjunto de primitivas pensadas para aplicaciones de IA. Por eso, “MCP vs. API” es una comparación útil para tomar decisiones, pero no una oposición estricta entre conceptos equivalentes.

Una forma sencilla de verlo es esta:

La API expone lo que un sistema puede hacer. MCP traduce y organiza esas capacidades para que un agente pueda descubrirlas y utilizarlas de una forma común.

¿Qué aporta una API tradicional?

Una API convencional ofrece un contrato para que un programa invoque operaciones conocidas. En una API REST, por ejemplo, el cliente sabe que debe enviar una petición GET /customers/123 para recuperar un cliente o una petición POST /orders/ para crear un pedido.

La aplicación consumidora se programa alrededor de ese contrato. El equipo de desarrollo decide qué endpoint llamar, en qué momento, con qué parámetros y cómo procesar la respuesta. Esto ofrece control, previsibilidad y eficiencia.

Las APIs son especialmente adecuadas para:

• Integraciones deterministas entre servicios.
• Aplicaciones móviles y web con flujos conocidos.
• Procesamiento masivo o de baja latencia.
• Interfaces públicas para desarrolladores y socios.
• Automatizaciones en las que cada paso está definido de antemano.

Además, el ecosistema de las APIs está muy consolidado. Existen herramientas maduras para documentación, generación de clientes, pruebas, observabilidad, control de versiones, cuotas y seguridad. OpenAPI puede describir, entre otros, esquemas con API keys, HTTP authentication, OAuth 2.0, OpenID Connect o mTLS.

Su limitación en el contexto de los agentes no es que una API sea incapaz de servirles. Un agente puede utilizar una API directamente si su plataforma permite registrar funciones o herramientas. El problema aparece al escalar: cada aplicación de IA necesita adaptar el contrato de cada servicio, seleccionar qué operaciones exponer al modelo y transformar sus respuestas en contexto útil.

¿Qué aporta MCP?

MCP estandariza la comunicación entre una aplicación de IA (el host) y uno o varios servidores MCP. El host crea un cliente para cada servidor y agrega las capacidades disponibles para que el modelo pueda utilizarlas. La arquitectura oficial de MCP separa además la capa de datos, basada en JSON-RPC 2.0, de la capa de transporte.

Un servidor MCP puede exponer tres primitivas principales:

• Herramientas (tools): funciones ejecutables para consultar un servicio o realizar acciones, como buscar pedidos, crear una incidencia o actualizar una tarea.
• Recursos (resources): fuentes de información que pueden incorporarse al contexto, como un documento, un esquema de base de datos o el contenido de un registro.
• Prompts: plantillas reutilizables que estructuran una interacción o un flujo de trabajo.

El cliente puede descubrir estas capacidades en tiempo de ejecución. Por ejemplo, solicita la lista de herramientas, recibe sus nombres, descripciones y esquemas de entrada, y posteriormente invoca una mediante tools/call. Los esquemas permiten validar argumentos y los resultados pueden combinar texto, contenido estructurado y referencias a recursos. La especificación de herramientas de MCP detalla este contrato.

MCP admite conexiones locales mediante entrada y salida estándar (stdio) y conexiones remotas mediante Streamable HTTP. Esto permite usar el mismo modelo conceptual tanto para una herramienta local que opera sobre archivos como para un servicio alojado en la nube.

Su principal ventaja es la interoperabilidad en la capa del agente. Un servidor MCP bien diseñado puede conectarse a distintos clientes compatibles sin crear una integración específica para cada uno. Del otro lado, un host puede incorporar servidores diferentes bajo un patrón común de descubrimiento e invocación.

MCP vs. API: no se reemplazan, se apoyan

En una arquitectura real, el servidor MCP suele funcionar como una capa de adaptación. Recibe una petición estándar del cliente de IA, valida los argumentos, aplica permisos y llama a la API interna o pública que ya contiene la lógica de negocio.

Por ejemplo, una plataforma de soporte puede mantener su API REST como interfaz canónica:

1. 01La API ofrece operaciones para consultar clientes, leer incidencias y publicar respuestas.
2. 02El servidor MCP agrupa esas operaciones en herramientas comprensibles para un agente, como buscar_incidencias o responder_incidencia.
3. 03El agente descubre las herramientas y decide cuál proponer según la petición del usuario.
4. 04El host aplica políticas y, si la acción es sensible, solicita confirmación.
5. 05El servidor MCP llama a la API con las credenciales y permisos correspondientes.

Esta separación es útil porque la lógica de negocio permanece detrás de la API, donde también puede atender a la aplicación web, la aplicación móvil y otras integraciones. MCP aporta una fachada específica para clientes de IA sin convertir al modelo en consumidor directo de toda la superficie técnica del sistema.

Tampoco es necesario exponer cada endpoint como una herramienta. De hecho, suele ser mejor diseñar herramientas de mayor nivel, acotadas y orientadas a la intención. En vez de trasladar veinte endpoints de bajo nivel, un servidor podría ofrecer preparar_reembolso, que consulte el pedido, compruebe las reglas y devuelva una propuesta antes de ejecutar la operación definitiva.

Ventajas de las APIs

• Ofrecen control preciso sobre cada petición y respuesta.
• Son una base estable para múltiples canales y consumidores.
• Encajan bien en operaciones de alto volumen, flujos deterministas y requisitos estrictos de latencia.
• Disponen de un ecosistema maduro de gateways, SDKs, pruebas, monitorización y gobierno.

Límites de las APIs para agentes

• Cada cliente de IA puede requerir una adaptación distinta.
• Una especificación técnica no siempre contiene las descripciones semánticas que ayudan al modelo a escoger correctamente una operación.
• Las respuestas pueden ser demasiado extensas o poco adecuadas para una ventana de contexto.
• Exponer toda una API aumenta el número de herramientas y dificulta su selección por parte del modelo.

Ventajas de MCP

• Proporciona una interfaz común para diferentes clientes de IA.
• Permite descubrir capacidades y sus esquemas dinámicamente.
• Distingue entre acciones, fuentes de contexto y plantillas de interacción.
• Facilita que una misma integración esté disponible en varios hosts compatibles.
• Puede encapsular varias llamadas a APIs en herramientas orientadas a tareas.

Límites de MCP

• Introduce otra capa que hay que desplegar, versionar, observar y proteger.
• La compatibilidad real puede variar según las funciones de MCP que implemente cada cliente.
• No elimina la necesidad de una API o de una capa de acceso a datos detrás del servidor.
• No convierte una herramienta mal diseñada en una herramienta segura o fácil de usar.
• Puede resultar innecesario si solo existe un consumidor y el flujo es completamente determinista.

La seguridad cambia cuando el consumidor puede razonar y actuar

En una integración tradicional, la secuencia de llamadas está escrita en código. En un agente, parte de la decisión puede depender del modelo y de contenido externo no confiable. Por ello, conectar una herramienta no equivale a autorizar cualquier uso de esa herramienta.

Para servidores MCP remotos, la especificación contempla autorización en el transporte HTTP y se basa en estándares de OAuth. Sin embargo, la autorización es opcional en MCP y una implementación debe diseñarla correctamente. La especificación de autorización exige, cuando se aplica, validar que los tokens estén destinados al servidor correcto y recomienda seleccionar permisos con el principio de mínimo privilegio.

También hay riesgos específicos: servidores locales con acceso al equipo, herramientas con descripciones no confiables, delegación incorrecta de credenciales, SSRF durante el descubrimiento OAuth o acciones destructivas propuestas por el modelo. La guía oficial de buenas prácticas de seguridad de MCP aborda amenazas como el confused deputy, el paso indebido de tokens, el secuestro de identificadores de estado y el compromiso de servidores locales.

Como mínimo, una implementación debería:

• Conceder a cada servidor y herramienta solo los permisos necesarios.
• Separar operaciones de lectura y escritura.
• Validar entradas, salidas, rutas y URIs en el servidor.
• Tratar las descripciones, anotaciones y respuestas externas como datos no confiables.
• Mostrar qué herramienta se va a ejecutar y pedir confirmación para acciones sensibles o irreversibles.
• Aplicar límites de uso, registros de auditoría, tiempos de espera e idempotencia cuando corresponda.
• Ejecutar servidores locales en un entorno aislado y con acceso restringido al sistema.
• Evitar que el servidor MCP acepte o reenvíe tokens destinados a otros servicios.

La propia especificación de herramientas recomienda mantener a una persona en el circuito, con capacidad para denegar invocaciones. MCP estandariza la conexión, no la confianza.

¿Cuándo conviene usar una API?

Utiliza una API directamente cuando:

• El consumidor es una aplicación tradicional y no un agente.
• El flujo está definido de principio a fin y no necesita descubrimiento dinámico.
• Necesitas el máximo control sobre latencia, reintentos, caché o volumen.
• Estás publicando una interfaz general para desarrolladores y múltiples tipos de clientes.
• Solo tienes un agente y unas pocas operaciones estables que puedes registrar como funciones sin añadir otra capa.

Una API también debería seguir siendo la base cuando la organización ya concentra allí su lógica de negocio, permisos y auditoría. No hace falta duplicar esa lógica dentro del servidor MCP.

¿Cuándo conviene usar MCP?

MCP resulta especialmente útil cuando:

• Quieres que una integración funcione con varios clientes o entornos de agentes compatibles.
• El agente necesita combinar herramientas y fuentes de contexto de distintos sistemas.
• Las capacidades disponibles cambian y conviene descubrirlas en tiempo de ejecución.
• Necesitas exponer archivos, documentos o esquemas como recursos, además de ejecutar acciones.
• Quieres ofrecer una integración oficial de tu producto para el ecosistema de asistentes de IA.
• Deseas encapsular APIs complejas en tareas de negocio más claras y seguras para un modelo.

El beneficio aumenta con el número de combinaciones. Si una empresa debe conectar varios agentes con muchos servicios, una interfaz compartida reduce el trabajo de adaptadores punto a punto.

¿Cuándo usar ambos?

En la mayoría de los productos consolidados, esta será la opción más razonable:

• API como núcleo: mantiene la lógica de negocio, los datos, la autorización y los contratos para cualquier consumidor.
• MCP como capa para agentes: selecciona las capacidades apropiadas, las describe con claridad, limita su alcance y transforma los resultados en contexto útil.

Este patrón permite evolucionar la experiencia del agente sin romper las aplicaciones que ya consumen la API. También evita que la capa MCP se convierta en una segunda implementación de la lógica empresarial.

Una regla práctica para decidir

Puedes tomar la decisión con tres preguntas:

1. 01¿Quién consumirá la interfaz? Si es código determinista, empieza por una API. Si son varios clientes de IA, valora MCP.
2. 02¿La capacidad ya existe detrás de una API? Consérvala y crea una capa MCP solo si aporta interoperabilidad o mejor semántica para el agente.
3. 03¿El modelo debe decidir entre herramientas o acceder a contexto heterogéneo? Cuanto mayor sea esa necesidad, mayor será el valor de MCP.

En resumen:

API para exponer capacidades de software; MCP para presentar capacidades y contexto a agentes. En sistemas reales, lo habitual no será elegir uno u otro, sino utilizar MCP sobre APIs bien diseñadas.

Conclusión y uso en Gescon

MCP responde a una necesidad que las APIs tradicionales no trataban de forma uniforme: conectar modelos y agentes con herramientas, recursos y flujos de trabajo mediante un contrato común. Su descubrimiento dinámico y sus primitivas reducen el coste de integrar un mismo servicio en diferentes aplicaciones de IA.

Pero MCP no sustituye la arquitectura existente. Las APIs siguen siendo el mecanismo adecuado para exponer servicios, centralizar reglas de negocio y atender integraciones deterministas. Un servidor MCP puede apoyarse en ellas y ofrecer al agente una superficie más pequeña, semántica y controlada.

La decisión, por tanto, no debería partir de cuál es la tecnología más nueva. Debe partir del consumidor y del problema: usa una API cuando necesites una interfaz general y predecible; usa MCP cuando necesites que agentes compatibles descubran y utilicen capacidades de forma común; usa ambos cuando quieras combinar una base madura con una experiencia diseñada específicamente para IA. MCP y API en Gescon

En nuestra plataforma, los agentes de inteligencia artificial pueden conectarse a APIs REST tradicionales, así como servidores MCP. En el apartado de Integraciones disponemos de información sobre algunos conectores desarrollados por NurIA Labs en Gescon. En función del proveedor aprovechamos la conexión a su servidor MCP mientras que en otras optamos por adaptar de forma nativa las integraciones de los agentes a las APIs.