The MCP tool directory.

Creates a new on-call schedule in PagerDuty, defining rotation patterns for team members. This endpoint allows you to set up complex schedules with multiple layers, each having its own rotation pattern, user assignments, and time restrictions. Use it to establish new on-call rotations, manage team availability, and ensure continuous incident response coverage. The created schedule can be used in escalation policies to determine who gets notified during incidents. Note that while you can create a basic schedule structure, some elements like rendered schedule entries are read-only and will be populated by the system after creation.

Creates a new service in PagerDuty, which is a key component for managing incidents and alerts. This endpoint allows you to set up a service with various configurations including escalation policies, incident urgency rules, support hours, and alert grouping parameters. Use this when you need to add a new monitored service to your PagerDuty account, such as a new application, infrastructure component, or business process. The created service will be used as a target for incoming alerts and incidents, helping to organize and streamline your incident management process. Note that some advanced features like intelligent alert grouping may depend on your PagerDuty plan.

Creates a new tag in PagerDuty for labeling and categorizing entities. This endpoint allows users to add a custom label to their PagerDuty account, which can be used to organize and filter various resources such as incidents, services, or teams. The created tag can be subsequently assigned to relevant entities to improve organization and searchability within the PagerDuty platform. Use this endpoint when you need to introduce a new categorization or labeling scheme in your PagerDuty setup. Note that this endpoint only creates the tag; assigning it to specific entities would require separate API calls.

Creates a new team within your PagerDuty account. This endpoint allows you to establish a group of users with shared responsibilities, often used for organizing incident management and on-call schedules. Use this when setting up a new department, project team, or any other group that needs to collaborate on incident responses. The created team can be configured as public or private, determining the level of access for non-members. Note that while you can create the team structure with this call, you'll need separate API calls to add members or assign schedules to the team.

Creates a new webhook subscription in PagerDuty to receive specific event notifications. This endpoint allows users to set up automated notifications for various incident-related events, such as triggers, acknowledgments, and resolutions. The webhook can be configured to filter events by service, team, or account-wide, and supports custom HTTP headers for enhanced integration capabilities. Use this when you need to integrate PagerDuty's real-time incident updates with external systems or workflows. Note that the webhook's secret for payload verification is only provided in the initial creation response and cannot be retrieved later.

Creates a new post on a specified PagerDuty Status Page. This endpoint allows you to publish information about incidents or scheduled maintenance, including details such as the post type, timing, and associated updates. Use this to communicate service status, planned downtime, or ongoing issues to your users or customers. The post can include multiple updates, each with its own message, severity, and impact on specific services. This is particularly useful for providing real-time information during incidents or for scheduling and describing maintenance windows.

Creates or updates a postmortem for a specific status page post in PagerDuty. This endpoint allows you to add detailed analysis and insights about an incident after its resolution. The postmortem can include rich-text content and offers the option to notify subscribers. Use this when you need to provide a comprehensive review of an incident, its root causes, and lessons learned. It's particularly useful for maintaining transparency and improving incident response processes. Note that the postmortem is limited to 10,000 characters and is always associated with an existing status page post.

Creates a new Response Play in PagerDuty, which is a predefined set of actions to be executed in response to an incident. This endpoint allows you to configure automated responses, including adding subscribers, assigning responders, setting up conference details, and defining how the Response Play can be triggered. Use this when you want to standardize and automate your incident management process, ensuring consistent and efficient responses to different types of incidents. The Response Play can be set to run automatically for specific services or be manually triggered by team members or responders, depending on the configuration. This tool is particularly useful for creating templated responses for common incident types or for implementing best practices across your organization's incident management workflow.

Creates one or more overrides for a specific schedule in PagerDuty. This endpoint allows you to temporarily modify the on-call schedule by assigning different users for specific time periods. It's useful for handling planned absences, shift swaps, or special coverage requirements without permanently altering the regular schedule. The overrides are applied to the schedule identified by the {id} parameter in the endpoint URL. Multiple overrides can be created in a single request, enabling efficient batch modifications to the schedule. Each override specifies a start time, end time, and the user who will be on call during that period. The endpoint should be used when temporary changes to the on-call rotation are needed. It does not modify the underlying schedule configuration.

Creates a new event rule for a specific service in PagerDuty. This endpoint allows you to define complex conditions and actions for handling incoming events, enabling automated incident management and alert routing. Use this when you need to set up custom logic for processing events, such as setting priorities, annotating incidents, or suppressing alerts based on specific criteria. The rule's position in the evaluation order can be specified, and various time-based conditions can be applied to control when the rule is active. This endpoint is crucial for fine-tuning your incident response workflow and reducing alert noise.

Creates a new subscription for a PagerDuty status page. This endpoint allows users to set up notifications for specific status pages or components within those pages. It's used to keep subscribers informed about updates, incidents, or changes to the monitored services. The subscription can be configured for either email or webhook notifications, allowing for flexible integration with various notification systems. This tool should be used when setting up new monitoring or alert systems, or when adding new stakeholders who need to be kept informed about service status. It's particularly useful for DevOps teams, IT managers, or customer support teams who need real-time updates on service health. Note that this endpoint only creates the subscription; it does not manage or trigger the actual notifications.

Creates a new template in PagerDuty for standardized status updates. This endpoint allows users to define customizable templates for various notification types, including emails and short messages. It's primarily used to streamline communication during incident management by providing consistent and pre-formatted status update messages. The template can include placeholders for dynamic content, allowing for personalized and context-specific notifications. This endpoint should be used when setting up new standardized communication formats for incident updates, but it's important to note that currently only 'status_update' type templates are supported.

Creates a new notification rule for a specific user in PagerDuty. This endpoint allows you to define how and when a user should be notified about assigned incidents. You can specify the delay before notification, the method of contact, and the urgency level of incidents that trigger this rule. This is particularly useful for customizing alert behaviors for different users based on their preferences or role within the organization. The rule created will be associated with the user identified by the provided ID in the URL path.

Creates a new user in the PagerDuty system with the specified attributes. This endpoint should be used when onboarding new team members or adding users to your PagerDuty account. It allows you to set up essential user information, including name, email, role, and time zone preferences. The created user will have default contact methods and notification rules, which can be customized later. Note that some fields like teams, contact methods, and notification rules cannot be set during user creation and must be managed separately. The endpoint requires at minimum a name, email, and user type, with several optional fields for further customization.

Creates a new status update notification rule for a specific user in PagerDuty. This endpoint allows you to define how a user will be notified about incident status updates. It's used to customize notification preferences for individual users, ensuring they receive timely updates through their preferred contact method. The rule specifies which contact method (email, phone, push notification, or SMS) should be used for sending status updates. This is particularly useful for tailoring notification strategies to match users' roles and responsibilities within the incident management process.

Create a new Workflow Integration Connection. Scoped OAuth requires: `workflow_integrations:connections.write`

Delete a custom field for an incident type. Custom Fields (CF) are a feature which will allow customers to extend Incidents with their own custom data, to provide additional context and support features such as customized filtering, search and analytics. Custom Fields can be applied to different incident types. <!-- theme: warning --> > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. Scoped OAuth requires: `custom_fields.write`

Delete a field option for a custom field. <!-- theme: warning --> > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. Scoped OAuth requires: `custom_fields.write`

Deletes the account subscription associated with a specific business service in PagerDuty. This endpoint is used to terminate the subscription or billing relationship between a business service and the account. It should be used when you need to discontinue the subscription for a particular business service, such as when the service is no longer needed or when restructuring your PagerDuty setup. This action is irreversible, so it should be used with caution. The endpoint does not return any specific data upon successful deletion, likely providing only a success status code.

Deletes a specific add-on from the PagerDuty account using its unique identifier. This endpoint should be used when you want to remove an integration or extension that is no longer needed or active in your PagerDuty setup. It's important to note that this action is irreversible, and once an add-on is deleted, it cannot be recovered without re-adding it. Use this endpoint with caution, as removing an add-on may impact any automated workflows or integrations that depend on it.

This endpoint allows you to delete specific alert grouping settings in PagerDuty. It is used to remove outdated or unnecessary configurations that determine how alerts are grouped into incidents. The deletion is permanent and cannot be undone, so it should be used with caution. This operation is particularly useful when updating your incident management strategy or cleaning up unused configurations to maintain an efficient alert grouping system. Note that deleting these settings may affect how future alerts are grouped, potentially impacting your team's incident response workflow.

Delete all OAuth delegations as per provided query parameters. An OAuth delegation represents an instance of a user or account's authorization to an app (via OAuth) to access their PagerDuty account. Common apps include the PagerDuty mobile app, Slack, Microsoft Teams, and third-party apps. Deleting an OAuth delegation will revoke that instance of an app's access to that user or account. To grant access again, reauthorization/reauthentication may be required. At this time, this endpoint only supports deleting mobile app OAuth delegations for a given user. This is equivalent to signing users out of the mobile app. This is an asynchronous API, the deletion request itself will be processed within 24 hours. Scoped OAuth requires: `oauth_delegations.write`

Deletes a specific Automation Action from the PagerDuty system. This endpoint is used to permanently remove an Automation Action, which includes any associated scripts or jobs in Runbook Automation. It should be used when an Automation Action is no longer needed or has become obsolete. Once deleted, the action cannot be recovered, so use this endpoint with caution. This operation is typically performed by administrators or users with appropriate permissions to manage Automation Actions.

This endpoint removes a specific automation action from a particular service in PagerDuty. It is used to disassociate an automated workflow or action from a service, effectively stopping that action from being triggered for incidents related to the specified service. This operation is useful when you need to update your incident management workflow or when an automated action is no longer relevant for a specific service. It's important to note that this endpoint only removes the association between the action and the service; it does not delete the automation action itself from the system. Use this endpoint with caution, as removing an automation action from a service will immediately affect the incident response process for that service.

Deletes a specific automation runner from the PagerDuty system. This endpoint is used to permanently remove an automation runner, which is responsible for executing automated tasks and workflows. It should be used when an automation runner is no longer needed or needs to be replaced. Once deleted, all associated automated actions and schedules tied to this runner will be affected. Exercise caution when using this endpoint, as the deletion is irreversible and may impact existing automation setups.

Deletes a specific business service from the PagerDuty system. This endpoint should be used when you want to permanently remove a business service that is no longer needed or relevant to your organization's incident management structure. It's important to note that this action is irreversible and will remove all associations between the deleted business service and any technical services or incidents. Use this endpoint with caution, as it may impact reporting and historical data related to the deleted business service. Before deletion, ensure that no active incidents or dependencies rely on this business service to avoid disruptions in your incident management workflow.

Deletes all priority thresholds for business services in the PagerDuty account. This endpoint is used to remove the configured priority settings that determine how incidents are escalated based on their urgency for business services. It should be used when you want to reset or remove all priority threshold configurations across your business services. This operation is irreversible and will affect how future incidents are prioritized and escalated for all business services in the account. It's important to note that this action does not delete the business services themselves, only their associated priority thresholds.

Deletes a specific cache variable associated with an event orchestration in PagerDuty. This endpoint is used to remove temporary data storage that was previously set up for use in event orchestration workflows. It should be used when you need to clean up or remove outdated cache variables that are no longer needed in your event management process. This operation is permanent and cannot be undone, so it should be used with caution. The endpoint requires both the event orchestration ID and the specific cache variable ID to ensure precise removal of the intended data.

This endpoint deletes a specific cache variable associated with a service in PagerDuty's event orchestration system. It is used to remove temporary data that is no longer needed, helping to maintain system efficiency. The endpoint should be used when you want to permanently remove a cache variable from a particular service, such as when the variable is obsolete or to free up resources. It's important to note that this action is irreversible, and once deleted, the cache variable cannot be recovered. Use this endpoint with caution to avoid accidentally removing critical data used in event orchestrations.

Deletes a specific custom field from incidents in PagerDuty. This endpoint allows users to remove a custom field that is no longer needed or relevant for incident management. It should be used when you want to permanently delete a custom field from all incidents, both existing and future. The operation is irreversible, so caution should be exercised when using this endpoint. It's important to note that this action will remove the specified custom field and its associated data from all incidents, which could impact reporting and analysis based on that field.