Caso de estudio · Automatización del soporte al cliente
El agente de soporte dedicaba más contexto a las definiciones de herramientas que al propio ticket.
El agente de IA de un equipo de soporte estaba conectado a una docena de servidores MCP y ahogaba cada prompt en esquemas de herramientas. Pasar al Code Mode de onemcp devolvió el contexto al problema del cliente — y redujo el coste y la latencia de cada respuesta.
- Sector
- Soporte al cliente SaaS
- Equipo
- Organización de soporte de ~15 personas
- Stack técnico
- Zendesk · Stripe · Postgres · API interna de pedidos · Slack
# Resumen
- Sobrecarga de herramientas por solicitud reducida alrededor de un 90 %
- Esquema de herramientas por llamada de ~15 000 a ~500 tokens
- Menor coste y latencia en cada respuesta
Escenario ilustrativo inspirado en implementaciones habituales de onemcp. El equipo descrito es una composición y no un cliente nombrado; las cifras son representativas y no medidas.
Contexto
Un equipo de soporte SaaS había construido un agente de IA para clasificar y responder tickets. Para trabajar de verdad, necesitaba alcance: Zendesk para el ticket, Stripe para el cargo, Postgres y una API interna de pedidos para el estado de la cuenta, y Slack para escalar. Cada uno de ellos era un servidor MCP, cableado directamente en el agente.
El agente fue útil desde el primer día. También era lento y caro de un modo que el equipo no lograba explicar del todo — hasta que examinó qué contenía realmente cada prompt.
El reto
Cada servidor MCP al que el agente se conectaba inyectaba, en cada solicitud, su esquema de herramientas completo en el contexto. Con una docena de servidores conectados, eso suponía cientos de definiciones de herramientas y parámetros acompañando a cada ticket — lo necesitara o no el ticket en curso.
El coste se manifestaba de tres formas:
- Contexto desperdiciado. Unos 15 000 tokens de texto repetitivo de herramientas precedían a la pregunta real del cliente en cada prompt. En hilos largos, las definiciones desplazaban a la propia conversación.
- Mayor coste y latencia. Esos tokens de entrada se pagaban y procesaban en cada turno, multiplicados por miles de tickets a la semana.
- Más margen de error. Un prompt más grande y ruidoso daba al modelo más ocasiones de elegir la herramienta equivocada o de perder el hilo en un ticket de varios pasos.
El enfoque
El equipo situó todos los servidores del agente tras un único portal de onemcp e hizo que el agente dialogara con él mediante el Code Mode.
En lugar de precargar cada definición, el portal expone tres meta-herramientas:
search— encontrar las herramientas pertinentes para el ticket que se tiene delante.describe— obtener a demanda la firma exacta de esas herramientas.execute— ejecutar un breve script que las llama, en una sola ida y vuelta.
Así, un ticket de reembolso carga las herramientas de Stripe y de pedidos que necesita, y nada más. El catálogo completo sigue disponible — simplemente ya no se arrastra a cada prompt.
Los resultados
- Alrededor de un 90 % menos de sobrecarga de herramientas por solicitud. El esquema de herramientas por llamada bajó de unos 15 000 tokens hacia ~500. El ahorro se repite en cada turno de cada ticket.
- Respuestas más baratas y rápidas. Menos tokens de entrada por llamada suponían una factura más baja y una primera respuesta más rápida, sin retirar ninguna herramienta del alcance del agente.
- Un manejo multipaso más estable. Con el contexto puesto en el ticket y no en la caja de herramientas, el agente mantuvo el hilo a lo largo de reembolsos, consultas de cuenta y escalados.
El agente se volvió más rápido y más barato el mismo día del cambio, y no quitamos ni una sola herramienta. Simplemente dejó de cargarlas todas en cada mensaje.