Por qué rechazamos un ahorro del 96% en tokens
Encontramos un servidor MCP que ahorra un 96% en tokens. Utiliza una sola herramienta: execute_code. En lugar de llamar a funciones específicas, el agente escribe JavaScript para obtener datos.
Sobre el papel, gana. Para tareas complejas, la ejecución de código supera al llamado de herramientas en eficiencia.
Pero no lo adoptamos. En su lugar, mantuvimos nuestras herramientas discretas y con nombre.
He aquí por qué la elección obvia fue la elección incorrecta para nuestro agente.
El objetivo determina el diseño
La mayoría de la gente construye para modelos de frontera en una ventana de chat. Esos modelos tienen presupuestos de tokens enormes. Para ellos, la ejecución de código es la reina.
Nosotros construimos para un agente orientado a la voz basado en un modelo local pequeño (Hermes 3 8B) en un barco.
Para un modelo pequeño, la limitación no son los tokens. La limitación es la fiabilidad.
Si un modelo pequeño tiene dificultades para llamar a una herramienta sencilla, pedirle que escriba JavaScript correcto es una tarea mucho más difícil. execute_code sacrifica fiabilidad por tokens. No podemos permitirnos ese intercambio.
El problema de la última milla
La ejecución de código traslada la "última milla" del trabajo al agente. El agente debe:
- Filtrar los datos
- Ordenar los resultados
- Formatear la salida
Nuestras herramientas realizan este trabajo dentro del servidor. Por ejemplo, al preguntar sobre el estado de la batería, nuestra herramienta devuelve una cadena lista para texto a voz (text-to-speech). Dice "68 por ciento, 12,8 voltios" en lugar de números brutos.
Si usamos execute_code, el agente debe escribir la lógica para formatear ese discurso. Los modelos pequeños fallan en esto constantemente.
La regla de la ausencia
En un barco, los sensores se desconectan. En nuestro sistema, un sensor ausente devuelve un null limpio. Esto es una llamada exitosa.
En un modelo de ejecución de código, un sensor ausente suele lanzar un error. Si un modelo pequeño adivina algunas rutas incorrectas, activa los límites de error y rompe el agente. Las herramientas con nombre nos permiten convertir la ausencia en un éxito, no en un fallo.
Lista de verificación: Adoptar vs. Construir
Antes de adoptar o construir un servidor MCP, hazte estas preguntas:
• ¿Quién es el agente objetivo? (Modelo de frontera vs. Modelo local pequeño)
• ¿Cuál es la limitación principal? (Tokens vs. Fiabilidad)
• ¿Quién hace la última milla? (¿La herramienta formatea los datos o el agente?)
• ¿Cómo gestiona la ausencia? (¿Es un valor ausente un error o un null?)
• ¿Cuál es el coste de mantenimiento? (¿Estás heredando una base de código inactiva?)
No ignoramos el otro proyecto. Aprovechamos sus ideas. Tomamos su lógica de gestión de alarmas y de descubrimiento de rutas y la añadimos a nuestra hoja de ruta.
La eficiencia es genial, pero la fiabilidad es obligatoria cuando estás en el mar.
Fuente: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi