Как превратить 10 000 API-эндпоинтов в одну CLI-команду для ИИ-агентов — VogueTech

Что появилось / что изменилось

Появился openapi-to-cli — утилита, которая превращает любую OpenAPI/Swagger-спецификацию в один CLI-инструмент без генерации кода и компиляции.

Ключевые факты:

На входе: OpenAPI/Swagger из URL или локального файла, базовый URL API, настройки авторизации, опциональные фильтры эндпоинтов по профилям.
На выходе: бинарник ocli, где каждая операция API становится отдельной CLI-командой.
Команды создаются на лету из кешированной спецификации, а не прошиваются в код.
Спеки хранятся в .ocli/specs, можно подключать несколько профилей для одного API.
Один бинарник может содержать несколько API сразу и переключаться между ними через ocli use <profile>.
Есть два режима поиска по большим API: BM25-поиск по естественному языку и поиск по регулярным выражениям.
Поддерживаемая авторизация в версии v0.1.7: Basic и Bearer. OAuth2/Auth0 и кастомные заголовки пока не работают.

Главное изменение по сравнению с MCP/Skills: вместо сотен JSON-описаний инструментов вы даёте агенту один shell-инструмент, а он сам ищет нужную команду.

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

Схема простая:

Вы вызываете openapi-to-cli и "онбордите" API:

npx openapi-to-cli onboard \
  --api-base-url https://api.github.com \
  --openapi-spec https://raw.githubusercontent.com/github/rest-api-description/main/descriptions-next/api.github.com/api.github.com.json

Это создаёт профиль default и кеширует спецификацию.

Для именованного профиля, например github:

ocli profiles add github \
  --api-base-url https://api.github.com \
  --openapi-spec https://raw.githubusercontent.com/github/rest-api-description/main/descriptions-next/api.github.com/api.github.com.json

Под капотом ocli:
- кеширует спецификации в .ocli/specs;
- хранит несколько профилей для одного API (например, read-only и admin);
- позволяет включать/выключать эндпоинты по профилю;
- монтирует несколько разных API в один бинарник и переключается между ними командой ocli use <profile>.
Для больших API --help уже бесполезен, поэтому есть поиск:
- BM25-поиск на естественном языке:
```
ocli commands --query "create pull request" --limit 5
ocli commands --query "upload file" --limit 5
```
- Регулярные выражения:
```
ocli commands --regex "repos.*pulls"
```

Поиск смотрит на имя команды, HTTP-метод, путь, описание и параметры. BM25-движок написан на TypeScript и портирован из picoclaw.

Что это значит для вас

Если вы строите агентные пайплайны и уже тонете в MCP-серверах и Skills, openapi-to-cli решает несколько практических проблем.

1. Меньше шума в контексте LLM

100 MCP-инструментов = сотни JSON-схем в контексте, плюс отдельный сервер и транспортный слой. Это съедает окно контекста и усложняет выбор инструмента.

100 CLI-команд = один shell-инструмент и текстовый поиск по списку команд. Агент тратит токены на рассуждение, а не на метаданные инструментов.

Типичный сценарий для агента:

ocli commands --query "create pull request" --limit 5
# агент выбирает лучшую команду
ocli repos_pulls_post ...

Для интеграции в ИИ-систему вы просто даёте модели один инструмент "выполни shell-команду", а дальше она сама ищет нужный вызов API через ocli.

2. Быстрая разведка чужих API из терминала

Нужно быстро понять, что умеет GitHub REST API или Box API:

ocli use github
ocli commands --query "upload file" --limit 5

Дальше запускаете найденную команду, подставляете параметры и сразу видите результат. Это удобно для разработчиков, которые не хотят листать документацию или писать временные скрипты.

3. Управление правами через профили

Для одного и того же API можно завести:

read-only профиль для осторожных агентов;
write/admin профиль для доверенных автоматизаций.

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

4. Где инструмент пока не поможет

Если ваш API использует OAuth2, Auth0 или сложную схему с кастомными заголовками, текущая версия v0.1.7 вам не подойдёт.
Если вы жёстко завязаны на MCP-экосистему и вам критична именно эта архитектура, придётся городить мост между MCP и CLI.
Для простых скриптов с 2–3 эндпоинтами openapi-to-cli может быть избыточен — проще написать руками.

Инструмент распространяется через npm (npm install -g openapi-to-cli или npx openapi-to-cli), так что для России всё упирается только в доступ к npm и GitHub. Если они у вас открываются без VPN, проблем не будет.

Место на рынке

openapi-to-cli конкурирует не с GPT-5 или Claude 4, а с подходами к интеграции API в агентные системы.

Сегодня популярны три варианта:

MCP-сервера и Skills — каждому эндпоинту свой инструмент. Проблема: при сотнях эндпоинтов вы получаете "зоопарк" конфигураций и раздутый контекст.
Сгенерированные SDK — удобно для обычной разработки, но для LLM-агентов это десятки файлов кода и сложная обвязка.
CLI-обёртки — один инструмент, много команд. Вот сюда и попадает openapi-to-cli.

По сравнению с MCP-подходом:

меньше накладных расходов на описание инструментов — один бинарник вместо сотен JSON-схем;
проще масштабировать большие API вроде GitHub REST API с сотнями эндпоинтов;
легче подключать несколько разных API в один агент через ocli use github / ocli use box.

С другой стороны, у MCP есть плюс в виде стандартизированного протокола и экосистемы вокруг него. openapi-to-cli — это ставка на старый добрый shell и текстовый поиск.

Если вы уже управляете сотнями MCP-серверов и Skills, имеет смысл честно оценить: какую часть из этого можно заменить одной CLI-командой + поиском по командам. Для больших API с OpenAPI-спеками ответ часто будет: "почти всё".

Что появилось / что изменилось

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

Что это значит для вас

Место на рынке

Читайте также