Документация

Всё что нужно для старта с mttrly.

Руководство по быстрому старту

Три шага: создать аккаунт, установить обязательный агент и запустить первую проверку.

Шаг 1: Создай аккаунт

Зарегистрируйся по email. Telegram можно подключить позже для мобильных алертов и approval; Slack и Discord — limited beta для выбранных клиентов.

Шаг 2: Установи агента

Открой Add server в аккаунте и скопируй token-specific installer из onboarding. Команда уникальна для этого подключения и устанавливает обязательный systemd-агент.

app.mttrly.com → Add server → Copy install command

Шаг 3: Проверь подключение

Открой дашборд или Telegram и выполни /healthcheck. В MCP-enabled IDE вызови mttrly_get_server_status. Если агент вернул актуальные CPU, память и диск, подключение готово.

Справочник по командам

Актуальный стартовый набор messenger-команд. Полный каталог, доступный аккаунту, покажет /help в подключённом канале.

$ /healthcheck

Запустить общую проверку сервера: load, память, диск и настроенный HTTP healthcheck.

Example:

/healthcheck

$ /status

Показать подробный systemd-статус одного сервиса.

Options:

<service>Точное имя systemd-сервиса

Example:

/status nginx

$ /logs

Получить ограниченный снимок journal-логов одного сервиса.

Options:

<service>Точное имя systemd-сервиса

Example:

/logs nginx

$ /restart

Запросить перезапуск systemd-сервиса. Это approval-required действие; флага обхода подтверждения нет.

Options:

<service>Точное allowlisted-имя systemd-сервиса

Example:

/restart nginx

$ /setup_deploy

Создать deploy profile с существующим app path, build/restart-шагами и healthcheck. После настройки deploy запрашивается обычной фразой.

Example:

/setup_deploy

Настройка

Hosted settings и deploy profiles настраиваются в аккаунте и guided chat flows. Общего файла /etc/mttrly/config.yaml у агента нет.

Модель конфигурации: Hosted account settings и сгенерированные файлы агента в /etc/mttrly

Hosted server settings

Добавляй и выбирай серверы в дашборде или подключённом мессенджере. Installer записывает server-specific identity files; не копируй токены между серверами.

app.mttrly.com → Servers → Add server

/etc/mttrly/allowed-services.conf

Systemd wrappers разрешают state-changing действия только для точных unit names из этого allowlist. Одно имя сервиса на строку.

nginx
myapp.service
redis-server

Deploy profile

Настрой существующее приложение через /setup_deploy и меняй профиль через /deploy_config. Профиль хранится в hosted configuration, а не как кастомный YAML playbook на агенте.

/setup_deploy
/deploy_config

Модель безопасности

Безопасность встроена в архитектуру mttrly.

Только исходящие соединения

Агент сам устанавливает зашифрованное исходящее соединение. Новый входящий управляющий порт mttrly не требуется; существующие правила файрвола и порты приложений остаются под твоим контролем.

Подтверждение опасных действий

Approval-required restart, deploy и script-действия обычно создают pending action. Явно авторизованный bounded Investigation только для mttrly_execute_command и узко настроенная preauthorization — отдельные исключения; оба остаются в аудите.

Ограниченные права

Агент работает от отдельного service user и использует scoped wrappers для привилегированных операций. Точные права зависят от capabilities, включённых для сервера.

Зашифрованный транспорт и явная граница данных

Агент использует зашифрованный транспорт. Релевантные диагностические фрагменты и операционные записи могут обрабатываться или храниться для диагностики и аудита. Не помещай секреты в prompts и logs; актуальная граница данных описана в Privacy Policy.

Ротация токенов

Если токен мог утечь, ротируй его через authenticated account flow. Предыдущий credential инвалидируется в рамках ротации.

Решение проблем

Частые проблемы и их решения.

Агент не подключается

→Проверь, разрешены ли исходящие WebSocket-соединения (порт 443)
→Убедись, что API-токен правильный
→Проверь логи агента: journalctl -u mttrly

Команды зависают

→Возможно, сервер под высокой нагрузкой
→Проверь сетевое подключение
→Перезапусти агента: systemctl restart mttrly

Ошибки доступа

→Убедись, что пользователь mttrly имеет доступ к управляемому сервису
→Добавь sudo-права для нужных команд в /etc/sudoers.d/mttrly

MCP-сервер

Подключение mttrly к AI-ассистентам кодинга через Model Context Protocol. Endpoint: https://api.mttrly.com/mcp

Подключение

MCP-сервер mttrly использует HTTP-транспорт с аутентификацией OAuth 2.1. Добавь его в клиент:

Claude Codebash

claude mcp add mttrly --transport http https://api.mttrly.com/mcp

OAuth-авторизация откроется в браузере автоматически.

Cursorjson

{
  "mcpServers": {
    "mttrly": {
      "url": "https://api.mttrly.com/mcp"
    }
  }
}

Cursor → Settings → Cursor Settings → MCP → Add server.

Claude Desktopconnector

Settings -> Connectors -> Add custom connector -> https://api.mttrly.com/mcp

Используй Connectors UI в Claude Desktop или Claude.ai.

OpenAI Codextoml

[mcp_servers.mttrly]
url = "https://api.mttrly.com/mcp"

Добавь в ~/.codex/config.toml. Запусти codex mcp login mttrly для OAuth.

Аутентификация

Поддерживаются два режима аутентификации:

OAuth 2.1 (рекомендуется)

Стандартный OAuth flow с PKCE S256. JWT-токены подписаны RS256. Issuer: https://app.mttrly.com. Audience: https://api.mttrly.com/mcp. MCP-клиенты обрабатывают это автоматически — ты просто подтверждаешь вход в браузере.

API Key

Bearer-токен с префиксом mtr_. Передавай как Authorization: Bearer mtr_your_key. Доступен в дашборде.

Неавторизованные запросы возвращают 401 с заголовком WWW-Authenticate, указывающим на OAuth discovery endpoint.

Справочник инструментов

40 инструментов организованы по уровню доступа. Всегда вызывай mttrly_get_capabilities первым, чтобы проверить план и доступные инструменты.

Доступно на всех планах

mttrly_get_capabilities

Текущий план, доступные инструменты, ограниченные инструменты и лимиты плана. Вызывай первым.

mttrly_list_servers

Список всех подключённых серверов со статусом (online/offline).

mttrly_get_server_status

Детальный статус сервера: CPU, RAM, диск и количество активных алертов.

server_idstringrequired— ID сервера из mttrly_list_servers

mttrly_get_alerts

Алерты (инциденты) сервера с фильтрацией по severity/status. Retention ограничен планом.

server_idstringrequired— ID сервера

limitnumberoptional— Макс. алертов, 1–500. По умолчанию: 20

since_daysnumberoptional— Глубина поиска в днях, 1–30. По умолчанию: 7

statusstringoptional— Фильтр: active | resolved | all. По умолчанию: all

mttrly_quick_triage

Детерминированный Watchdog-safe first-pass triage. Использует простое сопоставление симптомов, а не AI-investigation.

server_idstringrequired— ID сервера

symptomstringoptional— Необязательная подсказка о симптоме, максимум 500 символов

mttrly_list_playbooks

Список доступных плейбуков с категориями и требованиями подтверждения.

server_idstringoptional— Опциональный фильтр по серверу

categorystringoptional— Фильтр: monitoring, logs, services, nginx_certs, docker, scheduling, config, security, fix, maintenance или all. По умолчанию: all

Требуется план Deployment Bro

mttrly_run_diagnostic

Запустить недеструктивное диагностическое расследование на сервере. Требуется Deployment Bro или выше; действует 30-секундный кулдаун на сервер.

server_idstringrequired— ID сервера

descriptionstringrequired— Описание проблемы, напр. "высокий CPU", "nginx не отвечает", "диск заполняется". Макс. 2000 символов.

mttrly_run_playbook

Выполнить плейбук на сервере. Read-only плейбуки выполняются сразу. Опасные возвращают pending_approval — вызови mttrly_approve_action после подтверждения пользователя.

server_idstringrequired— ID сервера

playbook_idstringrequired— ID плейбука из mttrly_list_playbooks

parametersobjectoptional— Key-value параметры, напр. {"service": "nginx"}. Проверь mttrly_list_playbooks для списка параметров

mttrly_execute_command

Запрос на ограниченное выполнение команды на сервере. Если есть подходящий playbook, предпочитай mttrly_run_playbook. Требует подтверждения или явного investigation bypass, а выполнение записывается в audit log.

server_idstringrequired— ID сервера

commandstringrequired— Команда, запрошенная для выполнения с подтверждением

reasonstringoptional— Опциональная причина выполнения (записывается в аудит-лог, если указана)

mttrly_get_pending_actions

Список действий, ожидающих подтверждения.

server_idstringoptional— Опциональный фильтр по серверу

mttrly_approve_action

Подтвердить или отклонить pending action. Вызывай только после явного подтверждения пользователя. Блокирует до завершения выполнения (до 60с).

action_idstringrequired— ID действия из mttrly_run_playbook, mttrly_execute_command или mttrly_get_pending_actions

decisionstringrequired— approve = выполнить, reject = отменить

mttrly_get_audit_log

Аудит-трейл сервера — подтверждения действий, выполнения команд, запуски плейбуков, авто-фиксы.

server_idstringrequired— ID сервера

limitnumberoptional— Макс. записей, 1–200. По умолчанию: 50

sincestringoptional— ISO 8601 timestamp — записи после этого времени

Workflow подтверждения

Approval-required действия обычно следуют двухэтапному паттерну:

1.Вызови mttrly_run_playbook или mttrly_execute_command для действия, требующего подтверждения → получи action_id и описание.

2.Покажи детали действия пользователю и спроси подтверждение.

3.Вызови mttrly_approve_action с action_id и решением (approve/reject).

4.Если одобрено, инструмент блокирует до завершения выполнения (до 60с) и возвращает результат.

Read-only плейбуки выполняются сразу без подтверждения. Явно авторизованный Investigation bypass применяется только к mttrly_execute_command и остаётся server-scoped, time-limited, action-limited и audited. Проверь requires_approval из mttrly_list_playbooks.

Коды ошибок

Все ошибки возвращают JSON-объект с code, message и suggested_action.

PLAN_REQUIRED

Инструмент требует более высокий план. Ответ содержит URL для апгрейда.

→ Сообщи пользователю об ограничении плана и покажи ссылку на апгрейд.

SERVER_OFFLINE

Агент на сервере не подключён.

→ Проверь, запущен ли агент на сервере.

SERVER_NOT_FOUND

Неверный server_id.

→ Вызови mttrly_list_servers чтобы увидеть доступные ID серверов.

DIAGNOSTIC_COOLDOWN

30-секундный кулдаун диагностики на сервере не истёк.

→ Подожди окончания кулдауна перед повторным запросом.

DOCKER_NOT_AVAILABLE

Запрошен Docker-плейбук, но Docker не установлен на сервере.

→ Пропусти Docker-плейбуки или установи Docker на сервер.

ACTION_EXPIRED

Pending action превысил TTL 30 минут и был автоматически отменён.

→ Повтори исходную команду или плейбук для создания нового pending action.

RATE_LIMITED

API-ключ превысил лимит 60 запросов в минуту. Возвращает HTTP 429.

→ Подожди сброса окна rate limit (1 минута) и повтори.

VALIDATION_ERROR

Тело запроса не прошло валидацию (напр. пропущено обязательное поле, description свыше 2000 символов).

→ Проверь параметры запроса по схеме инструмента.

TIMEOUT

Запрос превысил таймаут (по умолчанию 60с).

→ Повтори запрос.

Лимиты

•Глобальный: 60 запросов в минуту на API-ключ. Превышение возвращает HTTP 429 с кодом RATE_LIMITED. Окно сбрасывается через 1 минуту.

•mttrly_run_diagnostic: 30-секундный кулдаун на сервер. Возвращает DIAGNOSTIC_COOLDOWN при раннем вызове.

•mttrly_approve_action: блокирует до 60 секунд, ожидая завершения выполнения.

•Look-back запроса алертов ограничен тарифом (Watchdog: 7 дней; Deployment Bro и Crew: 30 дней). Это лимит запроса, а не обещание срока хранения.

Лимиты планов

Конкретные ограничения ресурсов по планам, контролируемые API:

Лимит	Watchdog (бесплатно)	Deployment Bro (3900₽/мес)	Deployment Crew (9900₽/мес)
Серверы	1	3	9
Строк логов за запрос	50	500	500
Look-back запроса алертов	7 дней	30 дней	30 дней
Scheduled checks	—	5	Без ограничений

Матрица доступа по планам

Инструмент	Watchdog (бесплатно)	Deployment Bro (3900₽/мес)	Deployment Crew (9900₽/мес)
mttrly_get_capabilities	✓	✓	✓
mttrly_list_servers	✓	✓	✓
mttrly_get_server_status	✓	✓	✓
mttrly_get_alerts	✓	✓	✓
mttrly_quick_triage	✓	✓	✓
mttrly_run_diagnostic	—	✓	✓
mttrly_list_playbooks	✓	✓	✓
mttrly_run_playbook	—	✓	✓
mttrly_execute_command	—	✓	✓
mttrly_get_pending_actions	—	✓	✓
mttrly_approve_action	—	✓	✓
mttrly_get_audit_log	—	✓	✓

* Deployment Crew имеет тот же набор MCP-инструментов, что и Deployment Bro, плюс: до 9 серверов сейчас; командный доступ и webhook-интеграции выкатываются поэтапно.

Готов проверить документацию на реальном сервере?

Создай аккаунт по email. Onboarding покажет token-specific команду для обязательного outbound-агента.

Создать аккаунт по email Сначала проверить публичный URL