Rootly MCP server

Official

by rootlyhq

Overview Schema Source Related Servers Discussions Admin

Python

Remote

List Shifts

list_shifts

Read-only

List on-call shifts with user and schedule filters, enriched user details, and MCP-level pagination to find who is on call or when handoffs occur.

Instructions

List on-call shifts with reliable filtering, enrichment, and MCP-level pagination.

Unlike the raw API, this tool:

Actually filters by user_ids (client-side filtering)
Includes user_name, user_email, schedule_name, team_name
Calculates total_hours for each shift
Returns a predictable paginated result for MCP clients

Use this instead of the auto-generated listShifts when you need user filtering or dependable pagination on large tenants.

Answers questions about individual shifts: who is on call at a given time, when a handoff happens, which shifts were overrides, or one person's schedule (via user_ids). For questions about totals across a team -- hours per responder, coverage, load -- use get_oncall_schedule_summary, whose response size depends on team size rather than on how long a range you asked for.

Ranges longer than the upstream cap are split into windows and merged automatically, so a multi-month range is a normal request.

Input Schema

Name	Required	Description
`to_date`	Yes	End date/time for shift query (ISO 8601 format, e.g., '2026-02-15T23:59:59Z')
`user_ids`	No	Comma-separated list of user IDs to filter by (e.g., '2381,94178'). Only returns shifts for these users.
`from_date`	Yes	Start date/time for shift query (ISO 8601 format, e.g., '2026-02-09T00:00:00Z')
`page_size`	No	Number of enriched shifts to return per page (max: 100). This paginates the MCP response even when the upstream shifts API does not.
`page_number`	No	Page number of enriched shifts to return (1-indexed). Use this instead of relying on the generated listShifts pagination.
`schedule_ids`	No	Comma-separated list of schedule IDs to filter by (optional)
`include_user_details`	No	Include user name and email in response (default: True)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.0Nov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds substantial behavioral context beyond that: client-side user_ids filtering, enriched fields, total_hours calculation, predictable pagination, and automatic splitting/merging of long date ranges. There is no contradiction with the read-only annotation.

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 longer than average but appropriately front-loads the tool's purpose and uses bullets for key differentiators. Some pagination-related wording is repeated, but overall the structure is clear and the length is justified by the tool's complexity and multiple relevant siblings.

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

Completeness5/5

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

Given the complexity, full schema coverage, output schema, and read-only annotations, the description is complete enough for correct invocation. It covers the key behavioral traits, alternatives, and range-handling constraints without needing to restate return-value details already captured by the output schema.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description still adds useful meaning beyond the schema by explaining that user_ids filtering is client-side and that pagination is MCP-level and predictable, though it does not elaborate on every parameter.

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 states a specific verb and resource: listing on-call shifts with reliable filtering, enrichment, and MCP-level pagination. It further scopes the tool to individual-shift questions and distinguishes it from the auto-generated listShifts and get_oncall_schedule_summary, so an agent can identify its role without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit routing guidance: use this instead of the auto-generated listShifts when user filtering or dependable pagination is needed, and use get_oncall_schedule_summary for team-level totals. The individual-vs-summary distinction is concrete and actionable.

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

Deploy Server