Opsgenie MCP server: archived, and ending
Two independent reasons not to build here, and where Atlassian is pointing Opsgenie customers instead.
Last verified 1 September 2026 · from Atlassian's MCP server documentation, the archived community repository and the official registry
This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.
Summary
No maintained Opsgenie MCP server exists. giantswarm/mcp-opsgenie is archived, with 9 stars and a final push on 8 May 2026.
Atlassian's own MCP server does not fill the gap. It covers Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo, and carries no Opsgenie tools.
The bigger reason is the end-of-life date: Opsgenie is scheduled for end of life on 5 April 2027, so any new integration has a known expiry date.
What is the Opsgenie MCP server, and is it usable?
Opsgenie is Atlassian's alerting and on-call product: it routes alerts, runs escalation policies and manages who is paged.
Atlassian has been consolidating that capability into Jira Service Management, and Opsgenie has a published end-of-life date rather than a roadmap.
That changes the advice. For most vendors in this guide the question is which connector to use. For Opsgenie the question is what to migrate to.
Every one of the 90 vendors in this directory gets the same four checks. Opsgenie passes 0 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Fail | Atlassian's own MCP server covers Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo. It carries no Opsgenie tools. |
| Maintained | Fail | The best community server, giantswarm/mcp-opsgenie, is archived. It has 9 stars and was last pushed on 8 May 2026. |
| Distributed | Fail | No maintained package, and no Opsgenie entry in the official MCP registry. |
| Usable | Fail | Opsgenie itself is scheduled for end of life on 5 April 2027, so any integration built now has a fixed shelf life. |
Opsgenie works in production observability, and nothing maintained connects to it.
| Part of the work | What Opsgenie has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | None | No code product, and no server |
| CI & release | None | No pipeline product, and no server |
| Production observability | Alerting, on-call schedules, escalation policies | No. Alerting and on-call are the product's purpose, and the only server covering them is archived |
| Agent observability & evals | None | No traces or evaluations, and no server |
| AI cost management | None | No spend data, and no server |
Opsgenie's alerts and schedules are not reachable through anything maintained. The end-of-life date means that will not change. Plan around the destination product rather than this retired surface.
What can an AI agent do with Opsgenie?
Two things to watch, and the second outranks the first.
Atlassian publishes an MCP server, and Opsgenie is not in it.
Atlassian's MCP server documents coverage for Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo. Opsgenie does not appear among them.
The only Opsgenie-specific server, giantswarm/mcp-opsgenie, is archived with 9 stars and a final push on 8 May 2026.
Guard: Check the product list on an Atlassian connector before assuming Opsgenie is included.
Opsgenie reaches end of life on 5 April 2027.
Any integration built against Opsgenie now has a fixed shelf life, regardless of whether a maintained server appears in the meantime.
Guard: Spend the effort on the platform you are migrating to, and treat Opsgenie access as temporary.
Do you need the MCP server at all?
No, and no maintained one exists to need. If you are staying with Atlassian, Jira Service Management is where the capability is consolidating, and it is covered by Atlassian's own MCP server alongside Jira and Confluence.
If you are moving off, several alerting and incident platforms publish maintained servers. PagerDuty exposes 101 tools with a read-only default, covering on-call, escalation and incidents. No PagerDuty tool name is listed here. incident.io documents 32 tools including escalation_respond for acknowledging a page and escalation_path_show for who would be paged at each level.
Rootly registers 252 tools covering shift metrics, handoff summaries and responder availability. FireHydrant offers five tools with a read-only scope. Neither set is named tool by tool on this page.
For the alerts themselves, before they reach an on-call tool, Prometheus exposes firing alerts and alerting rules, and Grafana, Datadog and Dynatrace all reach their own alerting surfaces.
Do not build against Opsgenie. Connect the platform you are migrating to, and use its server instead.
Opsgenie MCP server setup
Nothing here installs an Opsgenie server, because there is none and the only community one is archived. This is a migration route, and the date on it matters.
Opsgenie is scheduled for end of life on 5 April 2027. Anything built against it now has a fixed shelf life, which changes the calculation from integrate to replace.
Connect the platform you are moving to, and use its server. Two in this directory publish one.
incident.io, hosted, in Claude Code
incident.io runs a hosted server documenting 32 tools across incidents, alerts, escalations, schedules, the catalog and follow-ups, which covers the Opsgenie surface closely.
No credentials go into the configuration. The endpoint authorizes in the browser on first use.
claude mcp add --transport http incidentio \ https://mcp.incident.io/mcp
PagerDuty, read-only
PagerDuty publishes a first-party server, and a user API key scoped to reads keeps an agent querying rather than paging anyone.
The key is PagerDuty's own, and what it can see in PagerDuty is what the agent will see.
claude mcp add-json "pagerduty" '{"command":"uvx",
"args":["pagerduty-mcp"],
"env":{"PAGERDUTY_USER_API_KEY":"<your-key>"}}'Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Atlassian's own server does not cover it
Connecting Atlassian's MCP server does not help here. It covers Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo, and carries no Opsgenie tools.
That is worth checking before assuming the parent company closed the gap. Reading the coverage list needs no credentials.
Atlassian MCP: Jira · Confluence · JSM · Bitbucket · Compass · Rovo Opsgenie tools: none
The community server cannot be fixed
giantswarm/mcp-opsgenie was archived on 8 May 2026 and accepts no further changes. It has 9 stars and is Apache-2.0, so a fork is legally straightforward and operationally yours.
Checking the archive flag needs no credentials; it is public repository metadata.
gh api repos/giantswarm/mcp-opsgenie --jq .archived # true
Read-only access, permissions and security
No Opsgenie credential is worth creating
With end of life set for 5 April 2027, a new integration credential against Opsgenie has a known expiry.
Paging is a write action
A connector that can create or escalate an alert can wake someone up. Scope the key to reads, unless paging someone is the point.
A fork inherits its own risk
Forking an archived server means you own its dependencies and its security updates, with no upstream to receive a fix.
incident.io's hosted route stores no token
Browser authorization keeps a long-lived credential out of the configuration file.
On-call data is personal data
Schedules and escalation policies name individuals and their availability, and that reaches the model with the rest.
Troubleshooting
- Atlassian's MCP server is connected but exposes no Opsgenie tools
- That is expected. Atlassian's own server covers Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo. It carries no Opsgenie tools at all.
- You want to fix or extend `giantswarm/mcp-opsgenie`
- You cannot upstream it. The repository was archived on 8 May 2026 and accepts no further changes. A fork is the only route, and you would own it.
- The MCP registry returns nothing for Opsgenie
- There is nothing to return. A registry search on 24 August 2026 found no Opsgenie entry, and no maintained package exists either.
- You are deciding whether to build a connector yourself
- Weigh it against the end-of-life date. Opsgenie is scheduled for end of life on 5 April 2027, so anything built now has a fixed shelf life.
- Migrating the alerting first, then connecting whatever replaces Opsgenie, avoids paying twice.
Opsgenie MCP server: Reference
| Item | Value |
|---|---|
| Official server | None |
| Atlassian MCP server coverage | Jira · Confluence · Jira Service Management · Bitbucket · Compass · Rovo |
| Opsgenie tools in it | None |
| Best community server | giantswarm/mcp-opsgenie, archived |
| Its stars | 9 |
| Created | 10 June 2025 |
| First release | v0.0.1, 27 June 2025 |
| Final push | 8 May 2026, when it was archived |
| Its license | Apache-2.0 |
| Maintained package | None |
| Official MCP registry results | None |
| Opsgenie end of life | 5 April 2027 |
| Inventory source | GitHub API and Atlassian's product coverage, read 24 August 2026 |
What engineers report
Two dates carry this section: when the community server stopped, and when the product stops.
| What was checked | What it shows |
|---|---|
| Community server | giantswarm/mcp-opsgenie, archived |
| Its stars | 9 |
| Its final push | 8 May 2026 |
| Its license | Apache-2.0 |
| Opsgenie tools in Atlassian's own MCP server | None |
| Opsgenie end of life | 5 April 2027 |
| Official MCP registry results | None |
Repository facts for giantswarm/mcp-opsgenie come from the GitHub API on 24 August 2026, which reports it archived. Atlassian's MCP server documentation was checked on the same date and lists Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo without Opsgenie. The official MCP registry has no Opsgenie entry.
Should you connect an agent to Opsgenie?
No. A server exists and is not usable. Best for migrating, and connecting the destination platform's server instead.
- Strongest fit
- Nobody. The product has an end-of-life date and no maintained connector.
- Main advantage
- None to report: the only Opsgenie server is archived.
- Main weakness
- Two independent blockers, an archived server and a 2027 end of life.
- Operational risk
- Building an integration with a known expiry date.
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, from $10 per million spans.
See agent observabilityFrequently asked questions
Is there an Opsgenie MCP server?
Not a maintained one. giantswarm/mcp-opsgenie is archived, with 9 stars and a final push on 8 May 2026.
Does Atlassian's MCP server cover Opsgenie?
No. It documents Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo, and carries no Opsgenie tools.
Should I build an integration anyway?
Opsgenie is scheduled for end of life on 5 April 2027, so anything built now has a fixed shelf life.
What should I move to?
Jira Service Management if you are staying with Atlassian, or PagerDuty, incident.io, Rootly or FireHydrant, all of which publish maintained servers.