Orchestra MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Merge incidents

merge_incidents

Merge up to five named incidents into a target incident at one level, rejecting merges that would create deeper nesting.

Instructions

Merge the incidents named in the request body into the incident in the path. Merging is one level deep - merging an incident that already has a parent, or naming one that has incidents merged into it, is rejected rather than nesting further.

agentSessionId is optional, and only Orchestra agent sessions should set it. When set, the merge is attributed to Orchestra AI and linked to that session, and the session may only merge the incident it was started for, into an older incident.

Input Schema

Name	Required	Description
`incidentIds`	Yes
`incident_id`	Yes	Incident ID to merge the named incidents into.
`agentSessionId`	No	Optional, and only for Orchestra agent sessions, which read it from the ORCHESTRA_AGENT_SESSION_ID environment variable. When set, the merge is attributed to Orchestra AI and linked to that session, which may then only merge the incident it was started for, into an older incident.
`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.

Changed1 schema field changedv2026.10.29-0Oct 31, 2026

addedInput schema / properties / agentSessionId

Added value: +{
+  "anyOf": [
+    {
+      "format": "uuid4",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Optional, and only for Orchestra agent sessions, which read it from the ORCHESTRA_AGENT_SESSION_ID environment variable. When set, the merge is attributed to Orchestra AI and linked to that session, which may then only merge the incident it was started for, into an older incident."
+}

First observedv0.1.0Sep 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries most of the weight and does so: it discloses the one-level-deep rejection rule and the agentSessionId attribution and scope restriction (a session may only merge its own incident into an older one). What it omits is the effect on the source incidents after a successful merge.

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?

Two short paragraphs, front-loaded with the core action, then the constraint, then the optional-parameter caveat. Every sentence carries information. Minor redundancy: the agentSessionId paragraph closely mirrors the schema description of the same field.

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?

An output schema exists, so return values need not be explained. With 4 parameters at 75% coverage and annotations covering mutation safety, the description supplies exactly what is missing: the nesting restriction and the session-scoped attribution rule. Nothing needed to invoke it correctly is absent.

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 75% and both incident_id and agentSessionId already have schema descriptions. The description still adds value by explaining the practical consequence of agentSessionId — attribution to Orchestra AI plus a restriction on which incident that session may target — and by framing incidentIds as the merge sources. It never mentions the maxItems 5 cap, though the schema does.

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?

Opens with a specific verb+resource: merge the incidents named in the request body into the incident in the path. The direction of the merge (sources into target) is unambiguous. It stops short of naming the sibling it inverts, unmerge_incidents, so sibling differentiation is only implicit.

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?

Gives real constraint guidance — merging is one level deep, and merging an incident that already has a parent or one that has children is rejected. That tells the agent when the call will fail, but there is no explicit statement of when to prefer this over unmerge_incidents or how to prepare incidents first.

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

Deploy Server