MCP vs API: cuándo usar MCP o HTTP directo

Jakub Swistak
Publicado Actualizado 7 min de lectura
Diagrama de comparación de arquitectura que muestra patrones de integración con MCP y HTTP

Al conectar un agente de IA con herramientas y API externas, hay dos enfoques generales: usar Model Context Protocol (MCP) como capa de abstracción, o llamar a una API directamente mediante HTTP. Ambos funcionan. Tienen distintas compensaciones en flexibilidad, complejidad, rendimiento y portabilidad.

Esta publicación compara ambos enfoques con ejemplos concretos de código, análisis de latencia y un marco de decisión para elegir entre ellos.

Los dos enfoques

Integración directa mediante HTTP

La aplicación de IA (o su backend) llama directamente a API externas usando solicitudes HTTP estándar. El desarrollador escribe código para construir solicitudes, gestionar la autenticación, analizar respuestas y devolver los resultados al LLM.

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

Integración con MCP

La aplicación de IA se conecta a un servidor MCP que encapsula la API externa. La aplicación usa el protocolo MCP para descubrir herramientas disponibles, llamarlas por nombre y recibir resultados. El servidor MCP gestiona las llamadas HTTP reales a la API externa.

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

La diferencia clave: con HTTP directo, la aplicación de IA es propietaria del código de integración con la API. Con MCP, el servidor MCP es el propietario, y la aplicación de IA solo llama herramientas por nombre.

Puedes tener el lado MCP de este diagrama sin crear el servidor: Quickchat AI aloja un servidor MCP con HTTP transmitible para cada AI Agent, y convertir tu agente en un servidor MCP se reduce a pegar una URL en la aplicación de IA.

Comparación de código

Comparemos ambos enfoques con un ejemplo práctico: obtener los repositorios de un usuario de GitHub.

Integración directa mediante HTTP

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Obtiene repositorios de un usuario de GitHub."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

Para integrar esto con un LLM, también necesitas:

  • Una definición de herramienta en el formato que espere el LLM (esquema de function calling de OpenAI, esquema de uso de herramientas de Claude, etc.)
  • Código para analizar la llamada de herramienta del LLM, invocar get_user_repos e inyectar el resultado de vuelta en la conversación
  • Manejo de errores para fallos HTTP, límites de tasa y expiración de autenticación

Servidor MCP

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """Obtiene los 10 repositorios actualizados más recientemente de un usuario de GitHub.

    Args:
        username: nombre de usuario de GitHub que se buscará
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "desconocido"
            lines.append(f"- {r['name']} ({lang}, {stars} estrellas): {r['description'] or 'Sin descripción'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

La versión con MCP encapsula la llamada a la API, la autenticación y el formato de la respuesta dentro del servidor. Cualquier cliente compatible con MCP puede usar esta herramienta sin saber nada sobre la API de GitHub.

Qué cambia para la aplicación de IA

AspectoHTTP directoMCP
Definición de herramientaEscrita en el formato nativo del LLM (esquema de OpenAI, etc.)Generada automáticamente desde el servidor MCP
AutenticaciónGestionada por la aplicación de IAGestionada por el servidor MCP
Análisis de respuestaLa aplicación de IA extrae y da formato a los datosEl servidor MCP devuelve un resultado ya formateado
Manejo de erroresLa aplicación de IA maneja los errores HTTPEl servidor MCP maneja errores y devuelve mensajes de error estructurados
Agregar una herramienta nuevaEscribir código nuevo en la aplicación de IAConectarse a un servidor MCP nuevo (o agregar una herramienta a un servidor existente)
Cambiar de LLMReescribir definiciones de herramientas para el formato del nuevo LLMNo se necesitan cambios

Comparación de rendimiento

MCP agrega una capa entre la aplicación de IA y la API externa. Esa capa tiene un costo.

Latencia

Para el transporte stdio (servidores MCP locales), la sobrecarga es mínima: creación del proceso al iniciar (una sola vez, normalmente por debajo de 100ms) y comunicación entre procesos por mensaje (menos de un milisegundo en sistemas modernos). En la práctica, la llamada a la API externa domina la latencia total.

Para servidores MCP remotos (Streamable HTTP o SSE), agregas un viaje de ida y vuelta HTTP entre el cliente y el servidor MCP, más el viaje de ida y vuelta HTTP del servidor MCP a la API externa. Si el servidor MCP y la API externa están en la misma ubicación, esta sobrecarga es pequeña (milisegundos de un solo dígito). Si están en regiones distintas, se acumula. Sin embargo, el transporte rara vez es lo que percibe el usuario: al crear un agente de centro de ayuda sobre el servidor MCP alojado de Notion, 248 llamadas a herramientas promediaron 2.7 segundos cada una, casi todo dedicado a búsquedas en Notion y renderizado de páginas, no al salto intermedio.

ConfiguraciónLatencia añadida aproximada
Servidor MCP local (stdio)< 1ms por llamada a herramienta
Servidor MCP remoto (misma región que la API)1-5ms por llamada a herramienta
Servidor MCP remoto (región distinta a la API)10-50ms por llamada a herramienta

Para la mayoría de los casos de uso de agentes de IA, donde la inferencia del LLM tarda 500ms-5s, la sobrecarga de MCP es insignificante.

Gestión de conexiones

HTTP directo: tu aplicación gestiona conexiones con cada API externa. Esto implica manejar pools de conexiones, lógica de reintentos y límites de tasa por API.

MCP: tu aplicación gestiona una conexión por servidor MCP. El servidor gestiona la conexión con la API externa. Si tienes 10 herramientas distribuidas en 3 servidores MCP, gestionas 3 conexiones en lugar de 10.

Cuándo usar MCP

Múltiples integraciones de herramientas

Si tu aplicación de IA necesita conectarse a más de 5 servicios externos, MCP reduce la carga de integración. En lugar de escribir y mantener clientes de API personalizados para cada servicio, te conectas a servidores MCP (muchos de los cuales están disponibles como proyectos open source).

Portabilidad entre plataformas de IA

Si creas servidores MCP para tus herramientas, esos servidores funcionan con cualquier cliente MCP: Claude Desktop, Cursor, Windsurf, aplicaciones personalizadas y plataformas como Quickchat AI. Con HTTP directo, tendrías que volver a implementar las definiciones de herramientas para el formato de cada plataforma.

Descubrimiento dinámico de herramientas

MCP admite el descubrimiento de herramientas en tiempo de ejecución mediante tools/list. Una aplicación de IA puede conectarse a un servidor y saber qué herramientas están disponibles sin ninguna configuración hardcodeada. Esto es útil en escenarios donde las herramientas cambian con frecuencia o son configurables por el usuario.

Separación de responsabilidades

Si distintos equipos son propietarios de distintas herramientas, MCP proporciona un límite claro. El equipo propietario de la integración con Salesforce crea y mantiene el servidor MCP de Salesforce. El equipo de la aplicación de IA se conecta a él sin necesidad de entender la API de Salesforce. Las actualizaciones de la API de Salesforce se gestionan en el servidor MCP sin tocar la aplicación de IA.

Cuándo usar HTTP directo

Una o dos integraciones

Si tu agente de IA solo necesita llamar una API (por ejemplo, una consulta a una base de datos), la sobrecarga de ejecutar un servidor MCP es innecesaria. Una llamada HTTP directa es más simple y tiene menos partes móviles.

Además, no tienes que escribir la solicitud a mano. El constructor de API Action en lenguaje natural lee una API REST documentada, genera el método, la URL, los parámetros y la descripción, y luego te permite probar la respuesta real antes de habilitarla.

Control máximo sobre las solicitudes

Los servidores MCP abstraen los detalles HTTP. Si necesitas control preciso sobre la construcción de solicitudes (headers específicos, parámetros de consulta, firma de solicitudes o autenticación no estándar), HTTP directo te da ese control sin pelear con una capa de abstracción.

Operaciones sensibles a la latencia

Si cada milisegundo importa (por ejemplo, agentes de voz en tiempo real donde las llamadas a herramientas deben completarse dentro de presupuestos de tiempo estrictos), eliminar la capa MCP elimina un salto.

Llamadas HTTP no relacionadas con IA

Si la llamada HTTP no la activa un agente de IA (por ejemplo, un cron job de backend que sincroniza datos), MCP no aplica. MCP está diseñado específicamente para la comunicación entre IA y herramientas. Los servicios de backend normales deben usar clientes HTTP normales.

Enfoque híbrido

Muchos sistemas de producción usan ambos. El patrón:

  • MCP para integraciones de herramientas que el agente de IA llama durante conversaciones (consultas a CRM, creación de tickets, consultas a bases de conocimiento)
  • HTTP directo para operaciones internas de backend, webhooks y comunicación de sistema a sistema

Así funciona Quickchat AI internamente. La plataforma admite tanto HTTP Request Actions (llamadas directas a API con plantillas de parámetros) como Remote MCP Actions (conexiones a servidores MCP externos). Tú eliges el enfoque correcto para cada integración:

Tipo de integraciónEnfoque recomendado
Llamada simple a una API con parámetros conocidosHTTP Request Action
Integración compleja con varias herramientas relacionadasRemote MCP Action
Servicio de terceros con un servidor MCP existenteRemote MCP Action
API interna con autenticación personalizadaHTTP Request Action
Herramienta configurable por el usuarioRemote MCP Action

Para una comparación detallada de cómo funciona esto en la práctica, incluidas las diferencias entre GPT Actions de OpenAI y MCP, consulta GPT Actions vs MCP.

Marco de decisión

Usa este diagrama de flujo para elegir:

  1. ¿El agente de IA llama la herramienta? Si no (es una operación de backend), usa HTTP directo.
  2. ¿Cuántas herramientas externas necesitas? Si son 1-2, HTTP directo es más simple. Si son 3 o más, considera MCP.
  3. ¿Existe un servidor MCP preconstruido para el servicio? Si sí, usarlo ahorra tiempo de desarrollo.
  4. ¿Necesitas que la integración funcione en varias plataformas de IA? Si sí, MCP ofrece portabilidad.
  5. ¿La latencia es crítica (presupuesto inferior a 100ms para llamadas a herramientas)? Si sí, mide la sobrecarga de MCP y decide en consecuencia.
  6. ¿Distintos equipos son propietarios de distintas integraciones? Si sí, el modelo de un servidor por integración de MCP ayuda con los límites de propiedad.

En la práctica, si estás creando un agente de IA que necesita interactuar con servicios externos, MCP es cada vez más la opción predeterminada. El ecosistema de servidores preconstruidos es lo bastante amplio como para que muchas veces puedas empezar sin escribir ningún código de servidor.

Lecturas adicionales