NewAgent Observability is live.
Back to directory
Opsgenie logo

Opsgenie MCP server: archived, and ending

Two independent reasons not to build here, and where Atlassian is pointing Opsgenie customers instead.

Connector
Community only, and archived
Coverage
Nothing maintained
Tools
0 maintained
Working route
Migrate to a platform with a live server

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.

CheckResultEvidence
OfficialFailAtlassian's own MCP server covers Jira, Confluence, Jira Service Management, Bitbucket, Compass and Rovo. It carries no Opsgenie tools.
MaintainedFailThe best community server, giantswarm/mcp-opsgenie, is archived. It has 9 stars and was last pushed on 8 May 2026.
DistributedFailNo maintained package, and no Opsgenie entry in the official MCP registry.
UsableFailOpsgenie 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 workWhat Opsgenie has hereCan an agent reach it
Code, tests & reviewNoneNo code product, and no server
CI & releaseNoneNo pipeline product, and no server
Production observabilityAlerting, on-call schedules, escalation policiesNo. Alerting and on-call are the product's purpose, and the only server covering them is archived
Agent observability & evalsNoneNo traces or evaluations, and no server
AI cost managementNoneNo 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.

Terminal
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.

Terminal
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.

Terminal
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.

Terminal
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

ItemValue
Official serverNone
Atlassian MCP server coverageJira · Confluence · Jira Service Management · Bitbucket · Compass · Rovo
Opsgenie tools in itNone
Best community servergiantswarm/mcp-opsgenie, archived
Its stars9
Created10 June 2025
First releasev0.0.1, 27 June 2025
Final push8 May 2026, when it was archived
Its licenseApache-2.0
Maintained packageNone
Official MCP registry resultsNone
Opsgenie end of life5 April 2027
Inventory sourceGitHub 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 checkedWhat it shows
Community servergiantswarm/mcp-opsgenie, archived
Its stars9
Its final push8 May 2026
Its licenseApache-2.0
Opsgenie tools in Atlassian's own MCP serverNone
Opsgenie end of life5 April 2027
Official MCP registry resultsNone

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 observability

Frequently 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.

Changelog

  • 8 May 2026. Repository archived. It accepts no further changes.
  • 27 June 2025. First release, v0.0.1.
  • 10 June 2025. giantswarm/mcp-opsgenie created on GitHub.

Sources

Every number on this page traces to one of these

  1. Repository facts from the GitHub API · giantswarm/mcp-opsgenie, retrieved 24 August 2026
  2. Atlassian MCP server product coverage, checked 24 August 2026
  3. Official MCP registry search for Opsgenie

Opsgenie’s own MCP documentation

For alerting and on-call with a live server:

For the alerts before they page anyone: