sentinelone-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENTINELONE_CONFIG | No | Override config path (default: config.json) | config.json |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tenantsA | List configured SentinelOne tenants from config.json. |
| refresh_loginA | Refresh SentinelOne session cookies for one or all tenants. Stores cookies in each tenant's Azure Key Vault. |
| process_pending_alertsA | Process pending XDR alerts from Elasticsearch and create them via GraphQL. Requires prior refresh_login for XDR visibility cookies. |
| get_alertsB | Fetch Cloud Detection alerts from SentinelOne Management API. Optional filters: site_ids (comma-separated), created_after (ISO8601). |
| get_cloud_detection_rulesA | List SentinelOne STAR / cloud-detection rules including name, description, status, severity, and S1QL body (the custom rule contents). |
| get_threatsC | Fetch recent SentinelOne threats. Returns threatName, storyline, user, computer, status, engines, maliciousProcessArguments, originatorProcess, initiatedByDescription. |
| get_unresolved_threatsA | Fetch unresolved threats created in the last N hours. Entry point for incident triage — resolved threats are excluded. |
| get_threat_contextB | Get timeline of a threat — reveals the custom rule name that triggered it. ALWAYS call before verdict. If Custom Rule, the threat name is a label not evidence. |
| get_storyline_eventsB | Fetch Deep Visibility events for a storyline (Management API). Use event_filter for S1QL: ObjectType = "URL" for URLs, event.type = "Process Creation" for processes. |
| run_dv_queryB | Run a raw Deep Visibility S1QL query (init → poll → events). Example: storyline = "ABC123" AND event.type = "Process Creation". |
| xdr_queryC | Query SentinelOne XDR Data Lake (SentinelDataLakeHelper.query). event_type: PROCESS_CREATION, DNS, NETWORK_CONNECT, FILE_CREATION, LOGIN, REGISTRY_MODIFIED, COMMAND_SCRIPT, URL, CROSS_PROCESS, etc. Filter kwargs: endpoint, os, site_id, src_process, src_user, image, cmdline, domain, url, dst_ip, dst_port, storyline_id. |
| mark_threat_resolvedA | Mark one or more threats as resolved with analyst verdict. verdict: false_positive | true_positive | suspicious | undefined. |
| purple_ai_queryB | Ask SentinelOne Purple AI a natural-language query. Uses Playwright headful; reuses browser session across calls. |
| purple_ai_resetA | Reset cached Purple AI browser session (forces re-login on next query). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Core resources (tenants, rules, Purple AI) are distinct, but several tools overlap in intent: get_threats vs get_unresolved_threats are near-duplicates, and get_storyline_events, run_dv_query, and xdr_query all offer event querying with only backend/scope differences. Descriptions help, but an agent could easily pick the wrong one without careful reading.
Most tools follow a readable snake_case verb_noun pattern like get_threats, list_tenants, and mark_threat_resolved. There are minor deviations: run_dv_query and xdr_query both represent query actions but use different forms, and purple_ai_query/reset are not strictly verb-first. Overall the pattern is consistent enough to be predictable.
14 tools is reasonable for a security operations server covering threats, alerts, Deep Visibility/XDR queries, tenants, and Purple AI. The count is slightly high because some event-query tools could be consolidated, but each tool still represents a plausible capability.
The set covers the main incident triage flow well: list unresolved threats, get threat context, query related events, and mark resolved. Minor gaps exist around cloud-detection rule management and alert status updates, but core investigative and response workflows are present.