El handler que sobrevive entre llamadas

Hasta ahora cada tool era stateless: cada invocación independiente, sin memoria de la anterior. Funciona para lookups, pero falla en operaciones de varios pasos.

Un carrito de compras es el caso clásico:

• El usuario agrega un item, después otro, después quita uno, después hace checkout.
• Cada llamada al tool tiene que ver lo que dejaron las anteriores.

Si cada handler arranca con el carrito vacío, no sirve. El estado tiene que vivir afuera de las funciones.

Las tres herramientas

A la derecha tenés tres tools que operan sobre el mismo carrito:

• cart_add. agrega un item con quantity.
• cart_remove. quita un item.
• cart_checkout. cierra el carrito y emite la orden.

Tu trabajo: implementar los handlers de modo que el estado persista entre llamadas y esté aislado por usuario.

El patrón

const carts = new Map();  // userId -> { itemId -> quantity }

async function cart_add({ item_id, quantity }) {
  const userId = getUserId();
  if (!carts.has(userId)) carts.set(userId, {});
  const cart = carts.get(userId);
  cart[item_id] = (cart[item_id] || 0) + quantity;
  return { ok: true };
}

Tres cosas que importan:

1. El Map carts vive afuera de las funciones. Si lo declarás adentro, se reinicia cada llamada.
2. Indexado por userId. Cada usuario tiene su propio carrito. Sin esto, todos comparten el mismo y se rompe en el segundo concurrent.
3. cart_add acumula. no sobrescribe. Si ya hay 2 de X y agregás 1 más, queda 3, no 1.

Cómo se evalúa

5 criterios llm-judge sobre 5 escenarios:

1. El estado persiste entre llamadas.
2. Está aislado por usuario.
3. cart_add acumula correctamente.
4. cart_remove quita sin romper el resto.
5. cart_checkout crea orden y deja carrito vacío.

Este patrón es la base de TODO MCP con estado. Vale la pena implementarlo bien acá. vas a usarlo en sistemas reales mucho más complejos.