Product and engineering

The PagerDuty connector.

Incidents, services and on-call schedules. Connect once with your own key. Every agent your team runs reads the same 5 tools under one permission model.

How access is governed

5

Read tools

Open by default. They run when called, and every call is logged with the endpoint, tool and capability.

0

Write tools

PagerDuty exposes no write tools. Nothing it does mutates external state.

0

Destructive tools

PagerDuty defines no destructive tools. Nothing here deletes data.

Defaults come from the capability on each tool definition, and an admin can tighten or open any tool individually. The endpoint's capability ceiling can only tighten that policy. An endpoint scoped to read never surfaces a write tool.

Every PagerDuty tool

5 tools, named as the agent sees them.

  • list_incidentsread

    List incidents, newest first. Use this to answer "what is on fire right now" (leave status at the default triggered+acknowledged) or to review a period (pass since/until). Returns incident `id` values — pass one to get_incident for the full record. Filter to a service with the `service_ids` values returned by list_services.

  • get_incidentread

    Get one incident in full, including its body/description, acknowledgements and resolve reason. Takes the `id` from list_incidents (e.g. "PT4KHLK"); the incident number will not work.

  • list_servicesread

    List the services (applications, components, systems) configured in PagerDuty. Use this to find a service ID before filtering list_incidents, or to check which services are currently in a warning/critical state.

  • list_oncallsread

    List who is on call. With no arguments this returns the people on call right now; pass since/until to see a future or past window. Each entry names the escalation policy, the schedule it came from, and the escalation level (level 1 is paged first).

  • list_usersread

    List users in the PagerDuty account. Use this to resolve a person's name or email to the user ID that list_oncalls takes in `user_ids`.

Use it from any agent

The same PagerDuty tools reach Claude Code, Cursor, Claude Desktop or your own agent through one MCP endpoint. The endpoint is scoped to a group, the token is issued per group and revocable from the dashboard, and an allowed-tool list and capability ceiling limit what it exposes. Reads run. Gated writes refuse unless an admin opens them. Destructive tools remain unavailable over MCP.

.mcp.json · works for Cursor and Claude Desktop too
{
  "mcpServers": {
    "growth": {
      "type": "http",
      "url": "https://app.notara.ai/mcp/g/acme/growth",
      "headers": {
        "Authorization": "Bearer ntr_mcp_xxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

The URL and token are placeholders. Real endpoints are issued per group from the dashboard.

Setup

  1. 01

    Create a PagerDuty API Key in your PagerDuty account (where to find it). The key is yours: Notara stores it encrypted and never sees a bill.

  2. 02

    Paste it into the Notara dashboard. Credentials can be scoped to the workspace or to one person.

  3. 03

    The tools appear with their capability defaults already set. Tighten or open any of them per tool, then invite the agent to a channel or issue an MCP token.

More in product and engineering

Connect PagerDuty once. Use it everywhere.

Use Notara directly, or bring us the workflow that needs to be redesigned and built.