pagerduty-mcp-community
Related Servers
Alternatives to pagerduty-mcp-community
No user-submitted related servers found.
Related Servers
AlicenseBqualityFmaintenanceEnables management of PagerDuty incidents, services, schedules, and more directly from MCP-enabled clients, with embedded interactive UIs for incident command center, on-call management, and other features.6377Apache 2.0- AlicenseNot gradedqualityBmaintenanceMCP server for IncidentRelay, exposing its entire REST API (279 operations) through gateway and curated tools for on-call scheduling, alert routing, and incident management.MIT
- FlicenseNot gradedqualityDmaintenanceA modular MCP server exposing tools for integrating with services like GitHub, Redash, Jenkins, Figma, Jira, Confluence, Teams, Datadog, PagerDuty, Slack, and Presto, enabling users to manage these platforms through natural language via an MCP client.-
- AlicenseBqualityCmaintenanceUnified MCP server for DevOps engineers that provides real-time read and write access to Kubernetes, ArgoCD, Prometheus, and PagerDuty from any MCP-compatible AI agent.2173 npm3MIT
- FlicenseNot gradedqualityCmaintenanceAn incident management MCP server for on-call engineers, providing tools to search incidents, review deploys, query logs, analyze latency metrics, and acknowledge or summarize incidents.-
- AlicenseNot gradedqualityCmaintenanceMCP server for the Splunk On-Call (VictorOps) API providing comprehensive incident management, on-call schedules, team administration, and alert reporting through natural language.MIT
TDQS
Scored across 20 tools
Each tool targets a distinct resource or specific sub-resource (e.g., get_escalation_policy vs list_escalation_policies, get_event_orchestration_router). No two tools have overlapping purposes, making selection unambiguous.
All tools follow a consistent verb_noun pattern using snake_case: get_<resource> for single items, list_<resource> for collections. There are no deviations or mixed conventions.
With 20 tools covering the major PagerDuty resources (incidents, services, teams, users, schedules, escalation policies, etc.), the count is appropriate for a comprehensive read-only API surface.
The server is entirely read-only; there are no create, update, delete, or action tools (e.g., acknowledge incident, create service). This is a significant gap for most workflows, leaving agents unable to take any action.