Orchestra MCP Server

Official

by orchestra-hq

Overview Schema Source Related Servers Discussions Admin

Python

Remote

List incidents

list_incidents

Read-only

List incidents for the workspace the credential resolves to, most severe first, with merged children nested under their parent.

Instructions

List incidents for the workspace the credential resolves to, most severe first, with merged children nested under their parent.

Filters apply to top-level incidents only - a child is always returned alongside its parent, so a filtered list still shows the full incident rather than part of one. Use name to filter incidents by a case-insensitive substring match on the incident name. Use sort_column and sort_direction to sort top-level incidents by a single column instead; merged children keep the default order.

Input Schema

Name	Required	Description	Default
`name`	No	Filter by a case-insensitive substring match on the incident name.
`page`	No	Page number. Must be greater than or equal to 1.
`status`	No	Filter by status. Comma-separated values are supported.
`severity`	No	Filter by severity. Comma-separated values are supported.
`page_size`	No	Number of items per page. Defaults to 10; maximum 100.
`sort_column`	No	Column used to sort incidents. Defaults to open, most severe first.
`sort_direction`	No	Sort direction. Ignored unless `sort_column` is set.	desc
`include_archived`	No	Include archived incidents. Defaults to false.
`X-Orchestra-Account-Id`	No	Act on this account rather than the one the credential resolves to. Omit it to use the credential's own account. An API key is issued to a single account, so it may only name that account; an OAuth token may name any account its grant covers.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2026.10.12-0Oct 14, 2026

addedInput schema / properties / sort_column

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "severity",
+        "name",
+        "created_at",
+        "updated_at"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Column used to sort incidents. Defaults to open, most severe first."
+}

addedInput schema / properties / sort_direction

Added value: +{
+  "default": "desc",
+  "description": "Sort direction. Ignored unless `sort_column` is set.",
+  "enum": [
+    "asc",
+    "desc"
+  ],
+  "type": "string"
+}

First observedv0.1.0Sep 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest. It adds real behavioral context: default ordering by severity, nested merged children, and the key invariant that a child is always returned alongside its parent so a filtered list still shows complete incidents. That invariant is the kind of non-obvious trait an agent could not infer from the schema alone.

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?

Front-loads the core behavior (what is returned and in what order) in the first sentence, then devotes precisely-scoped sentences to filter and sort semantics. No redundant restatement of name/schema fields; every sentence earns its place.

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?

With a full-coverage input schema, an output schema, and readOnly annotations, the description only needs to supply the semantics the structured fields can't express (ordering, nesting, filter scope), and it does so. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so baseline is 3; the description goes beyond it by describing the interaction between `sort_column`/`sort_direction` (single column, children keep default order) and the scoping of filters to top-level incidents. It doesn't restate `page`, `page_size`, `status`, `severity`, or the account header, which 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+resource (list incidents) plus meaningful scope details: the credential's workspace, most-severe-first ordering, and merged children nested under parents. This distinguishes it from get_incident (single incident) and list_incident_events without needing to open a schema.

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?

Explicitly explains how to drive the tool: use `name` for substring filtering, and `sort_column`/`sort_direction` to sort by a single column instead. It also clarifies that filters apply to top-level incidents only. It does not name sibling alternatives (e.g. get_incident) or state when not to use it, keeping it short of a 5.

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

Deploy Server