logicmonitor-mcp

LogicMonitor MCP-Server – stellt die LogicMonitor REST API (v3, /santaba/rest) als MCP-Tools bereit.

Überblick

Dieser Server implementiert das Model Context Protocol (Streamable HTTP/SSE-Transport) und kapselt die LogicMonitor-Endpunkte, die von der eigenen LogicMonitor-Integration von MSPbots verwendet werden. Er folgt der Vendor-MCP-Service-SOP von MSPbots: zustandslos, keine gespeicherten Anmeldedaten, Authentifizierung pro Anfrage über Header.

Die zugrunde liegende API authentifiziert über LMv1 – eine pro Anfrage berechnete HMAC-SHA256-Signatur aus einem Access-Id-/Access-Key-Paar (das gleiche Schema, das MSPbots selbst für diese Integration verwendet: Company + Access Id + Access Key, kein OAuth). Dieser Server berechnet die LMv1-Signatur selbst für jede ausgehende Anfrage aus den in den Headern dieser Anfrage übermittelten Anmeldedaten; er speichert sie niemals.

Related MCP server: databricks-mcp

Schnellstart

Docker (empfohlen)

docker compose up --build

Der Server startet auf http://localhost:8080.

Lokal (uv)

uv sync
python -m logicmonitor_mcp

Health Check

curl http://localhost:8080/health
# {"status": "ok"}

Für den Health-Endpunkt sind keine Anmeldedaten erforderlich.

Authentifizierung

Jede Anfrage an /mcp muss die folgenden HTTP-Header enthalten:

Fehlt einer der drei Header, wird 401 Unauthorized zurückgegeben.

Umgebungsvariablen

logicmonitor-mcp hat keine erforderlichen Umgebungsvariablen – alle Identitätsdaten (Company/Access Id/Access Key) werden pro Anfrage über Header übermittelt.

MCP-Endpunkt

POST http://localhost:8080/mcp

Verbinden Sie Ihren MCP-Client mit:

• Transport: http (Streamable HTTP / SSE)

• Header: X-LogicMonitor-Company, X-LogicMonitor-Access-Id, X-LogicMonitor-Access-Key (alle erforderlich)

Tool-Liste

15 Tools – entsprechend den 15 LogicMonitor-API-Endpunkten, die bereits unter dieser Integration in MSPbots registriert sind (sys_integration subject_code LOGICMONITOR), sodass die Tool-Abdeckung mit dem bestehenden Umfang von MSPbots übereinstimmt. Alle Tools sind schreibgeschützt (readOnlyHint=True); es gibt keine Schreib-/Lösch-Tools in diesem Dienst.

Paginierung: size hat standardmäßig 50 und wird serverseitig auf ein hartes Maximum von 1000 begrenzt – LogicMonitors eigenes dokumentiertes/erzwungenes Maximum für diesen Parameter (Werte über 1000 werden von LogicMonitor selbst stillschweigend begrenzt; eine höhere Anfrage führt nie zu einem Fehler, sondern liefert höchstens 1000 Ergebnisse). Unabhängig davon ist jede einzelne Tool-Antwort auf 20.000 Zeichen begrenzt – wenn eine Ergebnisseite dies überschreiten würde, wird die Antwort mit den Feldern truncated/original_count abgeschnitten, anstatt vollständig zurückgegeben zu werden.

Geräte (3)

Geräte-DataSources (4)

Alarme (3)

Verwaltung (2)

Berichte (2)

SDT (1)

Fehlerbehandlung

Tool-Fehler werden als JSON-String zurückgegeben (keine Ausnahme auf Protokollebene), sodass ein Agent programmatisch darauf verzweigen kann:

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

code gehört zu einem festen Vokabular: not_configured, unauthorized, not_found, invalid_argument, rate_limited, upstream_error. retryable gibt an, ob derselbe Aufruf sicher wiederholt werden kann (true für rate_limited/upstream_error, sonst false).

Netzwerk-Robustheit

• Ausgehende Timeouts: Verbindung 5s / Lesen 30s / Schreiben 10s / Pool 5s.

• Begrenzte Wiederholungen (bis zu 3 Versuche) mit begrenztem exponentiellem Backoff bei 429/5xx, wobei Retry-After berücksichtigt wird, falls vorhanden.

• Jeder Wiederholungsversuch berechnet die LMv1-Signatur von Grund auf neu (sie enthält die aktuelle Epochenzeit), sodass eine wiederholte Anfrage niemals mit einer veralteten/abgelaufenen Signatur gesendet wird.

• Ein einzelner gemeinsamer httpx.AsyncClient-Verbindungspool wird für die Prozesslebensdauer wiederverwendet.

Testbeispiel

Geräte auflisten:

{
  "method": "tools/call",
  "params": { "name": "logicmonitor_get_devices", "arguments": { "size": 10 } }
}

Entsprechendes curl gegen den laufenden Server (Streamable-HTTP-MCP-Endpunkt):

curl -X POST http://localhost:8080/mcp \
  -H "Content-Type: application/json" \
  -H "X-LogicMonitor-Company: <company>" \
  -H "X-LogicMonitor-Access-Id: <access_id>" \
  -H "X-LogicMonitor-Access-Key: <access_key>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": { "name": "logicmonitor_get_devices", "arguments": { "size": 10 } }
  }'

Ein parametrisierter Aufruf:

{
  "method": "tools/call",
  "params": {
    "name": "logicmonitor_get_device_datasources",
    "arguments": { "device_id": "7186" }
  }
}

API-Referenz

• Offizielle Dokumentation: LogicMonitor REST API v3

• Authentifizierungsschema: LMv1 API Tokens

• Basis-URL-Muster: https://{company}.logicmonitor.com/santaba/rest

Bekannte Lücken / Noch nicht verifiziert

• Noch nicht gegen ein Live-LogicMonitor-Portal getestet – bisher nur Protokollebene-Verifizierung (Health Check, 401 bei fehlenden/teilweisen Headern, tools/list mit allen 15 Tools, unit-getestete Fehlercode-Zuordnung).

• Die Tool-Abdeckung entspricht absichtlich den 15 bestehenden registrierten LogicMonitor-API-Einträgen von MSPbots und nicht der vollständigen LogicMonitor-REST-API-Oberfläche (die zusätzlich Schreiboperationen, Dashboards, Websites, Collector und LogicModules abdeckt) – auf Anfrage erweiterbar, falls eine breitere Abdeckung benötigt wird.