Una suite de 570 utilidades independientes y guiadas por configuración que cubren todo el ciclo de desarrollo de producto — planificar → desarrollar → QA → automatizar la retroalimentación → desplegar — utilizables como herramientas CLI normales o mediante lenguaje natural con Claude, Codex y Cursor. Cada herramienta es autónoma y se configura con flags y variables de entorno (sin rutas host ni identificadores privados incrustados). Python · Go · Bash.
🧭 Dos formas de usarlo: hablar con él a través de un asistente de IA (configuración más abajo), o ejecutar las herramientas directamente desde la terminal (más abajo ¿Prefieres la línea de comandos?). En ambos casos son las mismas herramientas.
Yala no es un cajón de sastre de scripts: cubre cada etapa del proceso de publicación de software, de modo que un único kit de herramientas (y un único asistente de IA conectado a él) pueda llevar una funcionalidad desde la idea hasta producción y mantenerla sana después:
flowchart LR
P["🗺️ Plan"] --> D["🔨 Develop"] --> Q["🔍 QA"] --> F["🔁 Feedback automation"] --> Y["🚀 Deploy"] --> PA continuación, un pase de demostración alrededor del ciclo. Cada comando es una herramienta real de este repositorio (todas admiten --help); cada frase entre comillas es un prompt real que puedes darle a Claude una vez conectado el servidor MCP (configuración en la siguiente sección).
"Investiga las mejores prácticas para receptores de webhook idempotentes y dame un informe con citas." "Dame un informe de arquitectura de este repo — archivos activos, acoplamiento, adónde pertenece."
# discover the work already hiding in the codebase (TODO/FIXME/secrets/skipped tests),
# ranked by severity × age × churn, into a living TODO.md
python src/project-autopilot/autopilot_backlog.py --repo . --write-todo TODO.md"Crea un servicio HTTP de Python llamado billing-api y verifícalo." "¿Qué paquetes se ven afectados por mi cambio con respecto a main? Genera una matriz de CI únicamente para esos." "Genera una especificación OpenAPI a partir de esta captura HAR y luego un servidor mock en el puerto 8400."
python src/development/scaffold_runner.py new billing-api # bootstrap + verify
python src/turborepo/turbo_affected.py --base main # build only what changed"Calcula una puntuación de riesgo sobre mi diff; si es alta, haz una revisión automatizada completa y solo muéstrame hallazgos verificados." "Haz lint de esta migración para detectar reescrituras de tablas e índices no concurrentes antes de fusionarla." "Prueba de carga el endpoint de staging y dame p95/p99: falla si es peor que la línea base."
python src/code-review/review_risk.py --from main --json # deterministic risk score
python src/code-review/review_gate.py --findings findings.json # policy gate for CILas categoría project-autopilot convierte el ciclo en un proceso continuo 24/7: un supervisor ejecuta trabajos con protecciones que mantienen las pruebas en verde, clasifican los errores de producción en incidencias, parchean nuevos CVE, revisan PRs, mejoran la cobertura y extraen nuevo backlog pendiente. Todo exclusivamente mediante PR reactivos (nunca hace push a una rama protegida), con un interruptor de emergencia, un presupuesto diario de acciones y un resumen matinal que solo te alerta cuando se necesita intervención humana.
cd your-project
python <yala>/src/project-autopilot/autopilot_supervisor.py init --repo . # generates autopilot.yaml
python <yala>/src/project-autopilot/autopilot_supervisor.py run # ...and walk away
python <yala>/src/project-autopilot/autopilot_report.py --state-dir .autopilot --since 24hAnaliza este test A/B: ¿la mejora es real o estoy espiando los datos?"* · *"Alertar en #ops en IRC cuando la tasa de errores se dispare."
"Revisa con lint mi workflow de GitHub Actions para detectar acciones noas seguras e inyección de scripts." "Controla este despliegue: cobertura ≥ 80, sin CVE críticos, pruebas en verde." "Despliega el canario con barreras de métricas y revierte automáticamente si se incumple el SLO."
python src/cicd/deploy_gate.py --gate cmd:pytest --gate git_clean # CI promotion gate…y los desencadenantes del autopiloto detectan los errores del nuevo despliegue, que se convierten en backlog, que se convierte en el próximo plan. El ciclo se cierra.
Related MCP server: Atlassian MCP Server
En lugar de memorizar cientos de nombres de herramientas, solo tienes que describir qué quieres y Claude encuentra la herramienta adecuada y la ejecuta. Ninguna herramienta inunda tu contexto: el kit expone sus "meta herramientas" pequeñas (find_tools, tool_info, run_tool, list_categories) que permiten al asistente buscar y ejecutar bajo demanda.
Configuración — unos 2 minutos:
# 1. get the toolkit and install the shared Python packages
cd yala-toolkit
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
# 2. register the MCP server with Claude Code (one time)
claude mcp add yala -- python3 "$(pwd)/src/claude-mcp/yala_mcp_server.py"
# 3. check it connected
claude mcp list # you should see: yala ... ✔ ConnectedAhora abre una sesión nueva de Claude Code y simplemente pregunta — encuentra abajo los ejemplos de prompt.
El mismo servidor stdio funciona con cualquier cliente MCP:
# Codex CLI
codex mcp add yala -- python3 "$(pwd)/src/claude-mcp/yala_mcp_server.py"
# Cursor — add to ~/.cursor/mcp.json:
# { "mcpServers": { "yala": { "command": "python3",
# "args": ["/ABSOLUTE/PATH/yala-toolkit/src/claude-mcp/yala_mcp_server.py"] } } }Si abres los componentes del repositorio en un editor que gestione un .mcp.json, el servidor se ofrece automáticamente. Consulta el sitio src/claude-mcp/ para ver los detalles y una --self-test.
Cuando el servidor MCP esté conectado, estas son cosas reales que puedes escribirle a Claude. Nunca tienes que nombrar la herramienta: basta con describir la tarea; Claude busca, la ayuda de la herramienta y la ejecuta.
Solo navegando
"¿Qué herramientas de yala tengo para bases de datos SQL?"
"Listar las categorías de herramientas de yala."
"¿Existe una herramienta de yala para comprobar la caducidad de un certificado TLS?"
Sistema, archivos y tareas cotidianas
"Usa yala para mostrarme qué está ocupando el espacio de mi carpeta personal."
"Encuentra archivos duplicados en ./Downloads con yala y muestra los mayores."
"Elige la mejor compresión para esta carpeta y dime cuánto ahorraría."
"Dame una foto de este equipo: CPU, memoria, disco."
Seguridad y secretos
"Escanea este repositorio buscando secretos hardcodeados con yala."
"Revisa mis dependencias por CVE conocidos."
"Audita los permisos de los archivos bajo /etc/myapp para ver si algo es escribible por cualquiera."
Git y revisión de código (categoría code-review)
"Calcula el score de riesgo de mi git diff actual y dime si requiere una revisión cuidadosa."
"Haz una revisión de código automatizada de mis cambios con main y muestra solo hallazgos reales y verificados."
"¿Quién debería revisar este PR? Revisa el git blame y señalame si hay riesgo de factor bus."
"Pasa la lista de verificación de revisión sobre mis cambios en preparación (etged): secretos, restos de debug, pruebas faltantes."
Turborepo / monorepo (categoría turborepo)
"¿Cuál es el camino crítico en la construcción de este titurborepo?"
"¿Qué paquetes se ven afectados "si cambio contra main? Generame una matríz de CI solo para esos."
"Realiza lint de mi turbo.json — ¿queda la cache bien configurada?"
"Audit my workspaces par existir ciclos de dependency y versión derivos "ADrift"."
Empezar un proyecto nuewovo (categoría development + herramientas de scaffold)
"Crea con andamia const (es) un nuevo servicio HTTP P pitónico llamado billing-api y verifílo."
"¿Qué formas de proyecto puede crear el kit de scaffold?"
Trabajo con APIs (categorías api-docs y api-versioning)
"Genera una especificación OpenAPI a partir de este archivo HAR."
"Compara estas dos especificaciones OpenAPI y dime si algo es un cambio incompatible."
"Monta una simulación (mock) de server desde openapi.yaml en la portu 8400."
Operaciones constantes IRC y bots (categoría irc-ops)
"Monta un servidor IRC versando (ergo) local y pon un agente de logging en #ops."
"¿Sigue mi bot conectado a #alerts? Haz una health check del servidor IRC."
Backups, datos e infraestructura
"¿Hay algún backupo sin explicar? Comprobado contra un RPO de 24 horas."
"Eperfila este CSV — tipos, proporción de nulos y algo que esté fuera de lo normal."
"Salta de la versión 1.2.3 a la siguiente versión minor."
Tip: si una herramienta puede modificar cosas (borrar archivos, publicar comentarios, lanzar un servidor), está marcada como mutante y admite
--dry-run— pídele a Claude "haz el ensayo primero" y lo hará.
Cualquier herramienta es un script normal, sin IA:
cd yala-toolkit
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
python src/system-process/system_info.py # your first toolCualquier herramienta imprime sus opciones con --help, y cada carpeta de category tiene su propio README con explicaciones en lenguaje normal, pasos de configuración y ejemplos listos para copiar. Navega por las categorías del final.
Herramientas Python (.py): python3 src/<categoría>/<herramienta>.py --help
Herramientas Go (.go, en go-tools/): go run src/go-tools/<herramienta>.go -h
Herramientas Bash (.sh, en bash/): bash src/bash/<herramienta>
Workflows Libretto (.ts, en libretto/): cópialos en tu carpeta de runs de Libretto y ejecuta libretto run <slug>
Algunas cateías necesitan instalación extra (ffmpeg, Docker, behavior base de datos, un LLM, etc.). Cada README de category tiene a su sección “Antes de empezar” donde encontrarás los comandos de instalación exactos.
Las tools se agrupan en carpetas de categorías dentro de cate.src/:
src/<category>/<tool>.py # or .go / .sh
src/<category>/README.md # beginner-friendly docs: intro, setup, examples per toolPor ejemplo: python src/network-recon/port_scan.py 10.0.0.5 --ports 1-1024
Cada categoría, organizada por su lugar en el ciclo. Cada carpeta tiene su README amigable para principiantes con pasos de instalación y ejemplos por herramienta.
Comprender el código, investigar el problema y descubrir el trabajo antes de escribir.
Categoría | Herramientas | Descripción |
1 | Agente LLM que hace un plan, reúne información de todas las fuentes de datos locales alcanzables y escribe un informe citado | |
[Web Search Spider Tools](środowiskowo, src) | 4 | Apuntan a una API JSON de SearXNG mediante |
5 | Tendencias vía | |
8 | Acciones vía Yahoo Finanzas, cripto vía CoinGecko/Coinbase — — no necesita claves API; solo lectura, sin trading/ejecución | |
5 | Combina las CLI | |
6 | Base de datos vectorial: | |
6 | Convierte preguntas en lenguaje natural en PostgreSQL — seguro y consciente del esquema: planificación de cand data, generación mediante LLM, |
Crea, escribe, compila — proyectos, APIs, interfaces, datos, y todo el flujo de git alrededor de ellos.
Categoría | Herramientas | Descripción |
12 | Utilidades de Git, extracción de TODO, comprobaciones de licencia/deps, limpieza de Docker, validación de env, pre-commit | |
8 | Bootstrap del stack de desarrollo de Next.js, asistente de env, comprobaciones de migración, análisis de bundle, preflight de despliegue | |
15 | reinicio de toolchain, auditorías de codebase (exportaciones sin usar, huecos de cobertura, assets, i18n, complejidad), actualizaciones de deps y codegen | |
8 | scaffold, edición, catálogo, versionado y publicación de bibliotecas de componentes publicables | |
8 | requieren la CLI | |
8 | requieren | |
8 | Analiza el grafo de tareas + ruta crítica (desde | |
8 | Genera una especificación OpenAPI 3 a partir de tráfico observado (HAR/NDJSON) o del código fuente de rutas (Flask/FastAPI/Express/Fastify), renderiza una especificación a una página de documentación HTML/Markdown autocontenida, un diff de cambios incompatibles (puerta semver), un servidor mock directamente desde una especificación, ejemplos de peticiones curl/Postman/.http, bundle/dereference de múltiples archivos (aplanado de $ref) y un generador de SDK de cliente Python tipado y solo-stdlib | |
8 | Potentes scripts basados en jq — un recetario de recetas avanzadas (group/pivot/top-N/dedup), flatten/unflatten, diff estructural de rutas, JSON→CSV, deep-merge, perfilado de formas, listado de rutas y streaming de archivos enormes (NDJSON / arrays gigantes) | |
13 | Utilidades de Bash portables para certificados, alertas de disco/memoria, esperas de servicios, copias de seguridad y auditorías | |
7 | Un pipeline de i18n auditado para juegos/software — extrae cadenas de muchos formatos (JSON/YAML/Android/iOS/gettext/XLIFF/CSV), traducción con LLM con preservación forzada de placeholders + terminología, valida determinísticamente cada unidad (un | |
2 | Convierte cualquier documento (PDF/DOCX/PPTX/XLSX/HTML/…) a Markdown, individual o recursivamente | |
8 | Un ejecutor de pipelines DAG (deps/parallel/retries/manifest), un motor declarativo extract→transform→load (csv/json/ndjson/sqlite), validación de calidad de datos (Great-Expectations-lite), perfilado de datasets, inferencia de esquemas (DDL/JSON-Schema/rules), extracción incremental/CDC basada en watermarks, seguimiento de lineage + freshness y diff/reconciliación de datasets — todo sobre archivos planos + SQLite, sin necesidad de warehouse/Airflow | |
12 | Paneles de DBA de PostgreSQL (salud, consultas lentas, bloat, índices, locks, vacuum, tamaños, conexiones), diff de esquemas, pg_dump protegido, además de un ejecutor de consultas PG/SQLite y un analizador de SQLite | |
12 | Programas Go solo-stdlib ( |
Todo lo que decide si un cambio es lo suficientemente bueno para publicarse.
Categoría | Herramientas | Descripción |
8 | Puntuación determinista de riesgo de diff, un revisor LLM con pasada de verificación adversarial (filtra hallazgos alucinados/ruidosos), una lista de verificación de revisión basada en reglas, sugerencia de revisor basada en blame + indicadores de bus-factor, un merge-gate de políticas sobre hallazgos/SARIF, publicación en GitHub/GitLab/Markdown/SARIF, orquestación de la CLI | |
8 | Un generador de carga HTTP de uso autorizado con percentiles de latencia (modelos cerrados/abiertos), pruebas de carga de recorridos de usuario de varios pasos (usuarios virtuales, encadenamiento de valores), microbenchmarks de comandos + código Python con comparación A/B, histograma de latencia + análisis de cola, muestreo de CPU/memoria/FD de procesos, pruebas de resistencia/remojo con detección de fugas + deriva de latencia, y una compuerta de regresión de rendimiento para CI frente a una línea base | |
8 | Inyectores de fallos a nivel de sistema — presión de CPU/memoria/IO, caos de red TCP (latencia/partición, sin root), kill/pausa de procesos/contenedores con límites de explosión, y llenado de disco/inodos/solo lectura — además de un orquestador de experimentos de caos en estado estable con reversión garantizada, una compuerta de radio de explosión + interruptor de hombre muerto, un chaos monkey programado y un ejecutor de ejercicios game-day con marcador | |
8 | Un ejecutor de migraciones (Postgres + SQLite) con detección de desviación de checksum + reversión, andamiaje de migraciones, un linter de migraciones seguras (reescrituras de tablas, índices no concurrentes, drops/renames, backfills sin límites), instantáneas de esquema JSON normalizadas + comparación de instantáneas que genera DDL, verificación de integridad/orden/desviación para CI, upserts idempotentes de datos semilla y backfills de columnas por lotes reanudables | |
12 | inspector de solicitudes con tiempos de fase, sonda de endpoints/latencia/diff/replay, además de endurecimiento de uso autorizado: escaneos de cabeceras de seguridad/CORS/auth/límites de tasa, auditoría JWT, introspección GraphQL, lint de OpenAPI | |
5 | Escaneo de secretos, comprobaciones de CVE en dependencias, integridad de archivos, auditorías de permisos, generación de contraseñas | |
6 | Detectar + prevenir la inyección SQL — escanear código fuente (7 lenguajes) y un linter de Python de precisión AST para consultas no parametrizadas, un detector de payloads estilo WAF, un cazador de intentos en registros, una lista blanca de identificadores para casos que los parámetros no pueden cubrir, y un probador de endpoints de uso autorizado | |
7 | Herramientas defensivas de endpoint — triaje heurístico estático, un escáner de firmas (reglas integradas + personalizadas, YARA opcional), comprobaciones de reputación de hash/denylist, análisis de binarios ELF/PE, un gestor de cuarentena, un vigilante de directorios y un front-end para ClamAV; Python puro cuando no hay motor instalado, verificado con el archivo de prueba EICAR | |
6 | Exponer procedencia + señales para imágenes/vídeo/texto/código hechos por IA — Credenciales de contenido C2PA, metadatos de generador Stable Diffusion/ComfyUI/EXIF (evidencia sólida), además de heurísticas de píxeles/texto/código de baja confianza claramente etiquetadas; un despachador enruta cualquier archivo al detector correcto | |
6 | Cifrado de archivos autenticado (AES-256-GCM / ChaCha20-Poly1305, claves envueltas con scrypt, AEAD fragmentado con detección de manipulación + truncamiento) utilizando la librería auditada | |
6 | SOLO redes autorizadas/propias |
Los bucles que observan lo que has publicado, aprenden de ello y corrigen o registran trabajo automáticamente.
Categoría | Herramientas | Descripción |
10 | Un supervisor que ejecuta bucles de agentes sobre disparadores cron/intervalo/evento (reinicio tras caída, sin solapamiento), una capa de seguridad (kill switch + presupuesto diario de acciones + límite de intentos + escalada), detección de eventos por flanco (nuevo commit / CI rojo / nuevo error / nueva CVE), un resumen matinal (qué ejecutó, qué arregló, qué te necesita) y 5 trabajos solo-PR listos, con salvaguardas — keep-tests-green, error-triage, CVE-watch, auto-review, coverage-nudge; delega las correcciones a un | |
11 | Bucles de larga duración e iteración-hasta-objetivo para una base de código: puerta de racha de calidad, cobertura hasta objetivo, barrido de errores de producción, deriva de docs, changelog git, estabilizador de tests inconsistentes, cobertura de logs, reescritura de mensajes de error, sink de CVE de dependencias, traspaso reinovable y salud del workspace; con detección determinista y un paso de corrección conectable | |
7 | Una plataforma de experimentación sin dependencias — un motor de evaluación de flags por hash consistente (focalización, despliegues, variantes, requisitos previos, interrupción) + un servidor de flags de recarga en caliente, asignación determinista A/B/n, estadísticas desde cero (prueba z de dos proporciones + intervalos de Wilson, prueba t de Welch, sin scipy), planificación de tamaño/potencia con Bonferroni, control monótono de rollout porcentual y auditoría de higiene de configuración y código | |
6 | Ambos lados de los webhooks — firma/verificación HMAC para esquemas de GitHub/Stripe/Slack/Shopify/ genéricos (tiempo constante, ventanas de replay), un receptor que verifica y deduplica, entrega fiable firmada con reinientos con backoff/jitter + | |
8 | Un proceso de logs de extremo a extremo — emite logs JSON con contexto enlazado y redacción de secretos, analiza cualquier formato (JSON, logfmt, nginx, syslog) y lo convierte a NDJSON, consulta con nivel y tiempo, agrega (tasas por nivel, top-N, percentiles de latencia, gráfico temporal), cola múltiple de archivos en vivo con rotación, redacción de PII/secretes paisajes, envía a Loki/Elasticsearch/HTTP (lotes + reintentos) y alerta por umbral, pico o ausencia | |
8 | Los pilostos de trazas y métricas — propagación del contexto de traza W3C, instrumenta comandos shell como spans de OpenTelemetry (las llamadas anidadas forman un árbol de traza), exporta a OTLP/Jaeger/Zipkin (lotes + reintentos), analiza árboles de trazas, rutas críticas y percentiles de latencia dos, dibuja diagramas ASCII de trazas, una librería de métricas Prometheus + servidor de recopilación | |
8 | Empieza a generar paneles de Grafana, reglas de alerta de Prometheus, alertas de burn-rate SLO multi-ventana y enrutamiento de Alertmanager desde especificaciones; prueba las reglas de alerta con el agente (promtool-lite, afirmaciones CI); envía notificaciones a Slack/PagerDuty/Alertmanager/webhook; un panel de terminal en vivo (indicadores, sparklines) y una página de estado HTML autónoma | |
8 | Analiza las exportaciones de facturación por servicio/equipo/función (más eventos y movores), detecta anomalías/picos de coste, predice el gasto hasta fin de período con presupuesto, distribuye showback/chargeback de presupuesto por etiquetas con cobertura, hace cumplir presupuesto del presupuesto (real + previsto), recomienda los rightsizing de recursos, la recuperación de recursos en desuso/huérfanos y el asesoramiento sobre reserved-instance/Savings-Plan — desde sus exportaciones de facturación/uso, sin lean a nube | |
8 | Provisiona/gestiona servidores IRC ergo en Docker, despliega agentes de canal resistentes (modos pipe/exec/log), supervisa una flota completa de agentes a desde una especificación con reinicio basado en heartbeat, moderón/operador de administración, supervision de canales (alertas de silencio, barreras, condiciones, salidas), health-gate que verifica los bots previstos en sus canales, un declarante configurable y exportación CHATHISTORY (NDJSON/texto/HTML) — IRC con biblioteca estándar, probado contra el servidor ergo real | |
3 | correo electrónico a través de cualquier servidor SMTP; SMS/llamadas mediante una API compatible con Twilio — establece |
Categoría | Herramientas | Descripción |
8 | Lint de configuraciones de GitHub Actions / GitLab CI para corrección + seguridad (acciones sin fijar, inyección de scripts, secretos hardcodeados), generar un pipeline a partir de un stack detectado, ejecutar pipelines localmente con un DAG de stages/needs + matriz, expandir matrices de build, calcular versiones a partir de Conventional Commits, generar entradas de Keep-a-Changelog, compuertas de despliegue (cobertura/CVE/tests/etiquetado) y empaquetar/verificar artefactos de build con procedencia | |
8 | Un controlador de despliegue automático con compuerta de métricas y rollback automático, puntuación de análisis canary (promover/mantener/revertir), orquestación de despliegues azul-verde + por anillos, un watchdog de SLO que revierte automáticamente ante una violación sostenida, una compuerta de congelación de despliegues por presupuesto de errores (tasa de consumo de SRE), un planificador de estrategias de despliegue (radio de explosión) y un interruptor de corte operativo con registro de auditoría | |
8 | Analizar planes de Terraform para detectar cambios destructivos/pérdida de datos, inspeccionar el inventario de estado (+ secretos en el estado), un linter de seguridad de IaC (tfsec-lite), aplicación de política como código (fail-closed), estimación de costes mensual con deltas de plan (infracost-lite), generación de user-data de cloud-init + validación de esquema real, creación/conversión de inventarios de Ansible (ini/yaml/json) y orquestación de plan/apply/destroy multi-stack con confirmación + bloqueo + auditoría | |
8 | Linter de seguridad/fiabilidad de manifiestos (kube-linter-lite), generador de manifiestos endurecidos (que pasan el linter), calculadora de peticiones de recursos/QoS/redimensionado, renderizador de overlays por entorno (mini-kustomize), comprobación de configuración de sondas + ejecución de sondas en vivo, simulador de actualizaciones continuas (disponibilidad mínima), generador de NetworkPolicy + analizador de cargas de trabajo abiertas y un linter de Dockerfile + inspector de imágenes, todo nativo de manifiestos (sin necesidad de clúster/kubectl) | |
8 | Una puerta de enlace perimetral configurable (enrutamiento/auth/LB/CORS/reescritura), división de tráfico canary con métricas en vivo estable-vs-canary, agregación de API (BFF) con fan-out/merge en paralelo, un registro de descubrimiento de servicios (TTL + heartbeat + desalojo), un sidecar de malla con reintentos/timeouts/circuit-breaking + expulsión de valores atípicos, un proxy de inyección de fallos para pruebas de caos, aplicación de contratos OpenAPI en el perímetro e identidades de servicio mTLS (CA + certificados hoja SPIFFE) | |
8 | Un proxy inverso consciente de versiones (enrutar por ruta/cabecera/Accept/consulta a upstreams por versión), un proxy que inyecta cabeceras RFC 8594 Deprecation/Sunset/Link/Warning (+ 410 al llegar al sunset), un validador de manifiesto de ciclo de vida de versiones + cronología, una compuerta CI de auditoría de sunset con sondeo de cabeceras en vivo, análisis de uso de endpoints obsoletos a partir de registros de acceso por consumidor, un generador de guías de migración en Markdown entre dos especificaciones, notificaciones de obsolescencia escalonadas y un resolvedor/comprobador de negociación de versiones independiente | |
8 | Renderizado de configuración por capas + plantillas | |
8 | Administración de Vault independiente del host: ejecutar un comando con solo secretos acotados en un entorno limpio, configurar AppRoles de mínimo privilegio, rotación de claves verificada por hash, desellado, copia de seguridad cifrada + restauración ante desastres y exportación de salud/KV a través de la API HTTP; configurado íntegramente mediante variables de entorno | |
6 | Los 5 algoritmos clásicos de limitación (token/leaky bucket, ventana fija/deslizante) como biblioteca + CLI, un limitador distribuido mediante Lua atómico de Redis, un proxy inverso de aplicación (429 + cabeceras | |
8 | Un motor de copia de seguridad cifrada (AES-256-GCM) completa/incremental, una restauración con resolución de cadenas y verificación de suma de comprobación por archivo, verificación de integridad/cadena + restauración de prueba profunda, poda de retención GFS, copia/restauración de bases de datos (SQLite/Postgres/MySQL), replicación externa con seguimiento de retardo, un ejecutor de runbooks de DR con seguimiento de RTO y simulacros, y monitorización de frescura de copias (alertas de RPO/faltantes/reducidas) | |
8 | Producir/consumir eventos con grupos de consumidores + manejo de cartas muertas en Redis Streams y Kafka, monitorizar el retraso de consumidores (alertas de umbral), gestionar/reencaminar DLQ, un registro de esquemas de eventos versionado con comprobaciones de compatibilidad hacia atrás/adelante, un relé de outbox transaccional (BD→stream), reproducción/reprocesamiento de eventos por id/rango de tiempo y una toma de streaming en vivo de solo lectura | |
10 | Herramientas de la API de gestión de RabbitMQ: panel de salud, inventario/salud de colas, auditorías de consumidores/conexiones, monitor de cartas muertas, exportación de topología, inspección de mensajes, prueba de publicación y purga protegida | |
10 | Panel de salud, memoria por prefijo, claves grandes, auditorías de TTL/config, slowlog, auditoría de clientes, latencia, claves calientes/frías y exportación/restauración de keyspace | |
7 | Monitorización de NVIDIA GPU/CUDA, salud de Ollama/LiteLLM y un panel de stack con un solo comando | |
8 | Lint de configuración SSH, comprobaciones multi-host, higiene de known_hosts/authorized_keys, ejecución en paralelo, túneles | |
6 | solo hosts autorizados | |
8 | SOLO infraestructura autorizada/propia |
Bloques de construcción para los asistentes y automatizaciones que impulsan el ciclo.
Categoría | Herramientas | Descripción |
2 | Un servidor MCP stdio que expone todo el toolkit a Claude como cuatro meta-herramientas (búsqueda de herramientas clasificadas, detalle por herramienta con | |
23 | Patrones reutilizables de bucle de agente — ReAct, plan-ejecución, reflexión, auto-consistencia, debate, árbol-de-pensamiento, enrutamiento de herramientas (texto + llamada nativa de funciones), presupuesto/map-reduce, bucles de verificador e intérprete de código, revisión constitucional, juez LLM, orquestación supervisor/trabajador, pipelines de roles, conjuntos entre modelos, memoria a largo plazo, compactación de contexto, RAG-con-citas, extracción de esquemas, operador de shell con compuerta y salvaguardas FSM — contra cualquier API de chat compatible con OpenAI | |
4 | Un ejecutor de herramientas en subprocesos aislado (timeout/reintento/rlimit CPU+memoria, salida siempre-JSON), validación de entrada/salida JSON-Schema + generación de esquemas a partir de un ejemplo, un verificador de seguridad de comandos shell/SQL para patrones peligrosos y búsqueda semántica de similitud de herramientas sobre descripciones — todo solo stdlib, CLI + importable | |
8 | apuntan a una API local compatible con Ollama por defecto: | |
8 | requieren | |
8 | Rastreadores avanzados sobre el framework Crawlee (cola de peticiones, autoescalado, reintentos) — rastreo profundo de sitios, scraping de enrutador lista->detalle, APIs JSON paginadas, auditoría SEO/enlaces rotos, CSS+XPath (Parsel), rastreo de sitemaps, renderizado JS + capturas de pantalla (Playwright) y un rastreador resiliente/con proxy | |
8 | Flujos de trabajo avanzados de Libretto impulsados por Playwright (TypeScript, ejecutar vía | |
11 | la transcripción apunta a una API Whisper compatible con OpenAI por defecto: |
El cajón del escritorio siempre útil.
Categoría | Herramientas | Descripción |
5 | Diagnósticos de CPU/memoria/disco, monitoreo de procesos, gestión de servicios y de inicio | |
10 | Organizar, deduplicar, renombrar, sincronizar, respaldar, hacer tail y convertir archivos y datos | |
6 | Evaluar y seleccionar automáticamente códecs (gzip/bzip2/xz/zstd), crear + inspeccionar archivos, recomprimir sin pérdida para recuperar espacio (con verificación de ida y vuelta) y auditar un árbol para ahorros de compresión + duplicados | |
10 | Paneles de servicios de desarrollo locales, salud del repositorio, notas de Obsidian, ayudantes de nginx/vault/docker | |
2 | Capturar cualquier flujo |
Este toolkit es para administración legítima de sistemas, desarrollo, evaluación de seguridad e investigación en sistemas que posees o estás explícitamente autorizado a gestionar. No contiene herramientas para descifrar contraseñas, evadir autenticación o acceso no autorizado. Las categorías de reconocimiento de red y túneles de red son herramientas de diagnóstico/operaciones de doble uso — úsalas solo contra infraestructura que poseas o tengas permiso por escrito para evaluar, y ten en cuenta los avisos de uso autorizado por herramienta.
Independiente: cada script se ejecuta por sí solo; sin importaciones cruzadas entre herramientas.
Impulsado por configuración: los objetivos, credenciales y rutas provienen de flags o variables de entorno. Los secretos se leen solo del entorno, nunca se pasan por la línea de comandos.
--dry-run en cualquier cosa que mute el estado; --help en todas partes.
Local-first: las herramientas de IA/datos usan servicios locales por defecto (Ollama, SearXNG, una base de datos vectorial local, etc.) y degradan con elegancia cuando un servicio no está disponible.
Search the yala toolkit's 500+ standalone CLI utilities by task (e.g. 'diff openapi specs', 'redis memory', 'gfs retention'). Returns ranked matches with descriptions. Start here.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 8) | |
| query | Yes | What you want to do, in plain words | |
| category | No | Optional category slug filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states it returns ranked matches with descriptions, which gives the return format. However, it does not mention whether the operation is read-only, any authentication requirements, or potential errors. For a search tool, this is adequate but not highly transparent.
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 concise (two sentences) and front-loaded with the core action and examples. 'Start here' is a useful directive. No unnecessary words or repetition.
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 (3 params, no output schema), the description covers what it does, gives concrete examples, and specifies the return type (ranked matches with descriptions). The schema handles parameter details, so the description is complete for an agent to correctly invoke it.
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 coverage is 100% with clear descriptions for each parameter (query, limit, category). The tool description adds no extra parameter information beyond the schema, but the schema already provides sufficient meaning. Baseline of 3 applies because the description does not need to compensate.
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: to search the yala toolkit's 500+ CLI utilities by task. It uses a specific verb ('search') and resource ('yala toolkit's 500+ standalone CLI utilities'), and includes examples. This distinguishes it from siblings like tool_info (specific tool details), run_tool (execution), and list_categories (category listing).
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 phrase 'Start here' clearly positions this as the entry point for finding tools, implying it should be used before other tools when you need to locate a utility. However, it does not explicitly state when not to use it or mention alternative tools, though the context provides enough guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overview of every yala toolkit category with tool counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It implies a read-only operation by saying 'overview' but does not explicitly state that no modifications occur, nor does it mention any permissions, side effects, or return format. This is a minimal disclosure.
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, front-loaded sentence that conveys the essential purpose with no filler. 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 no output schema, the description adequately covers the main purpose and output scope. It could mention the format of the counts or categories, but for the low complexity, it is sufficiently 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?
The tool has zero parameters, and the baseline for this case is 4. The description does not need to add parameter-specific information, as there is nothing to clarify.
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 provides an overview of every yala toolkit category with tool counts. It uses a specific resource ('yala toolkit category') and identifies the output scope ('with tool counts'), making it distinct from siblings like find_tools or tool_info.
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 is provided on when to use this tool versus alternatives. It does not mention scenarios where find_tools or tool_info would be more appropriate, nor does it specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a yala tool from the toolkit root and return exit code, stdout, stderr, and timing. Args are an argv list (no shell). Tools marked mutates=true support --dry-run — prefer it first.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Command-line arguments, one list element each | |
| name | Yes | ||
| stdin | No | Optional text piped to the tool | |
| timeout_s | No | Seconds before the run is killed (default 60, max 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses the return format (exit code, stdout, stderr, timing), the no-shell argument behavior, and the dry-run support for mutating tools. This is substantial for an execution tool, though it could mention error handling or permissions.
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 concise, front-loaded with the primary purpose, and every sentence contributes useful information. No redundant phrases, and the dry-run tip is valuable without bloating the text.
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 no output schema and no annotations, the description provides necessary return-value information (exit code, stdout, stderr, timing) and context (toolkit root, no shell). It covers the main execution aspects, though it could arguably mention what happens on timeout or failure, which is partially covered by timeout_s in the schema.
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 coverage is 75% (3/4 params described). The description adds meaning beyond the schema by clarifying that args are an argv list (no shell) and that --dry-run is a preferred flag for mutating tools, which contextualizes the args parameter. This adds value over the schema alone.
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 (execute) and resource (a yala tool), and specifies what it returns (exit code, stdout, stderr, timing). This distinguishes it from sibling tools like find_tools and tool_info, which are for discovery rather than execution.
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 guideline: prefer --dry-run for tools with mutates=true. While it does not explicitly name alternatives, it is the only execution tool among siblings, and the dry-run guidance is directly actionable, implying when to use this tool for safe testing first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one yala tool: description, example commands, live --help, and whether it mutates state. Use before run_tool.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Tool filename or stem, e.g. openapi_diff.py |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It mentions 'live --help' and 'whether it mutates state', but does not explicitly state whether tool_info itself has side effects or is read-only. The instruction 'Use before run_tool' hints it's safe, but not explicitly confirmed, leaving some ambiguity.
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 that list what the tool provides and when to use it. No unnecessary words 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 no output schema, the description explains the return content (description, examples, help, mutation status) and the intended usage context. It is complete for a retrieval tool without needing error details.
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?
Only one parameter 'name' with a clear description and example ('openapi_diff.py'). The schema covers 100% and the example enhances understanding, so it's above baseline.
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: to provide full detail about a single tool, including description, example commands, live --help, and mutation status. This distinguishes it from siblings like find_tools (discovery), run_tool (execution), and list_categories (categorization).
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?
Explicitly says 'Use before run_tool', giving a clear directive on when to call this tool. It also implies it's for retrieving details about a specific tool, contrasting with find_tools for searching and list_categories for listing categories.
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.
v0.1.0find_toolslist_categoriesrun_tooltool_infoScored across 4 tools
Each tool has a distinct purpose: find_tools searches for utilities, tool_info provides details on a specific tool, run_tool executes a tool, and list_categories gives an overview. No overlap or ambiguity.
All tool names follow a consistent lower_snake_case pattern with a clear verb or action prefix (find, tool_info, run, list). The naming is uniform and predictable.
With only 4 tools, the set is tightly scoped to the server's purpose of discovering, inspecting, and running CLI utilities. Each tool earns its place without redundancy.
The toolset covers the full workflow: discovering tools (find_tools, list_categories), getting details (tool_info), and executing them (run_tool). There are no missing operations for the stated purpose.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
A MCP server built for developers enabling Git based project management with project and personal…
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
