Skip to main content
Glama
Rootly MCP server

Rootly MCP server

Official
by rootlyhq

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ROOTLY_API_TOKENNoYour Rootly API token
ROOTLY_AUTH_HEADERNoBearer token for authentication (format: Bearer <YOUR_ROOTLY_API_TOKEN>)

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": true
}
resources
{
  "subscribe": false,
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_endpointsA

List all available Rootly API endpoints with their descriptions.

get_server_versionA

Get the Rootly MCP server version.

Returns the current version of the deployed MCP server. Useful for checking if the server has been updated.

list_incidentsA

🚨 List incidents with structured filters - ESSENTIAL for incident response.

WHEN TO USE: • During incident response to check for related ongoing incidents • For shift handoffs to review recent incidents by team/service • For post-incident analysis to find patterns by severity/date range • For audit workflows requiring specific filtering criteria

Use this when you need date-range, team, service, severity, or status filters. For simple text searches, prefer search_incidents instead.

Argument caps: page_size <= 100. Values outside the bounds are clamped and reported, not rejected.

collect_incidentsA

Collect a bounded working set of incidents across multiple pages for audits and analysis.

Use this instead of list_incidents when you want a compact batch of incidents in one tool call, while keeping payload size under control.

Argument caps: max_results <= 100, batch_size between 10 and 100. Values outside those bounds are clamped and reported, not rejected.

search_incidentsA

Search incidents with flexible pagination control.

Use page_number=0 to fetch all matching results across multiple pages. Use page_number>0 to fetch a specific page.

max_results (also accepted as limit) caps how many incidents come back in either mode: across pages when page_number=0, and within the page otherwise. Left unset, a single page returns page_size incidents and page_number=0 stops at 5.

Argument caps: page_size <= 20, max_results <= 10. Values outside those bounds are clamped and reported, not rejected.

get_incidentA

Retrieve a single incident with PIR-related fields for direct verification.

get_incident_retrospectiveA

Fetch the written retrospective for one incident.

Answers "what did we learn from INC-4460" in a single call. Returns the document's title, content and status alongside the incident it belongs to, and reports the incident's retrospective progress so a blank document is distinguishable from one nobody has started.

The route exists only in this direction: /post_mortems cannot be filtered by incident, and the document carries no reference back to one, so the id has to come from the incident's own relationship. Doing that here keeps a caller from having to know it. Use list_incident_post_mortems to search across retrospectives instead.

list_incident_post_mortemsA

Browse retrospectives across incidents.

Answers "the last five retrospectives", "published ones for this team since June", or "how many are still draft". Each result carries the document's analysis -- summary, causes, impact, actions. A recognised Timeline is dropped and the record says so with timeline_omitted, because a minute-by-minute log is a third of a document and rarely what a browse is after. What remains is still capped, and a record cut that way carries content_truncated with its real content_chars. Use get_incident_retrospective for one document whole, Timeline included and nothing cut.

Filtering happens upstream for status, severity, team, service and dates. Free-text search is not offered here because the API's search matches titles only, and titles are generated from the incident name -- it cannot find a retrospective by what it says. Use get_incident_retrospective when the incident is already known.

list_incident_rolesA

List role assignments for an incident (who is Commander, Scribe, etc.).

Returns one entry per defined role with role metadata and the assigned user (or user_id: null for roles that are defined on the incident but not yet assigned). Use this to answer questions like "who is the incident commander?", "is there a postmortem owner?", or "list all roles for INC-4460".

Implementation note: this wraps GET /v1/incidents/{id}?include=roles and flattens the JSON:API included array of incident_role_assignments into a flat table so callers don't need to walk the relationships graph.

get_incident_meeting_transcriptsA

Read what was said on an incident's calls (Rootly Meeting Scribe).

Returns the spoken transcript of each recorded call for the incident, as text per speaker turn, alongside Scribe's own summary. Covers Google Meet, Zoom and Microsoft Teams calls that Scribe recorded.

Use this to catch up on a call you missed, or to pull decisions and actions out of an incident bridge. Recordings where nobody spoke are skipped rather than returned empty.

create_incidentC

Create an incident with a scoped set of fields for agent-driven workflows.

update_incidentA

Update native incident fields via PUT /v1/incidents/{id}.

Only the arguments you provide are sent, so unspecified fields — including the lifecycle status — are left untouched.

find_related_incidentsA

šŸ” Find historically similar incidents using ML similarity analysis - CRITICAL for incident response.

WHEN TO USE: • EARLY in incident response to learn from past similar issues • When you're unsure about root cause or resolution approach • Before escalating to find if this is a known pattern • For post-incident analysis to identify recurring issues

Provide either incident_id OR incident_description (e.g., 'website is down', 'database timeout errors'). Use status_filter to limit to specific incident statuses or leave empty for all incidents.

Argument caps: max_results <= 20. Values outside the bounds are clamped and reported, not rejected.

suggest_solutionsA

šŸ’” Get actionable solution recommendations from similar resolved incidents - KEY for incident response.

WHEN TO USE: • AFTER find_related_incidents to get specific resolution steps • When team is stuck on how to resolve the current incident • To speed up incident resolution with proven solutions • For training new responders on resolution patterns

Provide either incident_id OR title/description. Defaults to resolved incidents for solution mining.

Argument caps: max_solutions <= 10. Values outside the bounds are clamped and reported, not rejected.

get_oncall_shift_metricsA

šŸ“Š Get on-call workload metrics and shift statistics - ESSENTIAL for fairness and planning.

WHEN TO USE: • Monthly/quarterly reviews of on-call distribution • Before adjusting schedules to ensure fair workload • For management reporting on on-call burden • When investigating potential on-call burnout

Returns shift counts, total hours, and statistics grouped by user, schedule, or team.

Examples:

  • Monthly report: start_date='2025-10-01', end_date='2025-10-31'

  • Specific user: start_date='2025-10-01', end_date='2025-10-31', user_ids='123,456'

  • Specific team: team_ids='team-1' (will query schedules for that team first)

get_oncall_handoff_summaryA

Get current on-call handoff summary. Shows who's currently on-call and who's next. Optionally fetch incidents (set include_incidents=True, but slower). Each responder's role is their On-Call role (e.g. Responder, Admin); shifts themselves carry no role.

Use filter_by_region=True with a timezone to see only people on-call during business hours in that region (e.g., timezone='Asia/Tokyo', filter_by_region=True shows only APAC on-call during APAC business hours).

Useful for:

  • Quick on-call status checks

  • Daily handoff meetings

  • Regional on-call status (APAC, EU, Americas)

  • Team coordination across timezones

get_shift_incidentsB

Get incidents and alerts that occurred during a specific shift or time period.

Useful for:

  • Shift handoff summaries showing what happened during the shift

  • Post-shift debriefs and reporting

  • Incident analysis by time period

  • Understanding team workload during specific shifts

Returns incident details including severity, status, duration, and basic summary.

get_schedule_shiftsA

List shifts for one schedule over a date range.

Replaces the generated getScheduleShifts, which passed the range straight through and failed with Datetime range exceeds 1 month on anything longer than the upstream accepts. Ranges longer than that are split into windows and merged here, so a two-month question is a normal request.

Use list_shifts instead when the question spans schedules or filters by user.

list_shiftsA

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.

get_oncall_schedule_summaryA

Get compact on-call schedule summary for a date range.

Returns one entry per user per schedule (not raw shifts), with aggregated hours. Optimized for AI agent context windows.

Use this instead of list_shifts when you need:

  • Aggregated hours per responder

  • Schedule coverage overview

  • Responder load analysis with warnings

One row per user per schedule, so the response stays the same size whether the range is a week or a year. For individual shift times, or for one person's schedule, use list_shifts instead.

Ranges longer than the upstream cap are split into windows and merged automatically.

check_responder_availabilityA

Check if specific users are scheduled for on-call in a date range.

Use this to verify if at-risk users (from On-Call Health) are scheduled, or to check availability before assigning new shifts.

Returns scheduled users with their shifts and total hours, plus users who are not scheduled. Shift times and hours are clipped to the requested window; date-only end dates include that entire UTC day.

create_override_recommendationA

Recommend replacement responders for an override shift.

Finds users in the same schedule rotation who are not already heavily loaded during the period.

Returns recommended replacements sorted by current load (lowest first), plus a ready-to-use override payload for the top recommendation.

check_oncall_health_riskA

Check if any at-risk responders (based on On-Call Health analysis) are scheduled for on-call.

Integrates with On-Call Health (oncallhealth.ai) to identify responders with elevated workload health risk and checks if they are scheduled during the specified period. Optionally recommends safe replacement responders.

Privacy: This tool surfaces identifiable employee workload health data from On-Call Health. It is an opt-in feature — an administrator must explicitly configure the ONCALLHEALTH_API_KEY environment variable to enable it.

Available only in self-hosted deployments. Requires ONCALLHEALTH_API_KEY environment variable.

get_alert_by_short_idA

Get alert details by short_id or alert URL. Use this when a user pastes an alert URL or short_id from a pager notification and wants to investigate the alert.

list_auditsA

Read the Rootly audit log: who changed which configuration object, when, and what changed.

Each record carries the action, the acting user, the source, and the before-and-after value of every modified field. Use it to answer "who changed this escalation policy", "what did this workflow look like before", or to collect change evidence for a compliance review.

Covers roughly 60 resource types at the object level and is retained indefinitely. Two limits worth knowing: schedule rotations, escalation levels and shift overrides are not audited, and sign-in events are kept separately from this log.

Returns a single page of at most 25 records, newest first, alongside total_matching so a wider search can be narrowed with the filters. It does not walk the whole log, so a full compliance export belongs on the REST endpoint rather than here.

Requires an API token whose role has the "Audits - read" permission.

list_investigationsB

List AI SRE investigations you can see, newest first.

get_investigationA

Get an investigation's verdict: summary, root cause, confidence, hypotheses, evidence, causal chain and open_questions (what Rootly couldn't verify, so you can check them with tools only you have).

get_investigation_progressA

Follow a running investigation. Returns new steps and tool calls since after_cursor, waiting up to wait_seconds for them. Keep calling with after_cursor=next_cursor until done is true.

start_investigationA

Start an AI SRE investigation on one alert or incident. Then follow it with get_investigation_progress.

cancel_investigationB

Cancel a running investigation.

list_alert_eventsC

List alert_events

create_alert_eventC

Creates a new alert event

get_alert_eventA

Retrieves a specific alert_event by id

update_alert_eventA

Updates a specific alert event. Only alert events with kind 'note' (user-created notes) can be updated. System-generated events are immutable to maintain audit trail integrity.

list_alert_groupsD

List alert groups

create_alert_groupB

Creates a new alert group. Note: For enhanced functionality and future compatibility, consider using the advanced alert grouping with conditions field instead of the legacy group_by_alert_title, group_by_alert_urgency, and attributes fields.

get_alert_groupB

Retrieves a specific alert group by id

update_alert_groupB

Update a specific alert group by id. Note: For enhanced functionality and future compatibility, consider using the advanced alert grouping with conditions field instead of the legacy group_by_alert_title, group_by_alert_urgency, and attributes fields.

list_alert_routesB

List all alert routes for the current team with filtering and pagination. Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.

create_alert_routeB

Creates a new alert route from provided data. Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.

Asynchronous Rule Creation

For organizations with large numbers of routing rules, Rootly supports asynchronous rule processing to improve performance. When enabled, rule creation happens in the background.

Asynchronous processing is also applied automatically, whether or not it is enabled for your organization, when a request carries a rule graph too large to save within the request timeout. Size is measured in total dependent records — rules plus their condition groups, conditions and destinations — and for an update it includes the rules already on the route, not just those in the payload.

Important: Whenever rules are processed asynchronously, the rules list in the API response will not be up-to-date immediately after creation. You should refetch the alert route, or poll the async rule creation status endpoint with the request_id you supplied, to confirm the rules have landed.

If you experience slow operations when managing alert routes with many rules, contact Rootly customer support to enable asynchronous rule processing for your organization.

get_alert_routeA

Get a specific alert route by id. Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.

Optional Parameters

  • show_nested_ids (query parameter): When set to true, the response will include IDs for all nested resources (destinations, condition_groups, conditions). This is useful when you need to reference these nested resources for updates or deletions via PATCH requests.

Example: GET /v1/alert_routes/{id}?show_nested_ids=true

update_alert_routeA

Update a specific alert route by id. Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.

Asynchronous Rule Creation

For organizations with large numbers of routing rules, Rootly supports asynchronous rule processing to improve performance. When enabled, rule updates happen in the background.

Asynchronous processing is also applied automatically, whether or not it is enabled for your organization, when a request carries a rule graph too large to save within the request timeout. Size is measured in total dependent records — rules plus their condition groups, conditions and destinations — and includes the rules already on the route, not just those in the payload, so a small payload against a large route may still be processed asynchronously.

Important: Whenever rules are processed asynchronously, the rules list in the API response will not be up-to-date immediately after update. You should refetch the alert route, or poll the async rule creation status endpoint with the request_id you supplied, to confirm the rules have landed.

If you experience slow operations when managing alert routes with many rules, contact Rootly customer support to enable asynchronous rule processing for your organization.

patch_alert_routeC

Updates an alert route. Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.

list_alert_routing_rulesB

List alert routing rules. Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.

create_alert_routing_ruleA

Creates a new alert routing rule from provided data. Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.

get_alert_routing_ruleA

Retrieves a specific alert routing rule by id. Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.

update_alert_routing_ruleB

Update a specific alert routing rule by id. Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.

list_alert_urgenciesD

List alert urgencies

create_alert_urgencyD

Creates a new alert urgency from provided data

get_alert_urgencyB

Retrieves a specific alert urgency by id

update_alert_urgencyC

Update a specific alert urgency by id

list_alerts_sourcesD

List alert sources

create_alerts_sourceC

Creates a new alert source from provided data

get_alerts_sourceC

Retrieves a specific alert source by id

update_alerts_sourceC

Update a specific alert source by id

list_incident_alertsC

List incident alerts

attach_alertC

Attach alerts to an incident from provided data

list_alertsD

List alerts

create_alertC

Creates a new alert from provided data

get_alertC

Retrieves a specific alert by id

update_alertD

Updates an alert

list_catalog_entitiesD

List Catalog Entities

create_catalog_entityC

Creates a new Catalog Entity from provided data

get_catalog_entityB

Retrieves a specific Catalog Entity by id

update_catalog_entityC

Update a specific Catalog Entity by id

list_catalog_entity_propertiesA

Deprecated: This endpoint is deprecated, please use include=fields on catalog entities or native catalog endpoints (teams, services, functionalities, incident_types, causes, environments) to retrieve field values instead.

List Catalog Entity Properties.

create_catalog_entity_propertyA

Deprecated: This endpoint is deprecated, please use the fields attribute on catalog entities or native catalog endpoints (teams, services, functionalities, incident_types, causes, environments) to set field values instead.

Creates a new Catalog Entity Property from provided data.

get_catalog_entity_propertyA

Deprecated: This endpoint is deprecated, please use include=fields on catalog entities or native catalog endpoints (teams, services, functionalities, incident_types, causes, environments) to retrieve field values instead.

Retrieves a specific Catalog Entity Property by id.

update_catalog_entity_propertyA

Deprecated: This endpoint is deprecated, please use the fields attribute on catalog entities or native catalog endpoints (teams, services, functionalities, incident_types, causes, environments) to set field values instead.

Update a specific Catalog Entity Property by id.

list_catalog_propertiesC

List Catalog Properties - returns catalog_properties type

create_catalog_propertyC

Creates a new Catalog Property - returns catalog_properties type

get_catalog_propertyB

Retrieves a specific Catalog Property by id - returns catalog_properties type

update_catalog_propertyC

Update a specific catalog_property by id - returns catalog_properties type

list_catalogsD

List catalogs

create_catalogC

Creates a new catalog from provided data

get_catalogC

Retrieves a specific catalog by id

update_catalogC

Update a specific catalog by id

list_causesD

List causes

create_causeC

Creates a new cause from provided data

get_causeC

Retrieves a specific cause by id

update_causeC

Update a specific cause by id

get_custom_field_optionA

[DEPRECATED] Use form field endpoints instead. Retrieves a specific custom field option by id

update_custom_field_optionA

[DEPRECATED] Use form field endpoints instead. Update a specific custom field option by id

list_custom_fieldsB

[DEPRECATED] Use form field endpoints instead. List Custom fields

create_custom_fieldB

[DEPRECATED] Use form field endpoints instead. Creates a new custom field from provided data

get_custom_fieldC

Retrieves a specific custom_field by id

update_custom_fieldA

[DEPRECATED] Use form field endpoints instead. Update a specific custom field by id

list_custom_formsD

List custom forms

create_custom_formC

Creates a new custom form from provided data

get_custom_formB

Retrieves a specific custom form by id

update_custom_formC

Update a specific custom form by id

get_dashboard_panelB

Retrieves a specific dashboard panel by id

update_dashboard_panelC

Update a specific dashboard panel by id

list_dashboardsD

List dashboards

create_dashboardC

Creates a new dashboard from provided data

get_dashboardC

Retrieves a specific dashboard by id

update_dashboardC

Update a specific dashboard by id

list_environmentsD

List environments

create_environmentC

Creates a new environment from provided data

get_environmentC

Retrieves a specific environment by id

update_environmentC

Update a specific environment by id

list_escalation_policiesD

List escalation policies

create_escalation_policyC

Creates a new escalation policy from provided data

get_escalation_policyB

Retrieves a specific escalation policy by id

update_escalation_policyC

Update a specific escalation policy by id

list_escalation_levelsC

List escalation levels

create_escalation_levelC

Creates a new escalation level from provided data

list_escalation_levels_pathsC

List escalation levels

create_escalation_level_pathsC

Creates a new escalation level from provided data

get_escalation_levelC

Retrieves a specific escalation level by id

update_escalation_levelB

Update a specific escalation level by id

list_escalation_pathsC

List escalation paths

create_escalation_pathC

Creates a new escalation path from provided data

get_escalation_pathC

Retrieves a specific escalation path by id

update_escalation_pathC

Update a specific escalation path by id

list_form_field_optionsD

List form_field_options

create_form_field_optionC

Creates a new form_field_option from provided data

get_form_field_optionA

Retrieves a specific form_field_option by id

update_form_field_optionC

Update a specific form_field_option by id

get_form_field_placement_conditionB

Retrieves a specific form_field_placement_condition by id

update_form_field_placement_conditionC

Update a specific form_field_placement_condition by id

get_form_field_placementC

Retrieves a specific form_field_placement by id

update_form_field_placementC

Update a specific form_field_placement by id

list_form_fieldsD

List form_fields

create_form_fieldC

Creates a new form_field from provided data

get_form_fieldC

Retrieves a specific form_field by id

update_form_fieldC

Update a specific form_field by id

get_form_set_conditionC

Retrieves a specific form_set_condition by id

update_form_set_conditionC

Update a specific form_set_condition by id

list_form_setsB

List form_sets. Without filter[resource_type], returns incident form sets and, when Problem Management is enabled, problem form sets. Pass filter[resource_type]=incident to list only incident form sets.

create_form_setC

Creates a new form_set from provided data

get_form_setC

Retrieves a specific form_set by id

update_form_setC

Update a specific form_set by id

list_functionalitiesD

List functionalities

create_functionalityC

Creates a new functionality from provided data

get_functionalityC

Retrieves a specific functionality by id

update_functionalityC

Update a specific functionality by id

get_functionality_incidents_chartC

Get functionality incidents chart

get_functionality_uptime_chartC

Get functionality uptime chart

list_workflow_tasksD

List workflow tasks

create_workflow_taskC

Creates a new workflow task from provided data

get_workflow_taskB

Retrieves a specific workflow_task by id

update_workflow_taskC

Update a specific workflow task by id

list_workflow_form_field_conditionsC

List workflow form field conditions

create_workflow_form_field_conditionC

Creates a new workflow form field condition from provided data

get_workflow_form_field_conditionC

Retrieves a specific workflow form field condition by id

update_workflow_form_field_conditionC

Update a specific workflow form field condition by id

list_workflow_groupsD

List workflow groups

create_workflow_groupC

Creates a new workflow group from provided data

get_workflow_groupC

Retrieves a specific workflow group by id

update_workflow_groupC

Update a specific workflow group by id

list_workflow_runsC

List workflow runs

create_workflow_runC

Creates a new workflow run from provided data

list_workflowsD

List workflows

create_workflowD

Creates a new workflow from provided data

get_workflowC

Retrieves a specific workflow by id

update_workflowC

Update a specific workflow by id

list_heartbeatsD

List heartbeats

create_heartbeatC

Creates a new heartbeat from provided data

get_heartbeatB

Retrieves a specific heartbeat by id

update_heartbeatC

Update a specific heartbeat by id

list_incident_action_itemsC

List incident action items

create_incident_action_itemC

Creates a new action item from provided data

get_incident_action_itemsC

Retrieves a specific incident_action_item by id

update_incident_action_itemC

Update a specific incident action item by id

list_all_incident_action_itemsC

List all action items for an organization

list_incident_custom_field_selectionsA

[DEPRECATED] Use form field endpoints instead. List incident custom field selections

create_incident_custom_field_selectionA

[DEPRECATED] Use form field endpoints instead. Creates a new incident custom field selection from provided data

get_incident_custom_field_selectionA

[DEPRECATED] Use form field endpoints instead. Retrieves a specific incident custom field selection by id

update_incident_custom_field_selectionA

[DEPRECATED] Use form field endpoints instead. Update a specific incident custom field selection by id

list_incident_eventsC

List incident events

create_incident_eventC

Creates a new event from provided data

list_incident_form_field_selectionsC

List incident form field selections

create_incident_form_field_selectionC

Creates a new incident form field selection from provided data

get_incident_form_field_selectionC

Retrieves a specific incident form field selection by id

update_incident_form_field_selectionC

Update a specific incident form field selection by id

get_incident_retrospective_stepB

Retrieves a specific incident retrospective step by id

update_incident_retrospective_stepC

Update a specific incident retrospective step by id

get_incident_sub_statusC

Retrieves a specific incident_sub_status by id

update_incident_sub_statusC

Update a specific incident_sub_status by id

list_incident_typesD

List incident types

create_incident_typeC

Creates a new incident_type from provided data

get_incident_typeB

Retrieves a specific incident_type by id

update_incident_typeC

Update a specific incident_type by id

list_live_call_routersD

List Live Call Routers

create_live_call_routerC

Creates a new Live Call Router from provided data

get_live_call_routerB

Retrieves a specific Live Call Router by id

update_live_call_routerC

Update a specific Live Call Router by id

list_meeting_recordingsA

List all meeting recording sessions for an incident. Returns recordings sorted by session number. Each recording represents one bot session with its own transcript, status, and metadata.

list_all_meeting_recordingsA

List meeting recordings across the organization. Returns the current user's standalone recordings plus incident-backed recordings the user can access. Supports filtering by status, platform, and created_by.

get_meeting_recordingB

Retrieve a single meeting recording session including its status, duration, speaker count, word count, and transcript summary.

list_observability_logsA

Search Rootly Observability logs with the Logs explorer query syntax (service:, severity:, index:, trace_id:, @attribute:value, OR inside field groups, - negation, * prefix, free text). Rows are newest first, clipped and redacted. meta.query and meta.window echo the effective query and window. Requires a personal or Global API key (Team API Keys are group-scoped and get 403 unsupported_api_key) or an OAuth token with the obs.logs:read (or all) scope, and the Observability logs read permission. A Global API key uses its service user's Observability role, which starts as the team's default Observability role. Limited to 60 requests per minute per token; on this endpoint the X-RateLimit-* headers report that per-minute budget, not the default API limit. Every 429 returns the errors envelope with code rate_limited and a Retry-After header.

list_observability_patternsA

List log patterns (clustered log templates) with counts against the previous window of the same length. Only service:, severity: and pattern: filters apply; others are echoed in meta.ignored_filters. Each pattern's logs_query drills into matching rows with GET /v1/observability/logs; it is omitted when that query would exceed the /logs length or clause limits. Requires a personal or Global API key (Team API Keys are group-scoped and get 403 unsupported_api_key) or an OAuth token with the obs.logs:read (or all) scope, and the Observability logs read permission. A Global API key uses its service user's Observability role, which starts as the team's default Observability role. Limited to 60 requests per minute per token; on this endpoint the X-RateLimit-* headers report that per-minute budget, not the default API limit. Every 429 returns the errors envelope with code rate_limited and a Retry-After header.

count_observability_logsA

Count logs matching a Logs explorer query, grouped by service, index, severity or an attribute key (@http.status_code). Answers questions like "errors per service in the last 6h" (filter[query]=severity:error, filter[from]=now-6h, group_by=service). Values are ordered by count, largest first; meta.total counts every matching log, and each value's logs_query drills into its rows with GET /v1/observability/logs (null for a blank value, which the query syntax cannot select, or when the drill-down would exceed the query limits: 512 characters or 20 clauses). A log can carry an attribute key more than once (log, resource and scope attributes), so attribute counts can add up to more than meta.total; when logs match but none have the attribute, data is empty and meta.warnings has code attribute_missing. Requires a personal or Global API key (Team API Keys are group-scoped and get 403 unsupported_api_key) or an OAuth token with the obs.logs:read (or all) scope, and the Observability logs read permission. A Global API key uses its service user's Observability role, which starts as the team's default Observability role. Limited to 60 requests per minute per token; on this endpoint the X-RateLimit-* headers report that per-minute budget, not the default API limit. Every 429 returns the errors envelope with code rate_limited and a Retry-After header.

list_on_call_rolesC

List On-Call Roles

create_on_call_roleC

Creates a new On-Call Role from provided data

get_on_call_roleB

Retrieves a specific On-Call Role by id

update_on_call_roleC

Update a specific On-Call Role by id

list_on_call_shadowsC

List shadow shifts for schedule

create_on_call_shadowC

Creates a new on call shadow configuration from provided data

get_on_call_shadowA

Retrieves a specific On Call Shadow configuration by ID

update_on_call_shadowC

Update a specific on call shadow configuration by id

list_override_shiftsD

List override shifts

create_override_shiftC

Creates a new override shift from provided data. If any existing override shifts overlap with the specified time range, they will be automatically deleted and replaced by the new override. This endpoint is idempotent: re-sending an identical override (same user and same start/end time) returns the existing override with a 200 status and does not recreate it.

get_override_shiftA

Retrieves a specific override shift by id

update_override_shiftC

Update a specific override shift by id

get_playbook_taskC

Retrieves a specific playbook_task by id

update_playbook_taskC

Update a specific playbook task by id

list_playbooksD

List playbooks

create_playbookC

Creates a new playbook from provided data

get_playbookC

Retrieves a specific playbook by id

update_playbookC

Update a specific playbook by id

list_pulsesD

List pulses

create_pulseC

Creates a new pulse from provided data

get_pulseA

Retrieves a specific pulse by id

update_pulseC

Update a specific pulse by id

get_retrospective_process_groupC

Retrieves a specific Retrospective Process Group by id

update_retrospective_process_groupC

Update a specific Retrospective Process Group by id

list_retrospective_processesC

List retrospective processes

create_retrospective_processC

Creates a new retrospective process from provided data

get_retrospective_processC

Retrieves a specific retrospective process by id

update_retrospective_processC

Updates a specific retrospective process by id

get_retrospective_stepB

Retrieves a specific retrospective step by id

update_retrospective_stepC

Update a specific retrospective step by id

list_schedule_rotation_active_daysD

List schedule rotation active days

create_schedule_rotation_active_dayC

Creates a new schedule rotation active day from provided data

list_schedule_rotation_usersC

List schedule rotation users

create_schedule_rotation_userC

Creates a new schedule rotation user from provided data

list_schedule_rotationsD

List schedule rotations

create_schedule_rotationC

Creates a new schedule rotation from provided data

get_schedule_rotationC

Retrieves a specific schedule rotation by id

update_schedule_rotationB

Update a specific schedule rotation by id

list_schedulesD

List schedules

create_scheduleC

Creates a new schedule from provided data

get_scheduleC

Retrieves a specific schedule by id

update_scheduleC

Updates a specific schedule by id

list_servicesD

List services

create_serviceC

Creates a new service from provided data

get_serviceC

Retrieves a specific service by id

update_serviceC

Update a specific service by id

get_service_incidents_chartC

Get service incidents chart

get_service_uptime_chartC

Get service uptime chart

list_severitiesD

List severities

create_severityC

Creates a new severity from provided data

get_severityB

Retrieves a specific severity by id

update_severityC

Update a specific severity by id

list_shift_coverage_requestsB

List active shift coverage requests for a schedule.

get_shift_coverage_requestC

Retrieves a specific shift coverage request.

list_status_page_templatesC

List status page templates

create_status_page_templateC

Creates a new template from provided data

get_status_page_templateB

Retrieves a specific status_page_template by id

update_status_page_templateC

Update a specific template event by id

list_status_pagesD

List status pages

create_status_pageC

Creates a new status page from provided data

get_status_pageC

Retrieves a specific status page by id

update_status_pageC

Update a specific status page by id

list_sub_statusesD

List Sub-Statuses

create_sub_statusC

Creates a new Sub-Status from provided data

get_sub_statusC

Retrieves a specific Sub-Status by id

update_sub_statusC

Update a specific Sub-Status by id

list_teamsD

List teams

create_teamC

Creates a new team from provided data

get_teamC

Retrieves a specific team by id

update_teamC

Update a specific team by id

get_team_incidents_chartC

Get team incidents chart

get_user_email_addressesB

Retrieves all email addresses for the specified user

create_user_email_addressC

Creates a new user email address from provided data

list_user_notification_rulesC

List user notification rules

create_user_notification_ruleC

Creates a new user notification rule from provided data

get_user_phone_numbersA

Retrieves all phone numbers for the specified user

create_user_phone_numberC

Creates a new user phone number from provided data

list_usersD

List users

get_current_userC

Get current user

get_userC

Retrieves a specific user by id

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
list_incidents_resourceList recent incidents as an MCP resource for quick reference.
get_oncall_status_resourceShow current on-call status across teams - critical for incident response context.
get_workflow_guide_resourceProvide workflow guidance for common Rootly operations.

TDQS

C2.4/5.0

Scored across 274 tools

Disambiguation2/5

The set is dominated by near-duplicate surface: list_incidents vs search_incidents vs collect_incidents, list_alerts vs get_alert_by_short_id, update_alert_route vs patch_alert_route, list_alert_routes vs list_alert_routing_rules, list_escalation_levels vs list_escalation_levels_paths, list_meeting_recordings vs list_all_meeting_recordings, and a large deprecated custom_field/catalog_entity_property family that shadows the form_field endpoints. A handful of tools (list_incidents/search_incidents/collect_incidents, list_shifts/get_oncall_schedule_summary) carry good disambiguating prose, but most of the 274 entries give an agent no reliable basis for choosing among siblings.

Naming Consistency3/5

The dominant convention is verb_noun snake_case (list_x/get_x/create_x/update_x), which is readable, but deviations accumulate: patch_alert_route alongside update_alert_route, singular/plural mismatches (get_alerts_source, create_alerts_source vs list_alerts_sources, create_alert), and purpose-verb names (search_incidents, collect_incidents, find_related_incidents, suggest_solutions, check_responder_availability, start_investigation). Individually minor, but at 274 tools the irregularities make name-based discovery unreliable.

Tool Count1/5

274 tools is an extreme mismatch for any single MCP surface — it is essentially a whole REST API dumped into one server namespace, including deprecated endpoints the descriptions themselves tell you not to use. An agent cannot hold this tool list in context or select reliably from it; meaningful scoping or curated subsets would be required.

Completeness4/5

Coverage of the incident-management domain is unusually thorough: incidents, alerts and alert routing, on-call schedules/shifts/overrides, escalation policies, retrospects, workflows, forms, catalogs, status pages, audit log and observability all have read/write operations, plus higher-level agent tools (find_related_incidents, suggest_solutions, on-call health). The main gap is the near-total absence of delete/archive operations, which leaves lifecycle dead ends for resources an agent can create but not remove.

Maintenance

ActivityActive
ResponsivenessSyncing