Dejá que Claude maneje tu barra de menú.
Toolbox corre un servidor MCP local, así un agente puede listar tus widgets y usarlos: agregar una tarea, sumar a una nota, arrancar un timer, revisar qué repos dejaste sin commitear. Apagado por default, opt-in widget por widget, solo loopback — y tus scripts locales nunca están en el menú.
Dos tools, no cien.
Unos veinte widgets con un puñado de acciones cada uno serían cerca de cien tools. Darle a un modelo una lista tan larga es caro en contexto y lo hace peor eligiendo la correcta. Así que el servidor publica exactamente dos: una para descubrir — qué widgets existen y qué puede hacer cada uno, con los schemas de argumentos completos cuando el agente pregunta por uno específico — y una para ejecutar.
El costo es un roundtrip extra. El beneficio es que la lista de tools mantiene el mismo tamaño tengas cinco widgets instalados o treinta, y el modelo recibe un índice compacto en vez de una pared de schemas.
Cuando va a actuar, toma el mismo camino que tu click. Las acciones mutan los mismos stores en los que escribe la interfaz, así que una tarea que agrega Claude persiste en disco, aparece en tus otras ventanas y se sincroniza como cualquier otra. Dos reglas mantienen seguros los reintentos: las acciones fijan un estado destino explícito en vez de invertir — "completar esto" siempre significa hecho, así que una llamada repetida no puede des-completarlo — y cuando una referencia es ambigua, la acción se niega y lista los candidatos en lugar de elegir uno.
- Tool de descubrimiento: widgets, acciones y schemas a pedido
- Tool de ejecución: una acción más sus argumentos
- La lista de tools no crece a medida que instalás widgets
- Las mutaciones van por el mismo store que la interfaz
- Estado destino explícito, así un retry nunca es destructivo
Widget por widget, y nunca ampliables desde adentro.
"El agente puede usar tus widgets" solo tranquiliza si podés decir cuáles. Hay dos capas: lo que declara el autor de cada widget, y tu propio override en esta máquina.
El caso normal, para acciones que solo leen o escriben los datos del propio widget — tareas, notas, checklists, un timer. Visible al agente, y podés ocultar cualquiera.
Legítimo pero que merece un sí deliberado: cosas que salen a la red o sondean tu filesystem. Ocultas hasta que las prendés, y mostradas destildadas con una nota que lo aclara.
Para cualquier cosa destructiva. Oculto, y no hay toggle — no es "apagado por default", es no disponible. Tu override se ignora para estos, a propósito.
El agente no puede ampliar su propio alcance
Ninguna tool expuesta puede escribir la config de visibilidad del agente. Claude no puede prender un widget que dejaste apagado, des-ocultar uno que ocultaste, ni llegar a uno bloqueado — el único camino es la interfaz local: click derecho en un widget, o Ajustes → Agente. Es una regla que el código sostiene, no una intención.
Los scripts locales están excluidos, punto
El widget de Automatizaciones puede correr scripts en tu máquina cuando vos hacés click en un tile. Eso se le niega al agente en dos niveles: los tiles de script se le anuncian como no ejecutables, y la acción de correr los rechaza igual — incluso si vos habilitaste los scripts locales para tu propio uso. No es una preferencia que puedas prenderle al agente.
El catálogo se señaliza, no se instala
Antes, si pedías un widget que no tenías, al agente se le decía que no existe. Ahora se le dice dónde encontrarlo — recorrer el catálogo es de solo lectura. Instalar es una tool aparte, sensible, que dice en voz alta que carga código y que hay que consultarlo con vos primero, y el paquete igual tiene que pasar la verificación de firma y de hash en la capa nativa. Señalizar no es instalar.
Apagar un widget se lleva sus tools
La visibilidad ante el agente sigue al widget. Lo deshabilitás y sus acciones se des-publican al instante, sin reiniciar nada — y desinstalar un widget instalable se lleva sus tools con él. No queda una entrada vieja dando vueltas para que un modelo la intente.
Los widgets que hoy tienen tools.
Más un grupo core para el container en sí: spaces, tabs, reordenar y mover widgets, y recorrer el catálogo de solo lectura.
Los widgets instalables también pueden exponer tools — Git Status fue el primero, y varios widgets del catálogo (cripto, acciones, clima, traductor) declaran las propias. Instalás uno y sus tools aparecen sin reiniciar la app.
Un comando, o un bloque de JSON.
Prendés el servidor en Ajustes → Agente. Genera un token y te muestra las dos formas de conectarte, ya completadas con él — un comando de terminal para Claude Code, y un bloque de config para Claude Desktop, Cursor o VS Code. Copiás el que corresponda a tu cliente.
El transporte es HTTP streamable plano sobre loopback, así que no hay nada que instalar al lado ni un proceso wrapper que mantener vivo. Regenerar el token corta a todos los clientes que tenían el viejo.
- Anda con Claude Code, Claude Desktop, Cursor y VS Code
- Nada extra que instalar — el servidor es la app
- Regenerar el token revoca los clientes viejos al instante
- Combina bien con LLM Quota si estás dosificando un plan
claude mcp add --transport http toolbox \ http://127.0.0.1:41434/mcp \ --header "Authorization: Bearer <token>"
{
"mcpServers": {
"toolbox": {
"type": "http",
"url": "http://127.0.0.1:41434/mcp",
"headers": {
"Authorization": "Bearer <token>"
}
}
}
} Un puerto local sigue siendo un puerto.
Abrir un listener en tu máquina merece más que un "es solo localhost", así que acá está exactamente qué hace. El toggle viene apagado y con él apagado el servidor nunca arranca. Prendido, bindea solo 127.0.0.1 — nunca tu red local — y cada request tiene que traer un bearer token, generado con 128 bits de aleatoriedad y comparado en tiempo constante.
Arriba de eso hay una allowlist de Host y Origin, que existe para frenar el DNS rebinding: una página web que resuelve un dominio que ella controla a tu dirección de loopback no puede llegar al servidor, porque los requests que llegan con un Host no-loopback se rechazan antes de que corra la autenticación. Los cuerpos de request tienen tope, y todo lo que no sea el POST esperado se rechaza de plano.
Dónde vive el token, con honestidad. Está en texto plano en un archivo de config local del dispositivo — el mismo modelo que usan las herramientas de línea de comandos de GitHub, npm y AWS. Protege un puerto loopback, y quien puede leer ese archivo ya está corriendo código como vos. Ese archivo está deliberadamente excluido del sync en la nube, así que prender el servidor en una máquina nunca lo prende en otra y el token no viaja.
- Apagado por default; el servidor no arranca si está apagado
- Bindea solo 127.0.0.1 — sin exposición a la LAN
- Bearer token de 128 bits, comparación en tiempo constante
- Allowlist de Host/Origin contra DNS rebinding, chequeada antes de la auth
- Local del dispositivo: nunca se sincroniza, opt-in por máquina
Preguntas, respondidas.
¿Qué es MCP, en un párrafo?
El Model Context Protocol es una forma estándar de que un cliente de IA — Claude Code, Claude Desktop, Cursor, VS Code — descubra y llame herramientas que viven fuera de él. Un programa expone un conjunto de tools con descripciones y schemas de argumentos; el modelo lee esa lista y decide cuándo llamar a una. Toolbox implementa el lado servidor, así que tus widgets se vuelven herramientas que el modelo puede usar.
¿Viene prendido?
No. Está apagado hasta que lo prendés en Ajustes → Agente, y con el toggle apagado el servidor ni siquiera se pone a escuchar. La preferencia es local del dispositivo, guardada en un archivo que está deliberadamente excluido del sync de iCloud: prenderlo en una máquina no lo prende en ninguna otra, y el token nunca sale de la máquina donde se generó.
¿El agente puede correr scripts en mi máquina?
No. El widget de Automatizaciones puede correr scripts locales cuando vos hacés click en uno, y esa capacidad se le niega al agente específicamente: un tile de script se le lista como no ejecutable, y la acción de correr lo rechaza igual — independientemente de que vos hayas habilitado los scripts locales para tu propio uso. No es una preferencia que puedas prenderle al agente, porque spawnear procesos arbitrarios en nombre de un modelo es un footgun, no una feature.
¿El agente puede instalar widgets solo?
Los puede encontrar, no instalarlos en silencio. Listar el catálogo es de solo lectura, y la tool de instalar está marcada como sensible: su propia descripción dice que instalar carga código y que hay que preguntarte primero. Por abajo, la instalación está gateada igual que una manual — el paquete tiene que pasar la verificación de firma minisign y de hash en la capa nativa, así que un widget sin firmar o adulterado se rechaza sin importar quién lo pidió.
¿Por qué el agente ve solo dos tools?
Porque unos veinte widgets con un puñado de acciones cada uno son cerca de cien tools, y volcar eso en el contexto de un modelo lo hace a la vez caro y peor eligiendo. Así que el servidor publica dos: una para descubrir qué existe — widgets y sus acciones, con los schemas completos cuando preguntás por un widget específico — y una para ejecutar. Cuesta un roundtrip extra y significa que la lista de tools no crece a medida que instalás más widgets.
¿El agente puede darse más acceso?
No, y esto está aplicado en el código, no prometido. Ninguna tool expuesta puede escribir la configuración de visibilidad del agente: un agente no puede prender un widget que dejaste apagado, des-ocultar uno que ocultaste, ni tocar uno que su autor bloqueó del agente por completo. El único camino para cambiar lo que el agente ve es la interfaz local — click derecho en un widget, o Ajustes → Agente.
¿Una acción del agente se comporta distinto a un click?
Va por el mismo camino. Las acciones mutan los mismos stores que muta la interfaz, así que una tarea que agrega Claude persiste, aparece en tus otras ventanas y se sincroniza igual que una que escribiste vos. Dos reglas de diseño hacen que los reintentos sean seguros: las acciones fijan un estado destino explícito en vez de invertir el actual — "completar esto" siempre significa hecho, así que un retry no puede des-completarlo — y cuando una referencia es ambigua, la acción se niega y lista los candidatos en vez de adivinar.
¿Es gratis?
Sí. Webstarted Toolbox es gratis y no pide cuenta, y el servidor MCP es parte de la app — no hay nada extra que comprar ni en lo que registrarse.
Descargá Webstarted Toolbox
Gratis. El servidor MCP viene integrado — lo prendés en Ajustes → Agente. macOS 12+ y Windows 10+.
Un ícono, muchas mini-tools
Este es solo uno de los widgets de Webstarted Toolbox. Mirá los demás: