¿Y si romper el código de tus usuarios hoy te salva de un motín mañana?
Esa es la apuesta que acaba de hacer el creador de Charlotte. Con 111 estrellas —no es una multitud, pero sí usuarios reales— renombró las 43 herramientas de su servidor MCP. Fuera los dos puntos: charlotte:navigate. Adentro los guiones bajos: charlotte_navigate. Un commit. ¡Pum!
MCP —el Model Context Protocol, ese puente elegante entre agentes de IA y herramientas externas— exige nombres estrictos: letras, números, guiones bajos, puntos, guiones. Nada de dos puntos. Nunca. Pero los SDK tempranos lo dejaban pasar. Hasta que la v1.26.0 puso avisos en cada registro. ¿Arreglar ahora, con poquitos usuarios? ¿O después, entre docs, memoria muscular y antorchas?
Eligió ahora. Astuto.
¿Por qué lanzar el cambio disruptivo con solo 111 estrellas?
Los que salen lastimados son los que tienen prompts o configs personalizados que referencian nombres de herramientas como strings. Por ahora, es un grupo chico. En seis meses, será enorme.
Aquí brilla el genio de MCP. Los clientes —como Claude Desktop o Cursor— descubren las herramientas dinámicamente al conectar. El agente pregunta: “¿Qué traes?” Charlotte responde con la lista fresca. ¿Nombres de ayer? Puf. Desaparecidos. La mayoría actualiza sin drama.
Solo duelen los strings hardcodeados. Hoy, raros. Mañana, plaga.
Mi visión, que el original pasa por alto: esto es como el gran cambio al modelo de dispositivos en el kernel de Linux 2.6. Los early adopters refunfuñaron… y luego le agradecieron a Torvalds cuando el ecosistema se endureció. Charlotte apuesta lo mismo. Lanza quiebres frágiles de joven; forja acero después. Predicción osada: los servidores MCP que ignoren esto se romperán bajo hordas de agentes para 2025.
¿Y el spin del PR? Ninguno. Lógica cruda de dev, sin bombo. Refrescante.
Pero espera: la v0.6.0 trae más que un renombrado. Rellenado de formularios por lotes. Fin a los devoradores de tokens.
¿Por qué el rellenado de formularios por lotes destroza los costos de tokens en agentes de IA?
Imagina: formulario de contacto con 10 campos. ¿Antes de 0.6.0? Diez llamadas a herramientas. charlotte_type aquí, charlotte_select allá. Cada una arrastra ~4.000 tokens de overhead de schema. Por diez: 40k tokens tirados, antes de escribir “Jane Smith”.
¿Ahora? charlotte_fill_form se traga un array:
{ “fields”: [ { “element_id”: “inp-a3f1”, “value”: “Jane Smith” }, { “element_id”: “inp-b7c2”, “value”: “[email protected]” }, // etc. ] }
Una llamada. Maneja inputs, selects, checkboxes, fechas, colores. Detecta tipos automáticamente. ¿Para un tester volando 50 páginas? 500 llamadas se achican a 50. Los tokens se multiplican: los ahorros explotan a escala.
Es arquitectura pura: los round-trips de MCP matan ventanas de contexto. Agrúpalos, y los agentes respiran. ¿Por qué tardó tanto? Ceguera a tokens, seguro. Los agentes eran juguetes; ahora son bestias de carga.
Chromium perezoso. Arreglo brutal.
Los servidores abrían navegadores al arrancar. Bien para juguetes. ¿Pero Cursor? ¿Claude Desktop? Encienden todo lo del config. ¿Navegador idle? Hoguera de RAM… para sesiones de código donde nunca navegas.
¿Ahora? Lanzamiento en la primera llamada a herramienta. ¿Idle? Mudo. Sin navegador, sin quema.
Escritura lenta sigue. charlotte_type suma character_delay. ¿Por qué? Sitios con búsqueda en vivo, autocompletado, validación… ignoran pegados. Necesitan disparos de teclas. ¿Trivial? Diles eso a tus tests de agente fallando.
Soporte a Node 20. Bajó el requisito de 22 —innecesario. Las masas LTS celebran.
Cómo un bug sigiloso de JS embrujó tres archivos
Luego los fantasmas: new Function(‘return ’ + expr). ASI —Automatic Semicolon Insertion— convertía multi-statements en null. Golpeó evaluate.ts en v0.4.1. Arreglado.
¿wait-for.ts? Mismo veneno, v0.5.0.
¿pollUntilCondition? Tercer strike, v0.6.0. Todos migrados a CDP Runtime.evaluate.
Lección clavada: busca el patrón con
