swsd-mcp
This MCP server lets an MCP client read and manage SolarWinds Service Desk (SWSD) records using the user's JWT.
Check server info/health and identify the authenticated user.
Search, list, and retrieve incidents, comments, tasks, problems, changes, releases, assets/CMDB records, contracts, purchase orders, vendors, risks, time entries, KB solutions, catalog items, users, groups, sites, departments, roles, custom fields, and audit history.
Create and update incidents, assign tickets, change states, add comments, manage tasks, log time, create problems/changes/releases/assets, submit service requests, author KB articles, and delete records where enabled.
Upload and download attachments, with byte limits and opaque references.
Use triage/reporting helpers such as SLA risk, ticket stats, my queue, change calendar, and custom-field discovery.
Respect configured profiles/tool sets and write modes (live, dry-run, disabled), with guarded delete confirmation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@swsd-mcp show me incident 60310"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
swsd-mcp
MCP server for SolarWinds Service Desk (SWSD / Samanage). Works with any Model Context Protocol client to handle tickets, service requests, knowledge-base work, change/release workflows, assets/CMDB context, procurement records, risks, time entries, and attachments using each user's own SWSD JSON Web Token. See the client compatibility matrix for transport and widget guidance.
📖 Full docs: mcp-swsd.pages.dev
The server holds zero credentials at rest. HTTP tokens are supplied per request; stdio keeps the configured token for the process lifetime. The Windows companion saves the user's JSON Web Token in Windows Credential Manager, and the MCP server does not save it to disk.
Windows companion app
SWSD for AI apps installs swsd-mcp on this PC and chooses which tools your AI apps can use. Your JSON Web Token is saved in Windows Credential Manager. The Windows companion app page has the full guide. Pictures use example data.
Set up this PC
Install the Windows
swsdplugin.Start a new local chat and ask to set up SWSD on this computer.
On Set up, select Install tools. This setup needs Node.js 24.15 or newer within version 24, or Node.js 26 or newer, with npm. Node 25 is not supported. If Node.js is missing or outside those versions, setup can install the current Node.js LTS through winget after you confirm. Windows may ask for administrator approval. Reopen the app when installation finishes.
Choose United States or Europe, paste your JSON Web Token, and select Test. The field stays masked. ? and Where do I find my token? show where to copy it in SWSD. Generate a JSON Web Token only when none is shown.
Choose Triage (22 tools), Agent (52), Knowledge (17), Operations (146), or a saved custom profile. The choice is saved immediately. Quit and reopen the AI app, then start a new chat so the server loads that profile.
Open it again from SWSD Setup on the Start menu.
Install the tools, then add your JSON Web Token.
Connection and status
Home shows Node.js, the installed tools, your JSON Web Token, region, profile, and updates. The token stays masked. Test checks the connection and marks it Verified. Changing United States or Europe clears that check until you select Test again. Repair reinstalls the tools. Remove saved JSON Web Token deletes the credential on this PC. Quit the AI app afterwards. The token remains valid in SWSD until it is revoked there.
Tool guide
Tools is a searchable catalog of all 146 tools for the profile you select. Ctrl+F focuses search, which matches the friendly name, the tool id, and the description. Each tool is marked Read, Edit, or Delete. Read looks up a record, Edit creates or changes one, and Delete always previews the record first. Tools outside the profile stay grouped apart until you search. A match can point you to a profile that includes it, and you can switch to that profile from the detail. Select a tool to see where it is available and copy an example prompt.
See which tools a profile includes, and copy an example prompt.
Custom profiles
On Tools, open Custom profiles to name a set and check the tools your AI apps may use. Save profile makes that set active and adds it to the Home and Tools pickers. Rename, Delete, and New manage the set. Deleting the active custom profile returns you to Agent.
Export JSON saves the profile as a file you can share. Import JSON loads a file into the builder. Select Save profile to start using an import. The file is the version-1 profile in Custom profiles: name, version, tools, and an optional description. Extra fields are rejected. Names that match Triage, Agent, Knowledge, Operations, or Full are reserved.
Choose the tools in a named profile, then save or share it as JSON.
Appearance
Appearance follows Match Windows, or you can choose Light, Dark, or a named theme. The choice is saved on this PC. Named themes are Dracula, Catppuccin Mocha, Catppuccin Macchiato, Catppuccin Frappe, Catppuccin Latte, Nord, Gruvbox Dark, Gruvbox Light, Tokyo Night, Tokyo Night Storm, Tokyo Night Day, One Dark, One Light, Solarized Dark, Solarized Light, Rosé Pine, Rosé Pine Moon, Rosé Pine Dawn, Monokai, Material Ocean, GitHub Dark, and GitHub Light.
Updates, diagnostics, and release notes
Check now looks for a newer published release. When one is available, Update installs it after checking the package, and keeps your current tools if the install does not finish. What's new opens the release notes on this PC, including changes that are not published yet. Copy report copies a diagnostics summary for support: versions, whether tools are installed, the profile, the region, whether a credential is saved, display scale, and a short redacted log. The report does not include your token.
Help and issue links
Report a bug and Request a feature open the GitHub forms with the app version, server version, Windows version, and profile filled in.
Related MCP server: TDX MCP Server
Quick start
You need:
An MCP client installed: the client must support stdio or Streamable HTTP (compatibility matrix)
Node.js 24.15+ or Node.js 26+ for local npm/
npxinstalls. Node 25 is not supported.An SWSD JSON Web Token: in Setup → Users & Groups → Users, open your User detail page and copy the existing token. Use Actions → Generate JSON Web Token only when no token is shown (SWSD administrator rights required to generate)
VS Code
Open the Command Palette: Ctrl+Shift+P on Windows/Linux or Shift+Command+P on macOS.
Run MCP: Add Server....
Install with either supported local option:
Command (stdio): enter
npx -y swsd-mcp.NPM Package: enter
swsd-mcp, confirm that the publisher ismikimatsub, then select Allow.
Name the server
swsd, then choose Global for your VS Code profile or Workspace for the current project.
Other stdio clients
1. Add the config
Claude Desktop and Cursor use this JSON shape. Add the swsd entry inside the mcpServers object in your client's config file:
{
"mcpServers": {
"swsd": {
"command": "npx",
"args": ["-y", "swsd-mcp"],
"env": {
"SWSD_TOKEN": "your-jwt-here",
"SWSD_BASE_URL": "https://api.samanage.com"
}
}
}
}Replace your-jwt-here with your token. EU tenants use https://apieu.samanage.com instead. To customize behavior, add any configuration variable (most common: SWSD_PROFILE to choose the tool set) into the same env block.
2. Drop it in the right file
Client | Config file path |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Claude Code |
|
Cursor |
|
Continue, Cline, other clients | check your client's docs for its configuration format |
Create the file if it doesn't exist. Then restart your client.
Windows plugin setup: after installing the Windows swsd plugin, start a new local chat and ask to set up SWSD on this computer. Reopen setup from the Windows Start menu. The WPF settings window has Home and Tools tabs.
Appearance offers Match Windows, Light, Dark, and named themes such as Dracula, Catppuccin, Nord, Gruvbox, and Tokyo Night, saved on this PC.
Browse tools by area, search with Ctrl+F, inspect Read/Edit/Delete badges and
example prompts, and select a profile to change the available tool set. The ?
beside JSON Web Token shows the SWSD User detail screen and Actions →
Generate JSON Web Token, used only when no token is shown. Test verifies the
connection and stores the JSON Web Token in Windows Credential Manager. Home also provides tool installation/repair, update checks, and US/EU region selection. The picker offers Triage, Agent, Knowledge, Operations, and saved custom profiles. On the Tools page, build a custom profile, then save, rename, delete, import, or export it. Other MCP clients still use the server configuration below (SWSD_PROFILE=custom). Tools and settings live under %LOCALAPPDATA%\swsd-mcp. Restart the desktop app and start a new chat after a profile change.
The Windows companion app section above is the setup and day-to-day guide, with the full page on the docs site.
Claude Code shortcut: skip editing the file by hand. This saves a private entry for the current project in ~/.claude.json:
claude mcp add swsd --env SWSD_TOKEN="your-jwt-here" --env SWSD_BASE_URL="https://api.samanage.com" -- npx -y swsd-mcpMicrosoft Copilot Studio: different path. Copilot Studio can't spawn local processes, so it needs an HTTP-transport server. See copilot-studio/README.md and the Azure Container Apps recipe.
3. Verify it works
In your MCP client, ask:
"Use swsd to check if you can connect."
The agent should call swsd_health_check and report success. If it does, you're set up. Try a few more:
"Show me incident 60310": incident reference tools accept either the internal id (≥7 digits) or the human-facing number visible in the SWSD UI (≤6 digits); other tools may require internal ids.
"List incidents updated in the last 7 days":
updated_within: "7d"(also"24h","1w","30d")."What tickets are assigned to me?":
swsd_list_my_incidentsresolves your email from the JWT and user record, then filters each fetched page locally. Scan metadata reports any remaining candidates.
Tools (146 across 15 categories)
Category | Tools |
Utility |
|
Incidents |
|
Comments |
|
Tasks |
|
Problems |
|
Change & Release |
|
Assets & CMDB |
|
Procurement & Risk |
|
Time tracking |
|
Attachments |
|
Solutions / KB |
|
Service Catalog |
|
Lookups |
|
Custom fields |
|
Audits |
|
Each tool's input schema and description are discovered by your MCP client at runtime; calls return structured results. See the Tools reference for full per-tool documentation.
MCP Apps widgets (rich UI)
Ten interactive UI bundles ship with read tools using the MCP Apps extension. On hosts that support MCP Apps, the tool returns a rendered widget alongside the structured response. On hosts without a widget surface, the same tools return their normal structured payload.

Example: swsd_list_incidents rendering the incident-list widget. Synthetic data; no real tenant info. See the full gallery for screenshots of all ten widgets.
Tool | Widget | What it renders |
|
| Single-record card (description, due date, SLA-violation count, resolution) |
|
| Knowledge-base article with sanitized HTML body |
|
| Filterable, sortable table |
|
| Risk-count chips + color-coded table with due countdowns |
|
| Vertical conversation with author chips and private badges |
|
| Timeline grouped by day with action chips and field diffs |
|
| Form that submits via |
|
| Searchable explorer with scope/module filters |
|
| Local-time day sections for changes/releases with shared-CI/group conflict badges |
|
| Summary tiles, median resolution time, and state/priority/assignee/category breakdowns |
swsd_change_calendar is read-only and available in Agent and Operations, or a custom selection.
It defaults to the next 30 days from UTC midnight today and scans up to three
100-row pages per kind (maximum ten pages). All window, state, assignee, group
and name-search filters are client-side; only pagination is sent to SWSD.
The response reports scanned pages/rows, unscheduled records and truncation.
Conflicts cover returned items only; unscanned or filtered-out records can hide
additional conflicts. Touching window edges do not overlap; missing ends assume
one hour. See the tool reference
for inputs, UTC window semantics and scan accounting.
See the Widgets reference for screenshots and per-widget detail.
Configuration
Most users only need SWSD_TOKEN and SWSD_BASE_URL:
Variable | Default | Notes |
| None | Required for stdio. Your SWSD JSON Web Token; HTTP uses a per-request authorization header. |
|
| EU tenant: |
|
|
|
| (empty) | With |
| (empty) | With |
|
|
|
|
| Download byte limit, 1–26214400. Checked before and during streaming; base64 adds about one third to response size. |
| None | Optional real-path boundary for local |
For the full env-var reference (HTTP transport, retries, rate limits, allowlists), see Configuration.
Profiles
Profiles control which tools are registered at startup. Cannot be changed mid-session.
Profile | Intent | Tool count |
| Read-heavy first-line support + commenting | 22 |
| Full ticket-handler workflow (default) | 52 |
| KB-author workflow + incident reads | 17 |
| Agent workflow plus change/release, ITAM, CMDB, procurement, and risk context, plus every KB authoring tool | 146 |
| Explicit selection from the tool list or a JSON profile file | Varies |
operations includes every tool, including KB authoring and guarded deletes. The legacy SWSD_PROFILE=full value is accepted as an alias for operations and emits one deprecation notice on stderr per process.
Custom profiles
Set SWSD_PROFILE=custom and supply SWSD_TOOLS, SWSD_PROFILE_FILE, or both:
SWSD_PROFILE=custom
SWSD_TOOLS="swsd_get_server_info, swsd_list_incidents"
SWSD_PROFILE_FILE=./profiles/desk.jsonThe JSON file uses this format:
{
"name": "Synthetic desk",
"version": 1,
"description": "Incident lookup and SLA review",
"tools": ["swsd_get_incident", "swsd_sla_risk"]
}Both sources are unioned and deduplicated. Unknown names produce a warning listing the skipped names on stderr. A selection with no valid tools is a startup error, even if extras are configured. No tools are included automatically. These two variables only select tools when the profile is custom.
Paths may be absolute or relative to the server's startup working directory; symlinks are resolved. Files must be regular JSON files, at most 256 KiB, and are never imported or evaluated. The required name is 1–80 characters (letters, digits, spaces, _, ., -, starting with a letter or digit); version must be 1; optional description is at most 2,048 characters. The combined input accepts at most 512 tool entries, before deduplication. File tool names are 1–128 characters; extra JSON properties are rejected. The JSON Schema matches these file rules; tool availability and a nonempty union are checked at startup.
Prompts and widgets appear only when all their required tools are selected. The catalog form requires both swsd_get_catalog_item and swsd_create_service_request; without the latter, the lookup remains available as text and structured data. Custom selections are fixed at startup; restart after changing the file or environment.
Delete tools require operations or explicit inclusion in the custom CSV/file; SWSD_ENABLE_EXTRAS cannot add them to other profiles. Call a delete tool without confirmation to preview, then re-call after the user confirms with confirm: true and a matching confirm_id. Dry-run always previews; disabled blocks. SWSD_WRITE_MODE and SWSD permissions still apply.
Use SWSD_ENABLE_EXTRAS=swsd_search_solutions,swsd_get_solution to add specific tools on top of a profile.
Hosting an HTTP server (advanced)
Quick Start above runs swsd-mcp on your own machine: your MCP client spawns it on demand via npx. Most users stop there.
Set up an HTTP-mode server only if you need:
Microsoft Copilot Studio integration: Copilot Studio can't spawn local processes
One shared instance for a team: one deploy, many users, each providing their own token per-request
Stricter network control: private VNet, IP allowlist, custom domain
The Docker image supports container hosting, including Azure Container Apps and a Docker-capable VM. Main builds publish :latest and :sha-XXXXXXX; release tag builds publish :X.Y.Z and :X.Y. See Deployment for the full guide and the Azure Container Apps recipe (recommended for Copilot Studio; scale-to-zero pricing).
Documentation
SECURITY.md: vulnerability reporting via GitHub Security Advisoriesdocs/SECURITY-POSTURE.md: security controls, supply-chain hardening, verification methodsCONTRIBUTING.md: bug reports, PR review criteria, local development setupCHANGELOG.md: version historycopilot-studio/: Microsoft Copilot Studio Swagger connector specs and import guidedocs/deployment/: cloud deployment recipes
License
MIT: see LICENSE. Provided "as is" without warranty.
Trademarks
SolarWinds, Samanage, and Service Desk are trademarks of SolarWinds Worldwide, LLC. This project is not affiliated with, endorsed by, or sponsored by SolarWinds. It wraps the publicly documented SWSD REST API.
Available Tools
52 toolsswsd_add_incident_commentA
Add a comment to a SWSD incident. Set is_private: true to make the comment internal-only (default false = visible to the requester). To edit a comment after posting, use swsd_update_comment. WRITE — does not retry on transient failure.
Inputs: body (required), incident_id (required), is_private.
swsd_assign_incidentADestructive
Assign an SWSD incident to an agent by email. Safer wrapper around swsd_update_incident — narrows the agent decision surface to "who gets this ticket." Use swsd_list_users with available_for_assignment_only=true to find valid assignees first. WRITE — does not retry on transient failure.
Inputs: id (required), assignee_email (required).
swsd_change_calendarARead-onlyIdempotent
Show a UTC change/release calendar widget and shared-CI/group scheduling conflicts. Fetches up to max_pages per kind (default 3, maximum 10); ONLY page/per_page are sent to SWSD. All date, state, assignee, group and name-search filters are client-side, over scanned rows only. Defaults to today at UTC midnight through 30 days later. Windows use overlap, with an exclusive end; missing, invalid or non-positive planned ends use start + 1 hour. Rows without a valid planned start are excluded and counted as unscheduled. Conflicts cover only returned items, not the whole tenant. At most 200 conflict details are returned; conflict_count counts all pairs and conflicts_truncated flags omitted details. scan reports pages_fetched per kind, rows_scanned, unscheduled and truncated; when truncated is true, unscanned records may contain more matches or conflicts. No server-side search or date ordering is assumed.
Inputs: to, from, kinds, query, +6 more. Returns: days, scan, items, window, +4 more
swsd_create_incidentA
Create a new SWSD incident. Required: name. Strongly recommended: description, requester_email, priority, category_name. The created incident's ID is returned for follow-up calls (swsd_assign_incident, swsd_add_incident_comment, etc.). WRITE — does not retry on transient failure; the agent should verify with swsd_get_incident before retrying. To set tenant-specific custom field values, pass custom_fields: [{name, value}] — call swsd_describe_custom_fields first to discover field names and (for Dropdowns) allowed values. Validated for Text, Dropdown, Number, Checkbox, and Date types.
Inputs: name (required), priority, site_name, description, +5 more.
swsd_create_incident_taskA
Create a new sub-task on a SWSD incident. Required: incident_id, name. Optional: description (plain text or HTML), due_at (ISO 8601), assignee_email. The created task is returned for follow-up calls. WRITE — does not retry on transient failure.
Inputs: name (required), incident_id (required), due_at, description, +1 more.
swsd_create_problemA
Create a new SWSD problem (ITIL problem record). Required: name. Strongly recommended: description, priority, category. The created problem's id is returned for follow-up calls. Use this when promoting a recurring incident to a problem record so root-cause analysis and known-error tracking can be tied to multiple incidents. WRITE — does not retry on transient failure; the agent should verify with swsd_get_problem before retrying.
Inputs: name (required), category, priority, description, +3 more.
swsd_create_service_requestA
Submit a SWSD catalog request, creating an incident with is_service_request: true (auto-set by SWSD on this endpoint) and the supplied form variable values. Use swsd_list_catalog_items to find the right catalog_item_id and swsd_get_catalog_item to inspect its variables before filling. Each request_variables entry needs custom_field_id (= the catalog item variable's id) and value (stringified to match the variable's kind — for dropdowns, one of the options choices). The created incident's id is returned for follow-up calls (swsd_get_incident, swsd_assign_incident, etc.). WRITE — does not retry on transient failure; the agent should verify with swsd_get_incident before retrying. To set tenant-specific custom field values, pass custom_fields: [{name, value}] — call swsd_describe_custom_fields first to discover field names and (for Dropdowns) allowed values. Validated for Text, Dropdown, Number, Checkbox, and Date types.
Inputs: catalog_item_id (required), description, custom_fields, requester_email, +1 more. Returns: dry_run, request, incident
swsd_describe_custom_fieldsARead-onlyIdempotent
List the SWSD tenant's custom-field schema. Returns id, name, type (e.g. "Text", "Dropdown", "Date"), required, scope, module, allowed values for dropdown fields, and help_text. Useful for understanding tenant configuration and documenting integrations. Default returns active fields only — pass active_only: false to see retired ones too. Filter by scope or module to narrow the surface (the tenant may have 100+ fields). v2 NOTE: custom field WRITES are now supported via the custom_fields parameter on swsd_create_incident, swsd_update_incident, swsd_create_solution, and swsd_update_solution. Pass custom_fields: [{name, value}] (name-keyed for portability). Validated field types: Text, Dropdown, Number, Checkbox, Date. Multi_picklist and User-type writes are not yet supported — set those via the SWSD UI.
Inputs: page, scope, module, per_page, +1 more. Returns: pagination, custom_fields
swsd_get_catalog_itemARead-onlyIdempotent
Get a single SWSD catalog item by id, including its variables (the form schema for service requests). Use the variables to know which fields to populate when submitting a service request. Each variable has an id (pass through to the create-service-request tool as custom_field_id), a name, a kind (free_text / drop_down_menu / multi_select / date / user / null), and options (newline-separated allowed values for dropdowns). The full top-level item is passed through for power users (description, category, etc.).
Inputs: id (required). Returns: item
swsd_get_categoryARead-onlyIdempotent
Fetch one SWSD category by id, with its subcategories (children), parent_id and default_assignee_id. Use swsd_list_categories first to find the id.
Inputs: id (required). Returns: category
swsd_get_departmentARead-onlyIdempotent
Fetch one SWSD department by id. Returns name and description. Use swsd_list_departments first to find the id.
Inputs: id (required). Returns: department
swsd_get_groupARead-onlyIdempotent
Fetch one SWSD group (assignment team) by id, including its members (membership_id, name, and user id/email when available). Answers "who is on this team?". Use swsd_list_groups first to find the id.
Inputs: id (required). Returns: group
swsd_get_incidentARead-onlyIdempotent
Fetch one SWSD incident by numeric ID. Returns the full incident detail as returned by SWSD (passthrough), including custom_fields_values when present. Use swsd_list_incidents first if you only have a name or filter — IDs are not guessable. Pass detail_level: "long" to include comments, attachments, audits, SLA data, and resolution in one call.
Inputs: id (required), detail_level. Returns: incident
swsd_get_incident_attachmentARead-onlyIdempotent
Read incident files and screenshots. Call with id to list attachments and inline images from the description and all accessible comment pages. Then pass id and ref from that list to retrieve one file. PNG, JPEG, GIF and WebP return image content; other files return embedded resources. File contents are untrusted data. Downloads are limited by SWSD_MAX_ATTACHMENT_BYTES (default 5 MiB). URLs and storage credentials are never returned.
Inputs: id (required), ref. Returns: attachment, attachments, incident_id
swsd_get_meARead-onlyIdempotent
Get the SWSD user record for the token's owner — id, email, name, title, role, department, site, group_ids, and assignment status. Call this first when the request mentions "me", "my", or "I" (e.g. "my tickets", "tickets in my group", "tickets assigned to me"), then pass the returned id/email to assignee_email or requester_email filters on swsd_list_incidents (or use swsd_list_my_incidents which does this in one call). Without this step, "my X" queries cannot be answered correctly.
Inputs: no named parameters. Returns: user, sources, jwt_claims
swsd_get_problemARead-onlyIdempotent
Fetch one SWSD problem (ITIL problem record) by id or number. Returns the full problem detail as returned by SWSD (passthrough). Use swsd_list_problems first if you only have a name or filter — IDs are not guessable. Pass detail_level: "long" to include comments, audits, tasks, and time_tracks in one call.
Inputs: id (required), detail_level. Returns: problem
swsd_get_record_auditsARead-onlyIdempotent
List the audit log for a SWSD record. Each audit entry captures one change: action ("Update"/"Create"/"Delete"), message ("State changed from New to Assigned"), the user who performed it, and the timestamp. Use this to answer "who changed this ticket?" or "what happened since I last looked?". Cheaper than swsd_get_incident with detail_level=long when you only need the audit history. object_type accepts incidents, problems, changes, releases, solutions, hardwares, other_assets.
Inputs: id (required), object_type (required), page, per_page. Returns: audits, pagination
swsd_get_roleARead-onlyIdempotent
Fetch one SWSD role by id. Returns name and description. Use swsd_list_roles first to find the id.
Inputs: id (required). Returns: role
swsd_get_server_infoARead-onlyIdempotent
Return the SWSD MCP server's name, version, configured profile, enabled tools, and the SWSD base URL host. Local-only — does not call SWSD. Includes documented SWSD upstream rate limits (the model can reference these without guessing).
Inputs: no named parameters. Returns: name, tools, profile, version, +3 more
swsd_get_siteARead-onlyIdempotent
Fetch one SWSD site (office/branch location) by id. Returns name, location code, description, time_zone. Use swsd_list_sites first to find the id.
Inputs: id (required). Returns: site
swsd_get_solutionARead-onlyIdempotent
Fetch one SWSD solution. Accepts an internal id (>=7 digits) or human-facing number (<=6 digits). Returns the full solution as returned by SWSD (passthrough), including both description (HTML) and description_no_html (plain text) fields, custom_fields_values, comments count, and attachment metadata. Use swsd_search_solutions first if you only have a topic — IDs are not guessable. Pass detail_level: "long" to include attachments, audits, and tags in one call.
Inputs: id (required), detail_level. Returns: solution
swsd_get_userARead-onlyIdempotent
Fetch one SWSD user by id. Returns name, email, role, site, department, title, disabled/assignable flags, and group_ids (teams the user belongs to). Use swsd_list_users first to find the id by name or email.
Inputs: id (required). Returns: user
swsd_health_checkARead-onlyIdempotent
Verify connectivity and authentication to SWSD by making a minimal request. Returns ok=true on success, otherwise an error explaining the failure (401 = bad token, 403 = insufficient permission, network error = unreachable).
Inputs: no named parameters. Returns: ok, base_url, api_version
swsd_link_solution_to_incidentAIdempotent
Attach a knowledge-base solution to an incident. Fetches the incident first, reads its existing linked solutions, appends the new one (preserving others), then PUTs with solution_ids (the SWSD write shape — distinct from the read shape solutions). Idempotent — if the solution is already linked, returns success without modifying the record. WRITE — does not retry on transient failure.
Inputs: incident_id (required), solution_id (required).
swsd_list_catalog_itemsARead-onlyIdempotent
List catalog items available in SolarWinds Service Desk. Each item represents an offerable service request template (e.g., "New Employee Onboarding", "Software Request") with a defined set of input variables (form fields). Use swsd_get_catalog_item to inspect a single item's variables, then swsd_create_service_request to submit a request.
Inputs: page, site, query, state, +2 more. Returns: items, pagination, applied_filters
swsd_list_categoriesARead-onlyIdempotent
List SWSD incident/solution categories. Returns id, name, parent_id, immediate children, and default_assignee_id. Categories form a hierarchy (parent_id links). Use this to validate category_name before swsd_create_incident or swsd_update_incident.
Inputs: page, query, per_page. Returns: categories, pagination
swsd_list_departmentsARead-onlyIdempotent
List SWSD departments (organizational divisions). Returns id, name, description. Use this to validate department_name before incident write tools.
Inputs: page, query, per_page. Returns: pagination, departments
swsd_list_groupsARead-onlyIdempotent
List SWSD groups (assignment teams). Returns id, name, description, disabled, member_count. Useful for understanding team structure when triaging tickets.
Inputs: page, query, per_page. Returns: groups, pagination
swsd_list_incident_commentsARead-onlyIdempotent
List comments on a SWSD incident. Returns id, body, is_private, author_email, author_name, created_at. Use swsd_add_incident_comment to add a new comment.
Inputs: incident_id (required), page, per_page. Returns: comments, pagination, incident_id
swsd_list_incidentsARead-onlyIdempotent
List SWSD incidents with structured filters and pagination. Returns compact summaries (id, name, state, priority, assignee_email, requester_email, category, updated_at) — call swsd_get_incident for the full detail of any one row. Filters use SWSD repeated-key array semantics (multiple values within a filter are OR-ed). requester_email is resolved through the requester directory and filtered server-side with requested_by. Unknown requesters return zero matches; lookup failures are errors. assignee_email and exact updated_from time cutoffs are applied to the fetched page. Counts explicitly identify their scope.
Inputs: page, query, sites, states, +15 more. Returns: scan, incidents, pagination, applied_filters
swsd_list_incident_tasksARead-onlyIdempotent
List sub-tasks on a SWSD incident. Returns id, name, description, state ("New" / "In Progress" / "Completed"), completed boolean, position, assignee, due_at, created_at, updated_at. Use swsd_create_incident_task to add a sub-task and swsd_update_task_state to mark one complete. Sub-tasks also appear inline in swsd_get_incident detail_level: "long".
Inputs: incident_id (required). Returns: count, tasks, incident_id
swsd_list_my_incidentsARead-onlyIdempotent
List incidents for the authenticated user. role=assignee (default) filters the fetched page by assignee; role=requester resolves your requester ID and filters all pages server-side. For group scope use swsd_list_incidents with assigned_to_group=<group_id>. Lookup failures are errors, and totals identify whether they count filtered matches or upstream candidates.
Inputs: page, role, query, sites, +15 more. Returns: role, scan, incidents, pagination, +3 more
swsd_list_problemsARead-onlyIdempotent
List SWSD problems (ITIL problem records) with structured filters and pagination. Returns compact summaries (id, name, state, priority, category, requester, assignee, updated_at) — call swsd_get_problem for the full detail of any one row. Filters use SWSD repeated-key array semantics (multiple values within a filter are OR-ed). Use this when investigating recurring incidents or identifying root causes that span multiple tickets.
Inputs: page, query, state, per_page, +4 more. Returns: problems, pagination, applied_filters
swsd_list_record_commentsARead-onlyIdempotent
List comments on a SWSD problem, change, or release. Returns id, body, is_private, author_email, author_name, created_at. Use swsd_add_record_comment to add a new comment.
Inputs: record_id (required), record_type (required), page, per_page. Returns: comments, record_id, pagination, record_type
swsd_list_record_tasksARead-onlyIdempotent
List sub-tasks on a SWSD problem, change, or release. Returns id, name, description, state, completed boolean, position, assignee, due_at, created_at, updated_at. Use swsd_create_record_task to add a sub-task.
Inputs: record_id (required), record_type (required). Returns: count, tasks, record_id, record_type
swsd_list_rolesARead-onlyIdempotent
List SWSD roles (permission profiles). Returns id, name, description. Useful for understanding what users can do in SWSD when triaging permission-related tickets.
Inputs: page, query, per_page. Returns: roles, pagination
swsd_list_sitesARead-onlyIdempotent
List SWSD sites (physical office/branch locations). Returns id, name, location code, description, time_zone. Use this to validate site_name before incident write tools.
Inputs: page, query, per_page. Returns: sites, pagination
swsd_list_time_tracksARead-onlyIdempotent
List SWSD time entries for an incident, problem, change, or release. Use this before adding/updating time when you need existing work-log context.
Inputs: id (required), object_type (required), page, per_page. Returns: pagination, time_tracks
swsd_list_usersARead-onlyIdempotent
List SWSD users. Returns id, name, email, disabled, available_for_assignment, role, site, department, title. Set available_for_assignment_only: true to find valid assignees for swsd_assign_incident. Set email to look up one user exactly.
Inputs: page, email, query, per_page, +1 more. Returns: users, pagination
swsd_log_timeA
Log time against a SWSD incident, problem, change, or release. Required: object_type, id, name, minutes_parsed. WRITE — honors SWSD_WRITE_MODE and does not retry on transient failure.
Inputs: id (required), name (required), object_type (required), minutes_parsed (required).
swsd_my_queueARead-onlyIdempotent
Work-queue view for the authenticated user (or a given assignee/group). Defaults to open incidents assigned to you, sorted by due_at ascending. Each row includes a computed SLA risk level for at-a-glance triage. Supports assignee_email override (client-side filter), assigned_to_group (server-side), states/priorities filters, and sort_by options.
Inputs: page, states, sort_by, per_page, +6 more. Returns: scan, incidents, pagination, assignee_email, +1 more
swsd_search_solutionsARead-onlyIdempotent
Search SWSD knowledge-base solution articles. Pass query for free-text search across titles and descriptions; pass category to filter to a category name. Returns compact summaries with truncated excerpts (240 chars). Use swsd_get_solution for the full HTML body of any one result. NOTE: search is asynchronously indexed — articles created or updated in the last few minutes (sometimes hours) may not appear yet. To verify a just-created article, use swsd_get_solution with the ID returned by swsd_create_solution.
Inputs: page, query, category, per_page. Returns: solutions, pagination
swsd_sla_riskARead-onlyIdempotent
List open incidents ranked by SLA breach risk. Computes a risk level for each incident based on due_at and sla_violations: "breached" (overdue or has violations), "critical" (due within 4 hours), "warning" (due within at_risk_within_hours), "ok", or "no_due_date". Results are sorted with breached first (most overdue first), then by time-to-breach ascending, no_due_date last. Defaults to excluding Resolved and Closed states. Limitation: incident list rows only normally include due_at. The sla_violations[] array is only present on the long incident layout, so rows are ranked primarily by due_at and violations are counted only when SWSD happens to include them on the row. Use swsd_get_incident with detail_level long for a complete per-incident SLA picture.
Inputs: page, states, per_page, priorities, +8 more. Returns: now, scan, counts, incidents, +2 more
swsd_ticket_statsARead-onlyIdempotent
Summarize scanned tickets created OR last updated in [from, to), defaulting to the last seven days. Alternates created and updated incident-list queries, deduplicates IDs, and shares max_pages across both scans. Totals and breakdowns cover only scanned matching rows, not the tenant backlog or a historical state snapshot. Open excludes Resolved/Closed; unassigned means no individual assignee. Breached uses computeSlaRisk on open tickets at scan time, using due_at and any returned sla_violations (list rows may omit violations). Resolution counts and median elapsed hours use valid resolved_at timestamps in the window only; rows without resolved_at are excluded, never approximated with updated_at. The list API may omit resolved_at, so resolution metrics may be incomplete. An older ticket resolved during the window but last updated afterward can also be absent from these date-filtered scans. Median is null if no valid nonnegative created_at-to-resolved_at durations exist. Assignee/category breakdowns return the top ten.
Inputs: to, from, per_page, max_pages, +1 more. Returns: scan, totals, window, by_state, +4 more
swsd_update_commentADestructive
Update the body of an existing SWSD incident comment. Pass incident_id, comment_id, and the new body. The is_private flag cannot be changed by this tool — to change visibility, delete and re-create. WRITE — does not retry on transient failure.
Inputs: body (required), comment_id (required), incident_id (required).
swsd_update_incidentADestructive
Update an existing SWSD incident. Pass id and any fields to change. Only fields you provide are sent — others stay as-is. For state transitions prefer swsd_update_incident_state (safer wrapper); for assignment prefer swsd_assign_incident; for comments use swsd_add_incident_comment. WRITE — does not retry on transient failure. To set tenant-specific custom field values, pass custom_fields: [{name, value}] — call swsd_describe_custom_fields first to discover field names and (for Dropdowns) allowed values. Validated for Text, Dropdown, Number, Checkbox, and Date types.
Inputs: id (required), name, priority, site_name, +4 more.
swsd_update_incident_stateADestructive
Transition an SWSD incident to a new state (e.g., "Assigned", "Resolved", "Closed"). Safer wrapper around swsd_update_incident — narrows the agent decision surface. State names are tenant-specific; common ones: "New - Unassigned", "Assigned", "In Progress", "Awaiting Input", "Resolved", "Closed". Call swsd_get_incident first to see the current state. WRITE — does not retry on transient failure.
Inputs: id (required), state (required).
swsd_update_problemADestructive
Update an existing SWSD problem. Pass id and any fields to change. Only provided fields are sent — others stay as-is. To replace the description entirely, pass the full new body. WRITE — does not retry on transient failure.
Inputs: id (required), name, state, category, +8 more.
swsd_update_taskADestructive
Update a SWSD incident sub-task. Pass incident_id (internal id or incident number), task_id, and name, assignee_email, due_at (ISO datetime), and/or is_complete. Only provided fields are sent. WRITE — honors SWSD_WRITE_MODE and does not retry on transient failure.
Inputs: task_id (required), incident_id (required), name, due_at, +2 more.
swsd_update_task_stateADestructiveIdempotent
Mark a SWSD incident sub-task as complete or incomplete. Pass completed: true to set the task to "Completed", or completed: false to revert to "New". For finer state control (e.g., "In Progress"), use the SWSD UI directly — this tool is the safer wrapper for the common done/not-done transition. WRITE — idempotent: re-applying the same value is a no-op on SWSD.
Inputs: task_id (required), completed (required), incident_id (required).
swsd_update_time_trackADestructive
Update an existing SWSD time entry on an incident, problem, change, or release. Pass name and/or minutes_parsed. WRITE — honors SWSD_WRITE_MODE and does not retry on transient failure.
Inputs: id (required), object_type (required), time_track_id (required), name, +1 more.
swsd_upload_attachmentA
Upload an attachment to a SWSD incident, problem, change, release, solution, hardware asset, other asset, or configuration item. Use content_base64 for hosted/HTTP clients; file_path is allowed only on stdio. WRITE — honors SWSD_WRITE_MODE.
Inputs: file_name (required), parent_id (required), parent_type (required), file_path, +1 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 52 tools
Many tools are cleanly distinct, but there are parallel families with unclear boundaries: incident-specific tools (swsd_list_incident_comments, swsd_list_incident_tasks, swsd_add_incident_comment) coexist with generic record tools (swsd_list_record_comments, swsd_list_record_tasks), so an agent must guess which set applies to incidents. Triage views (swsd_my_queue, swsd_list_my_incidents, swsd_sla_risk, swsd_ticket_stats) and task updates (swsd_update_task vs swsd_update_task_state) overlap substantially, though descriptions do offer guidance.
The dominant pattern is a consistent swsd_verb_noun snake_case convention across most tools. Deviations exist: noun-first names (swsd_ticket_stats, swsd_sla_risk), odd verbs (swsd_change_calendar implies mutation but is a read), and terminology drift between incident/ticket/record for the same underlying object.
52 tools for an ITSM surface is heavy and includes redundant incident-vs-record variants of the same operations. While the domain is broad, several tools could be consolidated (generic record tools parameterized by object_type) to reduce the decision surface considerably.
Incidents are well covered end-to-end (CRUD, state, assignment, comments, attachments, tasks, time), but changes and releases have no create/get/list/update tools despite a change_calendar and generic record helpers. Solution write tools referenced in descriptions (swsd_create_solution, swsd_update_solution) are absent from the surface, and there are no delete operations anywhere.
Maintenance
Related MCP Connectors
MCP server for GLPI: tickets, ITIL, assets, knowledge base. GLPI 10/11. Not affiliated with Teclib'.
Remote MCP server for managing Muninx tickets, messages, ticket search, and support analytics.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceRead-only MCP server for querying Movidesk tickets through the public Movidesk API.18 npm-
- FlicenseNot gradedqualityDmaintenanceAn MCP server that wraps the TeamDynamix Web API, enabling AI assistants to search tickets, manage assets, query the knowledge base, and look up people in your TDX instance.1-
- AlicenseNot gradedqualityBmaintenanceMCP server for ConnectWise PSA (Manage) enabling ticket management, time entry, and read-only lookups of companies, contacts, and configurations with role-based access control and bring-your-own-API-keys support.144 npm6MIT
- AlicenseAqualityCmaintenanceMCP server for the Snipe-IT asset management REST API, enabling read and write operations on assets, licenses, accessories, and more.13Apache 2.0