PagerDuty MCP Server

A server that exposes PagerDuty API functionality to LLMs. This server is designed to be used programmatically, with structured inputs and outputs.

Overview

The PagerDuty MCP Server provides a set of tools for interacting with the PagerDuty API. These tools are designed to be used by LLMs to perform various operations on PagerDuty resources such as incidents, services, teams, and users.

Getting Started

1. Initialize your local Python environment:

cd pagerduty-mcp-server
brew install uv
uv sync

2. The PagerDuty MCP Server requires a PagerDuty API token. You can provide this in two ways:

   Option 1: Environment Variable

   export PAGERDUTY_API_TOKEN=your_api_token_here
   

   Option 2: .env File (Recommended) Create a .env file in the project root:

   echo "PAGERDUTY_API_TOKEN=your_api_token_here" > .env
   

   The server will automatically load environment variables from the .env file if present.

Usage

As Goose Extension (Desktop)

In Goose:

1. Go to Settings > Advanced Settings > Extensions > Add custom extension.
2. Give the extension a name (e.g. pagerduty-mcp-server).
3. Set Type to StandardIO.
4. Enter the following in the Command field:

   uvx pagerduty-mcp-server
   

5. Click Save.
6. Enable the extension and confirm that Goose identifies your tools.

As Goose Extension (CLI)

  pagerduty:
    args:
      - pagerduty-mcp-server
    bundled: null
    cmd: uvx
    description: ''
    enabled: true
    env_keys:
      - PAGERDUTY_API_TOKEN
    envs: {}
    name: pagerduty
    timeout: 300
    type: stdio

Claude/Cursor

{
  "mcpServers": {
    "pagerduty-mcp-server": {
      "command": "uvx",
      "args": ["pagerduty-mcp-server"],
      "env": {
          "PAGERDUTY_API_TOKEN": <PAGERDUTY_API_TOKEN>
      }
    }
  }
}

As Standalone Server

uv run path/to/repo/pagerduty-mcp-server/.venv/bin/pagerduty-mcp-server

Response Format

All API responses follow a consistent format:

{
  "metadata": {
    "count": <int>,  // Number of results
    "description": "<str>"  // A short summary of the results
  },
  <resource_type>: [ // Always pluralized for consistency, even if one result is returned
    {
      ...
    },
    ...
  ],
  "error": {  // Only present if there's an error
    "message": "<str>",  // Human-readable error description
    "code": "<str>"  // Machine-readable error code
  }
}

Error Handling

When an error occurs, the response will include an error object with the following structure:

{
  "metadata": {
    "count": 0,
    "description": "Error occurred while processing request"
  },
  "error": {
    "message": "Invalid user ID provided",
    "code": "INVALID_USER_ID"
  }
}

Common error scenarios include:

• Invalid resource IDs (e.g., user_id, team_id, service_id)
• Missing required parameters
• Invalid parameter values
• API request failures
• Response processing errors

Parameter

... View full README on GitHub