Loading ToolBench
NinjaOne RMM API Gateway MCP Server - provides tools to discover, describe, and execute NinjaOne RMM API endpoints with fast memory for saved queries
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (find_, describe_, call, raw_call, memory_*). Descriptions are adequate (100-250 chars) but lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameters are typed and described, but lack enums for constrained values (e.g., 'method' accepts GET/POST/PUT/PATCH/DELETE but no enum). Error handling returns structured objects with hints, but lacks recovery guidance for common failures. Output schemas are not formally documented. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound, tools chain well (find → describe → call). Security: credentials injected via environment, not exposed as parameters.
Execute a NinjaOne API call. `endpoint`: 'METHOD /path' exactly as shown by find_endpoint (can include `{placeholders}` — supply values via `path_params`). `path_params`: values for `{name}` placeholders in the path. `query`: query-string parameters (e.g. filters, pagination). `body`: JSON request body for POST/PUT/PATCH. `memory_id`: load previously-saved params from fast memory; explicit args still override the saved values.
Full details for a specific endpoint: parameters, request body schema, responses. `endpoint` format: 'METHOD /path' — e.g. 'GET /v2/devices/{id}'.
Discover NinjaOne API endpoints. Use with no args to list categories. Pass `query` for fuzzy text search across path, summary, description, and tags. Filter by `category` (e.g. 'devices', 'Billing') and/or `method` (GET/POST/PUT/PATCH/DELETE). Returns a list of endpoint summaries. Use `describe_endpoint` for full parameter/schema detail on a specific match.
Delete a fast-memory entry. Pass `memory_id='*'` to clear all.
List all saved fast-memory entries.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels. memory_delete is DESTRUCTIVE, call/raw_call/memory_save are WRITE, others are READ_ONLY. LLMs cannot infer safety without explicit hints.
Parameter 'method' in find_endpoint accepts GET/POST/PUT/PATCH/DELETE but is defined as free-form string, not enum. LLMs may hallucinate invalid HTTP methods. Same issue with 'endpoint' parameter format, no regex pattern or strict validation.
Output schemas not formally documented. Tools return dicts with 'error', 'data', 'truncated', 'endpoint' fields, but LLMs cannot parse response structure without schema. Downstream tool chaining requires explicit field documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Save an API call for quick reuse later. Returns the saved entry including its `id`, which can be passed to `call(memory_id=...)` to replay.
Quick-form API call. Parses 'METHOD /path?query=value'. Example: raw_call("GET /v2/devices?df=class eq 'WINDOWS_WORKSTATION'") Pass `body` separately for POST/PUT/PATCH.
Descriptions lack WHEN-to-use guidance. 'call' vs 'raw_call' distinction is unclear, description says raw_call is 'quick-form' but doesn't explain when to prefer it over call. LLMs waste reasoning cycles deciding between similar tools.
Error handling returns hints but lacks recovery classification. 'Unknown endpoint' error suggests 'Use find_endpoint' but doesn't indicate if the error is retryable, user-fixable, or fatal. LLMs cannot plan recovery without explicit guidance.