Smithery lists the Opsphere connector for operational investigations
Smithery lists Opsphere as opsphere/opsphere. The listing, published on 15 October 2026, describes DevOps, SRE, and QA intelligence for Cursor: investigate bugs, assess release readiness, search logs, triage outages, diagnose failed CI, check deployments, and query connected cloud platforms. Connected systems remain the source of that evidence.
A Smithery session adds the connector with npx -y smithery mcp add opsphere/opsphere. Smithery also offers a direct connection to the Opsphere gateway. Opsphere is read-only by default and does not copy that telemetry into another store.
What changes
Opsphere is available from Smithery as a connector to the same remote gateway. Smithery is a client path. It does not replace the systems that hold logs, deployments, or cloud state.
How it works
Smithery published the listing on 15 October 2026 under opsphere/opsphere. The user adds it with npx -y smithery mcp add opsphere/opsphere, or uses the direct connection Smithery shows. Opsphere then queries the systems that the tenant has connected. Those systems supply the evidence.
Why it matters
A team working in Smithery can use the connector for release readiness, failed CI, outages, and connected cloud platforms on the remote gateway. Systems that are already connected remain the source of that evidence.
Limits and requirements
Opsphere is read-only by default. Source systems remain authoritative for the underlying operational data. A user-initiated action is separate from that default.
- The listing is opsphere/opsphere, published on Smithery on 15 October 2026.
- Adding the connector uses npx -y smithery mcp add opsphere/opsphere.
- Smithery does not become the source of logs, deployments, or cloud state.