AlertOps MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_MODE | No | env (default, reads ALERTOPS_API_KEY) or gateway (credential arrives per-request via X-AlertOps-Api-Key header). | env |
| LOG_LEVEL | No | debug | info (default) | warn | error. | info |
| MCP_TRANSPORT | No | stdio (default) or http. | stdio |
| ALERTOPS_API_KEY | No | API key issued under Account Settings -> Configurations -> Integrations -> API. Required when AUTH_MODE=env (default). | |
| CONDUIT_S2S_SECRET | No | When set, the HTTP transport requires a valid X-Gateway-S2S header on every /mcp request. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| alertops_list_alertsA | List alerts, newest first by default. Filter by status (open/closed/assigned/all), a date range (created or closed), a specific AlertID, or by group/integration/escalation-rule IDs. Paginated (Limit, max 100 per page; Offset). AlertIDs from this response are usable directly; message-level lookups (by inbound integration's messageID or uniqueInboundID) are separate tools. |
| alertops_get_alert_id_by_inbound_message_idA | Resolve the AlertID that a given inbound integration messageID was mapped or appended to. The messageID is the value an inbound integration call returns, not the AlertID itself. |
| alertops_get_alert_id_by_unique_inbound_idB | Resolve the AlertID that a given inbound integration's uniqueInboundID was mapped or appended to. The uniqueInboundID is the value an inbound integration call returns, not the AlertID itself. |
| alertops_list_usersA | List all users in the AlertOps account (username, full name, user type). Usernames from this response are required by alertops_get_user_contact_methods and alertops_get_user_schedule. |
| alertops_get_user_contact_methodsA | List a user's configured contact methods (email, phone/SMS, etc), including whether each is enabled. Contains contact PII. Requires a username from alertops_list_users. |
| alertops_list_groupsA | List all groups in the AlertOps account (group ID -> group name). Group IDs from this response are usable by alertops_list_alerts, alertops_get_oncall_now, and alertops_get_group_schedule. |
| alertops_list_topicsA | List all message topics configured in the AlertOps account, used to route inbound alerts to the right escalation/priority handling. |
| alertops_list_integrationsA | List configured inbound integrations in the AlertOps account (integration rule ID -> integration type, e.g. AWS, Azure Alert, AppDynamics). Integration Rule IDs from this response are usable by alertops_list_alerts. |
| alertops_get_oncall_nowA | List who is on-call right now, for every group or (optionally) a single group. Returns each group and its current on-call member(s). |
| alertops_get_user_scheduleA | List a specific user's on-call schedule for a date range (max duration 3 months). Requires a username from alertops_list_users. |
| alertops_get_group_scheduleA | List a group's on-call schedule for a date range (max duration 3 months). Requires a Group ID from alertops_list_groups. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Every tool targets a distinct resource/action: alerts, inbound-ID lookups, users, contact methods, groups, topics, integrations, on-call, and schedules. The two inbound-ID resolution tools are similar but clearly separated by identifier type (messageID vs uniqueInboundID) and well-described.
All tools follow the same alertops_ prefix with a consistent list/get verb pattern (e.g., alertops_list_alerts, alertops_get_user_schedule). The naming is uniform and predictable across the entire set.
11 tools is well-scoped for an AlertOps read/query-focused server. Each tool covers a meaningful data surface without redundancy, and the count stays in the ideal range.
The read/query surface is solid: alerts, users, groups, topics, integrations, and schedules are all represented. However, there are no alert lifecycle actions (acknowledge, resolve, assign) or any mutating operations, which is a notable gap for operational incident management workflows.