Обзор интеграции с агентами

Workflow в Triggo не обязательно запускать с холста. Как только вы опубликуете workflow, он превращается в вызываемое действие, которое внешние AI-агенты — Claude Desktop, Cursor, Windsurf, Claude Code или ваш собственный код на Node/Python/Go — могут обнаружить и выполнить. Эта страница — карта. Она объясняет, какие две поверхности Triggo предоставляет, когда какую выбирать и как выглядит сквозная интеграция агента.

Что значит интеграция с агентами

Когда вы собираете workflow на холсте и публикуете его, Triggo экспонирует этот workflow как удалённо вызываемое действие с типизированной схемой ввода, исполняемым эндпоинтом и отслеживанием статуса запуска. AI-агент — будь то размещённый ассистент или ваш собственный скрипт — может получить список доступных действий, изучить их схемы ввода, вызвать их с аргументами и опрашивать результат. Учётные данные, ограничения скорости, подтверждения и проверка областей доступа обрабатываются Triggo; агенту нужен только API key.

Две поверхности

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

MCP (Model Context Protocol)

Потоковый HTTP-эндпоинт по адресу POST /mcp. Сервер идентифицируется как triggo-runtime версии 1.0.0. Он предоставляет 19 инструментов в четырёх категориях:

• Действия (6) — list_actions, get_action, run_action, get_run_status, list_runs, approve_run
• Workflow (7) — list_workflows, get_workflow, create_workflow, update_workflow, delete_workflow, deploy_workflow, open_workflow
• Коннекторы (3) — list_connectors, get_connector_operations, get_operation_schema
• Сборки (3) — build_connector, get_build_status, validate_connector

MCP спроектирован для нативного обнаружения инструментов LLM — клиент автоматически сообщает модели о доступных инструментах, вам не нужно вручную прописывать HTTP-вызовы. Если ваш хост агента уже говорит на MCP, это самый короткий путь.

Runtime REST

Обычные HTTP-эндпоинты по префиксу /api/v1/runtime/. Они существуют для вызывающих, которым не нужна (или не должна быть нужна) зависимость от MCP SDK: ваших собственных скриптов, ботов, срабатывающих по вебхуку, cron-задач или одного workflow, вызывающего другой через HTTP-узел.

Обе поверхности используют одни и те же сервисы: действия берутся из одного каталога, запуски записываются в один журнал, ограничения скорости считаются по одному ключу Redis.

Когда какую использовать

Правило большого пальца: если вызывающий — это LLM, которому нужны автоматически обнаруживаемые инструменты, используйте MCP. Во всех остальных случаях — REST.

Модель аутентификации

Обе поверхности аутентифицируются одинаково — Bearer API key, выпущенный из дашборда Triggo:

Authorization: Bearer trg_<your-key>

У ключей есть области доступа (scopes). Каждый MCP-инструмент и каждый REST-эндпоинт объявляет, какие области ему нужны, и запрос отклоняется на границе, если области не совпадают. Канонические области доступа:

• actions:read — просматривать и изучать опубликованные действия
• actions:run — выполнять действия
• runs:read — читать статус и историю запусков
• approvals:decide — одобрять или отклонять запуски, ожидающие подтверждения человеком
• connectors:read — просматривать каталог коннекторов
• connectors:write — собирать и валидировать коннекторы

API key создаются в дашборде в разделе Agent Setup. Ключ в открытом виде показывается ровно один раз при создании; в базе Triggo хранит только соль и SHA-256-хэш, плюс 8-символьный префикс для отображения в UI. Потеряли ключ — выпускаете новый, восстановить нельзя.

Подробный цикл создания / ротации / отзыва см. в API keys.

Сквозной сценарий (6 шагов)

┌─────────────────┐  ┌──────────┐  ┌──────────┐  ┌───────────────┐
│ 1. Создать ключ │→ │ 2. Собрать│→│ 3. Опубл.│→ │ 4. Обнаружить │
│    (scopes)     │  │   workflow│  │ (действие)│  │ list_actions  │
└─────────────────┘  └──────────┘  └──────────┘  └───────┬───────┘
                                                         ↓
                                   ┌────────────┐  ┌──────────┐
                                   │ 6. Опросить│← │ 5. Вызвать│
                                   │ get_run    │  │ run_action│
                                   └────────────┘  └──────────┘

1. Создайте API key в Triggo с областями, которые нужны агенту (обычно actions:read + actions:run + runs:read).
2. Соберите workflow на холсте — триггер, действия, сопоставление полей.
3. Опубликуйте workflow. Публикация превращает его в вызываемое действие со стабильным slug и типизированной схемой ввода.
4. Обнаружьте действие со стороны агента — list_actions по MCP или GET /api/v1/runtime/actions по REST.
5. Вызовите действие — run_action (MCP) или POST /api/v1/runtime/actions/:slug/run (REST). Ответ содержит runId.
6. Получите результат — get_run_status (MCP) или GET /api/v1/runtime/runs/:runId (REST). Если в workflow есть шаг подтверждения, запуск остаётся в статусе pending_approval, пока кто-то его не разрешит.

Известные ограничения

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

• MCP-инструментам для workflow и сборки коннекторов нужны области, которые пока не доступны на API key. MCP-инструменты для workflow требуют workflows:read / workflows:write, а инструменты сборки коннекторов — connectors:write. Не все из этих строк областей пока входят в канонический список областей API key, поэтому доступ по Bearer-ключу к этим конкретным инструментам сейчас фактически закрыт. Инструменты действий и запусков по MCP с Bearer-ключом работают нормально. Доступ через OAuth-сессию (то есть использование Triggo из браузера, где вы залогинены) не затронут. Мы закрываем этот разрыв — следите за обновлениями в ограничениях скорости и release notes.
• Процессы подтверждения через API key ещё дорабатываются. Ожидайте, что поверхности approve_run / POST /runs/:runId/approve работают, но перед тем как выстраивать продакшн-цикл подтверждений поверх Bearer-ключа, проверьте release notes. Отдельная страница про подтверждения задокументирует стабильный контракт после его релиза.
• Ограничения скорости — на ключ, а не на пользователя. Один агент с одним ключом может исчерпать окно для всех, кто его использует. Заводите отдельный ключ на агента или на интеграцию, чтобы изолировать сбои.

Смотрите также

• API keys — создание, ротация и отзыв
• MCP quickstart — конфигурация Claude Desktop / Cursor / Claude Code
• Публикация workflow как действий — как workflow с холста становится вызываемым действием
• Ограничения скорости — лимиты по тарифам, заголовки, поведение при повторных попытках