Feature Requests

Feature Request: Add pagination to the NinjaOne integration via Super Magic MCP Server tools (and surface OS in the device list payload) Summary The NinjaOne integration in Thread MCP currently cannot support estate-wide device queries because its list tools do not paginate and the device search payload omits OS data. Both capabilities already exist in NinjaOne's underlying public API — this is a surfacing gap, not a new capability. Affected tools search_ninjaone_devices list_ninjaone_organizations Current verified limitations (observed in live testing) search_ninjaone_devices returns a hard maximum of 25 results per call with no pagination (no page token / cursor / offset). Unscoped searches truncate at 25 devices. list_ninjaone_organizations caps at 25 organizations and pads/truncates — it cannot enumerate all orgs. OS name and build number are not included in the device search payload; retrieving OS requires one get_ninjaone_device call per device. Net effect: any estate-wide query (e.g. "find all Windows Server 2012 / 2012 R2 across all clients") requires walking org IDs blindly, then making one detail call per device — potentially hundreds of calls across dozens of sessions. It is practically infeasible. Requested changes: Add cursor/page-token pagination to search_ninjaone_devices and list_ninjaone_organizations. NinjaOne's public API already supports paging on /v2/devices and /v2/organizations. Include os.name and os.buildNumber in the device list/search payload. The source /v2/devices endpoint already returns these fields, so exposing them eliminates the per-device detail fan-out at near-zero cost. Business justification These two changes convert multi-session, manual estate sweeps into a few paged calls. Primary use cases: end-of-life OS inventory (Server 2012/2012 R2, Win10 EOL), vulnerability/compliance reporting, and fleet-wide software/OS census. NinjaOne is the universal RMM across all our clients, and it is the source of truth for live device state — PSA ConfigurationItems are not a reliable substitute due to duplicates and stale records. This makes accurate Ninja-side enumeration essential. Priority: High — blocks all estate-wide device/OS reporting through the integration.

Summary: MSPs using ConnectWise Manage need the ability to search and list Configurations (devices/assets) directly within the Thread Super Magic Chat and/or Super Magic Agent, similar to how Liongard device lookups are available via the chat interface. Problem / Use Case: Currently, when a technician or the Magic Agent needs to look up a device or configuration tied to a client, there is no native way to query ConnectWise Manage Configurations from within Thread's Super Magic Chat or Agent flows. This creates friction technicians must leave Thread, open ConnectWise Manage, and manually search for the configuration before returning to the thread. This gap was highlighted during onboarding, where a Super Magic Agent Flow was unable to locate devices via the Liongard integration, while the chat-based lookup succeeded — indicating inconsistency in device resolution across Thread surfaces. Requested Functionality: Allow Super Magic Chat to search/list ConnectWise Manage Configurations by keyword, company, or device name. Allow Super Magic Agent Flows to query CW Manage Configurations as part of automated triage or troubleshooting steps. Return key configuration details: device name, type, status, associated company, and site. Expected Benefit: Reduces context-switching for technicians, enables faster triage, and allows the Magic Agent to make smarter, asset-aware decisions without human intervention.

Users need Super Magic Agent Flow actions to support the same integration tool access and behavior available in Super Magic Chat. Currently, device lookups through Liongard and PSA configuration searches work correctly in chat sessions but fail when the identical prompt is executed inside an automated flow, causing tickets to remain assigned to a catchall company. The requested enhancement is for flow-triggered agent actions to support integration tools such as Liongard, ConnectWise Manage configurations, and related lookup capabilities so automated workflows can reliably identify devices, determine the correct organization, and automatically reassign ticket company and contact information. The request also highlights the need for consistent behavior between chat and flow execution contexts, including support for cross-company device searches and integration queries without requiring a predefined company ID.

This would allow Super Magic to perform quality assurance checks via Skills by reading the work type and work role used in time entries, ensuring technicians are logging time correctly and consistently.

Beta currently provides a "write" merge permission but does not include a separate bundle permission needed for bundle and merge workflows.

Partners want the ability to rename Super Magic chat conversations with custom names (e.g., "Call Documentation Setup" or "Client Health Review - July"). Currently, the only option available for past conversations is to delete them - there is no way to rename or organize them. This would make it easier to reference and return to previous conversations, especially as Super Magic usage grows. Suggested category: Agentic AI.

Partners want the ability to instruct Super Magic directly (via a conversational command) to add time entries to an existing ticket. The desired workflow is for the user to tell Super Magic to log time against a specific ticket, rather than relying on automatic time logging. This would allow more flexible and manual control over time entry submission directly through the Super Magic interface.

Add support for approval-based ticket merge workflows in AI flows and skills. After a duplicate ticket is detected, the system should allow a manager or technician to review and approve the merge before any action is taken. Suggested options include approval emails with Approve or Decline actions, or interactive buttons and links directly inside internal ticket notes that can trigger the merge once confirmed. The goal is to support safe, human-verified automation for duplicate ticket handling while keeping the review process quick and easy.

Partners need the ability to schedule resources for a ticket that specifically targets the existing Assigned Resources, vs only the Ticket Owner. The Ticket Owner is fairly irrelevant. The ticket owner is often not the person responsible for moving the ticket forward -- the assigned resource is. Assigned resources can also change over the life of a ticket due to teamwork and handoffs, so the system needs to respect the current assigned resource(s) at the time the reminder fires, not a static owner. The current behavior ties to the ticket owner, which does not reflect real-world responsibility in many MSP workflows. EX: The active assigned resource(s) are the target of scheduling the follow-up date/time on a Stale Ticket. If Thread is already pulling and displaying the assigned resource in the Inbox UI, the data is clearly accessible. The gap is that other parts of Thread (like Super Magic, Reminder Agent, and Flows) don't leverage that same data point for targeting or automation.

Allow Super Magic to read the Audit Trail logs on ConnectWise service tickets. The Audit Trail is the most complete record of ticket activity, who touched a ticket and when, status and board changes, how much activity specific individuals are generating and where tickets stall. Right now Super Magic can't see any of it, so it's missing some of the richest context available on a ticket. What it unlocks. Better AI summaries and triage, visibility into ticket handling patterns, coaching opportunities for techs, and early warning on tickets that are getting bounced around. This would be a big win for us and I suspect for most MSPs running ConnectWise.