Summary
The MCP server currently only supports classic (v2) schedules via the /schedules and /schedules/{id} REST API endpoints. PagerDuty's newer v3 schedules — which use the /v3/schedules/... API family — are completely invisible to the MCP server.
Problem
When a schedule is created using PagerDuty's newer scheduling system (v3), the MCP server cannot:
- Read the schedule (
get_schedule returns 404)
- List it (
list_schedules omits it entirely)
- Update it (
update_schedule fails)
- Parse escalation policy references to it (the
schedule_v3_reference type causes a Pydantic validation error in get_escalation_policy)
This means any organization using v3 schedules cannot manage them through the MCP server at all.
How to reproduce
- Create a schedule using PagerDuty's newer scheduling UI (which creates a v3 schedule)
- Try to access it via the MCP server's
get_schedule tool — returns 404
- Try
list_schedules — the schedule does not appear
- If the schedule is referenced in an escalation policy,
get_escalation_policy fails with:
Input should be 'user_reference' or 'schedule_reference'
[type=literal_error, input_value='schedule_v3_reference', input_type=str]
Expected behavior
The MCP server should support v3 schedules, including:
- Listing and reading v3 schedules
- Creating and updating v3 schedules (with their rotations, events, custom shifts, overrides)
- Properly handling
schedule_v3_reference types in escalation policies
Context
- The v3 schedule API lives at
/v3/schedules/... with a different data model (schedules → rotations → events → custom shifts → overrides)
- PagerDuty's Go client library (
go-pagerduty/schedule_v3.go) fully implements the v3 API
- PagerDuty's Terraform provider already supports v3 schedules via the
pagerduty_schedulev2 resource
- The v3 API appears stable and actively used
Workaround
Currently the only workaround is to recreate the schedule as a classic (v2) schedule, or manage v3 schedules manually through the PagerDuty UI.
Summary
The MCP server currently only supports classic (v2) schedules via the
/schedulesand/schedules/{id}REST API endpoints. PagerDuty's newer v3 schedules — which use the/v3/schedules/...API family — are completely invisible to the MCP server.Problem
When a schedule is created using PagerDuty's newer scheduling system (v3), the MCP server cannot:
get_schedulereturns 404)list_schedulesomits it entirely)update_schedulefails)schedule_v3_referencetype causes a Pydantic validation error inget_escalation_policy)This means any organization using v3 schedules cannot manage them through the MCP server at all.
How to reproduce
get_scheduletool — returns 404list_schedules— the schedule does not appearget_escalation_policyfails with:Expected behavior
The MCP server should support v3 schedules, including:
schedule_v3_referencetypes in escalation policiesContext
/v3/schedules/...with a different data model (schedules → rotations → events → custom shifts → overrides)go-pagerduty/schedule_v3.go) fully implements the v3 APIpagerduty_schedulev2resourceWorkaround
Currently the only workaround is to recreate the schedule as a classic (v2) schedule, or manage v3 schedules manually through the PagerDuty UI.