Orchestra MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Update an incident

update_incident

Change an incident's status, severity, name, assignee or subscribers. A field left out of the request body keeps its stored value, and sending assignee as null unassigns.

Instructions

Change an incident's status, severity, name, assignee or subscribers. A field left out of the request body keeps its stored value, and sending assignee as null unassigns. An assignee or subscriber must be able to view the incident or be in the account's Slack workspace.

Returns the detail shape - a patch writes timeline rows of its own, so the caller's event count is out of date the moment the change lands.

Input Schema

Name	Required	Description
`name`	No
`status`	No
`assignee`	No
`severity`	No
`description`	No
`incident_id`	Yes	Incident ID.
`subscribers`	No
`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.

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

addedInput schema / properties / assignee

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedInput schema / properties / name / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 60,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / subscribers

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 20,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedv0.1.0Sep 26, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses non-obvious behavior: omitted fields retain stored values, null assignee unassigns, assignees/subscribers must be able to view the incident or belong to the workspace, and the patch writes its own timeline rows so the caller's event count goes stale immediately. That side-effect warning is exactly the kind of context annotations cannot carry.

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?

Three sentences, front-loaded with the field scope, then mutation semantics, then permission constraint and side effect. No filler; every clause adds actionable information.

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

Completeness4/5

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

An output schema exists so return values need not be explained, and the description still adds the stale-event-count caveat plus the permission prerequisite. It falls short only on the undocumented `description` parameter and the replacement semantics of the subscribers list.

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?

With only 25% schema description coverage, the description does useful work by naming the mutable fields and explaining partial-update and null-unassign semantics. However it omits the `description` parameter entirely and does not clarify null behavior for fields other than `assignee` or how the `subscribers` array (replace vs. append, maxItems 20) is treated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Change an incident's status, severity, name, assignee or subscribers') and enumerates the mutable fields, so the scope is unambiguous. It does not explicitly differentiate itself from near-neighbors like update_incident_settings, mute_incident, or merge_incidents, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by the patch semantics ('a field left out of the request body keeps its stored value'), which tells the agent how to call it, but there is no explicit when-to-use/when-not guidance or named alternative such as update_incident_settings for configuration changes.

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

Deploy Server