Skip to main content
sureops connects to external tools exclusively through the Model Context Protocol (MCP). Agents never call vendor HTTP APIs directly. This architecture gives you fine-grained control over what sureops can access, keeps credentials scoped to purpose, and lets you run sureops against tools that aren’t publicly reachable.

​
Why MCP

MCP is an open protocol for exposing tool capabilities to AI agents in a structured, permission-scoped way. Each MCP server acts as a proxy between sureops and a vendor tool, exposing only the operations the vendor or you choose to expose. For sureops, this means:
  • Vendor-controlled surface: what sureops can do with a tool is defined by that tool’s MCP server, not by sureops. Vendors publish their own MCP servers and manage their own capability sets.
  • No credential sprawl: your API keys stay on the MCP server side, not in sureops. sureops holds only the MCP endpoint URL and a connection token.
  • Network-transparent: your internal tools (Prometheus, Loki, Kubernetes API) don’t need to be internet-reachable. You run the MCP server inside your network and give sureops the endpoint.
  • Auditable: every tool call the AI makes goes through the MCP server, which can log and rate-limit it independently of sureops.

​
Two hosting modes

Every integration supports two hosting modes. You choose based on your network topology and preference:

Vendor-hosted MCP

The vendor runs the MCP server. sureops connects directly to the vendor’s public endpoint using your credentials. Setup is fastest — paste your API key, sureops connects immediately.Available for: Slack (via Slack’s MCP endpoint), GitHub (via GitHub App install).

Customer-hosted MCP

You run the MCP server inside your own network (or on infrastructure you control). sureops connects to your endpoint using a connection token you generate. Required for tools that aren’t internet-reachable (Prometheus, Loki, Kubernetes API, self-hosted Grafana).
When you use customer-hosted mode, sureops never touches your vendor credentials directly — the MCP server you run handles authentication to the underlying tool.

​
What agents do with integrations

During an incident, agents query integrations on-demand. The diagnosis specialist might:
  1. Pull PromQL metrics from Prometheus MCP to check error rate trends
  2. Search Loki MCP for relevant log lines around the incident window
  3. Query Tempo MCP for distributed traces to identify where a latency spike originates
  4. List failing pods and recent events from Kubernetes MCP
  5. Check recent deployments and open PRs from GitHub MCP
Raw telemetry data (logs, traces, raw metric series) is read, analyzed, and then discarded. sureops stores derived structure — root cause findings, recommendations, timeline entries — not raw observability data from your cluster.

​
Available integrations

​
Live in private beta

​
Coming soon

The following integrations are visible in Settings → Integrations but are not yet available for connection during private beta. They will be enabled in general availability.
  • Datadog — APM, logs, metrics, and monitors
  • PagerDuty — on-call schedules and incident escalation
  • Jira — issue tracking and change management
  • Microsoft Teams — team notifications and incident channels
  • AWS CloudWatch — AWS logs, metrics, and alarms

​
Grafana vs. Prometheus, Loki, Tempo

If you run the Grafana observability stack, you have a choice:
  • Connect Grafana — covers dashboards, Prometheus datasource queries, and unified alerts through a single MCP server. This is the recommended approach for most teams.
  • Connect Prometheus / Loki separately — useful if your Prometheus or Loki isn’t reachable through Grafana, or if you run them standalone without Grafana.
  • Always connect Tempo separately — the Grafana MCP server does not expose Tempo’s full TraceQL surface (trace search, traceql-metrics). Connect Tempo directly even if Grafana is already configured.
Next: GitHub integration