swsd-mcp

swsd_list_my_incidents

Read-onlyIdempotent

Retrieve incidents assigned to you in SolarWinds Service Desk. Filter by state, priority, date, site, category, or search text—then narrow results to your own assignments for a focused view of your open work items.

Instructions

List incidents assigned to the authenticated user. Internally calls swsd_get_me to discover the user's email, then calls /incidents.json with the OTHER server-side filters applied (state, priority, etc.) and narrows the response client-side by assignee.email — because SWSD's /incidents.json endpoint silently ignores assignee_email / requester_email filters (verified 2026-05-08 against the live API: a fake email returns the entire tenant). The client-side filter is the only correct way to scope to a specific user. For broader queries use swsd_list_incidents with assigned_to= (group filtering does work server-side).

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number (1-indexed).
`query`	No	Free-text search across incident title and description. Same async-indexing caveat as solution search — just-created tickets may not appear for a few minutes.
`sites`	No	Filter to incidents at any of these site names (use swsd_list_sites to discover).
`states`	No	Filter to incidents matching ANY of these states (e.g. ["New", "Assigned"]).
`sort_by`	No	Sort key. Default is SWSD-side (typically updated_at desc).
`per_page`	No	Results per page (1-100). SWSD caps at 100.
`categories`	No	Filter to incidents matching ANY of these category names.
`created_to`	No	Filter to incidents created on or before this ISO date or datetime.
`priorities`	No	Filter to incidents matching ANY of these priorities (e.g. ["High", "Medium"]).
`sort_order`	No	Sort direction. Use uppercase per SWSD convention.
`updated_to`	No	Filter to incidents updated on or before this ISO date or datetime. Pair with updated_from for an explicit range.
`departments`	No	Filter to incidents in any of these department names.
`created_from`	No	Filter to incidents created on or after this ISO date or datetime (YYYY-MM-DD or RFC 3339).
`state_is_not`	No	Negative state filter: exclude incidents in any of these states (e.g. ["Resolved", "Closed"] to see only open work).
`updated_from`	No	Filter to incidents updated on or after this ISO date or datetime (YYYY-MM-DD or RFC 3339).
`updated_within`	No	Convenience alias for updated_from. Accepts "Nh" (hours), "Nd" (days), or "Nw" (weeks). Examples: "24h", "7d", "1w", "30d". Ignored if updated_from is explicitly set.
`requester_email`	No	Filter to incidents requested by this email.
`assigned_to_group`	No	Filter to incidents assigned to this group ID. Use swsd_list_groups to find the ID. NOTE: this is GROUP id, not user id.

Output Schema

TableJSON Schema

Name	Required	Description
`scan`	Yes	Honest accounting of the client-side filter: what was scanned vs matched.
`incidents`	Yes
`pagination`	Yes
`assignee_email`	Yes	The authenticated user's email used as the assignee filter (applied client-side).
`applied_filters`	Yes	Echo of the filters applied to this query — empty object if none. Use this to reason about whether the result count reflects your filters or the tenant total. NOTE: assignee_email is applied client-side (post-fetch) because SWSD ignores it server-side.

Schema Changelog

Changes observed during successful MCP inspections.

Changed28 schema fields changedv2.3.1Aug 22, 2026

addedInput schema / properties / categories / items / maxLength
```
Added value: +500
```
addedInput schema / properties / categories / maxItems
```
Added value: +100
```

addedInput schema / properties / created_from / anyOf

Added value: +[
+  {
+    "format": "date",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "format": "date-time",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+    "type": "string"
+  }
+]

removedInput schema / properties / created_from / minLength
```
Removed value: -10
```
removedInput schema / properties / created_from / type
```
Removed value: -"string"
```

addedInput schema / properties / created_to / anyOf

Added value: +[
+  {
+    "format": "date",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "format": "date-time",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+    "type": "string"
+  }
+]

removedInput schema / properties / created_to / minLength
```
Removed value: -10
```
removedInput schema / properties / created_to / type
```
Removed value: -"string"
```
addedInput schema / properties / departments / items / maxLength
```
Added value: +500
```
addedInput schema / properties / departments / maxItems
```
Added value: +100
```
addedInput schema / properties / priorities / items / maxLength
```
Added value: +500
```
addedInput schema / properties / priorities / maxItems
```
Added value: +100
```
addedInput schema / properties / query / maxLength
```
Added value: +2000
```
addedInput schema / properties / requester_email / maxLength
```
Added value: +320
```
addedInput schema / properties / sites / items / maxLength
```
Added value: +500
```
addedInput schema / properties / sites / maxItems
```
Added value: +100
```
addedInput schema / properties / state_is_not / items / maxLength
```
Added value: +500
```
addedInput schema / properties / state_is_not / maxItems
```
Added value: +100
```
addedInput schema / properties / states / items / maxLength
```
Added value: +500
```
addedInput schema / properties / states / maxItems
```
Added value: +100
```

addedInput schema / properties / updated_from / anyOf

Added value: +[
+  {
+    "format": "date",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "format": "date-time",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+    "type": "string"
+  }
+]

removedInput schema / properties / updated_from / minLength
```
Removed value: -10
```
removedInput schema / properties / updated_from / type
```
Removed value: -"string"
```

addedInput schema / properties / updated_to / anyOf

Added value: +[
+  {
+    "format": "date",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "format": "date-time",
+    "maxLength": 64,
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+    "type": "string"
+  }
+]

removedInput schema / properties / updated_to / minLength
```
Removed value: -10
```
removedInput schema / properties / updated_to / type
```
Removed value: -"string"
```
addedInput schema / properties / updated_within / maxLength
```
Added value: +4
```
addedInput schema / properties / updated_within / pattern
```
Added value: +"^[1-9]\\d{0,2}[hdw]$"
```

First observedv2.1.0May 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description discloses behaviors well beyond the safe-read annotations: it internally calls swsd_get_me, filters response client-side, and reveals that /incidents.json silently ignores assignee_email/requester_email filters, supported by a dated verification. This conveys the critical failure mode (fake email returns the entire tenant) that annotations could never express.

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?

The purpose is front-loaded in the first sentence and each subsequent sentence carries essential information: the internal mechanism, the API bug, and the routing to the sibling tool. Slightly dense — the parenthetical verification detail could be trimmed — but nothing is padding.

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?

For a complex 18-parameter tool with no required params and an output schema, the description covers purpose, mechanism, and alternatives well. One notable gap: it does not explain how client-side narrowing interacts with pagination (e.g., per_page could yield fewer results after filtering), which an agent might need to reason about multi-page fetching.

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?

With 100% schema description coverage, the baseline is 3, and the description adds genuine value by warning that assignee_email/requester_email filters are silently ignored server-side — even though requester_email appears in the schema with a functional-sounding description. It also clarifies which params are routed server-side, but it does not explicitly tell agents to avoid the requester_email param.

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+resource+scope: 'List incidents assigned to the authenticated user.' It clearly distinguishes itself from swsd_list_incidents and explains the internal mechanism (via swsd_get_me, filtered client-side), so there is no ambiguity about what this tool does relative to its siblings.

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?

The description explicitly names the alternative ('For broader queries use swsd_list_incidents with assigned_to=<group_id>') and the selection condition, with the added rationale that group filtering works server-side while assignee filtering does not. The agent is told precisely when this tool is the right choice.

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

Install Server