Loading ToolBench
MCP server for searching and retrieving activity audit records from Netwrix Auditor based on filter criteria
The server provides three well-named, auditing-focused tools for activity record searching and retrieval. Tool names clearly follow verb_noun conventions (Search*, Retrieve*). Descriptions are present and moderately detailed (100-300 chars), explaining use cases and constraints like the 100+ record limit. Parameter schemas are partially visible in code but incomplete in JSON Schema representation, the 'filter' parameter in SearchActivityRecords shows a complex object structure with many field options documented inline, but formal JSON Schema types and constraints are not clearly defined in the visible code sections. Error handling exists (validation of count bounds, HTTP error responses) but lacks recovery guidance for the LLM. No tool annotations (readOnlyHint, etc.) despite all three being read-only. Pagination via continuation_mark is well-designed but undocumented in output schema. STDIO transport caps score at 50 theoretical max; actual score reflects definition quality independent of transport penalty.
Retrieves a batch of random activity audit records from Netwrix Auditor. Only use this tool for for sanity check to see if there're any audit records in the connected Netwrix Auditor instance. Use it with count = 1 in case other tools failed to retrieve any records or continuation mark.
Retrieves the subsequent batch of activity audit records for a query previously initiated by `RetrieveActivityRecords` or `SearchActivityRecords` or `RetrieveNextActivityRecords`. **Only use this tool if the previous response from one of those tools contained a `continuation_mark`**. Provide that exact `continuation_mark` to this tool to get the next page of results for the *original* query.
Searches for specific activity audit records in Netwrix Auditor based on provided filter criteria. Use this tool when the user wants to find records matching some conditions, such as actions performed by a particular user ('who'), changes to a specific object ('what' or 'object_name'), actions on a specific location ('where'), or events within a defined time range ('when'). You can combine multiple filters. The response may contain a `continuation_mark` if older records exist beyond the initial batch. If there're 100 or more Activity Records present it's considered that filter is too general and needs to be more specific
Input schemas lack formal JSON Schema type definitions and constraints. The 'filter' parameter in SearchActivityRecords is described inline as accepting many operators (Contains, Equals, NotEqualTo, StartsWith, etc.) but no enum or constraint definitions are visible in code. Parameter type must be explicitly declared as object with required properties.
Output schemas not documented. SearchActivityRecords and RetrieveNextActivityRecords return formatted JSON via FormatActivityRecordsResponse() but the response structure (fields, types, continuation_mark format) is not visible or documented. LLMs cannot plan downstream calls without knowing returned fields.
No tool annotations despite read-only semantics. All three tools are read-only (marked READ_ONLY in metadata) but no readOnlyHint annotation present in tool definitions. This omission forces LLMs to infer safety semantics instead of being explicitly told the tool cannot modify state.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error messages lack recovery guidance. When count is invalid or HTTP calls fail, responses like 'Error: Count should be greater than 0' or 'Network error while accessing Netwrix Auditor API' do not guide the LLM on next steps (e.g., 'Verify API connection settings' or 'Try with a smaller count').
Parameter 'count' lacks documented constraints. Code enforces count > 0 and count <= 1000 in SearchActivityRecords, but the parameter description does not state these bounds. RetrieveActivityRecords description says 'max: 100' but code does not enforce it.
Filter parameter structure underdocumented. ActivityRecordToolsDefinitions.FilterListDescription is referenced but not visible in provided code. LLM cannot understand valid filter combinations (e.g., can 'Who' and 'Where' be combined?) or operator syntax (e.g., how to express 'Who contains admin').