Rootly MCP server

Official

by rootlyhq

Overview Schema Source Related Servers Discussions Admin

Python

Remote

List Incident Post Mortems

list_incident_post_mortems

Read-only

Browse and filter incident retrospectives by status, severity, team, service, or date to review summaries, causes, impact, and action items. Use when you need multiple post-mortems rather than one known document.

Instructions

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.

Input Schema

Name	Required	Description	Default
`sort`	No	Sort order, e.g. '-created_at' for newest first	-created_at
`status`	No	Filter by status, e.g. 'published' or 'draft'
`severity`	No	Filter by severity slug
`team_ids`	No	Comma-separated team IDs
`page_size`	No	Retrospectives per page (default 5, max 10). Each one carries its document minus any Timeline, cut at a size limit if still long, so a large page is expensive; narrow with the filters instead of raising this.
`page_number`	No	Page number, 1-indexed
`service_ids`	No	Comma-separated service IDs
`created_after`	No	Only retrospectives created at or after this ISO date
`created_before`	No	Only retrospectives created at or before this ISO date

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.0Nov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond what readOnly/destructive/openWorld annotations convey: it discloses that a recognized Timeline is dropped and flagged via `timeline_omitted`, that remaining content is still capped and flagged with `content_truncated` plus real `content_chars`, and that a large page is expensive. These are the exact behavioral traits that would otherwise cause silent data-loss surprises for a browsing agent.

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?

Purpose and the key behavior (Timeline omission) are front-loaded, and the paragraph structure maps cleanly to purpose / content shape / filtering. It is slightly long and repeats the `get_incident_retrospective` recommendation in two places, which could be consolidated into one sentence without loss.

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?

For a 9-parameter, zero-required listing tool with an output schema and read-only annotations, this covers the remaining gaps: what is returned, what is intentionally stripped and how that's signalled, page-cost guidance, and the alternative tool. Nothing an agent needs in order to call it correctly is missing.

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 coverage is 100%, so the baseline is 3. The description adds useful framing that filtering happens upstream (i.e., these are server-side filters) and that no free-text parameter exists, but it doesn't add per-parameter semantics like sort syntax or date format beyond what the schema already documents.

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?

States a specific verb and resource ("Browse retrospectives across incidents") and immediately grounds it in concrete query shapes ("last five retrospectives", "published ones for this team since June"). It explicitly positions itself against `get_incident_retrospective`, so an agent can distinguish the list/browse case from the single-document case without opening either 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?

Explicit routing: use `get_incident_retrospective` when the incident is already known or when the whole document with Timeline is needed. It also states a meaningful when-not (free-text search is not offered here) and explains why, so an agent won't try to force a search-shaped query through this tool. Filter scope (status, severity, team, service, dates) is declared up front.

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

Deploy Server