ConnectWise Automate MCP server with decision tree architecture for Claude. Provides tools for interacting with the ConnectWise Automate API for endpoint management, company management, alert monitoring, and script execution.
This server demonstrates solid tool definition quality with consistent naming patterns, comprehensive parameter schemas, and detailed descriptions. All 15 tools are explicitly registered with well-structured schemas and descriptions. However, there are notable gaps in output schema documentation, error recovery guidance, and composition patterns that prevent a higher score. The server follows verb_noun naming conventions well (navigate, status, list, get, create, update, reboot, run_script, run_command). Parameter descriptions are detailed and include enum constraints where appropriate. The main weaknesses are: (1) no documented output schemas for tools, LLMs cannot predict response structure for downstream chaining; (2) missing error handling guidance in descriptions; (3) limited support for natural identifiers (many tools require numeric IDs only); (4) no confirmation/dry-run pattern for destructive operations.
Get details for a specific alert by ID. Alerts are read-only in the Automate API.
List alerts in ConnectWise Automate with optional filtering by computer, client or severity. Alerts are read-only in the Automate API: they carry no status and cannot be acknowledged or closed through it.
Create a new client in ConnectWise Automate
Get details for a specific client by ID
List all clients in ConnectWise Automate with optional filtering.
Update an existing client in ConnectWise Automate
Output schemas not documented. Tools return results but LLMs cannot predict field names, types, or structure for downstream tool chaining. E.g., cwautomate_clients_get returns client details but the response schema is not visible, preventing the agent from knowing what fields to extract for related calls.
Destructive operations lack confirmation/dry-run pattern. cwautomate_computers_reboot, cwautomate_computers_run_script, and cwautomate_computers_run_command are IRREVERSIBLE/DESTRUCTIVE but have no confirmation step or dry-run capability. Agents may accidentally reboot critical systems or execute unintended scripts.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
List the Automate command catalog. Commands are a fixed, server-defined set addressed by ID — call this to find the command ID before using cwautomate_computers_run_command.
Get details for a specific computer by its ID
List computers in ConnectWise Automate. Can filter by client, location, or online status.
Reboot a computer and wait for the command's result. Automate has no dedicated restart route: the reboot is issued as a catalog command (POST /Computers/{id}/CommandExecute). By default the first catalog entry named like 'Reboot' or 'Restart' is used; pass command_id (from cwautomate_commands_list) to choose a specific one. The API user's command level caps which commands may be issued.
Issue a catalog command to a computer and wait for its result. The command_id must come from cwautomate_commands_list; free-text commands are not accepted by Automate. Note that the API user's command level and the group-level 'Send Commands' grant silently cap which commands may be issued.
Run a script on a specific computer
Search for computers by name (matches any part of the computer name)
Discover available ConnectWise Automate tools by domain. Returns tool names and descriptions for the selected domain. All tools are callable at any time — this is a help/discovery aid, not a prerequisite.
Show credentials status and available domains
Descriptions for destructive tools are vague about consequences. cwautomate_computers_reboot describes what it does but does not emphasize the irreversibility or operational impact. cwautomate_computers_run_script lacks guidance on what scripts are safe. LLMs need explicit warnings in destructive tool descriptions.
No error recovery guidance in descriptions. Tools like cwautomate_alerts_get note that 'Alerts are read-only' but don't explain what the LLM should do if an alert is not found. Descriptions lack recovery hints (e.g., 'Call cwautomate_alerts_list to discover valid alert IDs').
Parameter descriptions lack constraints and validation guidance. E.g., cwautomate_computers_reboot's 'command_id' parameter has no description of what value format is expected or where it comes from. cwautomate_computers_list's 'limit' has no min/max bounds stated in the description (should be 1 - 100 or similar).
Many tools require numeric IDs only; no support for natural identifiers. cwautomate_clients_get requires a numeric client_id, but users typically refer to clients by name. No search_clients variant forces an extra lookup call. Similarly, cwautomate_computers_reboot requires computer_id; a computer_name variant would align better with chat data model.
cwautomate_status description is too short (44 chars). Should explain what credentials status and domain information reveal and when an agent should invoke it.
Tool composition could be more seamless. If cwautomate_computers_reboot frequently needs to discover command_id, the response from cwautomate_commands_list should be prominently featured and the parameter description should reference it. Currently, the chain is not obvious to LLMs.