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_repose 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
| Aspecto | HTTP directo | MCP |
|---|---|---|
| Definición de herramienta | Escrita en el formato nativo del LLM (esquema de OpenAI, etc.) | Generada automáticamente desde el servidor MCP |
| Autenticación | Gestionada por la aplicación de IA | Gestionada por el servidor MCP |
| Análisis de respuesta | La aplicación de IA extrae y da formato a los datos | El servidor MCP devuelve un resultado ya formateado |
| Manejo de errores | La aplicación de IA maneja los errores HTTP | El servidor MCP maneja errores y devuelve mensajes de error estructurados |
| Agregar una herramienta nueva | Escribir código nuevo en la aplicación de IA | Conectarse a un servidor MCP nuevo (o agregar una herramienta a un servidor existente) |
| Cambiar de LLM | Reescribir definiciones de herramientas para el formato del nuevo LLM | No 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ón | Latencia 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ón | Enfoque recomendado |
|---|---|
| Llamada simple a una API con parámetros conocidos | HTTP Request Action |
| Integración compleja con varias herramientas relacionadas | Remote MCP Action |
| Servicio de terceros con un servidor MCP existente | Remote MCP Action |
| API interna con autenticación personalizada | HTTP Request Action |
| Herramienta configurable por el usuario | Remote 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:
- ¿El agente de IA llama la herramienta? Si no (es una operación de backend), usa HTTP directo.
- ¿Cuántas herramientas externas necesitas? Si son 1-2, HTTP directo es más simple. Si son 3 o más, considera MCP.
- ¿Existe un servidor MCP preconstruido para el servicio? Si sí, usarlo ahorra tiempo de desarrollo.
- ¿Necesitas que la integración funcione en varias plataformas de IA? Si sí, MCP ofrece portabilidad.
- ¿La latencia es crítica (presupuesto inferior a 100ms para llamadas a herramientas)? Si sí, mide la sobrecarga de MCP y decide en consecuencia.
- ¿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
- Conecta tu AI Agent a un servidor MCP remoto: dale herramientas en vivo a tu agente, paso a paso
- Cómo funciona Model Context Protocol. MCP explicado: introducción a MCP
- GPT Actions vs MCP: comparación con el enfoque de OpenAI
- Especificación de MCP: la especificación oficial del protocolo
- HubSpot AI Actions: ejemplo de acciones de IA basadas en HTTP en la práctica
- El incidente de OpenAI y Hugging Face, qué ocurrió realmente: el incidente explicado paso a paso y qué significa realmente hackear