OpenConnector: обзор открытого шлюза коннекторов для AI-агентов

01Что это и зачем нужен шлюз

Проблема, которую решает OpenConnector, стара как интеграции: агенту нужен доступ к почте, задачам, таблицам и CRM, а давать ему мастер-ключ от всех сервисов нельзя. Классический путь — писать свой OAuth-слой для каждого сервиса и хранить токены в базе продукта. OpenConnector предлагает второй путь: поднять шлюз, один раз авторизовать пользовательские аккаунты в нём, а агенту выдать runtime-токен с политиками доступа.

Позиционирование прямое: в README проект называет себя открытой альтернативой Pipedream и Composio. Отличие в модели развёртывания — шлюз можно поднять в своём Docker или Kubernetes, с SQLite или PostgreSQL, а можно взять управляемый хостинг OOMOL. Контракты провайдеров и Action при этом одинаковые, заявленный смысл — «подключил один раз, используешь везде».

02Как устроен шлюз: схема работы

Архитектурно это три слоя. Первый — каталог провайдеров с описанием аутентификации (API-ключ, OAuth2, кастомные креды, без авторизации), схемами запросов и нужными скоупами. Второй — рантайм, который хранит подключения, выдаёт runtime-токены и исполняет Action. Третий — интерфейсы доступа: MCP-эндпоинт для агентных хостов, HTTP и OpenAPI для своих клиентов, SDK для кода приложения, CLI как локальный релей и веб-консоль для администрирования.

Для агентных хостов важна именно MCP-ветка: шлюз поднимает эндпоинт /mcp и отдаёт Action как MCP-инструменты. Это значит, что Claude Code, Codex, Cursor или собственный хост, умеющий MCP, подключаются к нему как к обычному серверу инструментов — без отдельного SDK под каждый сервис.

03Каталог и способы развёртывания

Каталог — главный актив проекта, и он проверяется одним запросом. На 01.11.2026 живой ответ connector.oomol.com/v1/catalog отдаёт 1698 провайдеров, 21 345 Action и 59 сервисов так называемого fusion API. В README при этом скромнее: «1000+ providers и 10 000+ Actions». Разница объясняется тем, что каталог растёт быстрее документации — в тексте обзора мы держим цифру из живого API и датируем её.

Практический вывод по развёртыванию: OOMOL Hosted снимает главную боль — регистрацию десятков OAuth-приложений, но привязывает к чужому рантайму. Self-host возвращает контроль и оставляет вам стоимость эксплуатации: база, хранилище, ротация кредов и обновления. Промежуточный вариант с Helm выглядит самым честным для продукта, у которого уже есть пользователи.

04Сравнение с Composio и Pipedream

Оба конкурента называются в README самого проекта, поэтому сравнение уместно. Мы берём только проверяемые поля на одну дату — звёзды GitHub, лицензию, наличие открытого self-host и MCP-режима. Маркетинговые цифры каталогов у конкурентов мы не воспроизводим: их нельзя снять тем же способом, что каталог OpenConnector.

Что это сравнение показывает по существу: OpenConnector не выигрывает по популярности и не пытается. Его аргумент — инспектируемый рантайм и одинаковые контракты в открытой и коммерческой поставке. Если команде нужно «просто работает и пусть живёт в облаке», Composio и Pipedream остаются более коротким путём. Если нужно «токены пользователей не покидают мой контур», выбор сужается до self-host вариантов, и здесь OpenConnector — самый свежий и самый открытый из них.

05Оценки по осям и динамика разработки

Оценки редакционные: мы не прогоняли шлюз под нагрузкой, поэтому «зрелость» и «прозрачность цены» занижены относительно возможностей. Веса осей: каталог 0,25; контроль и self-host 0,20; MCP и интерфейсы 0,20; документация 0,15; зрелость 0,10; прозрачность цены 0,10. Итог по формуле — 8,3 из 10.

06Плюсы, минусы и риски

• Токены не уходят в агент. Креды провайдеров живут в рантайме, агент работает с runtime-токеном и политикой доступа.
• Один каталог на все языки и фреймворки. MCP, HTTP, OpenAPI и SDK обращаются к одним и тем же Action с одинаковыми схемами.
• Реальный self-host. Docker, Node, PostgreSQL/SQLite, S3-совместимое хранилище и Helm-чарт — а не «self-host по запросу в sales».
• Инспектируемые контракты. У Action видны схемы запроса и ответа, требуемые скоупы и лениво подгружаемый исходник исполнителя.
• Аудит из коробки. Политики allow/block на уровне Action, редактированные логи прогонов, транзит файлов через собственное хранилище.

• Возраст. Проект публичный с 29.06.2026. Четыре месяца — мало для шлюза, через который идут доступы к корпоративной почте.
• Свои OAuth-приложения. В self-host режиме каждый OAuth-провайдер требует регистрации приложения у вендора — это дни работы, а не минуты.
• Лицензия не та, что ждёшь. README называет её Modified Apache-2.0, GitHub API отдаёт NOASSERTION. Юридически это надо читать, а не предполагать.
• Документация догоняет код. README обещает «1000+ провайдеров и 10 000+ Action», живой каталог — 1698 и 21 345; часть страниц docs описывает старые цифры.
• Цены hosted-режима не публичны в машинночитаемом виде. Состав Connect-кредитов и стоимость сверх пакета надо смотреть на oomol.com.

07Кому подходит и с чего начать

Подходит продуктовым командам, которые строят агента с доступом к рабочим приложениям и не хотят писать OAuth-слой на каждый сервис: типовой сценарий — «агент читает почту, раскладывает задачи в трекер и пишет в Slack». Второй сценарий — внутренние платформы, где нужно централизованно выдавать доступы и видеть, кто что вызывал. Третий — self-host в закрытом контуре, где облачные коннекторы запрещены политикой.

Не подходит, если нужен один сервис и одна функция: поднимать шлюз ради вызова GitHub API — избыточно, хватит токена в переменной окружения. Не подходит и тем, кто не готов эксплуатировать состояние: PostgreSQL или SQLite, хранилище для транзитных файлов, обновления и ротация кредов — это ваша зона ответственности в self-host.

git clone https://github.com/oomol-lab/open-connector
docker compose up

curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' -d '{"input":{}}'