Loading ToolBench
Model Context Protocol server for NinjaOne RMM integration with decision tree architecture for Claude
NinjaOne MCP server demonstrates solid foundation with complete tool registration, structured schemas, and clear naming conventions. All 7 tools follow verb_noun patterns (ninjaone_navigate, ninjaone_alerts_list, ninjaone_alerts_reset, etc.). However, significant gaps exist in parameter descriptions, output schema documentation, and error handling guidance. Tool descriptions are generally adequate (60-150 chars), but parameter documentation is inconsistent, many parameters lack descriptions entirely or provide minimal guidance. Output schemas are not documented, making it difficult for LLMs to plan downstream operations. The server follows good patterns for enum constraints (severity, domain, group_by) and accepts natural identifiers (organization_id, device_id) alongside system IDs. Destructive tools (ninjaone_alerts_reset_all) are clearly marked with descriptive names, but lack confirmation patterns or dry-run support.
Get details for a specific alert by its UID
List active alerts, filterable by severity, organization, or device
Reset (dismiss) an alert - acknowledges and marks as handled
Reset all alerts for a device or organization (destructive action)
Get alert count summary grouped by severity and/or organization
Discover available NinjaOne 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.
Parameter descriptions completely missing for: severity, source_type, organization_id, device_id, limit, cursor (ninjaone_alerts_list); alert_uid (ninjaone_alerts_get, ninjaone_alerts_reset); device_id, organization_id, severity (ninjaone_alerts_reset_all); group_by (ninjaone_alerts_summary). LLM cannot infer parameter semantics, valid ranges, or formats.
Output schemas not documented for any tool. LLM cannot plan downstream operations, understand result structure, or extract chaining IDs (e.g., alert_uid for follow-up calls). This violates the requirement that tools document what fields they return.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Show API credential status and available tool domains
Destructive tools (ninjaone_alerts_reset, ninjaone_alerts_reset_all) lack confirmation patterns or dry-run support. Agents may accidentally dismiss all alerts for an organization without explicit user confirmation.
ninjaone_alerts_reset_all has three optional filters (device_id, organization_id, severity) with no documentation of which combinations are required, how they combine (AND vs OR), or error cases. No guidance on 'reset all in organization' vs 'reset all matching severity' vs 'reset all' (global).
No error handling guidance. Tools do not describe what happens on invalid alert_uid, missing organization_id, or permission failures. LLM cannot self-correct or route failures appropriately.
ninjaone_alerts_list accepts 'limit' and 'cursor' parameters but output schema is undocumented. LLM cannot know if results include a next_cursor, total count, or per-item alert details necessary for pagination.
Parameter 'group_by' in ninjaone_alerts_summary uses enum values ('severity', 'organization', 'both') with no description of what output structure each choice produces. LLM cannot reason about downstream data extraction.