Glama führt den Opsphere-Connector für operative Untersuchungen
Glama führt Opsphere — DevOps & SRE Intelligence unter io.opsphere.mcp-cursor. Eine Glama-Sitzung kann das entfernte Opsphere-Gateway über Streamable HTTP und OAuth2 erreichen, um Bugs zu untersuchen, die Release-Bereitschaft zu prüfen, Logs zu durchsuchen, Ausfälle zu triagieren, fehlgeschlagene CI zu diagnostizieren, Deployments zu prüfen und verbundene Cloud-Plattformen abzufragen. Glama markiert die Inhaberschaft als geprüft und meldet, dass OAuth in Glama funktioniert.
Der Eintrag enthält Nur-Lese-QA-Subagents. Opsphere ist standardmäßig nur lesend. Verbundene Systeme bleiben die Quelle der Nachweise. Opsphere kopiert diese Telemetrie nicht in einen anderen Speicher.
Was sich ändert
Opsphere ist über Glama als Connector zum selben entfernten Gateway verfügbar. Glama ist ein Client-Weg. Es ersetzt nicht die Systeme, die Logs, Deployments oder den Cloud-Zustand halten.
Wie es funktioniert
Der Connector nutzt Streamable HTTP, und der Eintrag nennt MCP mit dem Datum 2025-11-25. Der Benutzer authentifiziert sich mit OAuth2. Opsphere fragt dann die Systeme ab, die dieser Tenant verbunden hat. Diese Systeme liefern die Nachweise.
Warum es wichtig ist
Ein Team, das in Glama arbeitet, kann den Connector für Release-Bereitschaft, fehlgeschlagene CI, Ausfälle und verbundene Cloud-Plattformen auf dem entfernten Gateway nutzen. Bereits verbundene Systeme bleiben die Quelle dieser Nachweise.
Grenzen und Voraussetzungen
Opsphere ist standardmäßig nur lesend. Quellsysteme bleiben für die zugrunde liegenden operativen Daten maßgeblich. Eine vom Benutzer ausgelöste Aktion ist von diesem Standard getrennt.
- OAuth ist erforderlich. Der Glama-Eintrag meldet, dass OAuth in Glama funktioniert.
- Die QA-Subagents im Eintrag sind nur lesend.
- Glama wird nicht zur Quelle von Logs, Deployments oder Cloud-Zustand.