OpenAPI to CLI это врапер между API и консолью

Не так давно я публиковал проект openapi-to-mcp, который позволяет любой API сервер с нормальной OpenAPI/Swagger спецификацией конвертировать в MCP сервер. Но теперь я развил эту идею в сторону консоли и сделал openapi-to-cli, который по OpenAPI/Swagger спецификации генерит удобную CLI над тем же самым API.

Как это работает

Допустим в спецификации API есть такие эндпоинты:
- GET /messages
- POST /messages
- GET /status
- GET /users

В момент добавления профиля openapi-to-cli конвертирует их в команды CLI примерно такого вида:
- npx openapi-to-cli messages_get
- npx openapi-to-cli messages_post
- npx openapi-to-cli status
- npx openapi-to-cli users

Каждая такая команда это по сути HTTP запрос к API серверу, параметры запроса попадают через опции CLI, а ответ API печатается обратно в терминал, подробную справку по каждой команде можно почитать добавив -h или --help на конце.

Быстрый старт через npx

Самый простой способ попробовать:

npx openapi-to-cli profiles add default \
  --api-base-url https://127.0.0.1:8080 \
  --openapi-spec https://raw.githubusercontent.com/readmeio/oas-examples/refs/heads/main/3.1/json/petstore-simple.json

Эта команда:
1. качает пакет openapi-to-cli, если его еще нет в кэше
2. создает профиль default для вашего API
3. скачивает и кэширует OpenAPI спеку под .ocli/specs/default.json
4. записывает настройки профиля в .ocli/profiles.ini

Список доступных команд можно посмотреть вызвав:

npx openapi-to-cli commands

После этого можно ходить в API из терминала, например вот так:

npx openapi-to-cli messages --limit 10

Есть короткая команда ocli, она заменяет npx openapi-to-cli, но нужно ставить глобально через через:

npm -g openapi-to-cli

Подробная справка на странице проекта.

Исходники: https://github.com/EvilFreelancer/openapi-to-cli
Пакет: https://www.npmjs.com/package/openapi-to-cli

Забудь про MCP и tools — конвертируй 100 000 API методов в один CLI инструмент на лету

Все сейчас пишут MCP-серверы и tools для агентов
На каждый API endpoint — отдельный tool с описанием, параметрами, схемой
10 методов? Ок
100? Уже больно
845 (GitHub API)? Удачи (да да можно делать поиск и тулов и MCP) но какой же это зоопарк и как его поддерживать?

Но так же мы поняли новый тренд это cli обертки
От сюда мы с @evilfreelancer пошли другим путём: берём любой OpenAPI spec (JSON/YAML) и конвертируем его в CLI команды на лету Без кодогенерации.
Без компиляции
Один бинарник — любое API

Что это даёт:

→ ocli search --query "create pull request" --limit 5 — BM25-поиск по 845 эндпоинтам за 7мс
→ ocli search --regex "repos.*pulls" — regex по путям, именам, описаниям
→ Несколько профилей одного API с разными наборами эндпоинтов (include/exclude)
→ Несколько API серверов в одном инструменте

Почему CLI, а не MCP tools для агентов?

100 MCP tools → ~50 000 токенов на описания в контексте
100 CLI команд → 1 tool "execute_command" + поиск нужной команды

Объективно я счита что агентов больше таскают команды вызвать, нежели разбираться с тонне контекста tools

Агент вызывает ocli search, находит нужную команду, выполняет её
Один tool_exec вместо тысяч
Контекстное окно свободно для работы, а не для описаний инструментов.

Сделал быстрый тест на реальных API:
- GitHub API — 845 endpoints, 11MB spec, JSON
- Box API — 258 endpoints, YAML

BM25 поиск — порт из Go (picoclaw) на TypeScript с Robertson IDF smoothing.

npm install -g git+https://github.com/EvilFreelancer/openapi-to-cli.git#feat/command-search

ocli profile add github

ocli search --query "upload file" --limit 5

GitHub: https://github.com/EvilFreelancer/openapi-to-cli

Немножечко хайпа на Reddit думаю не помешает ;)

Забрал RTX 4090 из сервиса Vik-on после модификации до 48гб, солидно она схуднула конечно. #server

Поставил в сервер, загрузил, ничего настраивать не пришлось, система подхватила карточку сама, штатный драйвер её увидел, даже vllm зарезервировала память под кеш.

Феномен предвзятости подтверждения и... нейросети

Сегодня предлагаю ещё один вопрос для рефлексии и философствования, на этот раз про одну из самых недооценённых проблем LLM, которая заключена не в галлюцинациях и даже не ошибках самих по себе, а в том как легко модели подыгрывают позиции пользователя.

Когда человек изучает некую тему, например про бег, он может спросить модельку "почему бег полезен" и получить вполне убедительный текст про сердце, кардиовыносливость, настроение и метаболизм. Но если другой человек спросит "почему бег вреден", модель с такой же уверенностью распишет про нагрузку на суставы, травмы, кортизол и износ организма.

Чуть иначе сформулировал запрос - и получил не просто другой акцент, а местами вообще противоположный вывод, в таких случаях мне вспоминается народная мудрость:

Вопрос содержит в себе 90% ответа.

Любой наш вопрос по отношению к модели скорее всего будет задан не из нейтральной позиции, даже при работе с кодовым агентом, а склоняясь к некоей определённой точке зрения, так как обычно вопрос уже содержит в себе скрытый ответ или намёк на него.

Частенько некоторые из нас не столько исследуют тему, сколько приходят за подтверждением того, к чему уже и так склоняются. И модель в таком сценарии работает не как объективный источник знаний, а как множитель мысли пользователя, усиливая его позицию аргументами. Про нечто похожее я уже писал ранее (но с точки зрения программирования), в том исследовании говорилось, что чем менее опытный инженер при помощи агентов создаёт программное обеспечение, тем менее сопровождаемое оно получается. И в этом, как по мне, одна из самых неприятных сторон языковых моделей, они очень убедительны там, где меньше всего нужна убедительность и больше всего нужна объективность. Проблема не только в том, что модель может ошибиться, проблема в том, что она может ошибиться в желаемую для пользователя сторону.

На этом фоне показательно смотрится тема, которую поднял Влад @NGI_ru в разрезе психологии. В посте на который я ссылаюсь проблема рассматривается с точки зрения галлюцинаций модели, но я всё же склоняюсь к предположению о том, что причина в самих вопросах (составленных вероятно предвзято), содержащих в себе частицу ответа, которую модель мультиплицировала.

В общем есть над чем задуматься.

PS. Кстати, рекомендую ознакомиться с вот этой публикацией Confirmation bias (предвзятость подтверждения), там очень хорошо расписана затронутая мною тема.

Openapi-to-cli

«openapi-to-cli» (ocli) — CLI-утилита на TypeScript, которая превращает любое OpenAPI/Swagger API в набор CLI-команд в рантайме, без кодогенерации. По сравнению с MCP+Search подходом, ocli даёт в 15 раз более компактные результаты поиска

Самый быстро растущий наш с Пашей проект за меньше чем 5 дней 100+ звезд

400 + Clones
2000 посещений репо

Что интересно в части рабочих чатиков видел обсуждение и тесты тулзы (и пока только положительные впечетления)

РЕПО: https://github.com/EvilFreelancer/openapi-to-cli

SGR Agent Core 0.7.0

Кратенько и по порядку, в этом релизе:

0️⃣ В документацию добавили страницу Highlights.

1️⃣ В ядро доехал долгострой RunCommandTool, причём не просто "запусти команду", а с разделением на safe и unsafe режимы, workspace-настройками и нормальной обвязкой под выполнение команд.

2️⃣ Переработали WebSearchTool, теперь помимо Tavily есть ещё поддержка Brave и Perplexity.

3️⃣ Ещё одна важная фича - поддержка stateless контекста пользователя, для интеграций, где нельзя или неудобно тащить полноценный stateful контекст, это очень полезная штука.

4️⃣ Переосмыслили ReasoningTool, сделали его более заменяемым, в агентов добавили возможность подсовывать свой кастомный тул через параметр, тем самым завезли поддержку ризонинг моделей.

5️⃣ Добавили новый агент IronAgent для работы с моделями у которых не предусмотрена поддержка function calling.

6️⃣ Из более прикладных историй ещё доехала пагинация для web_search_tool через limit/offset, добавили фикс пустого json_data для LLM-провайдеров с кривоватым поведением, добавили простой интерактивный шел sgrsh, а также логику фильтрации тулов по их названию/описанию (чтобы экономить контекст).

7️⃣ Добавили в example агента progressive_discovery, который может эффективно работать с 50+ тулами.

Параллельно в релизе заметно причесали внутрянку, проработали возможность передавать настройки в тулы через конфиг, вынесли преобразования и валидацию на уровень model validators, упростили factory-слой, привели всё к единой модели ToolDefinition, пофиксили работу стриминга и рендеринга диалоговых сообщений и много других приятных мелочей улучшающих качество жизни.

В 0.7.0 завезли много интересного, при этом наш проект продолжает активно развиваться, а в следующих итерациях мы планируем добавить поддержку Skills, LangFuse, SearXNG и Agent Client Protocol (ACP) в режиме агента.

Обновляйтесь, тестируйте новые возможности и делитесь обратной связью, а если встретите баги или проблемы - приносите их в issues на GitHub.

Репо: https://github.com/vamplabAI/sgr-agent-core/

С уважением, команда SGR Team.

Принял VibeCode эстафету от Рината @llm_under_hood

Попросил Cursor проанализировать все репозитории на диске в которые я коммитал хотя бы один раз, репозитории без .git индекса попросил игнорировать, полученный отчёт агент собрал в Markdown файл, после чего сгенерировал из него лендос по шаблону, получилась такая вот красота.

На графике хорошо видно, что весь 2025 всё шло более менее как обычно, но в первом квартале этого года я начал уже вайбкодить по-взрослому, число уникальных репозиториев и количество коммитов увеличилось в разы.

Эстафета - передай другому вайбкодеру, прощу коллег @countwithsasha, @alexs_journal, @kdoronin_blog и @simple_agi
принять участие в этом маленьком мероприятии и поделиться своими результатами.

Вайбкод для неискушенных

Решил провести на работе один небольшой эксперимент, предложил коллегам у которых нет айтишного образования попробовать нейросети и инструменты вайбкодинга при решении своих повседневных задач.

Важное условие эксперимента в использовании self-hosted моделей и opensource агентов. Плюс поскольку участники эксперимента специализируются не на разработке, а на решении проблем бизнеса нужна модель которая пусть и не супер кодит, но зато имеет широкий кругозор.

Поэтому мною были выбраны:
- агент Crush (в девичестве OpenCode) в качестве базового TUI, но важной его особенностью является поддержка Agent Client Protocol (ACP), что позволяет встроить его в любой совместимый клиент (например obsidian, drawio или pycharm)
- модели gpt-oss 20b и 120b, потому что они в себе идеально сочетают широкий кругозор, размер, скорость и поддержку function calling, что позволяет использовать их в качестве базы для агента

Пока что только рабочую группу собираю, но на следующей неделе полагаю эксперимент пойдет в полную силу. Результатами промежуточными поделюсь в конце следующей недели, ну или раньше, ежели чего прикольного будет.

Сегодня канал преодолел 3000 подписчиков, удивительно с какой скоростью это произошло, ведь 2000 было всего навсего в ноябре прошлого года, а с тех пор прошло чуть больше 4 месяцев.

Спасибо, что вы здесь, постараюсь и дальше радовать вас своим ворчанием, феласофией и забористым контентом :)

Эксперимент (день 1)

Первая проблема с которой столкнулись участники оказалась в сложности установки консольного тула Crush, на виндовс нужна утилита winget, на макоси brew, я кстати пробежался по всем консольным тулам (типа курсора, клод кода, джемини и так далее) и эта общая проблема, вместо создания MSI/EXE пакетов для виндовс и DMG для макоси авторы большинства консольных тулов делают непонятно что, какие-то скрипты для PowerShell, какие-то curl | bash, ладно бы на линуксе только, мы тут все привычные к такому.

Вторая проблема в том, что Crush оказывается не поддерживает ACP, на эту тему есть PR у них, который открыт с февраля, вообще это очень странно, ведь Crush это форк OpenCode, почему эту часть не портировали не очень понимаю.

Третья проблема с кодировками в конфигах, нельзя просто взять, прислать JSON-конфиг с линукса, вставить его в текстовый файл на виндовс и чтобы это работало, других способов настроить тул разработчики не предусмотрели, прямо как в старые добрые времена.

ACPBox - Agent Client Protocol (ACP) в формате OpenAI API

В последнее время много занимаюсь интеграцией агентов и в какой-то момент устал каждый раз заново собирать ReAct лупу под задачу, пришла идея взять уже готового агента по Agent Client Protocol (stdio, JSON-RPC) и не городить свой HTTP-слой, а выставить наружу привычный OpenAI-совместимый API - один base URL, те же /v1/models, /v1/chat/completions (стейтлесс), /v1/responses (стейтфул), чтобы подключались обычные клиенты и SDK, типа Open WebUI и аналогов.

За пару вечеров собрать проект ACPBox, под капотом там uvicorn, на каждый worker один долгоживущий процесс агента, запросы с OpenAI-формата переводятся в ACP и обратно, стриминг и список моделей из режимов агента поддерживаются.

Установка изолированно через pipx:

pipx install acpbox

Пример минимального config.yaml для OpenCode агента:

acp:
  command:
    - opencode
    - acp
  env: {}
  workspace: "./workspace"

gateway:
  host: "0.0.0.0"
  port: 8080
  workers: 1
  threads: 1

Для курсора вместо opencode acp задаём agent acp, аналогичная фичу можно использовать и для джемини, и для клод кода и так далее.

Запускаем так:

acpbox --config ./config.yaml

На https://localhost:8080/docs появится OpenAPI/Swagger UI, можно будет потыкать агента.

Репозиторий: https://github.com/EvilFreelancer/acpbox
PyPi пакет: https://pypi.org/project/acpbox/

PS. Важный нюанс, кодовый агент, типа того же OpenCode или Cursor нужно настраивать заранее и отдельно, так как ACPBox это просто обёртка для работы кодовым агентом и занимается только решение задачи проксирования запросов от пользователя к агенту и обратно.

За вчера порядочно прокачал проект Coddy, переделал подсистему которая пишет код на ACP, так что теперь её можно использовать с любым кодовым агентом.

В планах реализовать хук автоматического переключения на новую версию Docker-контейнера после мерджа PR и автоматического бампа версии.