Loading ToolBench
The server defines 13 tools with consistent naming (verb_noun pattern) and mostly complete schemas. However, there are critical gaps in parameter completeness, output schema documentation, and error handling guidance. Tool names follow good conventions (get_, isolate_, release_, run_, stop_, restrict_, etc.), but several tools have incomplete required parameters. Many parameters lack type specifications in the schema (e.g., isolation_type, scan_type are enums but device_id/device_name lack proper typing). Output schemas are not documented anywhere in the visible code, which is a significant compliance gap. Error handling is absent, no guidance on what to do if a device is not found, if an action fails, or how to retry. This server is above average for community implementations but has noticeable gaps that would cause LLM misuse.
Collect a forensic investigation package from a device containing system information, logs, and diagnostic data. Requires MCP.Admin role.
Test connectivity with the Response MCP server
Get download URL (SAS URI) for a completed investigation package. Returns a temporary download link valid for a short time.
List recent machine actions (response actions) from Microsoft Defender. Can filter by device, action type, or status.
Find a machine/device in Microsoft Defender by hostname. Returns device details including health status, risk score, exposure level, and device ID.
Isolate a device from the network to prevent lateral movement. Use Full isolation to block all connections, or Selective to allow Outlook/Teams/Skype.
Multiple tools (isolate_device, release_device, run_antivirus_scan, stop_and_quarantine, restrict_code_execution, remove_code_restriction) require either device_id OR device_name but neither is marked as required in the schema. The schema shows only 'comment' as required, but the description implies device identification is mandatory. This creates ambiguity: an LLM could call with comment alone, omitting both device identifiers, which would fail at runtime.
Output schemas are completely absent from the visible code. No documentation of what these tools return, what fields are in the response, or what structure the LLM should expect. This violates the pattern requirement that LLMs must know return structure to plan downstream calls. For example, get_machine_by_name presumably returns device_id, but this is never documented, forcing the LLM to guess what field name to use in follow-up calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Isolate multiple devices from the network in a single operation. Provide a comma-separated list of device names.
Release a previously isolated device from network isolation, restoring full connectivity.
Remove code execution restrictions from a device, allowing all applications to run again.
Restrict code execution on a device to only allow Microsoft-signed applications.
Initiate a Microsoft Defender Antivirus scan on a device. Quick scan checks common malware locations, Full scan checks entire disk.
Stop a running process and quarantine the associated file on a device. Requires the SHA1 hash of the file.
Update the status of a security incident. Use this to mark incidents as active, resolved, or redirected.
No error handling guidance in any tool description. LLMs are not told what to do if a device is not found, if isolation fails, if permissions are insufficient, or if an action times out. Descriptions like 'Isolate a device from the network' do not explain failure modes or recovery steps. Per pattern:recovery-guide, error responses must guide the LLM on next steps (retry, ask user, call a different tool).
Parameter type definitions are inconsistent. While enum fields like isolation_type and scan_type are properly typed, string parameters like device_id and device_name lack explicit 'type' declarations in their schema definitions. Parameters should declare 'type: string' alongside descriptions. This forces LLMs to infer types from context rather than from explicit schema metadata.
Destructive and high-risk operations (stop_and_quarantine, isolate_device, restrict_code_execution) have no confirmation step or dry-run mode. Per pattern:confirmation-request, irreversible operations should support explicit confirmation. An LLM could accidentally quarantine the wrong file or isolate critical infrastructure without user acknowledgment.
Tool descriptions lack dependency hints. For example, isolate_device accepts device_name as input, but get_machine_by_name is the obvious lookup tool. The description should say 'If you only have a hostname, call get_machine_by_name first to resolve the device_id.' This prevents wasted calls and guides multi-step planning per pattern:tool-description.
get_machine_actions has optional parameters (device_id, device_name, action_type, status, limit) but no defaults documented. What is the default limit? What happens if no filters are provided, do you get all actions or a capped result? Per pattern:tool-description, parameter defaults must be stated to help LLMs compose calls correctly.
isolate_multiple accepts a comma-separated string of device names but does not specify error handling for partial failures. If 3 out of 5 devices isolate successfully, is the call a success or failure? Does the response list which ones succeeded? Per pattern:response-shaper, multi-item operations must return per-item success/failure to enable granular recovery.
Tool descriptions reference Microsoft Defender internals without context. 'Use Full isolation to block all connections, or Selective to allow Outlook/Teams/Skype' assumes the LLM knows these distinctions. Better: 'Full isolation blocks all network traffic (emergency containment). Selective allows email/collaboration apps only (less disruptive).' This helps the LLM choose the right mode.