MCP-сервер: у планах

Як стоять справи

Зараз у Tenium немає сервера Model Context Protocol. Нічого встановлювати, немає адреси, до якої можна підключити асистента, і немає списку бета-тестувальників із датою запуску. Ми пишемо цю сторінку, бо про це запитують, а розмите «ШІ-інтеграція скоро» гірше за прямий опис того, що вже є і що поки лише задум.

Існує REST API. Усе, що описано нижче, можна зробити з ним уже сьогодні: скриптом або асистентом, який вміє виконувати HTTP-запити.

Що MCP-сервер дав би змогу робити асистенту

Перша версія, яку ми б створили, свідомо невелика і здебільшого працює лише на читання. Ідея в тому, щоб людина могла поставити асистенту запитання своїми словами й отримати відповідь на основі живих даних, не відкриваючи панель керування.

• Читати стан моніторів. «Які монітори клієнта А зараз не працюють?» або «Який був час відповіді сторінки оформлення замовлення в магазині цього тижня?» Це зводиться до перегляду списку моніторів і історії перевірок.
• Читати інциденти. «Коротко опиши вчорашній інцидент: коли почався, які регіони його підтвердили, скільки тривав». Це читання інциденту разом із підтвердженнями.
• Вносити невеликі зворотні зміни. «Створи вікно обслуговування на суботу з 02:00 до 03:00 для тестових моніторів». Із записом ми були б найобережнішими, тому він потребував би ключа з правом запису й явного підтвердження від людини, яка користується асистентом.
• Додавати контекст. «Додай до інциденту нотатку, що хостинг перезапустив PHP-FPM». Нотатки вже є в API і з’являються в хронології та у щомісячних звітах.

Важливе застереження: вікна обслуговування сьогодні не можна створити через REST API, їх налаштовують у застосунку. Для відповідного інструмента MCP спершу знадобився б такий ендпоінт, тож це залежність, а не обіцянка.

Принципи, яких ми дотримувалися б

• Жодних нових прав доступу. Сервер використовував би ті самі ключі API й ті самі рівні доступу, що й усе решта. Ключ для читання ніколи не зміг би нічого змінити, а відкликання ключа одразу припиняло б доступ асистента.
• Ізоляція клієнтів зберігається. Ключ, прив’язаний до одного простору клієнта, відкривав би лише монітори цього простору.
• Невелика кількість інструментів. Кілька зрозуміло названих інструментів, а не копія кожного ендпоінта. Асистенти краще вибирають інструмент, коли їх небагато.
• Журнал дій. Зміни, зроблені через сервер, потрапляли б у той самий журнал аудиту, що й зміни в застосунку.

Що можна робити вже сьогодні

Якщо ви хочете, щоб асистент допомагав із моніторингом просто зараз, практичний шлях — REST API. Створіть ключ лише для читання в розділі Налаштування → Ключі API, дайте асистенту можливість запускати curl або невеликий скрипт і нехай він викликає GET /monitors, GET /incidents та GET /monitors/{id}/checks. Залишайте ключ лише для читання, якщо немає особливої причини інакше. Ключі із правом запису доступні на тарифах Pro і Agency, а всі приклади є в документації з API та на сторінці для розробників.

Для автоматизації за сповіщеннями є другий шлях: підписані webhook. Контакт типу webhook доставляє події інцидентів на адресу, яку ви контролюєте, де невеликий сервіс передасть їх тому інструментарію, яким ви користуєтеся. Див. формат даних webhook.

Розкажіть, навіщо він вам потрібен

Якщо MCP-сервер був би вам корисним, напишіть нам: вкажіть, яким асистентом ви користуєтеся і яке завдання хотіли б йому доручити. Конкретні запити визначають, що ми створимо першим, і ми краще зробимо три інструменти, якими справді користуються, ніж двадцять, які нікому не потрібні. Цю сторінку навмисно не індексують пошукові системи, бо вона описує те, чого ще не існує.