Lanzamos nuestro servidor MCP y la gente empezó a usarlo de inmediato. Las consultas chicas andaban perfecto — “¿Cuánto gasté en Meta Ads este mes?” volvía en menos de dos segundos con datos limpios. Pero en el momento en que alguien pedía datos diarios a nivel de campaña en varias cuentas durante unos meses, todo se rompía.
La respuesta era demasiado grande para la ventana de contexto de la IA. Claude colapsaba. ChatGPT hacía timeout. Los datos estaban ahí, pero ninguna IA podía procesarlos.
Juntamos feedback, observamos cómo la gente realmente usaba el servidor, y construimos un pipeline de optimización basándonos en lo que aprendimos. Así funciona.
El problema es más grande de lo que parece
Cuando consultás datos de marketing a través de MCP, la respuesta son datos tabulares crudos — una fila por campaña por día. Una pregunta aparentemente simple como “Mostrame el rendimiento de Facebook Ads por campaña del último trimestre” puede devolver más de 5.000 filas.
Los modelos de IA tienen ventanas de contexto. Claude maneja aproximadamente 100K tokens. ChatGPT varía según el plan. Un token equivale a unos 3-4 caracteres. Una respuesta JSON con 5.000 filas puede superar los 500.000 caracteres — muy por encima de lo que cualquier modelo puede procesar en un solo turno.
La solución ingenua es truncar. Cortar los datos en algún límite, devolver lo que entre. Pero eso significa que la IA presenta datos parciales como si estuvieran completos. Un usuario pregunta “¿Qué campaña gastó más?” y la IA responde con confianza basándose en el 30% de las campañas reales. La que más gastó podría estar en el 70% que se descartó.
Decidimos: si los datos no entran, no devolver datos parciales. Darle a la IA suficiente contexto para que haga una pregunta más inteligente.
El pipeline
El optimizador se ubica entre la respuesta cruda de la API y la salida de la herramienta MCP. Ejecuta cuatro pasos, cada uno activado condicionalmente. La mayoría de las consultas nunca pasan del paso dos.
Paso 1: Validar y filtrar
Limpiamos los datos antes de cualquier otra cosa. Las filas donde todas las dimensiones están vacías se eliminan — son artefactos de paginación de la API o problemas de permisos. Ruido, no señal.
Si todas las métricas de la respuesta son cero, lo marcamos como un probable problema de permisos. La conexión puede verse sana, pero el token de acceso no tiene los scopes correctos. Mostramos una advertencia en vez de devolver una pared de ceros.
Solo este paso elimina entre el 5-15% de las filas en algunos datasets.
Paso 2: Convertir a CSV y verificar el presupuesto
JSON es caro para datos tabulares. Cada fila carga overhead estructural:
{
"campaign_name": { "value": "Venta de Verano", "display_name": "Campaña" },
"spend": { "value": 1234.56, "display_name": "Gasto" }
}Los mismos datos en CSV:
campaign_name,spend
Venta de Verano,1234.56Toda respuesta MCP usa CSV. Los modelos de IA lo parsean igual de bien que JSON, y es 85-99% más barato en tokens. Sin negociación de formatos, sin configuración. CSV es siempre la opción correcta cuando el consumidor es una IA.
Después de la conversión, estimamos el costo en tokens: caracteres × 0.3. Si entra en el presupuesto del cliente, lo devolvemos inmediatamente. Esto cubre la gran mayoría de las consultas.
Paso 3: Reducir la granularidad temporal
Cuando los datos exceden el presupuesto y la consulta incluye una dimensión temporal, probamos agregaciones más gruesas:
diario → semanal → mensual → total
Cada paso es una nueva llamada a la API. Agrega 2-5 segundos por intento, pero vale la pena. En vez de ver un recorte parcial de datos diarios, ves el 100% de tus datos semanales. No se pierde nada — se agrega de forma diferente.
Si algún nivel entra en el presupuesto, lo devolvemos con un aviso:
{
"_meta": {
"optimizations_applied": [
{
"type": "granularity_change",
"from": "daily",
"to": "weekly",
"detail": "Changed time aggregation from daily to weekly"
}
]
}
}Paso 4: Resumen de datos con instrucciones de re-consulta
Esta es la idea clave. Cuando los datos siguen sin entrar después de la reducción de granularidad, no truncamos. Devolvemos un resumen estadístico del dataset completo y le damos a la IA todo lo que necesita para re-consultar con precisión.
Para cada dimensión:
- Cantidad de valores únicos — cuántos valores distintos existen
- Top 20 valores — ordenados por frecuencia
Para cada métrica:
- mínimo, máximo, promedio, suma
Más instrucciones de re-consulta: operadores de filtro y sugerencias inteligentes basadas en la forma real de los datos:
{
"type": "data_too_large",
"summary": {
"total_rows": 4194,
"token_estimate": 45000,
"token_budget": 30000,
"dimensions": [
{
"field": "campaign_name",
"unique_count": 157,
"top_values": ["Brand Campaign", "Holiday Promo", "..."]
}
],
"metrics": [
{ "field": "spend", "min": 0, "max": 5000, "avg": 850, "sum": 127612 }
]
},
"requery_instructions": {
"suggestions": [
"Filter by campaign_name using CONTAINS or EQUALS",
"Filter spend > 850 to keep only above-average rows",
"Narrow the date range to reduce rows"
]
}
}La IA lee esto, entiende la forma de los datos, y arma una consulta de seguimiento con filtros apuntando exactamente a lo que el usuario necesita. En vez de 4.194 filas de todo, obtiene 200 filas de lo que importa.
No se pierde ningún dato. No se descarta ninguna fila en silencio. La IA simplemente hace una mejor pregunta.
Siempre decile a la IA qué pasó
Cada respuesta incluye un objeto _meta con transparencia total:
{
"_meta": {
"original_rows": 1985,
"returned_rows": 1857,
"format": "csv",
"token_estimate": 25563,
"token_budget": 30000,
"optimizations_applied": [
{
"type": "validation_filter",
"rows_removed": 128,
"detail": "Removed 128 rows with empty dimensions"
}
]
}
}La IA lee esto y se lo comunica al usuario. Sin cajas negras.
Guardarraíles de consulta
Las consultas grandes no solo chocan con límites de tokens — hacen timeout. Agregamos tres guardarraíles en el punto de entrada:
Límite de cuentas. Máximo 10 cuentas por consulta. Consultas multi-cuenta a través de docenas de cuentas publicitarias hacen timeout antes de devolver datos útiles. Si se excede, devolvemos la lista completa de cuentas para que la IA pueda acotar.
Protección de timeout. Cada consulta compite contra un deadline de 55 segundos — un margen cómodo antes del timeout HTTP de ~90 segundos de ChatGPT. Si hace timeout, devolvemos sugerencias concretas: acotar fechas, reducir dimensiones, usar granularidad más gruesa.
Sanitización de dimensiones. Los modelos de IA aman agregar "date" como dimensión. Siempre está mal — la agregación temporal es un parámetro separado. Lo sacamos silenciosamente en vez de fallar la consulta.
Presupuestos por cliente
Diferentes clientes de IA reciben diferentes presupuestos de tokens:
- Claude Code: 80.000 tokens
- ChatGPT Web: 80.000 tokens
- Claude Web: 30.000 tokens
- Clientes desconocidos: 30.000 tokens
El optimizador lee el tipo de cliente del contexto de autenticación MCP y se ajusta. La misma consulta podría devolver todos los datos en Claude Code pero activar un resumen de datos en Claude Web.
Lo que aprendimos del feedback de usuarios
Algunos patrones se destacaron al observar el uso real:
La gente consulta en grande. La consulta promedio abarca más de 3 meses de datos diarios en múltiples campañas. Los límites de tokens no son un caso borde — son el caso común para cualquier análisis serio.
Los modelos de IA no manejan bien los datos parciales. Cuando reciben resultados truncados, los presentan como completos sin las advertencias necesarias. Los usuarios toman decisiones con información incompleta sin saberlo. El enfoque de resumen de datos resuelve esto — la IA sabe que está trabajando con un resumen, no con el panorama completo, y actúa en consecuencia.
Los timeouts son peores que las respuestas grandes. Una consulta que devuelve un resumen de datos en 3 segundos es infinitamente mejor que una que cuelga 90 segundos y falla. Los guardarraíles importan tanto como la optimización.
Date-como-dimensión es universal. Todos los modelos de IA que probamos eventualmente intentan agregar “date” como dimensión en vez de usar el parámetro de agregación temporal. Corregir esto silenciosamente salvó más consultas fallidas que cualquier otro cambio individual.
El panorama más amplio de MCP
Mientras construíamos esto, miramos qué están haciendo otros sobre gestión de ventanas de contexto:
Toolsets dinámicos (Speakeasy) reducen el overhead de definición de herramientas — cargan esquemas bajo demanda en vez de mandar 50 por adelantado. Esto optimiza el lado del request.
Llamadas programáticas a herramientas (Anthropic) dejan que la IA escriba código para procesar datos localmente. Poderoso, pero requiere un entorno de ejecución de código.
Instrucciones del servidor explican relaciones entre herramientas en un solo bloque. El servidor MCP de GitHub pasó de 20% a 80% de precisión al agregar instrucciones explícitas.
Nuestro enfoque — optimizar el payload de datos — es complementario a todos estos. Diferentes capas del mismo problema.
Probalo vos mismo
El optimizador está activo en el servidor MCP de Detrics. Conectate desde app.detrics.io/mcp y probá una consulta grande — datos diarios de campañas de varios meses. Vas a ver o el CSV completo con _meta, o un resumen de datos con sugerencias de re-consulta.
Si estás construyendo tu propio servidor MCP, el patrón es simple: validar, CSV, granularidad más gruesa, resumir. Sin truncamiento.
Preguntas? support.detrics.io.