🧪 Beta pública. killBottleneck está completo en funciones y en beta — tanto la versión en la nube como la autoalojada; es una y la misma aplicación. Lo que estamos probando aquí es la parte autoalojada: instalación, proxies inversos, tu propio SMTP, actualizaciones. Instálala (Inicio rápido más abajo), intenta romperla y cuéntanos qué ha pasado: errores → Issues, ideas → Discussions. La v1.0 se publica cuando la beta se asiente.
Una imagen visual de tus proyectos, tu empresa y sus procesos: mapas de objetivos en los que personas y agentes de IA trabajan juntos, enteramente en tu propio servidor: tus datos nunca salen de la empresa. Abierto con el espíritu del código abierto, pero sin el derecho a revenderlo como servicio alojado; consulta la Licencia.
Nada de esto llama a casa. En una instalación predeterminada, el servidor no envía ninguna solicitud a ningún sitio, y la aplicación no carga nada de una CDN de terceros — fuentes incluidas, se sirven desde tu propia instancia. Todo lo que podría salir de tu red es algo que tú activas:
Solicitud saliente | Cuándo ocurre | Desactivación |
GitHub Releases API | Comprobación de versión, desde el navegador del usuario — no del servidor |
|
El endpoint de IA que configures | Solo con |
|
Google (inicio de sesión, selector de Drive) | Solo cuando configures | déjalas vacías (predeterminado) |
No hay telemetría, ni analíticas, ni comprobación de licencia.
Quién realiza un paso: una persona o una automatización — incluye el contrato de webhook para tus propios agentes
Mover un proyecto a otro sitio (exportación/importación JSON)
Apariencia (temas) · Notificaciones · Zona horaria y plantillas recurrentes
Datos y copia de seguridad · Equipo · Registro y clave de registro
Iniciar sesión con Google · Adjuntos · Correo electrónico (SMTP)
Solo necesitas Docker. Entonces:
cp .env.example .env # optional — the defaults are fine
docker compose up -dkillBottleneck se ejecuta en http://SERVER-IP:8090. Los compañeros de la red local solo tienen que abrirlo en un navegador.
El primer usuario que se registre se convierte automáticamente en administrador. Los demás pueden registrarse ellos mismos, o el administrador los invita desde Administración (esto crea una cuenta con una contraseña temporal para entregar).
Related MCP server: stablebaseline-mcp
Un editor completo de mapas de objetivos (nodos, aristas, estados, notas), varios mapas por usuario, comentarios en los objetivos, compartir mapas con compañeros (lectura / edición), mapas públicos, exportación a imagen/PDF.
El panel «Mi día» (tanto en la página de inicio como en la página de Tareas): un resumen clicable de lo vencido / de hoy / dentro de una semana / que bloquea a otros, calculado en vivo a partir de tus datos; santos junto a la fecha; una exportación PNG vertical para el móvil — tanto completa (con nombres de tareas) como anónima (nombres ocultos, para redes sociales). Con HTTPS también tienes Compartir… (el diálogo nativo Web Share de tu teléfono, sin servicios de terceros).
Registro de tiempo: un temporizador ⏱ en la barra superior (un clic inicia una medición «vacía» — el proyecto/cliente/objetivo se asigna mientras se ejecuta o después), un temporizador en cada tarea y en cada objetivo de un mapa (medir nunca cambia un estado — es puramente complementario), un panel «Registro de tiempo» a la izquierda con los registros (de–a, asignación retroactiva), un diálogo «Tiempo trabajado» en el menú de usuario (hoy/esta semana, desglosado por proyecto y cliente), un registro de clientes (proyecto→cliente, para que el tiempo también se acumule por cliente), y autoparada para temporizadores olvidados después de 12 h. Comportamiento de la bandeja de entrada: una medición sin asignar detenida con una nota (p. ej., «llamada con el cliente») también se guarda como idea en tu cajón.
La misma instancia, abierta en un móvil, cambia a una vista simplificada: las tareas de hoy, márcalas, añade una y lee mensajes — sin lienzo de mapa con el que luchar en una pantalla pequeña. Puedes volver a la vista completa en cualquier momento, y la aplicación se puede añadir a la pantalla de inicio (con HTTPS) para que se comporte como una nativa.
Más en la Guía de la vista simplificada.
El asesor de IA (crear un mapa a partir de un objetivo, expandir ramas, chatear sobre un mapa, resumen de proyecto con IA,
sugerir tareas a partir de un objetivo, un mapa desde texto/voz) se activa en .env mediante KB_AI_PROVIDER:
api — un servicio de IA remoto compatible con el contrato de API de killBottleneck: introduce la
dirección y el token que te ha dado tu proveedor. Sin GPU propia y sin mantenimiento.
ollama — tu propio modelo local: instala Ollama, descarga un modelo
(ollama pull gpt-oss:20b) y configura
KB_AI_URL=http://IP:11434 + KB_AI_MODEL=gpt-oss:20b.
Todo se ejecuta en tu lado, ningún dato sale de tu red. (Indicaciones básicas; la transcripción
de voz no está incluida.)
custom — tu propio endpoint que respete el mismo contrato de API.
Cuando se usa la IA, los datos del mapa se envían al endpoint que hayas elegido; con none (el valor predeterminado) nada
sale jamás de tu servidor.
Ánimo diario con IA (una línea en el panel «Mi día»): 1–2 frases que priorizan «lo que
bloquea a otros → vencido → hoy», con algún proverbio ocasional. Se genera por la mañana
mediante un trabajo cron (KB_SUMMARY_HOUR, por defecto 6) solo para cuentas que hayan iniciado sesión en los últimos
KB_SUMMARY_ACTIVE_DAYS días (por defecto 14, 0 = todos); para el resto se genera cuando
abren la aplicación. Opcionalmente, un modelo separado (más pequeño/rápido) solo para los resúmenes:
KB_SUMMARY_PROVIDER/URL/MODEL/TOKEN — sin ellos se usa la configuración general de IA anterior.
El panel funciona completo sin IA, solo sin esta línea. La IA nunca enumera
listas de tareas (estas se calculan a partir de tus datos y son clicables) y los nombres de las tareas se sanean
antes de incluirlos en la indicación.
killBottleneck incluye un servidor MCP integrado (mcp/): conecta tu asistente de IA a tu
propia instancia y los mapas se construyen conversacionalmente — «haz un mapa a partir de estas notas de reunión»,
ediciones masivas, marcar lo hecho. Funciona igual para instancias autoalojadas y alojadas,
solo cambia la dirección.
En la aplicación: menú de usuario → Claves API → una clave nueva con el alcance Lectura y escritura (Solo lectura es suficiente para acceso de lectura). El token se muestra solo una vez. Recomendado: ponle una fecha de caducidad a la clave y revócala cuando dejes de usarla.
Nada que instalar: el servidor está en npm como
killbottleneck-mcp, así que npx lo descarga
en el primer uso. (¿Prefieres ejecutarlo desde este repositorio? cd mcp && npm install y usa
node /absolute/path/mcp/index.js en lugar del comando npx de abajo.)
Regístralo con tu asistente:
Claude Code:
claude mcp add killbottleneck \
-e KB_URL=http://SERVER-IP:8090 \
-e KB_API_KEY=kb_user_... \
-- npx -y killbottleneck-mcpClaude Desktop (claude_desktop_config.json → mcpServers):
{
"mcpServers": {
"killbottleneck": {
"command": "npx",
"args": ["-y", "killbottleneck-mcp"],
"env": {
"KB_URL": "http://SERVER-IP:8090",
"KB_API_KEY": "kb_user_..."
}
}
}
}Herramientas: list_maps, get_map, create_map, add_nodes, update_node, delete_node
(además de herramientas de reglas). Un objetivo con un asignado o una fecha límite ES una tarea — no hay
registros de tareas separados.
Seguridad: una clave da acceso a los mapas de su propietario (exactamente como en la aplicación); los MAPAS compartidos y de equipo deliberadamente no son accesibles a través de una
clave (por ahora), y la administración, los ajustes de IA y los usuarios nunca lo son. Las escrituras pueden añadir/editar/eliminar
objetivos y tareas; un mapa completo no se puede eliminar a través de la API, ni tampoco el vértice de
un mapa. Límites: 120 lecturas + 30 escrituras por minuto por clave, como máximo 200 nodos por llamada, como máximo 20
claves por cuenta. Trabajar junto a un editor abierto se gestiona con detección de conflictos (el editor
ofrece recargar, el asistente recarga el mapa por sí mismo). Nota: add_nodes vuelve a ejecutar el diseño
de todo el mapa. La salida de las herramientas MCP está en inglés (los asistentes siempre la entienden); los mensajes de error del servidor
llegan en el idioma de tu cuenta.
Para cada objetivo de un mapa puedes indicar si lo hace una persona o una automatización. Que detrás de esa automatización haya un agente de IA o un trabajo cron programado no es problema tuyo — quien lo construye lo sabe.
Importante: la persona responsable de un objetivo es siempre un humano. Incluso para un paso automatizado hay alguien responsable, que recibe las notificaciones y a cuyo «Mi día» cuenta el objetivo. La automatización hace el trabajo; una persona responde por él.
Para un paso automatizado también registras qué automatización lo hace — es un registro de cómo están las cosas hoy («n8n ya hace este paso por nosotros»), no un comando. Eso es lo que permite ver de un vistazo qué partes del mapa las hacen personas y cuáles las hacen máquinas.
En cualquier objetivo puedes marcar una solicitud para que se automatice el paso y, opcionalmente, añadir una frase explicando por qué. La solicitud va al gestor de agentes de IA — una opción separada en un usuario (Gestión de usuarios → Gestor de IA), independiente de su rol; tanto un administrador como un miembro ordinario pueden tenerla junto con su rol.
Una vez que el gestor construye la automatización y la registra en el objetivo, la solicitud se guarda sola y el solicitante recibe un mensaje de que su objetivo ahora está automatizado. El ciclo completo:
person: ☑ I would like this automated ("I upload subtitles by hand, 20 minutes")
↓
the AI manager gets a notification → decides → builds an n8n workflow
↓
the manager records it on the goal: "n8n — subtitle translation"
↓
the requester gets a notification: "your goal is now automated by n8n — subtitle translation"Puedes subir archivos a cualquier objetivo. En un objetivo con una automatización, subir un archivo la inicia de inmediato — en lugar de rellenar un formulario en otro sitio, simplemente adjuntas lo que necesite procesarse (normalmente subtítulos, material fuente, una exportación).
Los adjuntos solo son visibles para las personas con acceso al proyecto. Los archivos están protegidos: el enlace por sí solo no revela nada.
El gestor de agentes de IA (o un administrador) mantiene un directorio de automatizaciones en Registro de agentes de IA: nombre, dirección de webhook, secreto de firma, activado/desactivado. En un objetivo, la automatización se elige por nombre — los miembros del equipo nunca ven la dirección ni el secreto. Cuando el nombre de un objetivo coincide con un agente del registro, killBottleneck puede iniciarlo por sí mismo.
Who may start it. Cada agente puede llevar una lista de direcciones de correo electrónico permitidas. Una lista vacía significa que la automatización puede ser iniciada por cualquiera que pueda editar cualquier mapa — dentro de una empresa eso suele estar bien, pero restringe en una instancia en la que dejes entrar a contratistas: quien pueda editar un mapa podría, de otro modo, iniciar cualquiera de tus flujos de trabajo de n8n e introducir su propio texto en ellos (el título y la descripción del objetivo van al agente en la carga útil).
Los archivos adjuntos están limitados a 200 archivos por proyecto, más un límite de espacio opcional para TODA la instancia (KB_FILES_MB en MB; 0 = cargas deshabilitadas por completo, vacío = sin límite — establece uno en un disco compartido para que una instancia alojada no pueda llenarlo). ⚠️ El antiguo FLOWMAP_MAP_FILES_MB era una cuota POR PROYECTO con un valor predeterminado de 200 MB — si lo tienes configurado, todavía se aplica, pero sin él ahora NO hay ningún límite de espacio.
Una automatización se inicia cuando:
se sube un archivo adjunto al objetivo, o
llega el turno del objetivo — estaba esperando a sus subobjetivos y todos acaban de completarse, o
alguien cambia manualmente el objetivo a «en curso» (así es también como se reintenta una ejecución fallida)
Una automatización en ejecución no se iniciará por segunda vez hasta que informe de vuelta o expire.
La solicitud saliente (POST a la dirección del agente, con una cabecera X-Signature = HMAC-SHA256 de todo el cuerpo usando el secreto del agente):
{
"run_id": "…", "run_token": "kbr_…",
"callback_url": "https://your-instance/api/kb/agent-callback",
"files_url": "https://your-instance/api/kb/agent-files?run_token=kbr_…",
"files": [{ "id": "…", "name": "subtitles.sbv", "size": 1234, "url": "https://…?run_token=kbr_…" }],
"map_id": "…", "map_title": "…",
"node_id": "…", "node_title": "…",
"description": "…", "deadline": "2026-08-01",
"owner": "responsible@company.com", "triggered_by": "who@company.com"
}El agente descarga archivos usando su token de ejecución; files_url es un listado en vivo, por lo que también ve los archivos adjuntos añadidos mientras se ejecuta. El token expira una vez que se informa del resultado.
Informe de vuelta (POST a callback_url, sin inicio de sesión — el token de ejecución lo autentica):
{ "run_id": "…", "run_token": "kbr_…", "status": "done", "result": "Translated into 3 languages" }status es done o failed. Un token es válido para un objetivo y un informe — una segunda llamada con el mismo token no se procesará.
Después de done, el objetivo se completa, y eso pone en marcha el resto del proceso: el siguiente objetivo se desbloquea y la persona responsable es notificada de que puede empezar. Si ese siguiente objetivo también está automatizado, se inicia de inmediato — así los pasos se encadenan.
Establece la dirección a la que el agente debe llamar de vuelta. callback_url lo ensambla el servidor, no el navegador — sin configuración usa la «URL de aplicación» de PocketBase, que tras la instalación es http://localhost:8090. Un agente que se ejecute en otra máquina se llamaría a sí mismo, y la ejecución se colgaría hasta agotar el tiempo. En .env:
KB_PUBLIC_URL=https://killbottleneck.yourcompany.com
KB_AGENT_TIMEOUT_MIN=90Cualquier dirección a la que el agente pueda llegar sirve — en una configuración autoalojada, http://192.168.1.10:8090 en la LAN es perfectamente válida. Las instancias alojadas (killBottleneck Cloud) lo tienen configurado automáticamente.
¿Tu n8n está en la misma red? El servidor llama a la dirección del webhook, lo que lo convierte en un clásico vector de escaneo de red interna — por lo que por defecto killBottleneck se niega a llamar a direcciones privadas (10.x, 192.168.x, 172.16–31.x, localhost, metadatos de la nube). En una configuración autoalojada donde n8n se ejecuta junto a killBottleneck, permítelo:
KB_ALLOW_PRIVATE_WEBHOOKS=1Sin esto, la ejecución se marca como fallida y el gestor de agentes de IA recibe un mensaje explicando el motivo. Un agente debe tener su secreto rellenado — sin él, la solicitud se firmaría con una clave vacía y el destinatario no tendría protección alguna, por lo que killBottleneck rechaza esa ejecución de plano. La dirección efectiva actual se muestra siempre al final del registro de agentes de IA, que te avisa cuando apunta a localhost. Esto solo afecta a las automatizaciones — si no las usas, no necesitas configurar esta variable.
El estado de una ejecución es visible directamente en el diálogo del objetivo — pendiente / en ejecución / completado / fallido, con el motivo en caso de fallo. Una ejecución se reinicia volviendo a cambiar el objetivo a «En curso».
Qué significa cada estado:
Estado | Qué está ocurriendo |
pendiente | la ejecución está en cola y sale en menos de un minuto (un único guardado de mapa envía como mucho unos pocos webhooks, así que nadie se queda esperando) |
en ejecución | el agente ha asumido el trabajo y aún no ha informado de vuelta |
completado / fallido | el agente informó de un resultado, o la ejecución expiró |
Una ejecución que no informa de vuelta en KB_AGENT_TIMEOUT_MIN (90 por defecto) minutos es marcada como fallida por un vigilante, que notifica tanto a la persona responsable como a los gestores de agentes de IA — así un objetivo nunca se queda colgado en silencio.
Las causas más comunes de fallo: el agente no está en el registro o está deshabilitado; no tiene secreto; su dirección apunta a una red privada y falta KB_ALLOW_PRIVATE_WEBHOOKS=1; o el webhook es inalcanzable. Los detalles (incluidos los errores de conexión) están en el registro del servidor — docker compose logs killbottleneck — no se muestran deliberadamente en la aplicación.
Un proyecto puede exportarse a un archivo .json e importarse en otro lugar — entre colegas y entre instancias. En el editor: Exportar → Exportar JSON, eligiendo con nombres o sin nombres. La importación está en el menú junto al botón «Nuevo proyecto».
Lo que contiene el archivo: el título, la descripción, toda la estructura de objetivos (incluidos estados, fechas límite, quién realiza cada paso y las solicitudes de automatización) y las tareas adjuntas. La opción «sin nombres» elimina tanto a los responsables como a los asignados — los nombres de las automatizaciones permanecen, ya que describen el proceso.
Cambiando desde Asana o Trello: la misma importación también acepta una exportación de proyecto de Asana (CSV) y una exportación de tablero de Trello (JSON). Las secciones/listas se convierten en ramas del mapa, las tareas/tarjetas en objetivos, las subtareas y listas de verificación en objetivos hijos; los estados (completado), las fechas límite, las descripciones y — para Asana — los asignados se transfieren (los correos electrónicos desconocidos para esta instancia se eliminan y se cuentan). Todo se convierte localmente en el navegador — nada llama a Asana ni a Trello. Límite: 400 elementos por archivo.
Lo que no se transfiere: archivos adjuntos, comentarios, uso compartido, archivado y series de numeración. Una importación siempre crea un proyecto nuevo propiedad de quien lo importa, regenera los identificadores de los objetivos (para que no colisionen con el original) y no comparte nada con nadie ni envía notificaciones — tienes que compartir el proyecto manualmente para colaborar en él. Las asignaciones a direcciones de correo electrónico que no existen en esta instancia se descartan, y la importación te dice cuántas.
En el menú del avatar → Apariencia, cada usuario elige un skin: Indigo (predeterminado), High contrast, Terminal o Paper. La elección se guarda en la cuenta, por lo que se aplica en todos los dispositivos, tanto en modo claro como oscuro, y también en la vista lite simplificada (el selector allí está en el pie de página).
Skins personalizados: un skin es un pequeño archivo JSON (formato kb-skin v1) — un conjunto de colores (HSL), fuentes y radio de las esquinas. El diálogo de Apariencia puede exportar el skin actual (en el caso de uno integrado, su definición — «cógelo y retócalo») e importar el de otra persona, desde un archivo o pegándolo. Por diseño no es CSS arbitrario: los valores pasan una lista blanca tanto en el cliente como en el servidor, por lo que un skin compartido no puede ejecutar ni enviar nada. Nunca se descargan fuentes web — solo se usan las fuentes incluidas con la aplicación y las fuentes del sistema; una fuente desconocida retrocede sin problema a la siguiente en la pila.
Aspecto de empresa: un administrador establece el skin predeterminado para toda la instancia en la administración de la organización — se aplica a todos los que no han elegido el suyo, incluida la pantalla de inicio de sesión. La elección de cada usuario siempre tiene prioridad.
Lo que un skin no cambia en v1 (por diseño): los colores de estado (rojo/ámbar/verde = retrasado/en curso/completado siguen siendo igualmente legibles en todas partes). La exportación del mapa (PNG/PDF) es fiel a la pantalla — se captura con el skin activo y el modo claro/oscuro, incluido el color de fondo; solo se omite el arte del fondo. El PDF del panel del proyecto y la imagen de «Mi día» permanecen deliberadamente claros para poder enviarse a cualquiera.
Skins de la comunidad y el editor de skins de código abierto: https://github.com/tengolabs/killbottleneck-skins — los skins son datos libres (CC0), el editor es MIT. Prueba el editor directamente en tu navegador, sin instalar nada: https://tengolabs.github.io/killbottleneck-skins/.
La campana en la cabecera muestra los últimos 20 eventos; la lista completa con filtros y paginación está en /notifications. Ahí también se encuentran los ajustes de notificación, para que cada usuario pueda activar o desactivar tipos individuales.
Las notificaciones se envían por: una tarea o un objetivo que se te asigna (incluso en un mapa que ya existe), un comentario en una tarea o un objetivo, un proyecto que se comparte contigo, un objetivo en espera que se desbloquea, una fecha límite próxima o incumplida (un resumen al día, no uno por elemento), una solicitud de automatización y su cumplimiento, una automatización que termina o falla, y un temporizador que se detiene automáticamente.
Los recordatorios de fechas límite se envían por la mañana; configura la hora con KB_DEADLINE_HOUR (7 por defecto, hora local del contenedor). Las notificaciones leídas se eliminan después de 30 días.
El canal de correo electrónico está listo, pero solo se activa una vez que SMTP está configurado (ver más abajo) — hasta entonces aparece atenuado en los ajustes.
Una plantilla puede configurarse para que se cree un proyecto a partir de ella automáticamente (p. ej., «todos los lunes» o «el día N del mes»). Para que el «lunes» y la hora de creación coincidan con tu hora local, configura esto en .env:
TZ=Europe/Prague # your time zone (empty = UTC)
KB_AUTO_HOUR=5 # the hour (0–23) from which projects are created on a given daySi el servidor no estaba despierto a esa hora (estaba apagado), el proyecto se crea a la siguiente hora posterior del mismo día — no se omite.
La zona se aplica a toda la instancia — para un equipo repartido entre zonas se usa la zona del servidor, no la de cada usuario.
Las tareas recurrentes (que mueven la fecha límite al completarse) se calculan deliberadamente en UTC, de modo que cruzar la medianoche o un cambio de hora no las desplace un día.
Todos los datos viven en la carpeta ./pb_data (SQLite + archivos subidos). Usa el script incluido para hacer una copia de seguridad:
./backup.sh # creates kb-backup-YYYY-MM-DD.tgz
./backup.sh restore FILE # restores data from a backup(A mano: para hacer una copia, copia la carpeta pb_data; para restaurarla, vuelve a colocarla.)
Una instancia = un equipo. Roles: Administrador (gestiona usuarios y roles, ajustes de organización — nombre y logotipo), Gestor (invita miembros, ve y gestiona todas las tareas), Miembro (sus propias tareas y mapas compartidos). Puedes invitar a personas desde Administración o directamente desde la página de Tareas.
La primera cuenta que se registre se convierte en el administrador. Si la instancia es accesible desde internet, establece KB_SETUP_CODE en .env — a partir de entonces, todo registro requiere esa clave, de modo que no cualquiera que conozca la dirección pueda crear una cuenta. Entrega la clave a las personas a las que quieras dejar entrar; además, un administrador puede invitar usuarios directamente (una invitación no necesita la clave). Vacío = registro sin clave.
Los usuarios pueden iniciar sesión con Google en lugar de correo electrónico y contraseña. Para configurarlo:
En Google Cloud Console ve a APIs y servicios → Credenciales → Crear credenciales → ID de cliente de OAuth → tipo Aplicación web.
En URIs de redirección autorizadas añade: https://YOUR-DOMAIN/api/oauth2-redirect
Copia el ID de cliente y el secreto de cliente en .env:
KB_GOOGLE_CLIENT_ID=…apps.googleusercontent.com
KB_GOOGLE_CLIENT_SECRET=…docker compose up -d — el botón «Iniciar sesión con Google» aparece solo.
Variables vacías = el inicio de sesión con Google está desactivado (el botón no se muestra). En una instancia con una clave de registro, el inicio de sesión con Google es solo para usuarios existentes: no se puede crear una cuenta nueva a través de Google (no hay forma de introducir la clave), por lo que la cuenta debe crearse primero con la clave.
Puedes fijar un archivo subido o un enlace (Drive, OneDrive, SharePoint, un correo electrónico concreto, cualquier cosa en https://) a cualquier objetivo. Un enlace tiene tres ventajas: no ocupa espacio, el equipo siempre abre la versión actual y el archivo permanece donde lo tengas.
Cuánto espacio pueden ocupar los archivos subidos lo determina KB_FILES_MB: se aplica a toda la instancia, no por proyecto:
Valor | Comportamiento |
vacío | sin límite (el valor predeterminado para autoalojamiento: es tu disco) |
un número | el tope en MB, p. ej. |
| subidas desactivadas, solo archivos adjuntos como enlaces |
Las instancias alojadas se ejecutan con 0: así el proveedor no guarda tus documentos, solo enlaces a ellos. Un enlace debe empezar por http:// o https://; una ruta de unidad de red (\\server\folder) no se abrirá desde un navegador por razones de seguridad, por lo que eso pertenece a la descripción.
SMTP se configura en la interfaz de administración de PocketBase: http://SERVER-IP:8090/_/ → Ajustes → Configuración de correo (la cuenta de superusuario se crea en el primer inicio: encontrarás el enlace en docker compose logs). Con SMTP configurado:
se envía una invitación a un nuevo usuario por correo electrónico (con un enlace para establecer una contraseña); sin SMTP, al administrador se le muestra una contraseña temporal que debe entregar manualmente,
funciona el restablecimiento de contraseña por autoservicio.
killBottleneck en sí mismo se ejecuta sobre HTTP; para acceder a él desde fuera de tu red local, usa una VPN o un proxy inverso. Un ejemplo con Caddy (certificados HTTPS automáticos):
# Caddyfile
killbottleneck.your-domain.com {
reverse_proxy 127.0.0.1:8090
}Añádelo al compose mediante docker-compose.override.yml (ese archivo no se sobrescribe con las actualizaciones):
services:
caddy:
image: caddy:2
ports: ["80:80", "443:443"]
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data
volumes:
caddy_data:HTTPS además desbloquea Compartir… para la imagen de «Mi día» (la Web Share API: el diálogo nativo para compartir de tu teléfono, sin servicios de terceros) y añadir la aplicación a la pantalla de inicio de tu teléfono (un service worker solo se ejecuta en un contexto seguro). Los navegadores no permiten ninguna de estas cosas por HTTP simple; en un dominio HTTPS aparecen solas, sin configuración.
killBottleneck no comprime las respuestas por sí mismo (no hay forma de activarlo de forma segura en PocketBase sin romper el comportamiento de la API cuando rechaza un cuerpo demasiado grande). El archivo principal del frontend es 488 kB sin comprimir y 157 kB con gzip; con datos móviles es la diferencia que más se nota al abrirlo por primera vez. Una línea es suficiente:
# Caddyfile
killbottleneck.your-domain.com {
encode gzip zstd
reverse_proxy 127.0.0.1:8090
}(En nginx: gzip on; gzip_types application/javascript text/css;. Detrás de Cloudflare o un servicio similar ocurre automáticamente: no hay nada que configurar.)
git pull # or download the new version
docker compose up -d --buildLas migraciones de la base de datos se ejecutan automáticamente al iniciar. Antes de una actualización importante, conviene hacer una copia de seguridad (./backup.sh).
Siempre con
--build: la aplicación y su lógica de servidor están integradas en la imagen, por lo que después de cada actualización (un cambio de código, variables de.envcomoTZ) necesitasdocker compose up -d --build, no solorestart.
Una sola vez, al actualizar desde una versión hasta v0.11: después del cambio de nombre del producto, el contenedor se llama killbottleneck en lugar de flowmap. El contenedor antiguo ocupa el puerto 8090, por lo que el nuevo no se levantaría; detenlo y elimínalo primero:
docker rm -f flowmap
docker compose up -d --buildTus datos están en la carpeta ./pb_data del disco, no en el contenedor: no perderás nada. Las variables FLOWMAP_* de tu .env siguen funcionando, no es necesario reescribirlas.
Un enlace público a un mapa comparte solo el lienzo del mapa: las tareas y los comentarios de las tareas no son visibles a través de él.
Licencia: fair-code — Licencia de Uso Sostenible (consulta la sección Licencia más abajo).
killBottleneck no es «código abierto» en el sentido estricto (OSI), y lo decimos claramente. Es fair-code: el código fuente es público, puedes descargarlo, ejecutarlo, modificarlo y usarlo, y para la gran mayoría de las personas ofrece los mismos beneficios que el código abierto clásico. Las partes que sí pueden ser código abierto clásico, son: el skin editor (MIT) y toda la skin gallery, incluido su validador (CC0).
Recibes todo killBottleneck: todas las funciones, incluida la colaboración en equipo y las funciones de IA. No hay una «versión gratuita» reducida, nada bloqueado tras un muro de pago. Incluso puedes alimentar la IA tú mismo, gratis: con tu propio modelo (Ollama) en tu máquina, o tu propia clave de API. Nuestra nube alojada (IA incluida) se ofrece solo como una comodidad para quienes no tienen dónde ejecutar killBottleneck: es comodidad, no una condición.
Lo que puedes hacer con killBottleneck — gratis y sin trampa:
Ejecutarlo tú mismo en tu propio ordenador o servidor: tus datos permanecen contigo.
Usarlo en tu empresa para tu propio trabajo y tu equipo, por completo.
Conectar tu propia IA (un modelo local o tu propia clave de API), o no usar IA en absoluto.
Modificarlo como necesites.
Ofrecer servicios en torno a killBottleneck (instalación, consultoría, personalizaciones para un cliente).
Lo que reservamos para nosotros — y lo que mantiene vivo a killBottleneck:
Alojar killBottleneck y cobrar a las personas por el acceso.
Ponerlo bajo marca blanca: publicarlo con la marca de otra persona.
Revenderlo como servicio de pago.
Ese es nuestro negocio: es lo que nos permite seguir añadiendo funciones, corrigiendo errores y manteniendo vivo killBottleneck. Te animamos activamente a construir sobre killBottleneck y a usarlo como necesites; solo no lo conviertas en un servicio alojado competidor. Términos completos: LICENSE. Los componentes de terceros conservan sus licencias originales (MIT, Apache-2.0, BSD, …); la lista completa con los textos de las licencias está en THIRD-PARTY-LICENSES.md.
Titular de los derechos: Tengo, s.r.o., N.º de identificación 03339165, Dolní Valy 205, 262 72 Březnice, República Checa. ¿Quieres alojar killBottleneck como servicio, distribuirlo bajo tu propia marca o revenderlo? La licencia no lo permite, pero hay una licencia comercial disponible; escribe a licence@killbottleneck.com.
Česká verze této sekce je v README.cs.md.
Construido por Richard Pobrislo (LinkedIn, Ctrl+Alt+AI): una sola persona, que es por lo que los canales de soporte de abajo son como son.
El código está escrito 100% por IA — Claude Fable 5, Claude Opus 5 y Claude Opus 4.8 — bajo dirección humana. Cada versión pasa por una suite de regresión automatizada y una comprobación manual clic a clic antes de publicarse; las notas de la versión indican qué se verificó y qué no se verificó deliberadamente.
Dónde | Para qué |
GitHub Issues / Discussions | errores e ideas para mejoras: en abierto, para que otros también puedan verlos |
problemas de seguridad (no en un issue público): consulta SECURITY.md | |
planes de pago: la instancia alojada | |
licencias comerciales: alojamiento como servicio, marca blanca, reventa | |
todo lo demás |
No aceptamos código de colaboradores externos (consulta CONTRIBUTING.md); ideas e informes de errores sí, y son bienvenidos.
killBottleneck es fair-code: todo el producto (todas las funciones) es libre de autoalojarse y seguirá siéndolo. Si te resulta útil:
sigue nuestro canal de YouTube con tutoriales y noticias sobre IA,
únete a nosotros en Discord.
Add a subtree of nodes to an existing map under parent_id (or under the apex when parent_id is omitted). A node is a goal; a node with an assignee (owner) OR a deadline IS a task — that is the only kind of task in killBottleneck (there is no separate task record; new work = new node). NOTE: this re-computes the layout of the whole map. Max 200 nodes per call. Returns the updated tree.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| map_id | Yes | ||
| parent_id | No | Existing node id to attach under; omit for apex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure and does so well: it explicitly notes that the whole map layout is recomputed, caps calls at 200 nodes, returns the updated tree, and explains the node-vs-task model (owner/deadline makes a task). It does not cover failure modes or permissions, but the disclosed behaviors are valuable and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the action and target, the second adds the crucial task-model semantics, and the third highlights warnings and return value. Every sentence earns its place with useful, non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested item structure and lack of an output schema, the description provides essential operational details: return value (updated tree), limits (max 200 nodes), side effects (layout recomputation), and task-model rules. It is sufficient for an agent to invoke the tool confidently, even if it doesn't enumerate all field behaviors or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It does by explaining parent_id semantics (omit for apex) and characterizing items as a subtree of nodes. Combined with the schema's field-level descriptions, the parameters are reasonably understandable, though map_id and the items array itself could use slightly more elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Add a subtree of nodes to an existing map') and clearly distinguishes this from siblings such as create_map (whole map) and update_node (existing node). It also clarifies placement under a parent_id or the apex, leaving no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: adding nodes to an existing map under a specified parent or as apex nodes. It implicitly differentiates from update_node by focusing on adding a subtree. It does not explicitly list exclusions or alternatives, but the usage scenario is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new goal map from an outline. The map gets an apex (root goal) from title/apex_text; outline items become nested nodes. Layout is computed automatically. Max 200 nodes per call. Returns the created tree with node ids.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Map/project title | |
| outline | Yes | Top-level items under the apex, each may have children | |
| apex_text | No | Root goal statement, defaults to title | |
| description | No | Map description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself discloses key behavioral traits: layout is computed automatically, max 200 nodes per call, and the tool returns the created tree with node ids. This goes beyond a bare 'create' statement. It does not cover permission requirements or side effects like notifications, but for a creation tool the disclosed behaviors are meaningful and helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the core purpose, the second explains the mapping of inputs to structure, and the third states constraints and return value. It is front-loaded with the action verb and completely free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational context: input transformation, automatic layout, node limit, and the returned tree with ids. With no output schema present, this return value information is valuable. It does not elaborate on the many optional outline node fields, but those are fully documented in the input schema, so the description does not need to repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level parameter schema has 100% description coverage, so the baseline is 3. The description adds value by explaining how parameters relate to the output: title/apex_text become the apex, and outline items become nested nodes. It also introduces the 200-node limit and the return shape, which are not in the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction ('Create a new goal map from an outline') and clearly distinguishes from siblings by focusing on creation as opposed to listing, retrieval, or modification. It also specifies the key transformation (outline to nested nodes) and the automatic layout behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating this creates a goal map from an outline, which strongly suggests the appropriate time to use it. It also gives a hard constraint (max 200 nodes per call) that helps decide feasibility. However, it does not explicitly mention alternatives like add_nodes for adding to an existing map, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an automation rule on a map: WHEN trigger fires (and optional AND conditions match) DO the actions in order. Rules run for changes made in the UI, via API and by agents alike. Structural limits: 50 rules per map, 10 actions, 20 conditions — there is NO monthly run quota. A rule applies only to future events, never retroactively. node_id scopes the rule to one node (required for schedule rules whose actions target a node).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable rule name (max 120 chars) | |
| map_id | Yes | ||
| actions | Yes | 1-10 actions, executed in order | |
| enabled | No | Default true | |
| node_id | No | Optional: scope the rule to one node of the map | |
| trigger | Yes | ||
| conditions | No | Optional AND chain checked on the trigger node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals important non-obvious traits: structural limits (50 rules per map, 10 actions, 20 conditions), the absence of a monthly run quota, forward-only applicability, and the node_id scoping requirement for schedule rules. This exceeds what one would expect from a typical description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, each contributing unique value: the core purpose, cross-UI/API/agent behavior, limits/quota, forward-only semantics, and the crucial node_id requirement. It is front-loaded and free of fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, nested tool with no output schema, yet the description covers key constraints and behavioral rules (limits, quota, future events, node_id requirement) that an agent needs before invoking. It omits any mention of return values, which would be helpful given the absence of an output schema, but the overall context is sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 71% of parameters with detailed descriptions, so the description need not repeat them. The added clarification that node_id is 'required for schedule rules whose actions target a node' is genuinely useful, but the description does not compensate for the remaining 29% of parameters lacking schema descriptions (e.g., map_id, enabled).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create an automation rule on a map' and explains the WHEN/DO structure, making the tool's purpose unmistakable. It clearly differentiates from sibling tools like list_rules, update_rule, and delete_rule by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides relevant context such as 'Rules run for changes made in the UI, via API and by agents alike' and 'applies only to future events, never retroactively,' which helps an agent understand when creating a rule is appropriate. However, it does not explicitly contrast with alternatives like update_rule or list_rule_templates, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a node INCLUDING its whole subtree. The apex (root) cannot be deleted and whole maps cannot be deleted via the API. Irreversible — read the map first and double-check the node id.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes | ||
| node_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the most critical behaviors: recursive deletion of the whole subtree, irreversibility, and API limitations (cannot delete apex or whole maps). This goes beyond the bare 'delete' semantics and gives the agent essential warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying distinct value: action/scope, restrictions, and irreversibility warning. No filler or repetition, with the most important information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers the deletion scope, exclusions, and safety advice. It does not mention permissions or side effects on related entities like rules, but given the lack of an output schema and the tool's simplicity, it is reasonably complete. A score of 5 would require covering those potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While the parameter names 'map_id' and 'node_id' are self-explanatory, the description does not explicitly map them to their roles or add constraints like format/required prerequisites. The advice to 'double-check the node id' subtly indicates importance but adds no concrete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a node') and specifies the scope ('INCLUDING its whole subtree'), distinguishing it from node update/add operations. It also clarifies constraints (apex and whole maps cannot be deleted), which reinforces the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating irreversible nature and advising to 'read the map first', implying the use of a read tool. It also gives explicit exclusions (apex, whole maps), but does not name alternative tools like update_node for replacement or get_map as the read step, so it falls short of explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an automation rule. Its run log stays (with the rule name snapshot). Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes | ||
| rule_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: the run log persists with a snapshot of the rule name, and the operation is irreversible. This goes beyond the function name, though it could also mention effects on scheduled actions or related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant content. The key points (deletion, log retention, irreversibility) are front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters, the description provides essential behavior (log retention, irreversibility) but is missing usage context such as how to find rule_id or map_id, and does not cross-reference related tools like list_rules or delete_rule_template to aid selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for map_id and rule_id (0% coverage), and the description does not explain what these parameters refer to or how to obtain them. The tool name implies rule_id is the rule identifier, but map_id is ambiguous without context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and the resource ('an automation rule'), and adds a specific detail about run log retention, making it distinct from sibling tools like delete_rule_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It doesn't mention that list_rule_templates or delete_rule_template should be used for templates, and there are no exclusions or context cues beyond the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a rule template from the library (author or admin only). Rules already created from it are independent copies and stay untouched.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It openly states the permission prerequisite and that existing rules are unaffected (no cascade). It does not detail whether deletion is permanent, but the verb 'delete' implies destruction. This is appropriate for a simple delete tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. The verb and object are front-loaded, and the second sentence adds valuable clarification about side-effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, permission, and side-effect behavior. It could mention whether deletion is reversible, but for a delete operation this is generally understood.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (template_id) with no description, and schema description coverage is 0%. The tool name and description make the purpose of template_id obvious, but the description does not explicitly define the parameter's format or source. It partially compensates but leaves some room for interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a rule template from the library') with a specific resource and scope. It distinguishes itself from sibling tools like delete_rule (which deletes rules) and save_rule_template (which manages templates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by noting the permission requirement ('author or admin only') and clarifies a key implication ('Rules already created from it are independent copies and stay untouched'). It does not explicitly mention alternatives, but the distinction from sibling tools is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one map as an indented tree with node ids, statuses ([✓] done, [~] in progress, [ ] todo), deadlines and owners. Always call this before modifying a map you have not read yet.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates this is a read operation, describes the output content, and implies safety precondition (read before modify). It does not detail edge cases or permissions, but for a straightforward read tool the description is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose and output format, the second gives a usage directive. Every word earns its place, and it is entirely front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description fully covers the essentials: what the tool does, what it returns, and when to invoke it. The safety instruction also adds important operational context, making the description complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for map_id. The phrase 'Read one map' clarifies that map_id identifies the specific map to read. This gives enough semantic context for a single parameter, though it does not provide format or example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and resource 'one map', and clearly details the output as an indented tree with node ids, statuses, deadlines, and owners. This differentiates it from sibling tools like list_maps (which lists maps) and get_org_structure (which reads organization structure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Always call this before modifying a map you have not read yet.' This provides a clear context for usage, though it does not explicitly name alternatives or exclusions like using list_maps for a high-level map list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the organization structure (the org map): positions and functions with node ids, holders and deputies. Use the node ids as dynamic rule targets "position:" / "deputy_of_position:". Read-only — holders and deputies are appointed by an admin in the app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description states 'Read-only' and explains that holders and deputies are appointed by admin. This discloses the non-mutating nature and external data source. However, it does not describe return format or pagination, though for a simple read this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then usage note. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description covers purpose, read-only nature, and dynamic node id usage. It is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds meaning about node ids but no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read the organization structure (the org map): positions and functions with node ids, holders and deputies.' This is a specific verb and resource, but it does not explicitly distinguish from sibling tool get_map, despite the parenthetical '(the org map)' which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. It provides usage of node ids for rule targets but no comparison with get_map or other read tools. This is essentially no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List goal maps in the killBottleneck account (id, title, node count, last update). Use archived=true to list archived maps instead.
| Name | Required | Description | Default |
|---|---|---|---|
| archived | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope (killBottleneck account), the returned fields, and the behavior of the archived flag (default vs archived). It doesn't explicitly state read-only, but 'List' inherently conveys non-mutating behavior, and the details about fields and filtering add meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes the only parameter guidance without any fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers all essential aspects: what is listed, account scope, returned fields, and filtering option. No pagination or rate limit details are necessary for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'archived' as a boolean with no description (0% coverage). The description compensates by explaining what archived=true does ('list archived maps instead'), implicitly clarifying that false (or omitted) lists non-archived maps. This is sufficient for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List goal maps in the killBottleneck account' with specific details on returned fields (id, title, node count, last update). It distinguishes from siblings like get_map (singular fetch) and create_map (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (listing maps in the named account) and gives explicit guidance for the archived parameter ('Use archived=true to list archived maps instead'). It does not explicitly name alternative tools for other use cases, but the 'instead' implies default behavior, which is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the run log of a map's automation rules (newest first, max 100): what fired, on which node, ok/failed/skipped and what the actions did. skipped = a safety stop (rule chain depth or per-save cap), detail says which.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes | ||
| rule_id | No | Optional: only runs of this rule |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read operation ('Read'), defines output semantics (ok/failed/skipped), and explains the non-obvious 'skipped' status as a safety stop with a detail field. This goes beyond minimal transparency, though it does not mention potential edge cases like empty results or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action ('Read the run log'), and each phrase provides useful information: ordering, limit, output fields, and status explanation. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains what the tool returns: recent run logs with node, status, action outcomes, and special handling of 'skipped'. It covers the essential behavior for a read-only log tool, though it could mention the response format (e.g., array) or pagination limits beyond 'max 100'. Overall, it is reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents 'rule_id' as optional and its purpose ('only runs of this rule'), covering 50% of parameter semantics. The description adds contextual meaning by referring to 'a map's automation rules', helping to clarify that 'map_id' is the map identifier. However, it does not explicitly name the parameters or add detail beyond the schema for 'map_id', making it adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read the run log of a map's automation rules', which uses a specific verb ('Read') and resource ('run log'), making the tool's purpose unambiguous. It also specifies key details like ordering (newest first), limit (max 100), and output fields (node, ok/failed/skipped, actions), clearly distinguishing it from sibling tools like list_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need to inspect rule run history), but it does not explicitly state when not to use it or name alternatives. For example, it does not contrast with list_rules or explain that this is for execution history rather than rule definitions. The context is clear but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List automation rules of a map: id, name, enabled, scope node, trigger, conditions, actions, last_fired and last_error (a non-empty last_error means the rule is misconfigured and its owner was notified).
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond a simple 'list' statement by explaining the meaning of last_error (misconfiguration and notification), which is useful context. It does not mention side effects or permissions, but the read-only nature of listing is inherent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that efficiently lists the tool's purpose, the fields returned, and the special meaning of one field. There is no fluff, and every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description is largely complete: it specifies the resource scope, the fields returned, and the significance of last_error. It lacks details about pagination, sorting, or whether all rules (enabled/disabled) are included, but these are not critical for a basic listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter map_id is required and has no schema description (0% coverage). The description mentions 'of a map', which contextually identifies map_id as the map identifier, but it does not explicitly define the parameter or its format. This provides minimal compensation for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('automation rules of a map'), clearly distinguishing it from sibling tools like list_rule_runs and list_rule_templates. It also lists the exact fields returned, making the purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the scope ('of a map') and listing the returned fields, which implies it is for inspecting rule configurations. However, it does not explicitly mention alternatives or when not to use it, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the instance-wide library of rule templates (shape of a rule without a map or node scope). To use one, read it and call create_rule on the target map with its trigger/conditions/actions — the created rule is an independent copy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clarifies the template shape and the copy relationship with create_rule, but does not explicitly state read-only behavior, pagination, or return format. The verb 'List' implies read-only, but other behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no fluff. The first sentence states the purpose, the second explains usage, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool, the description covers what the tool returns (rule templates without scope) and how to use the result (create_rule). No output schema exists, but the description explains the key fields (trigger/conditions/actions) and the copy semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and there is no param info to add. The description enriches understanding by explaining what a template contains (trigger/conditions/actions), which aids interpretation of the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'instance-wide library of rule templates' and explicitly differentiates from siblings by noting templates are 'without a map or node scope'. This makes it distinguishable from list_rules and other related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage flow: 'read it and call create_rule on the target map with its trigger/conditions/actions', indicating when to use this tool. However, it does not explicitly name alternative tools for when not to use it, so it falls short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a rule shape into the instance-wide template library (create, or update with template_id — only the author or an admin may update). Templates carry no map and no node scope; create_subnodes may only use parent=trigger_node. Template names are unique.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique template name (max 120 chars) | |
| actions | Yes | ||
| trigger | Yes | ||
| conditions | No | ||
| template_id | No | Update an existing template (author or admin only); omit to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses key behaviors: templates have no map/node scope, create_subnodes restricted to parent=trigger_node, names must be unique, and update permissions. This is good context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all high-signal: action+scope, key constraints, and uniqueness. No fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and complexity (nested actions, triggers, conditions), the description provides the essential context: what templates are, permission model, uniqueness, and a critical behavioral constraint. It doesn't explain return values, but no output schema is present. Minor gap: no statement about validation or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions template_id for updates and name uniqueness, but those are already in the schema. The schema itself provides detailed descriptions for trigger, actions, and conditions, so the description does not need to compensate heavily. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Save' and clearly identifies the resource: 'rule shape into the instance-wide template library.' It explicitly distinguishes create from update and notes templates are not rules, differentiating from siblings like create_rule/update_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: create or update with template_id, and that only the author or admin may update. It implies this is for reusable templates (no map, no node scope) rather than instance rules, but does not explicitly name alternatives like create_rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields of one node: title, status (todo/in_progress/done), description, deadline (YYYY-MM-DD, empty string clears), owner (e-mail, empty string clears), wait_for_children, colour, who performs it (executor_kind / executor_name) and the automation wish (automation_wanted / automation_note). Marking status done may unblock waiting nodes, notify their owners and trigger automations on them.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Node colour as #rrggbb, empty string clears | |
| owner | No | Accountable PERSON (e-mail). Stays a human even for AI/cron steps — this is who gets notified. Empty string clears. | |
| title | No | ||
| map_id | Yes | ||
| status | No | ||
| node_id | Yes | ||
| deadline | No | ||
| description | No | ||
| executor_kind | No | Who performs the step. Default "human". | |
| executor_name | No | Which automation handles this step, e.g. "n8n backup" — a record of what exists, not an instruction. Empty string clears. | |
| automation_note | No | Optional context for the automation wish. Empty string clears. | |
| automation_wanted | No | Wish that this step were automated; notifies the AI agent managers. | |
| wait_for_children | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important side effects: 'Marking status done may unblock waiting nodes, notify their owners and trigger automations on them.' It also explains clearing behavior for several fields. However, it does not clarify whether omitted fields remain unchanged or are reset, which is a key behavioral gap given no annotations to fill it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The first sentence efficiently lists the fields, the second explains the done-status side effects. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of annotations and output schema, the description covers most critical aspects: updatable fields, their semantics, and side effects. The main missing element is explicit partial-update semantics and any required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 46%, the description compensates by listing and explaining all 13 parameters, including enum values for status, deadline format (YYYY-MM-DD), owner email semantics, and clearing with empty strings. It adds meaning beyond the sparse schema for fields like wait_for_children and automation_wanted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update fields of one node' and enumerates all updatable fields, clearly distinguishing this from sibling tools like add_nodes and delete_node by specifying the update action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: updating an existing node's fields. However, it does not explicitly state when to avoid this tool in favor of alternatives (e.g., add_nodes for creation, delete_node for removal), so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an automation rule. Pass only enabled to toggle it on/off; otherwise pass the FULL new shape (name, trigger, actions, optional conditions/node_id) — partial field edits are not merged. Edits apply to future events only and clear the rule's error state.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| map_id | Yes | ||
| actions | No | ||
| enabled | No | ||
| node_id | No | ||
| rule_id | Yes | ||
| trigger | No | ||
| conditions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses important behavioral traits: partial field edits are not merged, edits apply to future events only, and the rule's error state is cleared. This goes beyond the minimum but doesn't cover every edge case (e.g., not found behavior, permissions), so it earns a 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the tool's core purpose. Every sentence adds value: the first defines the action, the second explains the two usage modes and the non-merging rule, and the third notes the temporal scope and side effect. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects) and lack of output schema or annotations, the description provides a solid high-level context: update modes, required fields, and side effects. It doesn't explicitly mention how to obtain the rule_id or what the response is, but these are relatively self-evident given the schema and sibling tools. The description is complete enough for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's top-level properties have no descriptions (0% coverage), so the description must compensate. It adds meaning by explaining that `enabled` can be used alone as a toggle, while a full update requires `name`, `trigger`, `actions`, and optionally `conditions`/`node_id`. This clarifies the parameter relationships and the non-merge semantics, which the schema alone doesn't convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Update') and resource ('automation rule'). It distinguishes itself from sibling tools by emphasizing the update action and the unique toggle behavior. The phrase 'automation rule' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance by separating the toggle mode ('pass only `enabled`') from the full-replacement mode ('otherwise pass the FULL new shape'). It also warns that partial edits are not merged. While it doesn't explicitly name alternatives like create_rule, the update vs create distinction is implicit and the mode selection is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.33.2-betaadd_nodescreate_mapcreate_ruledelete_nodedelete_ruledelete_rule_templateget_mapget_org_structurelist_mapslist_rule_runslist_rule_templateslist_rulessave_rule_templateupdate_nodeupdate_ruleEach tool targets a distinct resource and action. Map tools (list_maps, get_map, create_map, add_nodes, update_node, delete_node) are clearly separated from rule tools (create_rule, list_rules, update_rule, delete_rule, list_rule_runs) and template tools (list_rule_templates, save_rule_template, delete_rule_template). No two tools appear to do the same thing.
All tool names follow a consistent verb_noun pattern in snake_case, with verbs like list, get, create, add, update, delete, save. The nouns are appropriately pluralized for collections and singular for single entities, creating a predictable and readable API surface.
15 tools is well within the ideal 3-15 range. The count is justified by the dual domain of map management and automation rule management, with each tool serving a distinct purpose and no apparent bloat.
The tool surface covers the core lifecycle for maps (create, read, update nodes, delete nodes) and automation rules (create, read, update, delete, runs, templates), plus organization structure. The only notable gaps are lack of map-level update/delete, but these appear to be intentional API limitations rather than oversights.
End-to-end agent-managed company brain. Docs, diagrams, plans, Knowledge Graph. Lean & affordable.
Self-hostable shared brain for you and your AI agents — docs, flows, meetings, decisions, rationale
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tengolabs/killbottleneck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
