Opsgenie MCP server: community tools for alerts and on-call
Opsgenie's alerting and on-call features are moving into Jira Service Management. Atlassian's MCP server already covers that destination; small community servers cover Opsgenie itself until April 2027.
Checked 3 October 2026 · from Atlassian's Opsgenie migration page and Rovo MCP server documentation, GitHub and npm registry data
One of 91 guides to monitoring and developer tools. Each covers what an AI coding agent can get out of the tool through MCP, the protocol that lets the agent query the tool directly.
Summary
Opsgenie, Atlassian's alerting and on-call product, shuts down on 5 April 2027. Atlassian says its alerting and on-call features are now in Jira Service Management (JSM).
Atlassian's Rovo MCP server already has four JSM Operations tools. They search alerts, read on-call schedules and teams, and acknowledge, close or escalate alerts.
For an Opsgenie site that has not migrated, the routes are community servers or Opsgenie's REST API. The most-starred community server, giantswarm/mcp-opsgenie, was archived in May 2026.
How Opsgenie works with MCP
Opsgenie routes alerts from monitoring tools to the right people, runs escalation policies and holds on-call schedules. Atlassian stopped selling it on 4 June 2025.
Atlassian is moving those capabilities into JSM Operations, the incident and on-call part of Jira Service Management. Customers have until 5 April 2027 to move their data.
After that date Atlassian says Opsgenie "will no longer be accessible" and unmoved data will be deleted. Any MCP setup against Opsgenie itself has that end date built in.
Routes from an agent to Opsgenie data
| Route | Publisher | What it covers | Status on 3 October 2026 |
|---|---|---|---|
| Rovo MCP server, JSM tools | Atlassian | JSM Operations alerts, schedules, teams; alert actions | Hosted; needs API-token auth enabled by an admin |
burakdirin/opsgenie-mcp-server | Community | Eight alert tools: list, create, acknowledge, close, notes, logs, details | 0 stars; last push 12 July 2026 |
opsgenie-oncall-mcp (npm) | Community | Read-only: who is on call, list schedules | 1.0.0 published 7 August 2026; no linked source repository |
opsgenie-mcp-extended (npm) | Community | Alerts, schedules, overrides, teams, escalations, incidents | 0.1.0 published 16 July 2026; linked repository returns 404 |
giantswarm/mcp-opsgenie | Community | Opsgenie alerts and schedules | Archived; 9 stars; last push 8 May 2026 |
daviddykeuk/opsgenie-mcp also exists, with 1 star and a last push on 3 September 2025.
Every vendor here gets the same four checks: official, maintained, distributed and usable. Opsgenie passes 1 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Unknown | Atlassian has not published an Opsgenie-specific MCP server as of 3 October 2026. Its Rovo MCP server has Jira Service Management Operations tools; Atlassian does not say whether they read a site still on Opsgenie. |
| Maintained | Unknown | The best-known community server, giantswarm/mcp-opsgenie, is archived. Smaller servers were last updated between July and August 2026, each by a single maintainer. |
| Distributed | Pass | Community packages are on npm: opsgenie-oncall-mcp 1.0.0 (7 August 2026), opsgenie-mcp-extended 0.1.0 (16 July 2026) and opsgenie-mcp-server 1.1.0 (17 July 2025). Atlassian's Rovo server is hosted at https://mcp.atlassian.com/v2/mcp. |
| Usable | Unknown | No server's behaviour against a live Opsgenie account is documented beyond its own README. |
| Part of the work | What Opsgenie has here | Can an agent reach it |
|---|---|---|
| Production observability | Alerts, on-call schedules, escalations | Partial. Community servers reach Opsgenie; Atlassian's server reaches JSM Operations |
For a team still on Opsgenie, a community server or the REST API is the working route until April 2027. For a team that has moved to JSM Operations, Atlassian's own server is the one to keep.
What can an AI agent do with Opsgenie?
Atlassian's server connects, but the JSM Operations tools do not appear
Atlassian's documentation says the JSM tools support only API-token authentication. An organization admin must enable that first.
A client that signed in with OAuth sees Jira and Confluence tools without the four JSM Operations ones.
Guard: Ask an Atlassian admin to enable API-token auth, then reconnect with a token carrying the ops-alert and ops-config scopes.
JSM Operations tools return nothing for an Opsgenie site
Atlassian documents the tools against Jira Service Management. It does not say whether alerts on a site that is still on Opsgenie appear through them.
Guard: Test getJsmOpsAlerts against a known open alert before relying on the tool during an incident.
The agent acknowledges or closes a live page
updateJsmOpsAlert can acknowledge, close or escalate an alert. Several community servers can also create alerts, which notifies whoever is on call.
Guard: Issue a read-only token, or leave the write tools off, unless paging people is the job.
How to configure Opsgenie MCP for agents
- 1
Decide where the data lives
A migrated site belongs with Atlassian's server. A site still on Opsgenie needs a community server or the REST API.
- 2
Choose read or write
getJsmOpsAlerts,getJsmOpsScheduleInfoandgetJsmOpsTeamInforead.updateJsmOpsAlertchanges alert state. - 3
Use a service account for shared agents
Atlassian accepts a service-account API key as a bearer token. The agent then does not depend on one person's token.
- 4
Check provenance on npm packages
Two of the community packages have no reachable source repository, so their code cannot be reviewed on GitHub.
Paste this into your agent’s instructions
When you answer from Opsgenie or JSM Operations: - Say which route the data came from: Atlassian's server, a community server or the REST API. - Give the alert ID or schedule name you read. If JSM tools return nothing, say the site may not have migrated from Opsgenie. Ask before acknowledging, closing, escalating or creating any alert.
Do you need the MCP server at all?
Opsgenie's REST API remains available until shutdown. GET https://api.opsgenie.com/v2/alerts lists alerts, and the Who is On Call API returns current responders. EU accounts use api.eu.opsgenie.com.
If you are leaving Atlassian instead, PagerDuty, incident.io and Rootly each publish their own MCP servers covering incidents and on-call.
For the alerts before they reach an on-call tool, Prometheus and Grafana expose firing alerts and alert rules through their servers.
Connect what you will be running after April 2027. Treat any direct Opsgenie connection as temporary.
Opsgenie integration setup
Atlassian's server is hosted, so nothing installs. The JSM Operations tools need API-token authentication enabled by an organization admin.
Claude Code, Atlassian's server
Atlassian documents the OAuth form below. For the JSM tools, add an Authorization header with a base64-encoded email:api_token pair instead.
claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp
Cursor, Atlassian's server with an API token
This is Atlassian's documented API-token configuration. Replace the placeholder with the base64 value of email:api_token.
{"mcpServers":{"atlassian-mcp":{
"url":"https://mcp.atlassian.com/v2/mcp",
"headers":{"Authorization":"Basic <base64-email-and-token>"}}}}Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Opsgenie REST API, for a site that has not migrated
Opsgenie's API takes an API key in a GenieKey authorization header. The alerts endpoint returns at most 20,000 alerts across pages.
curl 'https://api.opsgenie.com/v2/alerts?limit=20' \ -H 'Authorization: GenieKey <api-key>'
What the vendor documents
Atlassian's migration page states the timeline plainly: "Opsgenie's alerting and on-call features are now available in Jira Service Management. Move existing Opsgenie data and configurations before April 5, 2027."
Should you connect an agent to Opsgenie?
Only as a bridge. Connect Atlassian's server if you have moved to JSM Operations, or a community server until April 2027. Best for teams migrating from Opsgenie to Jira Service Management who need on-call answers in the meantime.
- Strongest fit
- Only as a bridge. Connect Atlassian's server if you have moved to JSM Operations, or a community server until April 2027.
- Main advantage
- Atlassian's hosted server already covers alert search, on-call lookups and alert actions for JSM Operations.
- Main weakness
- Opsgenie shuts down on 5 April 2027, and its community servers are small, single-maintainer projects.
- Operational risk
- Alert-writing tools can acknowledge, close or escalate a real page.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface.
See agent observabilityFrequently asked questions
Is there an Opsgenie MCP server?
Only community ones. Atlassian has not published an Opsgenie-specific server as of 3 October 2026, and giantswarm/mcp-opsgenie is archived.
Does Atlassian's MCP server cover Opsgenie?
It covers Opsgenie's successor, JSM Operations, with four tools for alerts, schedules and teams. Atlassian does not say whether they read a non-migrated Opsgenie site.
When does Opsgenie shut down?
On 5 April 2027. Atlassian says unmoved data will then be deleted.
Can an agent find out who is on call?
Yes. getJsmOpsScheduleInfo returns current and next responders in JSM Operations, and the opsgenie-oncall-mcp package does the same for Opsgenie.