AlertOps MCP server

AlertOps MCP Server

MCP server for AlertOps's incident alerting/on-call API - alerts, message topics, users and their contact methods, groups, configured inbound integrations, and on-call schedules, for AI assistants and the WYRE Conduit gateway.

Authentication

AlertOps' REST API (https://api.alertops.com/api/..., per its published OpenAPI spec at api.alertops.com/swagger/v1/swagger.json) authenticates with a static account-level API key, generated under Account Settings -> Configurations -> Integrations -> API. Unlike most WYRE Conduit sidecars, the key is not sent as a bearer token or custom auth header - AlertOps requires it as an APIKey query-string parameter on every single request, GET and POST alike (live-verified 2026-09-20: an invalid key returns a clean {"reason":"Invalid API Key"} HTTP 401 on every endpoint this connector calls). This connector receives the key per-request via a custom header (never OAuth, same shape as every other static-key WYRE Conduit sidecar) and itself appends ?APIKey= when calling AlertOps' API. In gateway mode the key arrives per-request via the X-AlertOps-Api-Key header; in local/stdio mode it's read once from ALERTOPSAPIKEY.

Two separate claims here, at deliberately different confidence levels - don't collapse them into one "read-only" statement:

• Structurally verified (checked directly, stated with full confidence): this connector's own code makes zero calls to a write/mutating AlertOps endpoint. Every function in client.ts calls one of the 11 documented GET operations listed under Tools below; no POST call exists anywhere in src/.
• Vendor-documented, not independently verified (hedged deliberately): AlertOps ships role-based access control with built-in and custom roles built from individually-grantable read-only entitlements (e.g. MessagesViewGlobalAccess, UserViewGlobalAccess, GroupsViewGlobalAccess) - AlertOps' own docs describe a custom role built this way as letting a user "browse incidents, reports, users, and groups but cannot create, modify, or delete anything" (help.alertops.com, Role Based Access Control). A distinct User API Key, shown on a user's own Profile page, is described elsewhere in AlertOps' docs as gated by the UserAPIKeyAdd entitlement, implying an API key issued this way inherits the issuing user's role/entitlements. Whether that's actually enforced server-side against this connector's APIKey query parameter and its write endpoints specifically - i.e. whether AlertOps' backend rejects a write call (Create Alert, Close Alert, Assign, etc.) made with a key belonging to a read-only-scoped user, versus that restriction only ever being surfaced in AlertOps' own UI - has not been tested by WYRE. Nobody sent a write call against a live key to check, correctly: that would risk creating a real page/notification against real on-call staff, not something to run without consent. Do not read this connector, or this README, as having established that a read-only-provisioned AlertOps API key technically cannot perform writes** - only that this connector's own code never attempts one, and that AlertOps' documented role system supports provisioning a key that way.

Configuration

Tools

Shortened. The full README is on GitHub.