TOON, MCP y Agentes: menos hype, más arquitectura real (y un 25% de ahorro que sí importa)

Durante la ultima semana veía la misma frase repetida en X, LinkedIn., repositorios y demos:

“TOON es entre un 30% y un 60% más eficiente que JSON.”

Las barras eran verdes, los gráficos preciosos, y la narrativa impecable.

Pero, como arquitecto, cuando algo promete magia, yo hago siempre lo mismo:

• Lo pruebo yo.
• Con mis datos.
• Con mis modelos.
• Con mi métrica.

Aquí empieza esta historia: un benchmark que me llevó, sin quererlo, a repensar cómo deben hablar los agentes con la capa MCP, y por qué TOON —sin ser mágico— sí tiene un lugar claro en la arquitectura AI-native moderna.

El contexto: qué quería comprobar de verdad

Mi objetivo no era “coronar” a TOON como el nuevo JSON, sino responder a tres preguntas muy concretas:

1. ¿Cuánto ahorra TOON vs JSON compacto en tokens en un caso realista de negocio?

2. ¿Qué pasa con la precisión (retrieval accuracy) cuando el modelo tiene que hacer cálculos y filtros reales?

3. ¿Tiene sentido introducir TOON en una arquitectura con MCP + agentes, o es solo ruido?

Para ello monté un dataset de 600 facturas (en el repositorio os dejo 10, y si lanzas dotnet run 1 ó 2 ó 3 irá multiplicando, lo pongo así por si acaso para que no os gasteis demasiado por accidente), serializado en:

• TOON

• JSON compacto (lo que realmente usarías en APIs internas)

Y probé con:

• Modelo de razonamiento o1

• Estrategia RAW únicamente: prompts mínimos, sin cientos de líneas de instrucciones.

La validación se hizo contra ground truth calculado por código, con tolerancia ±0.1% en los cálculos numéricos.

Resultados RAW (o1): los números reales

Estos son los resultados relevantes, solo para estrategia RAW:

Ahorro real de tokens (RAW)

Calculando el ahorro en tokens de entrada:

• Diferencia: 2607 − 1959 = 648 tokens

• Porcentaje: 648 / 2607 ≈ 24.9%

Lo mismo que ya había visto con gpt-5-chat: el ahorro se mueve en una horquilla 22–27% (siendo generoso y datos muy cocinados llego al top del 27%); el valor más estable era en torno al 25%.

Nada del 30% y aun menos el 60%.

Nada de milagros.

Pero un 25% sostenido en un caso de negocio con facturas completas, que sí es defendible en FinOps.

Precisión: TOON no “piensa mejor” que JSON

En modo RAW, con o1:

• TOON-RAW → ✓ PASS, ~44.8 s
• JSON-RAW → ✓ PASS, ~44.6 s

Ambos responden correctamente a:

• facturas enterprise ES vencidas,
• líneas promo de categoría networking,
• comparación de declared_line_count vs líneas reales,
• combinación de payment_terms y payment_status,
• suma de grand_total y media aproximada de VAT.

Es decir:

• La precisión es equivalente.

• La latencia es prácticamente la misma (~45 s en ambos casos).

La única diferencia sistemática y medible es:

TOON-RAW usa ~25% menos tokens que JSON-RAW.
La mejora está en el coste y en la huella de contexto, no en la “inteligencia” ni en la velocidad del LLM.

Entonces, ¿por qué me importa TOON si “solo” ahorra un 25%?

Porque ese 25% no se aplica a una llamada aislada tipo “hola, mundo”, sino a:

• agentes que hacen tool-calls constantemente,

• cadenas MCP donde cada respuesta se vuelve a inyectar en el contexto,

• escenarios donde un solo flujo puede disparar:

  • 5, 10 o 20 llamadas a tools,

  • con resultados grandes que se reutilizan entre agentes.

En otras palabras:

En arquitecturas multi-agente + MCP, cada tool-result en TOON en lugar de JSON compacto te ahorra un 25% de tokens.
Y ese 25% se multiplica por el número de pasos, agentes y tareas.

Aquí es donde TOON, sin hype, sí tiene un sitio claro.

Dónde encaja TOON en una arquitectura AI-native con MCP y agentes

La idea no es reescribir tu plataforma a TOON (sinceramente: sería un error de arquitectura).

La idea es muy simple:

• Dentro de tu backend, tus APIs siguen hablando JSON compacto.

• En la frontera MCP → LLM / agentes, usas TOON como formato de intercambio optimizado para modelos.

Patrón recomendado:

• Backend / servicios internos → JSON mini (rápido, estándar, barato de integrar)

• MCP Server ↔ agentes / LLM → TOON (compacto, estable, menos tokens)

De esta forma:

• no tocas tus servicios,

• no rompes contratos existentes,

• y colocas TOON justo donde tiene impacto directo en coste de tokens y tamaño de contexto.

Arquitectura: agentes + MCP + TOON (en el sitio correcto)

Puntos clave:

• Los agentes nunca hablan directamente con las APIs: siempre lo hacen vía tools MCP.

• El MCP Server:

  • hacia dentro usa JSON compacto para integrarse con tus sistemas,

  • hacia fuera expone TOON a los modelos.

• El ahorro del 25% en tokens está exactamente en el tramo que más te duele en la factura:
  LLM ↔ MCP.

En mi artículo: De API a MCP: cómo exponer tus endpoints de forma segura para la IA; donde explico como transformar un servicio API de .NET a un MCP Server, encaja muy bien en la capa McpStdioWrapper.

FinOps con números: por qué el 25% RAW importa (y también en sostenibilidad)

Cuando hablamos de un 25% de ahorro token puede sonar pequeño… hasta que lo multiplicas por producción.

Los agentes MCP no hacen una llamada: hacen cientos, miles o millones.

Tomemos un ejemplo conservador pero realista:

• 2.000 millones de tokens de entrada al año —solo en tool-results reinyectados al modelo.

• JSON-RAW: baseline

• TOON-RAW: ~25% menos tokens

Ahorro bruto de tokens

2.000M × 0.25 = 500M tokens menos al año

Coste FinOps

Precio medio: 1,5 USD / millón de tokens input

Sostenibilidad: el beneficio silencioso que nadie cuenta

Cada token procesado por un modelo LLM tiene un coste energético:

• cómputo,

• refrigeración,

• aceleradores,

• infraestructura cloud,

• tráfico entre regiones,

• inferencias repetidas.

Reducir tokens no solo reduce la factura, también reduce:

1. Consumo energético por inferencia (hay papers recientes que estiman que cada millón de tokens equivale a varios Wh de energía en datacenters modernos).

2. Huella de carbono asociada a procesar menos tokens.

3. Carga térmica en inferencia acelerada (sí, incluso esto se mide para modelos reasoning-heavy como o1).

4. Necesidad de escalado en clusters de inferencia.

En plataformas AI-native grandes, esta ecuación es real:

Menos tokens → menos GPU time → menos energía → menos CO₂.

No es greenwashing: Si reduces cientos de millones de tokens al año, reduces consumo real y medible.

Conclusión: TOON no es magia, pero sí es arquitectura

Después de jugar con números reales, sin cocinar el dataset y sin enamorarme del formato, mi conclusión es simple:

• TOON no da un 30% de ahorro real.

• TOON sí da ~25% de ahorro RAW frente a JSON compacto, y lo repite de forma estable.

• TOON no mejora la precisión del modelo.

• TOON sí reduce tokens justo donde más duele: en tool-results de MCP y agentes.

• TOON no debe invadir tu backend.

• TOON sí debe vivir en la frontera MCP → LLM / agentes.

En otras palabras:

No necesitamos formatos mágicos.
Necesitamos saber dónde encaja cada pieza en una arquitectura AI-native.

Para mí, el reparto queda así:

• JSON compacto dentro de la casa (servicios, bases de datos, APIs internas).

• TOON en la puerta de la casa (MCP ↔ agentes / modelos).

• Agentes encima, orquestando tools y aprovechando ese 25% de ahorro en cada salto.

Nota final: el modelo lo es todo — y por qué debemos resistir la tentación del “prompt como backend”

Quiero cerrar este análisis con un mensaje muy sencillo, pero fundamental en cualquier arquitectura AI-native:

Un LLM no es un motor de cálculo.
Un LLM es un motor de razonamiento.

Eso cambia completamente cómo debemos diseñar prompts, formatos, herramientas y MCP servers.

1. El riesgo de la tentación: convertir el prompt en un backend

Aunque este punto es obvio, lo pongo, por que lo lo he visto en la vida real.

En las pruebas de este artículo utilicé preguntas que, deliberadamente, son deterministas:

• contar facturas,

• sumar importes,

• calcular medias,

• filtrar por condiciones lógicas exactas,

• comparar declared_line_count vs líneas reales.

Todo esto debería calcularlo el backend, no un modelo de lenguaje.

Pero precisamente porque era intencional, la prueba revela algo importante:

• El modelo no falla por el formato.

• El modelo no falla por TOON vs JSON.

• El modelo falla cuando le pedimos tareas que no son para un LLM.

Un modelo de razonamiento (o1) puede analizar, inferir, comparar, justificar, interpretar… pero cuando lo obligas a ser un ETL estadístico, no solo consumes más tokens: introduces variabilidad.

Por eso INF fue una lotería. No por TOON. No por JSON.
Sino por el tipo de tarea.

2. Qué SÍ deberíamos pedir a una IA (y qué NO)

Preguntas adecuadas para un LLM (zona “razonamiento”)

• “¿Qué patrón se repite en estas facturas?”

• “¿Qué anomalías detectas en relación a los clientes enterprise?”

• “¿Qué hipótesis explicarían estos valores de VAT?”

• “Resume los cambios relevantes entre dos documentos TOON.”

• “Genera un plan para validar la consistencia de este dataset.”

• “Explica qué parte de la estructura TOON no encaja con la API que recibimos.”

Preguntas que NO son adecuadas (zona determinista)

• “¿Cuál es la suma exacta de todos los grand_total?”

• “Cuenta cuántos elementos cumplen X.”

• “Calcula la media de este campo.”

• “Haz el diff matemático línea a línea.”

Estas últimas deben resolverse en:

• tu backend,

• tu MCP server,

• un microservicio,

• o una tool programática conectada al agente.

Esto no solo reduce tokens, sino que reduce variabilidad, mejora confiabilidad, y deja al LLM hacer lo que mejor hace: razonar, contextualizar, inferir.

3. ¿Qué nos aportó realmente TOON en todo esto?

Después de eliminar el ruido del prompt “INF” y quedarnos únicamente con el modo RAW, la conclusión fue clara:

TOON no mejora la precisión del modelo…
pero sí reduce tokens sin perder información.

Y ahí es donde encaja:

• TOON = formato compacto para mover datos entre capas AI (agentes ↔ MCP server ↔ LLM).

• JSON compacto = formato ideal en el backend.

• MCP = capa de traducción TOON ↔ JSON.

En otras palabras:

• El backend calcula.

• El LLM piensa.

• TOON minimiza tokens en el camino entre ambos.

Esa es la arquitectura sostenible.

4. Por qué este experimento “extremo” era necesario

Lo que hice fue intencional:

• forzar al modelo a tareas deterministas,

• cambiar formatos (TOON vs JSON),

• y medir tokens/tiempo/precisión bajo condiciones adversas.

¿Por qué?

Porque este tipo de pruebas revelan dónde está el valor real:

• no en el formato,

• no en el prompt,

• sino en la interacción modelo ↔ tool ↔ backend.

Es la totalidad —la arquitectura— la que importa.

Modelo + Tokens + Formato + MCP + Tools = la verdadera unidad de diseño en AI-native.

Y TOON encaja exactamente ahí: en la frontera entre agentes y modelo, donde optimizar tokens sin perder estructura sí importa.