prtg-mcp

MCP-сервер для PRTG Network Monitor (сетевой/инфраструктурный мониторинг Paessler). Предоставляет нативные HTTP API PRTG для датчиков, устройств и исторических данных датчиков в виде инструментов MCP.

Обзор

• HTTP-сервис без состояния. Учётные данные никогда не сохраняются — каждый запрос передаёт свои собственные учётные данные через заголовки, которые используются только в течение жизни этого одного запроса.

• Поддерживает конкурентные запросы; изоляция учётных данных на запрос выполняется через Python contextvars, а не через глобальный/общий экземпляр клиента.

• Точки входа: POST /mcp (протокол MCP) и GET /health (проверка работоспособности).

• Порт по умолчанию: 8080 (настраивается через MCP_HTTP_PORT).

Related MCP server: mcp-ntopng

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

В отличие от большинства интеграций в этой программе, PRTG не имеет отдельного входа или обмена токенами: имя пользователя и «passhash» (генерируется в интерфейсе PRTG в разделе My Account -> API Key, а не буквальный пароль учётной записи) отправляются как обычные параметры запроса при каждом вызове. Поэтому кэшировать нечего — каждый вызов уже полностью самодостаточен и не имеет состояния по замыслу самого вендора.

Параметры авторизации в заголовках

Отсутствие любого заголовка возвращает 401:

{
  "error": "Missing credentials",
  "message": "This server requires the X-PRTG-Server-Url, X-PRTG-Username, and X-PRTG-Passhash headers",
  "required_headers": ["X-PRTG-Server-Url", "X-PRTG-Username", "X-PRTG-Passhash"],
  "optional_headers": []
}

Неверные учётные данные проявляются как ошибка на уровне инструмента (см. Конверт ошибки ниже), классифицируемая по HTTP-коду состояния PRTG — 401/403 соответствует unauthorized. При любом ответе, отличном от 2xx, этот сервер пытается извлечь поле message/error из JSON-тела и возвращается к необработанному тексту ответа, если тело не является JSON (PRTG для некоторых некорректных запросов может вернуть XML-тело <error> даже на конечной точке .json).

Переменные окружения

Конечная точка MCP

• POST /mcp — протокол MCP (потоковый HTTP-транспорт)

• GET /health — проверка работоспособности, возвращает {"status": "ok"} (чисто локальная проверка, не вызывает PRTG)

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

Все 3 инструмента доступны только для чтения (readOnlyHint=True, idempotentHint=True); в этом сервисе нет инструментов записи/удаления.

Для count нет задокументированного жёсткого максимума на стороне вендора для конечной точки table.json PRTG, поэтому этот сервер применяет собственный предел платформы вместо бесконтрольной передачи значений: по умолчанию 50, значения выше 200 молча ограничиваются до 200, а не отправляются в PRTG как есть.

Формат ответа

Обе конечные точки, которые вызывает этот сервер (table.json, historicdata.json), являются вариантами вендора с JSON-суффиксом, поэтому при успехе клиент всегда разбирает только JSON. HTTP API PRTG в принципе может возвращать XML для других конечных точек/параметров, поэтому клиент разбирает защитно: ответ, отличный от 2xx, классифицируется в структурированный конверт ошибки ниже, а если ответ 2xx не удаётся разобрать как JSON, его необработанный текст возвращается под ключом raw_response вместо возникновения исключения.

Конверт ошибки

Ошибки инструментов возвращаются как структурированная JSON-строка вместо возникшего исключения, чтобы вызывающий агент мог ветвиться по code и решать, стоит ли повторить попытку:

{"error": {"code": "upstream_error", "message": "...", "retryable": true}}

code — одно из: not_configured, unauthorized, not_found, invalid_argument, rate_limited, upstream_error. Пустые наборы результатов возвращаются как обычная (не ошибочная) пустая коллекция, а не как not_found.

Возвращаемые значения инструментов (как успешные, так и ошибочные) — это компактный JSON (ensure_ascii=False, без indent) с ограничением в 20 000 символов — слишком большой результат усекает своё самое большое поле списка и сообщает truncated/original_count вместо возврата неограниченного блоба.

Примеры тестирования

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-PRTG-Server-Url: prtg.example.com" \
  -H "X-PRTG-Username: api_user" \
  -H "X-PRTG-Passhash: <your-passhash>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "prtg_get_sensors",
      "arguments": {}
    }
  }'

Проверено вживую (2026-07-30) на реальном основном сервере PRTG, все 3 инструмента вызваны сквозным образом через этот работающий сервер с реальными учётными данными: prtg_get_sensors и prtg_get_devices оба вернули 200 с реальной строкой prtg-version и допустимым (пустым) набором результатов — у этой конкретной тестовой учётной записи ноль датчиков/устройств, предоставленных в её видимой области, что подтверждено как подлинное состояние «нет данных» (не ошибка аутентификации) отдельным запросом content=probes, который вернул реальные данные (корневой probe PRTG плюс несколько реальных объектов планирования) с теми же самыми учётными данными. prtg_get_sensor_historic_data, вызванный с ID объекта, не являющегося датчиком (поскольку реального ID датчика не было), корректно достиг API и вернул собственную ошибку уровня контента вендора («The selected object cannot be used here»), что доказывает правильность конвейера запроса/аутентификации.

Справочник API

• Публичный, вход не требуется:

  • Формат таблицы датчиков/устройств: https://www.paessler.com/manuals/prtg/multiple_object_property_or_status#supported_output

  • Исторические данные: https://www.paessler.com/manuals/prtg/historic_data

Известные пробелы

• Область охвата — ровно 3 настроенные конечные точки MSPbots, а не полная поверхность API вендора — API PRTG также охватывает живое управление датчиками (пауза/возобновление/подтверждение), создание/удаление объектов, уведомления, отчёты и многое другое; это вне области охвата.

• Данные датчиков/устройств не удалось продемонстрировать на реальных записях — предоставленная тестовая учётная запись (Dash_Display, вероятно, учётная запись отображения только для панели мониторинга) имеет ноль датчиков и ноль устройств, предоставленных в её видимой области на этом конкретном экземпляре PRTG. Живое тестирование подтвердило, что это подлинно пустой результат (не ошибка аутентификации или реализации) путём успешного запроса другого, всегда заполненного типа объекта (content=probes) с теми же учётными данными и получения реальных данных.

• prtg_get_sensor_historic_data не удалось протестировать с реальным ID датчика по той же причине (нет датчиков для ссылки); вместо этого он был проверен подтверждением собственного ответа об ошибке уровня контента вендора для недопустимого ID объекта, что доказывает корректность формата запроса и аутентификации.