Loading ToolBench
NinjaOne RMM API Gateway MCP Server
Server provides 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (find_, describe_, call, raw_call, memory_*). Descriptions are substantive (100-250 chars) and explain WHEN to use each tool. However, output schemas are not formally documented, responses are inferred from code. Error handling returns structured objects with hints but lacks categorization (retryable vs fatal). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameter descriptions are present but some lack format constraints (e.g., 'endpoint' format is documented in prose, not schema pattern). Memory tools lack explicit idempotency guarantees.
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.
Output schemas not formally documented. Responses are inferred from code (e.g., _execute returns {endpoint, truncated, data}). LLMs cannot plan downstream tool calls without knowing response structure.
Tool annotations missing. 'call' and 'raw_call' are WRITE operations; 'memory_delete' is DESTRUCTIVE. FastMCP supports readOnlyHint/destructiveHint but they are not declared. Agents cannot distinguish safe from risky tools.
Error handling lacks categorization. Responses return {error, hint} but do not signal retryability. An auth error (NinjaAuthError) is not retryable; a transient API error might be. LLMs need explicit guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=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.
Parameter 'endpoint' format constraint documented in prose ('METHOD /path') but not in schema pattern field. LLMs cannot validate format without formal regex constraint.
memory_list and memory_delete lack detailed descriptions. memory_list has no description of return structure (list of what fields?). memory_delete description is terse (70 chars) and does not explain the '*' wildcard behavior clearly.