Skip to main content
sureops connects to most external tools through the Model Context Protocol (MCP) — for those integrations, agents never call the vendor’s HTTP API directly.
Slack is a deliberate exception. sureops calls Slack’s Web API directly with a bot token issued during app install, because Slack’s vendor-hosted MCP endpoint requires user-token auth that would undermine per-action audit attribution. The Slack connect screen still shows an MCP-hosting selector, like several other integrations — but MCP isn’t the recommended or supported path for Slack. See Slack for details.
For the MCP-based integrations, 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. For most integrations that MCP server is a customer-run, open-source implementation you control; for GitHub, sureops runs the MCP server itself. Either way, sureops’ access is bounded by what that server exposes.
  • 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.

​
How integrations are hosted

There isn’t one hosting toggle that applies to every integration — each one’s connection model is fixed by the vendor’s MCP support and sureops’ own hosting decision:

Vendor API — no MCP

Used only for Slack. sureops calls Slack’s Web API directly with the bot token issued during app install. No MCP server is in the path.

sureops-hosted MCP

Used only for GitHub. Rather than routing through GitHub’s own vendor-hosted MCP (which gates several tools behind a Copilot subscription most customers don’t have), the intent is for sureops to run a shared, multi-tenant MCP pod and authenticate each call with your GitHub App installation token, so there’s nothing for you to stand up. See the Warning on the GitHub integration page for the current state of the connect-screen flow.

Customer-hosted MCP

Used for Grafana, Prometheus, Loki, Tempo, Kubernetes, and ArgoCD. You run the MCP server inside your own network (or, in the sureops demo environment, it’s already provisioned in-cluster for you), and sureops connects to your endpoint using a connection token you generate. This is required for tools that aren’t internet-reachable.
For customer-hosted integrations, 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
Agents read raw telemetry (logs, traces, raw metric series) on-demand to reason through an incident, and write derived structure — root cause findings, recommendations, timeline entries — into the incident record.

​
Available integrations

​
Available now

ArgoCD requires a Growth or Enterprise plan — see Pricing & tiers for the full comparison.

​
Coming next

The following integrations are visible in Settings → Integrations, but aren’t connectable yet on any plan — they’re roadmap items, not a plan gate on an otherwise-working integration. The pricing page lists each one as a “Coming within Growth” or “Coming within Enterprise” chip, and its Settings connector card offers a Track on roadmap button rather than a Connect button:
  • Datadog (Coming within Growth) — APM, logs, metrics, and monitors
  • PagerDuty (Coming within Growth) — on-call schedules and incident escalation
  • Jira (Coming within Growth) — issue tracking and change management
  • Microsoft Teams (Coming within Enterprise) — team notifications and incident channels
  • AWS CloudWatch (Coming within Enterprise) — AWS logs, metrics, and alarms
Statuspage (Coming within Enterprise, public status page updates) is a roadmap item too, but unlike the integrations above it has no connector card in Settings → Integrations at all — track it on the app’s /roadmap page instead. See Pricing & tiers for the full plan comparison.

​
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