CloudThinker MCP server for Jira Service Management Operations: reads JSM_* env at startup, auto-connects to the JSM ops REST API, and serves alert, on-call, and idempotent alert-lifecycle tools over stdio.
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"ct-jsm-ops-mcp-server","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# ct-jsm-ops-mcp-server CloudThinker MCP server for **Jira Service Management Operations** — alerts, on-call schedules, and an idempotent alert lifecycle, served over stdio. Reads `JSM_*` env at startup, resolves the site's `cloudId`, proves the credential can actually read Operations, then serves tools. There is no connect or login tool: the first tool call works. ## Why this exists Atlassian's own Rovo MCP server exposes only four JSM ops tools (`getJsmOpsAlerts`, `getJsmOpsScheduleInfo`, `getJsmOpsTeamInfo`, `updateJsmOpsAlert`), and those are reachable **only under API-token auth, not OAuth** — which is the auth CloudThinker's `atlassian` connection uses. That surface also has no alert timeline, no responder management, and no assign or escalate. So this is a from-scratch wrapper over the JSM ops REST API (`https://api.atlassian.com/jsm/ops/api/{cloudId}/v1`) plus the Jira platform API for the incident issue itself. ## Environment | Env var | Required | Default | Purpose | |---|---|---|---| | `JSM_SITE_URL` | yes | — | Site origin, e.g. `https://acme.atlassian.net`. Project and board URLs are accepted and normalized back to the origin. | | `JSM_SITE_EMAIL` | yes | — | The Atlassian account the API token belongs to. | | `JSM_API_TOKEN` | yes | — | Atlassian API token from id.atlassian.com. Sent as `Authorization: Basic base64(email:token)`. | | `LOG_LEVEL` | no | `info` | Also mirrored into `FASTMCP_LOG_LEVEL`. | `cloudId` is **not** an input. It is resolved from `JSM_SITE_URL` via `/_edge/tenant_info`; it is a UUID the user has no reason to know. ## Startup preflight The server exits non-zero rather than starting when Operations is not usable, so the CloudThinker connection test reports the real reason instead of letting the failure surface mid-incident: | Condition | Exit | Reported as | |---|---|---| | Missing env var | 2 | which var is unset | | Unparseable `JSM_SITE_URL` | 2 | expected form | | Site or `cloudId` unreachable | 1 | check the site UR…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.