El bot captura, el MCP consume
Cómo se entera la tienda de lo que pasa en sus chats. No hay panel: hay un servidor al que le pregunta desde su propio Claude, y un reporte cada mañana. Y una regla sobre qué le toca al bot y qué no.
Queda una pregunta, y es la que más le importa al dueño: cómo se entera de lo que pasa en sus chats. El bot atiende unas seis mil conversaciones por mes, y cada una dice algo sobre qué quiere la gente. Nadie tiene tiempo de leerlas. La respuesta corta es que no armé un panel: la tienda le pregunta a su propio Claude. El mismo servidor que corre el bot expone un MCP, y Claude lo consulta por ella.
Detrás hay un reparto de trabajo que entendí tropezando dos veces: el bot captura, el MCP consume.
Una pregunta desde el Claude de la tienda
El dueño abre Claude, el mismo que usa para todo lo demás, y escribe: “¿qué pidieron ayer que no teníamos?”. Lo que vuelve se parece a esto, reconstruido y con datos inventados:
Ayer, pedidos sin stock: nueve.
Cuatro por el mismo modelo en 256 GB, que es de los que reponés. Dos dejaron teléfono para la lista de espera.
Tres por un modelo que no trabajás.
Dos por un color que no entró.
Para hacer hoy: llamar a los dos anotados y reponer el de 256.
No hay pantalla que aprender ni filtro que configurar. Si la respuesta abre otra pregunta, “¿y de qué anuncio vinieron?”, se contesta en el mismo chat.
Por debajo, Claude llamó herramientas del MCP. Hoy son diecisiete, y dieciséis sólo leen. Cuentan y listan conversaciones, traen los mensajes de una charla, muestran qué hizo el bot en cada turno y leen las novedades que conté en el post anterior. La única que escribe abre un reporte cuando el bot se equivocó.
El reporte de cada mañana
Las preguntas sueltas sirven, pero la tienda quiere lo mismo todas las mañanas. Para eso hay un skill que se instala en su Claude. Su única fuente es el MCP: no ve el código ni la base de datos. El reporte trae cuatro cosas:
- Demanda que no se pudo satisfacer. Qué pidieron y no había, separado según se pueda reponer o no.
- Lista de espera. Quién dejó sus datos para que lo llamen cuando entre el equipo.
- Embudo de reservas. Cuántas llegaron a las condiciones, cuántas al formulario y cuántas se concretaron.
- Origen. Cuántas conversaciones trajo cada anuncio, historia o post.
Leer todas las charlas de un día para armar eso sería carísimo, así que el reporte lee pocas. Primero pide dos índices y los cruza. Uno dice qué hizo el bot en cada charla. El otro dice en qué charlas aparecen ciertas frases. Sólo las charlas que alguno de los dos señala se leen enteras.
El último tramo repite una decisión del bot. El modelo lee las charlas señaladas y anota cada caso. Los números los calcula un script a partir de esas anotaciones, y llena siempre la misma plantilla. Si un número del reporte no sale de un caso anotado, no existe. Es la regla del mapa de la serie aplicada de nuevo: ninguna cifra viaja por el modelo.
Los teléfonos de la lista de espera son datos personales. Por eso el reporte es un archivo privado de la tienda, y compartirlo es decisión suya.
Lo que salió mal: adivinar lo que el bot ya sabía
La primera versión del reporte tenía un solo índice, el de las frases. Le pedía al buscador de Chatwoot los chats donde el bot había dicho “no lo tenemos” y sus variantes, y después los leía.
El buscador busca palabras sueltas y descarta las más comunes. “No lo tenemos” terminaba siendo buscar “tenemos”. Lo medí el 7 de septiembre: de 203 resultados, sólo 115 contenían la frase.
El error de fondo era otro. Estaba adivinando, a partir del texto, algo que el bot ya sabía con exactitud. Cuando el bot dice “no lo tenemos” es porque un momento antes buscó en el catálogo y la búsqueda volvió vacía. Eso queda registrado en el trace del turno.
Ese mismo día salió el otro índice: una herramienta que muestra esos traces como eventos. Por cada conversación dice qué herramientas llamó el bot, cuántas búsquedas volvieron vacías, por qué motivo pasó la charla a una persona y en qué etapa quedó la reserva. No llama a ningún modelo y no resume nada. Leer las charlas de un día eran unos setecientos mil tokens. Los eventos del mismo día son entre diez y veinte mil.
El segundo tropiezo: seguir buscando
Los eventos no ven todo. El cliente que llega diciendo que vio otro precio publicado en Instagram es texto del cliente, y ninguna herramienta del bot lo registra. Tampoco ven lo que pasa después del pase, cuando un vendedor cierra la reserva a mano. Para eso dejé viva la búsqueda por frases, como complemento.
Dos semanas después miré adónde se iba el tiempo. En los catorce días que terminaron el 22 de septiembre, esa búsqueda sola se llevó el 53% del tiempo de todo el MCP. La llamada más lenta tardó 47 segundos. No había nada mal programado. El buscador entrega quince resultados por página, cada página tarda unos dos segundos, y el reporte buscaba más de veinte frases.
Había arreglado el dato y había dejado la costumbre. El arreglo fue dejar de buscar. Ahora el servidor trae el texto de cada charla del día y se fija cuáles frases aparecen, tal como están escritas. Un día hábil entero tarda unos once segundos, y una frase ya no se confunde con una palabra suelta.
La frontera
De esos dos tropiezos salió la regla del título. El bot captura: mientras atiende, deja datos ordenados de lo que hizo. El MCP consume: todo lo que sea reporte, conteo o pregunta se arma después, leyendo.
La regla se prueba cuando llega un pedido. La tienda quiso que el bot etiquetara cada conversación según la etapa del flujo en la que estaba. Dije que no. Era meter la clasificación de un cliente en el prompt, y sumarle al modelo una tarea extra que cumple sólo a veces. La misma información sale de los eventos, completa y sin tocar el bot.
Tiene un límite, y conviene decirlo. El MCP sólo puede contar lo que alguien capturó, y la venta no está en ningún dato. El reporte sabe que una reserva se cerró, no que el equipo se cobró, así que no informa conversión a venta. Todavía no sé si la línea está bien puesta. Si algún día los traces no alcanzan, el arreglo va a ser que el bot capture mejor, no que el reporte adivine más.
Siete posts después, el sistema entero entra en una oración: el modelo escribe, el código decide, y la tienda puede preguntar por todo lo que quedó registrado.