Rootly MCP server

Official

by rootlyhq

Overview Schema Source Related Servers Discussions Admin

Python

Remote

List Audits

list_audits

Read-onlyIdempotent

Read Rootly audit log entries to see who changed which configuration, when, and what changed, with filters for user, source, resource type, and time range.

Instructions

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.

Input Schema

Name	Required	Description
`since`	No	Only changes at or after this ISO 8601 timestamp or date.
`until`	No	Only changes at or before this ISO 8601 timestamp or date.
`source`	No	Where the change came from: 'web', 'api', 'mobile', 'slack', 'scim' or 'oauth'.
`user_id`	No	Only changes made by this Rootly user ID.
`item_type`	No	Restrict to one resource type, e.g. 'Schedule', 'GeniusWorkflow', 'EscalationPolicy', 'ApiKey', 'Role', 'Membership'. Leave blank for every type.
`api_key_id`	No	Only changes made with this API key ID.
`max_results`	No	Maximum records to return. Max: 25.
`include_full_object`	No	Include each record's full object state alongside the diff. Off by default because it is the bulk of the payload.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.0Nov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavioral limits: approximately 60 resource types, indefinite retention, exclusions for schedule rotations, escalation levels and shift overrides, and separate handling of sign-in events. It also explains pagination behavior, the 25-record page cap, newest-first ordering, total_matching, and the required Audits-read API permission.

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

Conciseness5/5

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

The description is front-loaded with the core purpose and examples, then covers coverage limits, return behavior, and auth requirements in a compact structure. Despite being several paragraphs, each section adds decision-relevant information.

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?

The tool has rich annotations, full schema coverage, and an output schema, so the description does not need to explain return fields. It still supplies the missing operational context an agent needs: audit coverage gaps, pagination limits, when to avoid this tool, and required permissions.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents the meaning of all eight parameters. The description adds useful context about filters narrowing a wider search and the page-size ceiling, but it does not add per-parameter semantics beyond what the schema provides.

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: reading the Rootly audit log, including who changed which configuration object, when, and what changed. It clearly distinguishes this from a full compliance export by saying the REST endpoint is the right place for that, and it scopes coverage to object-level audit records.

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 use cases such as answering who changed an escalation policy, checking a workflow's prior state, and collecting compliance evidence. It also names when not to rely on this tool, specifically for a full compliance export, which should use the REST endpoint instead.

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

Deploy Server