PagerDuty Workflow Automation MCP Server

Unofficial MCP server for PagerDuty Workflow Automation (formerly Catalytic). This project is not affiliated with, endorsed by, or supported by PagerDuty. It uses the legacy Catalytic v1 API that PagerDuty may change or remove at any time. Use at your own risk.

MCP server that connects Claude to PagerDuty Workflow Automation (formerly Catalytic). Lets Claude find processes (workflows), trigger runs with input fields, and check or abort running instances.

Requires username/password login. SSO teams are not supported. The v1 API authenticates with a user key obtained by posting a username and password, and there is currently no working way to get that key on a team that logs in through SSO. See Authentication for details.

Built against the Catalytic internal v1 API (swagger spec in the local legacy_api/ folder, which is gitignored since it is internal PagerDuty documentation). Base URL is https://<team>.pushbot.com/v1 and every request authenticates with an x-user-key header.

Setup

pip install -r requirements.txt
cp .env.example .env

Get your User Key:

python3 get_token.py

It POSTs your username and password to /v1/teams/<team>/auth (you type them locally, they go only to your team's endpoint) and prints the CATALYTIC_USER_KEY and CATALYTIC_TEAM lines to paste into .env, using vi .env.

Related MCP server: ServiceNow MCP Server

Authentication

Every request carries an x-user-key header holding a 64-character user key. The only known way to obtain one is POST /v1/teams/<team>/auth with a username and password, which is what get_token.py does.

SSO teams do not work today. If your team logs in through an identity provider, that endpoint rejects your credentials and there is no substitute. Approaches that were tried and failed:

• Access tokens created in the web UI. These are a different credential format (a ~180-character serialized token). They are rejected by the v1 API as an x-user-key, and rejected as a Bearer token by the newer /api surface.

• The user-token request/approve/poll endpoints documented in the swagger spec (POST /teams/<team>/user-tokens, :approve, :poll). Only partially deployed: creation works, but polling returns 401 and approve/revoke/list return 404.

• Copying the key out of the web app. The current web UI no longer uses the v1 API. It authenticates with a catalytic.sid session cookie against a GraphQL endpoint, so no x-user-key header ever appears in its traffic.

• Reusing the browser session. The v1 API ignores session cookies and returns 403 without the header.

• Capturing the key from the SAML exchange. The spec's saml-auth schema shows a userKey in the response to POST /saml/auth, but on current deployments that request returns a 302 with no key in the redirect.

If you find a working method on an SSO team, please open an issue.

Use with Claude Code

The included .mcp.json registers the server for this project automatically. To register it globally instead:

claude mcp add "PagerDuty Workflow Automation" -- python3 /path/to/pagerduty-wfa-mcp-server/server.py

Use with Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "PagerDuty Workflow Automation": {
      "command": "python3",
      "args": ["/path/to/pagerduty-wfa-mcp-server/server.py"]
    }
  }
}

Multiple teams

The server can hold credentials for several teams at once. Copy config.json.example to config.json (gitignored) next to server.py:

{
  "default": "my-team",
  "teams": {
    "my-team": "<userKey>",
    "other-team": "<userKey>"
  }
}

Every tool accepts an optional team argument; when omitted, the default team is used. In Claude you can just say "list the workflows on other-team" and the right credentials are used. When there is no config.json, the server falls back to the single-team CATALYTIC_TEAM/CATALYTIC_USER_KEY values in .env.

Tools

Every tool takes an optional team. API paths below are relative to /v1/teams/{team}.

Workflows (processes):

Runs (instances):

Triggers and webhooks:

Users:

start_workflow takes inputs as a plain dict of field names to values:

start_workflow(
    process_id="8bf3db91-a8b2-4e34-aade-38c08a49170e",
    name="Renewal for Acme",
    inputs={"customer-name": "Acme", "priority": "High"}
)

API notes

• Run statuses: running, completed, failed, aborted.

• The swagger spec does not formally define the POST /runs request body; the server sends {processID, displayName, description, fields: [{fieldName, value}]} based on the run schema's writable fields. If the API rejects it, compare against a request the web UI makes (browser dev tools, Network tab) and adjust start_workflow in server.py.