Набор из 570 автономных, управляемых конфигурацией утилит, покрывающих весь цикл разработки продукта — планирование → разработка → QA → автоматизация обратной связи → деплой — которые можно использовать как обычные CLI-инструменты или описывать простым английским языком через Claude, Codex и Cursor. Каждый инструмент самодостаточен и настраивается через флаги и переменные окружения (без зашитых путей хоста или приватных идентификаторов). Python · Go · Bash.
🧭 Два способа использования: общайтесь через ИИ-ассистента (настройка ниже) или запускайте инструменты напрямую из оболочки (см. Предпочитаете командную строку? ниже). В обоих случаях — одни и те же инструменты.
Yala — это не сборник случайных скриптов: он покрывает каждый этап поставки ПО, так что один набор инструментов (и подключённый к нему ИИ-ассистент) может провести функцию от идеи до продакшена и поддерживать её в рабочем состоянии:
flowchart LR
P["🗺️ Plan"] --> D["🔨 Develop"] --> Q["🔍 QA"] --> F["🔁 Feedback automation"] --> Y["🚀 Deploy"] --> PНиже — демонстрация прохода по циклу. Каждая команда — реальный инструмент из этого репозитория (каждый поддерживает --help); каждая цитируемая строка — реальный запрос, который вы можете дать Claude после подключения MCP-сервера (настройка в следующем разделе).
"Исследуй лучшие практики для идемпотентных приёмников вебхуков и напиши мне отчёт с цитатами." "Дай мне архитектурный отчёт по этому репозиторию — горячие файлы, связанность, кто чем владеет."
# 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"Создай каркас нового Python HTTP-сервиса billing-api и проверь его." "Какие пакеты затронуты моим изменением относительно main? Сгенерируй CI-матрицу только для них." "Сгенерируй OpenAPI-спецификацию из этого HAR-захвата, затем mock-сервер на порту 8400."
python src/development/scaffold_runner.py new billing-api # bootstrap + verify
python src/turborepo/turbo_affected.py --base main # build only what changed"Посчитай оценку риска для моего диффа; если она высокая, проведи полный автоматический ревью и покажи только подтверждённые находки." "Проверь эту миграцию на перезапись таблиц и неконкурентные индексы, прежде чем я смержу её." "Проведи нагрузочное тестирование staging-эндпоинта и дай мне p95/p99 — провал, если хуже базовой линии."
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 CIКатегория project-autopilot превращает цикл в работу 24/7: супервизор запускает задания с защитными ограничениями, которые поддерживают тесты зелёными, триажируют ошибки продакшена в задачи, патчат новые CVE, ревьюят PR, подталкивают покрытие и добывают новый бэклог — всё только через PR (никогда не пуша в защищённую ветку), с аварийным выключателем, ежедневным бюджетом действий и утренним дайджестом, который будит вас только когда нужен человек.
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 24h"Проанализируй этот A/B-тест — рост реальный или я подглядываю?" · "Оповести #ops в IRC при всплеске частоты ошибок."
"Проверь мой GitHub Actions workflow на незакреплённые actions и инъекции скриптов." "Заблокируй этот деплой: покрытие ≥ 80, нет критических CVE, тесты зелёные." "Раскати canary с гейтом по метрикам и автоматическим откатом при нарушении SLO."
python src/cicd/deploy_gate.py --gate cmd:pytest --gate git_clean # CI promotion gate…и триггеры автопилота замечают ошибки нового деплоя, которые становятся бэклогом, который становится следующим планом. Цикл замыкается.
Related MCP server: Atlassian MCP Server
Вместо запоминания сотен имён инструментов вы просто описываете, что хотите, и Claude находит и запускает нужный инструмент. Никакого засорения контекста — набор предоставляет четыре небольших «мета-инструмента» (find_tools, tool_info, run_tool, list_categories), которые позволяют ассистенту искать и выполнять по требованию.
Настройка — около 2 минут:
# 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 ... ✔ ConnectedТеперь откройте новую сессию Claude Code и просто спросите — см. примеры запросов ниже.
Тот же stdio-сервер работает с любым 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"] } } }Открытие этого репозитория в редакторе, который читает проектный .mcp.json, автоматически предлагает сервер. Подробности и --self-test — в src/claude-mcp/.
После подключения MCP-сервера это реальные вещи, которые вы можете напечатать Claude. Вы никогда не называете инструмент — достаточно описать задачу; Claude ищет, читает справку инструмента и запускает его.
Просто просмотр
"Какие yala-инструменты у меня есть для работы с SQL-базами данных?"
"Перечисли категории yala-инструментов."
"Есть ли yala-инструмент для проверки срока действия TLS-сертификата?"
Система, файлы и повседневные задачи
"Используй yala, чтобы показать, что занимает место на диске в моей домашней папке."
"Найди дубликаты файлов в ./Downloads с помощью yala и покажи самые большие."
"Подбери лучшее сжатие для этой папки и скажи, сколько я сэкономлю."
"Дай мне снимок этой машины — CPU, память, диск."
Безопасность и секреты
"Просканируй этот репозиторий на захардкоженные секреты с помощью yala."
"Проверь мои зависимости на известные CVE."
"Проверь права на файлы в /etc/myapp на предмет чего-либо доступного для записи всем."
Git и ревью кода (категория code-review)
"Посчитай оценку риска для моего текущего git-диффа и скажи, нужен ли тщательный ревью."
"Проведи автоматическое ревью кода моих изменений относительно main и покажи только реальные, подтверждённые находки."
"Кто должен ревьюить этот PR? Проверь git blame и отметь риск bus-factor."
"Прогони чек-лист ревью по моим staged-изменениям — секреты, отладочные print, отсутствующие тесты."
Turborepo / монорепозитории (категория turborepo)
"Каков критический путь в сборке этого turborepo?"
"Какие пакеты затронуты, если я изменю относительно main? Сгенерируй CI-матрицу только для них."
"Проверь мой turbo.json — правильно ли настроен кэш?"
"Проверь мои воркспейсы на циклические зависимости и расхождение версий."
Начать новый проект (категория development + инструменты каркасов)
"Создай каркас нового Python HTTP-сервиса billing-api с помощью yala и проверь его."
"Какие формы проектов умеет делать набор каркасов?"
Работа с API (категории api-docs / api-versioning)
"Сгенерируй OpenAPI-спецификацию из этого HAR-файла."
"Сравни эти две OpenAPI-спецификации и скажи, есть ли ломающие изменения."
"Подними mock-сервер из openapi.yaml на порту 8400."
IRC-операции и боты (категория irc-ops)
"Подними локальный ergo IRC-сервер и посади логирующего агента в #ops."
"Мой бот всё ещё подключён к #alerts? Проверь здоровье IRC-сервера."
Резервные копии, данные и инфраструктура
"Есть ли просроченные резервные копии? Проверь по 24-часовому RPO."
"Профилируй этот CSV — типы, доля null и всё, что выглядит подозрительно."
"Подними 1.2.3 до следующей минорной версии."
💡 Совет: если инструмент может что-то изменить (удалить файлы, оставить комментарии, запустить сервер), он помечен как мутирующий и поддерживает
--dry-run— попросите Claude "сначала сделать пробный прогон", и он это сделает.
Каждый инструмент — обычный скрипт, ИИ не требуется:
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 toolКаждый инструмент выводит свои опции через --help, и в каждой папке категории есть собственный README с объяснениями на простом языке, шагами настройки и готовыми примерами. Смотрите категории ниже.
Python-инструменты (.py): python src/<category>/<tool>.py --help
Go-инструменты (.go, в go-tools/): go run src/go-tools/<tool>.go -h
Bash-инструменты (.sh, в bash/): bash src/bash/<tool>.sh
Libretto-воркфлоу (.ts, в libretto/): скопируйте в папку воркфлоу Libretto и запустите libretto run <slug>
Некоторым категориям нужно дополнительное ПО (ffmpeg, Docker, база данных, LLM и т.д.). В разделе «Перед началом» README каждой категории перечислены точные команды установки.
Инструменты сгруппированы в папки категорий в src/:
src/<category>/<tool>.py # or .go / .sh
src/<category>/README.md # beginner-friendly docs: intro, setup, examples per toolПример: python src/network-recon/port_scan.py 10.0.0.5 --ports 1-1024
Каждая категория, организованная по месту в цикле. В каждой папке есть свой README для начинающих с шагами настройки и примерами по каждому инструменту.
Поймите кодовую базу, исследуйте проблему и обнаружьте работу до написания кода.
Категория | Инструменты | Описание |
1 | LLM-агент, который планирует, собирает данные по всем доступным локальным источникам и пишет отчёт с цитатами | |
4 | нацелены на JSON API SearXNG через | |
5 | тренды через | |
8 | акции через Yahoo Finance, криптовалюты через CoinGecko/Binance/Coinbase — без API-ключей; только чтение, без торговли/исполнения | |
6 | собирают CLI | |
6 | векторная БД: | |
6 | Превращает вопросы на простом английском в безопасный, осведомлённый о схеме PostgreSQL — интроспекция схемы, LLM-генерация, защита «только чтение», EXPLAIN-валидация, самовосстановление, затем выполнение только на чтение; плюс пакетный запускатель, интерактивная оболочка, статический SQL-защитник и LLM-оптимизатор запросов |
Создавайте каркасы, пишите, собирайте — проекты, API, фронтенды, данные и git-воркфлоу вокруг них.
Категория | Инструменты | Описание |
12 | Git-хелперы, извлечение TODO, проверки лицензий/зависимостей, очистка Docker, валидация окружения, pre-commit | |
8 | Бутстрап dev-стека Next.js, env-мастер, проверки миграций, анализ бандла, миграции проверки перед деплоем | |
15 | Сброс тулчейна, аудиты кодовой базы (неиспользуемые экспорты, пробелы покрытия, ассеты, i18n, сложность), обновление зависимостей и кодогенерация | |
8 | Скаффолдинг, редактирование, каталог, версионирование и публикация публикуемых библиотек компонентов | |
8 | Требуют CLI | |
8 | Требуют | |
8 | Анализ графа задач + критического пути (на основе | |
8 | Генерация OpenAPI 3 спеки из наблюдаемого трафика (HAR/NDJSON) или из исходного кода маршрутов (Flask/FastAPI/Express/Fastify), рендер спеки в автономную HTML/Markdown документацию, диффломающих изменений (semver gate), mock-сервер прямо из спеки, примеры запросов curl/Postman/.http, многофайловый bundle/dereference ($ref flattening) и типизированный генератор Python client-SDK на чистом stdlib | |
8 | Мощные скрипты на jq — готовые продвинутые рецепты (group/pivot/top-N/dedup), flatten/unflatten, структурный path diff, JSON→CSV, глубокий merge, shape profiling, перечисление путей и стриминг огромных файлов (NDJSON / большие массивы) | |
18 | Портативные Bash-утилиты для сертификатов, алертов по памяти/диску, ожидания сервисов, резервного копирования и аудитов | |
7 | Аудируемый пайплайн i18n для игр/софта — извлечение строк из многих форматов (JSON/YAML/Android/iOS/gettext/XLIFF/CSV), перевод через LLM с обязательным сохранением плейсхолдеров и терминологии, детерминированная валидация каждой единицы (неправильный | |
2 | Конвертация любого документа (PDF/DOCX/PPTX/XLSX/HTML/…) в Markdown — отдельного файла или рекурсивно | |
8 | DAG-раннер пайплайнов (deps/parallel/retries/manifest), декларативный движок extract→transform→load (csv/json/ndjson/sqlite), валидация качества данных (Great-Expectations lite), профилирование датасетов, инференция схем (DDL/JSON-Schema/правила), инкрементальное/CDC-извлечение по watermark, отслеживание lineage + freshness, diff/reconciliation датасетов — всё на простых файлах + SQLite, без Data Warehouse/Airflow | |
32 | PostgreSQL DBA-дашборды (health, медленные запросы, bloat, индексы, locks, vacuum, sizes, connections), схема-дифф, защищённый | |
12 | Только stdlib Go-программы ( |
Всё, что решает, достаточно ли изменение готово к релизу.
Категория | Инструменты | Описание |
8 | Детерминированная оценка риска диффа, LLM-ревьюер с состязательным этапом проверки (отфильтровывает галлюцинированные/шумные находки), управляемый правилами чек-лист ревью, рекомендация ревьюера на основе blame + флаги bus-factor, политический merge-gate по находкам/SARIF, публикация в GitHub/GitLab/Markdown/SARIF, оркестрация CLI Alibaba | |
8 | HTTP-генератор нагрузки для авторизованного использования с процентилями задержки (закрытые/открытые модели), многошаговые нагрузочные тесты пользовательских сценариев (виртуальные пользователи, связывание значений), микробенчмарки команд и Python-кода с A/B-сравнением, гистограмма задержек + анализ хвоста, сэмплирование CPU/памяти/FD процессов, тестирование на выносливость/soak-тестирование с обнаружением утечек и ползучей задержки и CI-шлюз регрессии производительности относительно базовой линии | |
8 | Инжекторы сбоев системного уровня — нагрузка на CPU/память/IO, TCP-сетевой хаос (задержка/разделение, без root), kill/pause процессов/контейнеров с ограничением радиуса поражения, а также заполнение диска/inode/read-only — плюс оркестратор хаос-экспериментов в установившемся состоянии с гарантированным откатом, шлюз радиуса поражения + dead-man's-switch, планировщик chaos monkey и исполнитель game-day учений с оценочной картой | |
8 | Исполнитель миграций (Postgres + SQLite) с обнаружением дрейфа по контрольным суммам + откатом, каркас миграций, линтер безопасных миграций (переписывание таблиц, неконкурентные индексы, drop/rename, неограниченные backfill), нормализованные JSON-снимки схемы + сравнение снимков, которое генерирует DDL, проверка целостности/порядка/дрейфа для CI, идемпотентные upsert'ы seed-данных и пакетные возобновляемые backfill'ы колонок | |
12 | инспектор запросов с таймингами фаз, зондирование конечных точек/задержка/дифф/воспроизведение, плюс укрепление для авторизованного использования: сканирование security-header/CORS/auth/rate-limit, аудит JWT, интроспекция GraphQL, линт OpenAPI | |
5 | Сканирование секретов, проверки CVE зависимостей, целостность файлов, аудит разрешений, генерация паролей | |
6 | Обнаружение + предотвращение SQL-инъекций — сканирование исходного кода (7 языков) и AST-точный Python-линтер для непараметризованных запросов, детектор полезной нагрузки в стиле WAF, охотник за попытками в логах, разрешенный список идентификаторов для случаев, которые не покрываются параметрами, и тестер конечных точек для авторизованного использования | |
7 | Оборонительные инструменты конечных точек — статическая эвристическая триаж, сканер сигнатур (встроенные + пользовательские правила, опционально YARA), проверки репутации хешей/денлист, анализ ELF/PE-бинарников, менеджер карантина, наблюдатель за каталогами и фронтенд ClamAV; чистый Python там, где не установлен движок, проверено тестовым файлом EICAR | |
6 | Раскрытие происхождения + сигналов для изображений/видео/текста/кода, созданных ИИ — C2PA Content Credentials, метаданные генератора Stable Diffusion/ComfyUI/EXIF (веские доказательства), плюс четко помеченные эвристики пикселей/текста/кода с низкой уверенностью; диспетчер направляет любой файл в нужный детектор | |
6 | Аутентифицированное шифрование файлов (AES-256-GCM / ChaCha20-Poly1305, ключи, обернутые scrypt, блочный AEAD с обнаружением подделки и усечения) с использованием проверенной библиотеки | |
6 | ТОЛЬКО авторизованные/принадлежащие сети |
Циклы, которые следят за тем, что вы выпустили, учатся на этом и автоматически исправляют или создают задачи.
Категория | Инструменты | Описание |
10 | Супервизор, который выполняет циклы агентов по расписанию cron/интервалу/событийным триггерам (перезапуск при падении, защита от перекрытий), слой безопасности (аварийный выключатель + дневной лимит действий + лимит попыток + эскалация), детектирование событий (новый коммит / красный CI / новая ошибка / новая CVE), утренний дайджест (что запускалось/исправлено/требует вашего внимания) и 5 готовых задач на PR с защитными гейтами — keep-tests-green, error-triage, CVE-watch, auto-review, coverage-nudge; исправления передаются подключаемому | |
11 | Долго работающие циклы «итерации до достижения цели» для кодовой базы — quality-streak gate, coverage-to-target, production error sweep, docs drift, git changelog, стабилизатор нестабильных тестов, logging-evidence, rewrite error-message, dependency-CVE burndown, restart patience, workspace health — детерминированное определение рисков с подключаемым шагом исправления | |
7 | Независимый стек для экспериментов — движок оценки флагов на консистентном хэшировании (таргетинг, раскатки, варианты, предварительные условия, аварийный рубильник) + сервер флагов с горячей перезагрузкой, детерминированное распределение A/B/нескольких вариантов, статистика с нуля (z-тест двух долей + доверительные интервалы Уилсона, тест Уэлча, без scipy), расчёт объёма и мощности с поправкой Бонферрони, контроль яркости раскатки и аудит инсталляций кода | |
6 | Обе стороны вебхуков: подпись и проверка HMAC для GitHub/Stripe/Slack/Shopify-pod и общих схем (констант, time, replay windows), приём с проверкой и дедупликацией, надёжная идинг с ретраями с backoff/jitter + | |
8 | Полный pipeline: поток JSON-логов с контекстом и маскированием секретов; разбор любого формата (JSON/logfmt/nginx/syslog) в NDJSON; запросы с учётом уровня и времени; агрегирование (нормы по уровням, top-N, процентили отклика, timechart); чтение лог-файлов с ротацией в реальном времени; случайная маскировка PII/секретов; отправка в Loki/Elasticsearch/HTTP (пакетами + ретраи); алерт-правила на трош (всплески/отсутствие) | |
8 | Столпы трассировки и метрик: передача контекста W3C trace, встраивание shell-команд в разные OpenTelemetry spans (в вложенные tracing tree), экспорт в OTLP/Jaeger/Zipkin (пакетами + ретраи), анализ дерева трассы / критических путей / процентилей задержек, ASCII-графиков трассировок; через Prometheus library + | |
8 | Генерация дашбордов Grafana, правил алертов Prometheus, многодревенных SLO burn-rate алертов и маршрутизации Alertmanager по спецификации; тестирование правил на значениях метрик (promtool-lite, CI assertions); отправка уведомлений в Slack / PagerDuty / Alertmanager / webhook; живой терминал Iдэшборд (gauges/sparklines); и самодостаточная HTML-страница статуса | |
8 | Анализ billing exports по сервисам/задачам/тегам (+тренды и драйверы), детектирование аномалий и взлётов, прогноз расхода на конец периода относительно бюджета, тег-основанью showback/chargeback с покрытием, контроль бюджета (до плюс прогноз), рекомендации rightsizing, освобожение неиспользуемых/осиротевших ресурсов и советы по Reserved-Instances / Savings-Plans — всё на основе выгруженных биллинга, без облачное API на | |
8 | Подготовка и развёртывание IRC-серверов ergo в docker, запуск устойчивых канальных агентов (режимы pipe/exec/log), оркестрация всего флота агентов из спецификации с рестартом по heartbeat, права операторов/администраторов, мониторинг канала (алерты на тишину, флуд, слова, ухождение), гейт-проверку что expects messages are in place, скриптируемый минский announcer и выгрузка CHATHISTORY export (NDJSON/text/HTML, ) — только stdlib-only IRC, output tested with real ergo | |
3 | Электронная почта через любой SMTP-сервер; SMS/звонки через Twilio-совместимый API — соединительные данные |
Выкатывайте решения безопасно, держите конфигурацию актуальной и не давайте системе останавливаться.
Категория | Инструменты | Описание |
8 | Линтинг конфигураций GitHub Actions / GitLab CI на корректность и безопасность (незакреплённые actions, инъекции скриптов, захардкоженные секреты), генерация пайплайна на основе обнаруженного стека, локальный запуск пайплайнов с DAG стадий/зависимостей и матрицей, расширение матриц сборки, вычисление версий из Conventional Commits, генерация записей Keep-a-Changelog, шлюзы развёртывания (покрытие/CVE/тесты/тегирование) и упаковка/проверка артефактов сборки с провенансом | |
8 | Автоматизированный контроллер раскатки с метрическими шлюзами с автооткатом, скоринг канареечного анализа (продвинуть/удержать/откатить), оркестрация развёртывания blue-green и по кольцам, SLO-сторож с автоматическим откатом при устойчивом нарушении, шлюз заморозки развёртывания по error-budget (SRE burn-rate), планировщик стратегии раскатки (blast-radius) и операционный аварийный рубильник с журналом аудита | |
8 | Анализ планов Terraform на деструктивные/приводящие к потере данных изменения, инвентаризация состояния (+ секреты в состоянии), security-линтер для IaC (tfsec-lite), применение policy-as-code (fail-closed), ежемесячная оценка стоимости с дельтами планов (infracost-lite), генерация cloud-init user-data с валидацией по реальной схеме, сборка/конвертация Ansible inventory (ini/yaml/json) и оркестрация multi-stack plan/apply/destroy с защитными подтверждениями + блокировками + аудитом | |
8 | Линтер безопасности/надёжности манифестов (kube-linter-lite), генератор усиленных манифестов (проходящих линтер), калькулятор resource-request/QoS/right-sizing, рендерер оверлеев по окружениям (mini-kustomize), проверка конфигурации проб + живое выполнение проб, симулятор rolling-update (min-availability), генератор NetworkPolicy + анализатор открытых рабочих нагрузок, а также линтер Dockerfile + инспектор образов — всё нативно для манифестов (кластер/kubectl не нужны) | |
8 | Настраиваемый edge-шлюз (маршрутизация/аутентификация/LB/CORS/rewrite), канареечное разделение трафика с живыми метриками stable-vs-canary, агрегация API (BFF) с параллельным fan-out/merge, реестр service-discovery (TTL + heartbeat + вытеснение), mesh-sidecar с ретраями/таймаутами/circuit-breaking + изгнанием выбросов, прокси с инъекцией сбоев для chaos-тестирования, принудительное соблюдение OpenAPI-контрактов на границе и mTLS-идентичности сервисов (CA + SPIFFE leaf-сертификаты) | |
8 | Прокси с учётом версий (маршрутизация по path/header/Accept/query к апстримам по версиям), прокси, внедряющий заголовки RFC 8594 Deprecation/Sunset/Link/Warning (+ 410-on-sunset), валидатор манифеста жизненного цикла версий + таймлайн, аудит sunset как CI-шлюз с живым зондированием заголовков, анализ использования устаревших endpoint'ов по access-логам в разрезе потребителей, генератор Markdown-руководства по миграции между двумя спецификациями, поэтапные уведомления об устаревании T-minus и автономный резолвер/тестер согласования версий | |
8 | Многослойный рендеринг конфигурации + шаблонизация | |
8 | Независимое от хоста администрирование Vault — запуск команды только с ограниченными секретами в чистом окружении, настройка AppRole с минимальными привилегиями, ротация ключей с проверкой хеша, unseal, зашифрованное резервное копирование + восстановление после сбоев и экспорт health/KV через HTTP API; настройка полностью через переменные окружения | |
6 | Все 5 классических алгоритмов ограничителей (token/leaky bucket, fixed/sliding window) в виде библиотеки + CLI, распределённый ограничитель через атомарный Redis Lua, применяющий ограничения reverse proxy (429 + заголовки | |
8 | Движок полного/инкрементального зашифрованного (AES-256-GCM) резервного копирования, восстановление с разрешением цепочки с проверкой контрольных сумм каждого файла, проверка целостности/цепочки + глубокое тестовое восстановление, GFS-ротация с удалением, резервное копирование/восстановление БД (SQLite/Postgres/MySQL), офсайт-репликация с отслеживанием задержки, DR-runbook с отслеживанием RTO + учения и мониторинг свежести резервных копий (алерты RPO/отсутствия/уменьшения) | |
8 | Производство/потребление событий с consumer groups + обработкой dead-letter на Redis Streams и Kafka, мониторинг отставания потребителей (алерты по порогам), управление/перезапуск DLQ, реестр версионированных схем событий с проверками обратной/прямой совместимости, транзакционное outbox-реле (БД→стрим), повтор/переобработка событий по id/диапазону времени и read-only просмотр живого стрима | |
10 | Инструменты management-API RabbitMQ: дашборд здоровья, инвентаризация/здоровье очередей, аудит потребителей/подключений, монитор dead-letter, экспорт топологии, просмотр сообщений, тест публикации и защищённая очистка | |
10 | Дашборд здоровья, память по префиксам, большие ключи, аудит TTL/конфигурации, slowlog, аудит клиентов, задержки, горячие/холодные ключи и экспорт/восстановление keyspace | |
7 | Мониторинг NVIDIA GPU/CUDA, здоровье Ollama/LiteLLM и дашборд стека одной командой | |
8 | Линтинг SSH-конфигурации, проверки нескольких хостов, гигиена known_hosts/authorized_keys, параллельное выполнение, туннели | |
6 | только авторизованные хосты | |
8 | ТОЛЬКО авторизованная/собственная инфраструктура |
Строительные блоки для ассистентов и автоматизаций, которые приводят цикл в движение.
Категория | Инструменты | Описание |
2 | MCP stdio-сервер, который предоставляет Claude весь набор инструментов в виде четырёх мета-инструментов (ранжированный поиск инструментов, детализация по каждому инструменту с живым | |
23 | Переиспользуемые паттерны агентных циклов — ReAct, plan-execute, reflexion, self-consistency, debate, tree-of-thought, tool-routing (текст + нативный function-calling), budget/map-reduce, циклы verifier и code-interpreter, constitutional revise, LLM-judge, оркестрация supervisor/worker, ролевые пайплайны, кросс-модельные ансамбли, долговременная память, компактизация контекста, RAG-with-citations, schema-extract, gated shell operator и FSM guardrails — для любого чат-API, совместимого с OpenAI | |
4 | Изолированный раннер инструментов в подпроцессах (тайм-аут/повторы/rlimit CPU+память, вывод всегда в JSON), JSON-Schema валидация ввода/вывода + генерация схемы по примеру, проверка безопасности команд shell/SQL на опасные паттерны и семантический поиск похожих инструментов по описаниям — всё только на stdlib, CLI + импортируемые модули | |
8 | по умолчанию нацелены на локальный API, совместимый с Ollama: | |
8 | требуют | |
8 | Продвинутые краулеры на фреймворке Crawlee (очередь запросов, автомасштабирование, повторы) — глубокий обход сайта, скрапинг по схеме list->detail, постраничные JSON API, SEO-аудит и проверка битых ссылок, CSS+XPath (Parsel), обход по sitemap, JS-рендеринг + скриншоты (Playwright) и отказоустойчивый краулер с поддержкой прокси | |
8 | Продвинутые Libretto-воркфлоу на базе Playwright (TypeScript, запуск через | |
11 | транскрибация по умолчанию нацелена на Whisper API, совместимый с OpenAI: |
Всегда полезный ящик рабочего стола.
Категория | Инструменты | Описание |
5 | Диагностика CPU/памяти/диска, мониторинг процессов, управление службами и автозагрузкой | |
10 | Организация, дедупликация, переименование, синхронизация, резервное копирование, tail и конвертация файлов и данных | |
6 | Бенчмарк и автовыбор кодеков (gzip/bzip2/xz/zstd), создание и просмотр архивов, сжатие без потерь для экономии места (с проверкой обратимости) и аудит дерева каталогов на предмет выгоды от сжатия и дубликатов | |
10 | Дашборды локальных dev-сервисов, здоровье репозиториев, заметки Obsidian, хелперы для nginx/vault/docker | |
2 | Захват любого |
Этот набор инструментов предназначен для легитимного администрирования систем, разработки, оценки безопасности и исследований на системах, которыми вы владеете или которые вам явно разрешено администрировать. В нём нет инструментов для взлома паролей, обхода аутентификации или несанкционированного доступа. Категории network recon и network tunneling — это инструменты двойного назначения для диагностики и эксплуатации; используйте их только против инфраструктуры, которой вы владеете или на проверку которой у вас есть письменное разрешение, и обращайте внимание на уведомления об авторизованном использовании для каждого инструмента.
Автономность: каждый скрипт работает сам по себе; никаких перекрёстных импортов между инструментами.
Конфигурация через параметры: цели, учётные данные и пути задаются флагами или переменными окружения. Секреты читаются только из окружения и никогда не передаются через командную строку.
--dry-run для всего, что изменяет состояние; --help везде.
Локальность прежде всего: AI-инструменты и инструменты для работы с данными по умолчанию используют локальные сервисы (Ollama, SearXNG, локальную векторную БД и т.п.) и корректно деградируют, когда сервис недоступен.
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).
