Loading ToolBench
MCP server that provides tools for interacting with SentinelOne security platform. Enables querying agents, threats, alerts, applications, and performing remediation actions.
The server defines 8 tools with consistent naming conventions (s1_* prefix) and reasonable descriptions. All tools have input schemas with type definitions and parameter descriptions. However, there are several gaps: output schemas are not documented, error handling lacks recovery guidance, and descriptions, while present, are relatively brief (10-50 chars on average) compared to production baselines (194 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite tools like s1_isolate_agent and s1_reconnect_agent being reversible actions. Parameter descriptions are adequate but lack dependency hints and constraint details. The tools follow verb_noun patterns correctly and avoid generic names.
Get a specific SentinelOne agent by ID
Network isolate an agent (disconnect from network while maintaining S1 communication)
List SentinelOne agents with optional filters
List unified alerts via GraphQL. Use storylineId to correlate with threats.
List installed applications on endpoints. Useful for checking software versions, identifying risky software, or verifying installations.
Remove network isolation from an agent
No output schemas documented. LLMs cannot plan downstream calls or extract relevant fields from responses. All 8 tools lack documented return types.
Missing tool annotations for reversible and destructive operations. s1_isolate_agent and s1_reconnect_agent should declare idempotentHint=true; s1_set_alert_verdict and s1_set_alert_status should declare destructiveHint=true to signal to agents these are non-read-only operations.
Descriptions are very brief (10-50 chars). Baseline production tools average 194 chars. Current descriptions lack WHEN to use the tool and dependencies. Example: 's1_list_agents' description 'List SentinelOne agents with optional filters' does not explain when to call this vs s1_get_agent or how to use results downstream.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Set the incident status on alerts matching the given filters. Optionally set the analyst verdict at the same time. At least one filter is required.
Set the analyst verdict on alerts matching the given filters. At least one filter is required to avoid accidentally affecting all alerts.
No error handling or recovery guidance in any tool. If s1_set_alert_verdict fails because filters match no alerts, the LLM receives no hint to try different filters or verify alert existence first. No distinction between retryable, user-fixable, or fatal errors.
s1_set_alert_verdict and s1_set_alert_status require 'at least one filter' but this is not enforced in the schema, no 'minProperties' or 'required' constraint. LLMs may omit all filters, causing the tool to fail with an unclear error.
Parameter 'limit' is type 'number' (float) in schemas but descriptions and API context imply integers. Should be 'type: integer' with min/max bounds (e.g., 'limit: {type: integer, minimum: 1, maximum: 1000}').
Enum values in descriptions (e.g., 'windows, macos, linux' for osTypes) are informal. Should use JSON Schema enum constraints so LLMs see canonical values.