An MCP server for Jira Service Management Operations — the alert surface that replaced Opsgenie, which no other Jira MCP server covers.

Search alerts and read their notes and activity timeline; acknowledge, close, annotate them and add responders; and look up who is on call now and next. Twelve tools, four of them writes.

Demo

Three questions in one session, against a live JSM site: who is on call, what is open, and acknowledge what isn't. Watch the last answer in particular — the agent confirms the acknowledgement actually landed (ack landed 16:38:00.577Z) instead of assuming it did, which is the asynchronous-write behaviour described under What this server handles for you.

Quickstart

You need Node ≥ 24 and an Atlassian Cloud site with JSM Operations enabled. There is nothing to clone or build — your MCP client runs the published package.

1. Find your cloud id. Open this while logged in to your site:

https://<your-site>.atlassian.net/_edge/tenant_info

It answers with one line — {"cloudId":"..."} — and that UUID is what JSM_CLOUD_ID wants. If you'd rather not rely on that endpoint, the cloud id is also the segment after /s/ in the URL at admin.atlassian.com → Apps → Sites → your site.

2. Create an API token at id.atlassian.com.

3. Add the server.

Claude Code:

claude mcp add jira-alerts-mcp \
  --scope user \
  --env JSM_CLOUD_ID='your-cloud-id' \
  --env JSM_EMAIL='you@example.com' \
  --env JSM_API_TOKEN="${JSM_API_TOKEN}" \
  -- npx -y jira-alerts-mcp

--scope user registers the server for your whole account rather than only the directory you happened to run the command in. That is what you want for an alerts server — you want it in every session. Without the flag claude mcp add defaults to local scope, and the server exists in that one directory only.

Claude Desktop: open the config from the app rather than by hand — the Claude menu in your menu bar (not the settings inside the window) → Settings → Developer → Edit Config. That creates the file if it doesn't exist yet:

{
  "mcpServers": {
    "jira-alerts-mcp": {
      "command": "npx",
      "args": ["-y", "jira-alerts-mcp"],
      "env": {
        "JSM_CLOUD_ID": "your-cloud-id",
        "JSM_EMAIL": "you@example.com",
        "JSM_API_TOKEN": "your-api-token"
      }
    }
  }
}

mcpServers is a top-level key, and the file holds every server you have configured. If it already has an mcpServers block, add jira-alerts-mcp as another entry inside it — pasting the whole block above over the file replaces whatever was already there.

Then quit Claude Desktop completely and reopen it — the file is read only at startup, and closing the window is not quitting. The server then appears under the connectors panel in the message composer.

Most other MCP clients accept that same JSON shape. There is no scope choice to make here — claude_desktop_config.json is already per-user, the same reach as --scope user on the CLI.

4. Check it works. Ask your agent to list your open alerts. That runs jsm_list_alerts, which needs no ids and confirms your credentials and the read:ops-alert scope that nine of the fourteen tools share.

Then ask who is on call, which runs jsm_list_schedules. That is a separate check, because schedules need read:ops-config — if alerts work and schedules return 401, nothing is wrong with your token; see Required scopes below.

Things that catch people out: with claude mcp add the server name is the first positional argument, before any flags; -y on npx skips the install prompt, which an MCP client has no way to answer; and in zsh ${VAR} needs quoting. A server added without --scope user works in the directory you added it from and is simply missing everywhere else, with no error to explain the absence — if it seems to have disappeared, run claude mcp list from a different directory before touching anything else. For GUI-launched sessions the token has to live in the env block of the config itself — the shell environment isn't inherited, which is why the JSON above carries the credentials inline.

If the server never shows up in Claude Desktop, two causes account for almost all of it, and neither announces itself:

• npx wasn't on the PATH. A GUI app is launched by the window manager, not a shell, so a Node installed through nvm often isn't visible to it. Set "command" to the absolute path from which node and point "args" at the installed dist/index.js, or install Node system-wide. A Node older than 24 that is found fails as EBADENGINE rather than anything readable.
• The server exited during startup. Credentials are validated before the handshake, so a bad cloud id or token stops it dead — and because stdout is the protocol channel, that message goes to stderr only. Claude Desktop keeps it at ~/Library/Logs/Claude/mcp-server-jira-alerts-mcp.log (Windows: %APPDATA%\Claude\logs\), named after the key you used under mcpServers. Look for Startup failed: — it names exactly what is wrong.

git clone https://github.com/rrvrs/jira-alerts-mcp.git
cd jira-alerts-mcp
npm install
npm run build

  -- node /absolute/path/to/jira-alerts-mcp/dist/index.js

Configuration

Credentials are validated at startup, so a bad config fails immediately with an actionable message rather than on the first tool call.

.env.example lists these for reference. The server does not read .env itself — an MCP server is launched by its client, and the client owns the environment. Use the file as a checklist for your client's env block, or set -a; source .env; set +a for local development.

What your credentials can and cannot do

Both auth methods are not equivalent, and the difference is not documented by Atlassian. Verified against a live tenant on 2026-09-05:

The delete scopes are granted per token, not per authentication method. Two Atlassian account API tokens for the same account behave differently: one was refused on every DELETE with 401 Unauthorized; scope does not match — valid credentials, missing grant — and another completed the whole set. So a 401 on a delete is not a reason to abandon JSM_EMAIL + JSM_API_TOKEN. Reissue the token with the delete scopes included, or supply a 3LO or Forge OAuth token granted delete:ops-alert:jira-service-management as JSM_OAUTH_TOKEN. The 401 handler says exactly this, so the model reports it rather than retrying.

The delete-backed alert tools are jsm_delete_alert · jsm_delete_alert_note · jsm_remove_alert_tags · jsm_remove_alert_extra_properties · jsm_delete_alert_attachment.