Skip to main content
Glama
wpfleger96

PagerDuty MCP Server

by wpfleger96

get_oncalls

Retrieve on-call schedules, policies, or entries within specified time ranges for PagerDuty. Use filters like schedules, users, or policies to customize results. Supports current on-calls or historical data queries up to 90 days.

Instructions

List on-call entries for schedules, policies, or time ranges.

Behavior varies by time parameters:

  1. Without since/until: Returns current on-calls Example: get_oncalls(schedule_ids=["SCHEDULE_123"])

  2. With since/until: Returns all on-calls in range Example: get_oncalls(schedule_ids=["SCHEDULE_123"], since="2024-03-20T00:00:00Z", until="2024-03-27T00:00:00Z")

Args: current_user_context (bool): Use current user's team policies (default: True) schedule_ids (List[str]): Filter by schedules (optional) user_ids (List[str]): Filter by users (optional, excludes current_user_context) escalation_policy_ids (List[str]): Filter by policies (optional) since (str): Start of query range in ISO8601 format (default: current datetime) until (str): End of query range in ISO8601 format (default: current datetime, max range: 90 days in the future). Cannot be before since. limit (int): Max results (optional) earliest (bool): Only earliest on-call per policy/level/user combo (optional)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
current_user_contextNo
earliestNo
escalation_policy_idsNo
limitNo
schedule_idsNo
sinceNo
untilNo
user_idsNo

Implementation Reference

  • Handler function for the 'get_oncalls' tool. Decorated with @mcp.tool() for MCP registration. Manages input validation, user context, and delegates core logic to oncalls.list_oncalls().
    @mcp.tool()
    def get_oncalls(
        *,
        current_user_context: bool = True,
        schedule_ids: Optional[List[str]] = None,
        user_ids: Optional[List[str]] = None,
        escalation_policy_ids: Optional[List[str]] = None,
        since: Optional[str] = None,
        until: Optional[str] = None,
        limit: Optional[int] = None,
        earliest: Optional[bool] = None,
    ) -> Dict[str, Any]:
        """List on-call entries for schedules, policies, or time ranges.
    
        Behavior varies by time parameters:
        1. Without since/until: Returns current on-calls
           Example: get_oncalls(schedule_ids=["SCHEDULE_123"])
        2. With since/until: Returns all on-calls in range
           Example: get_oncalls(schedule_ids=["SCHEDULE_123"], since="2024-03-20T00:00:00Z", until="2024-03-27T00:00:00Z")
    
        Args:
            current_user_context (bool): Use current user's team policies (default: True)
            schedule_ids (List[str]): Filter by schedules (optional)
            user_ids (List[str]): Filter by users (optional, excludes current_user_context)
            escalation_policy_ids (List[str]): Filter by policies (optional)
            since (str): Start of query range in ISO8601 format (default: current datetime)
            until (str): End of query range in ISO8601 format (default: current datetime, max range: 90 days in the future). Cannot be before `since`.
            limit (int): Max results (optional)
            earliest (bool): Only earliest on-call per policy/level/user combo (optional)
        """
        if current_user_context:
            if user_ids is not None:
                raise ValueError(
                    "Cannot specify user_ids when current_user_context is True. See `docs://tools` for more information."
                )
            user_context = users.build_user_context()
            escalation_policy_ids = user_context["escalation_policy_ids"]
        elif not (schedule_ids or user_ids or escalation_policy_ids):
            raise ValueError(
                "When current_user_context is False, must specify at least one of: schedule_ids, user_ids, or escalation_policy_ids. See `docs://tools` for more information."
            )
    
        return oncalls.list_oncalls(
            user_ids=user_ids,
            schedule_ids=schedule_ids,
            escalation_policy_ids=escalation_policy_ids,
            since=since,
            until=until,
            limit=limit,
            earliest=earliest,
        )
  • Core helper function implementing the on-call listing logic: builds API parameters for PagerDuty's /oncalls endpoint, fetches data, parses each on-call entry with parse_oncall, and formats the standard response.
    def list_oncalls(
        *,
        schedule_ids: Optional[List[str]] = None,
        user_ids: Optional[List[str]] = None,
        escalation_policy_ids: Optional[List[str]] = None,
        since: Optional[str] = None,
        until: Optional[str] = None,
        limit: Optional[int] = None,
        earliest: Optional[bool] = None,
    ) -> Dict[str, Any]:
        """List the on-call entries during a given time range.
        An oncall-entry contains the user that is on-call for the given schedule, escalation policy, or time range and also includes the schedule and escalation policy that the user is on-call for. Exposed in `get_oncalls`.
    
        Args:
            schedule_ids (List[str]): Return only on-calls for the specified schedule IDs (optional)
            user_ids (List[str]): Return only on-calls for the specified user IDs (optional)
            escalation_policy_ids (List[str]): Return only on-calls for the specified escalation policy IDs (optional)
            since (str): Start of date range in ISO8601 format (optional). Default is 1 month ago
            until (str): End of date range in ISO8601 format (optional). Default is now
            limit (int): Limit the number of results returned (optional)
            earliest (bool): If True, only returns the earliest on-call for each combination of escalation policy, escalation level, and user. Useful for determining when the "next" on-calls are for a given set of filters. (optional)
    
        Returns:
            See the "Standard Response Format" section in `tools.md` for the complete standard response structure.
            The response will contain a list of on-call entries with user, schedule, and escalation policy information.
    
        Raises:
            See the "Error Handling" section in `tools.md` for common error scenarios.
        """
    
        pd_client = create_client()
    
        params = {}
        if schedule_ids:
            params["schedule_ids[]"] = schedule_ids
        if user_ids:
            params["user_ids[]"] = user_ids
        if escalation_policy_ids:
            params["escalation_policy_ids[]"] = escalation_policy_ids
        if since:
            utils.validate_iso8601_timestamp(since, "since")
            params["since"] = since
        if until:
            utils.validate_iso8601_timestamp(until, "until")
            params["until"] = until
        if limit:
            params["limit"] = limit
        if earliest is not None:
            params["earliest"] = earliest
    
        try:
            response = pd_client.list_all(ONCALLS_URL, params=params)
            parsed_response = [parse_oncall(result=result) for result in response]
            return utils.api_response_handler(
                results=parsed_response, resource_name="oncalls"
            )
        except Exception as e:
            utils.handle_api_error(e)
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by explaining behavioral variations based on parameters, providing concrete examples, and disclosing constraints like 'max range: 90 days in the future' and 'Cannot be before `since`.' It also explains the 'earliest' parameter's effect. However, it doesn't mention pagination behavior, rate limits, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, behavior variations with examples, then parameter details). Every sentence adds value, though the parameter section is somewhat dense. It could be slightly more front-loaded by moving key behavioral insights closer to the beginning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, 0% schema coverage, and no output schema, the description does an excellent job explaining parameters and behavior. However, it doesn't describe the return format (what fields are included in on-call entries) or error conditions, leaving some gaps in completeness despite strong parameter coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 8 parameters, the description fully compensates by providing detailed explanations for all parameters. It clarifies defaults, constraints, interactions (e.g., 'user_ids excludes current_user_context'), format requirements ('ISO8601 format'), and the purpose of each parameter, adding significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('List on-call entries') and resources ('schedules, policies, or time ranges'). It distinguishes itself from siblings like 'list_users_oncall' by focusing on entries rather than users, and from 'get_schedules'/'get_escalation_policies' by focusing specifically on on-call assignments rather than the underlying objects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use different parameter combinations (with/without since/until), and mentions exclusions like 'user_ids excludes current_user_context.' However, it doesn't explicitly compare to sibling tools like 'list_users_oncall' or provide guidance on when to choose this tool over alternatives for similar queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wpfleger96/pagerduty-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server