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.

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"]
    }
  }
}

Tools

Tool	API call	Purpose
list_workflows	GET /teams/{team}/processes	List processes, filter by category, owner, published
get_workflow	GET /teams/{team}/processes/{id}	Process details, including expected fields
start_workflow	POST /teams/{team}/runs	Trigger a run with optional name, description, and inputs
get_instance	GET /teams/{team}/runs/{id}	Status, tasks, and progress of a run
get_instance_fields	GET /teams/{team}/runs/{id}/fields	Field values of a run
find_instances	GET /teams/{team}/runs	Search runs by owner, status, or date range
stop_instance	PUT /teams/{team}/runs/{id}	Abort a running instance

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.