Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sentinelone-mcp show me the latest XDR alerts from today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
FastMCP server for SentinelOne: session login, XDR alerts, Purple AI, and SOC investigation tools.
Credentials live in Azure Key Vault only. config.json holds Azure identity + KV secret names, not values.
python -m venv .venv
source .venv/bin/activate
pip install -e .
playwright install chromium
cp config.example.json config.json # edit with your vault + secret namesPopulate KV secrets (see config.example.json for logical keys). Required:
S1-LOGIN-EMAIL, S1-LOGIN-PASSWORD, S1-LOGIN-TOTP (if MFA)
S1-LOGIN-URL, S1-API-URL (your SentinelOne console/API base URLs)
SENTINELONE-API-KEY, SENTINELONE-XDR-TOKEN
Optional: S1-XDR-REGION (default eu1), S1-SITE-ID
Session cookies (SENTINELONE-SESSION-COOKIES*) are written by refresh_login.
Related MCP server: Response MCP Server
python main.py # FastMCP stdio (default)
python main.py --mode login # refresh Playwright session → KV
python -m sentinelone_mcp # same as default MCP mode{
"mcpServers": {
"sentinelone": {
"command": "python",
"args": ["/path/to/sentinelone-sync/main.py"],
"cwd": "/path/to/sentinelone-sync"
}
}
}Override config path: SENTINELONE_CONFIG=/path/to/config.json
Fetch Cloud Detection alerts from SentinelOne Management API. Optional filters: site_ids (comma-separated), created_after (ISO8601).
Inputs: limit, tenant, site_ids, created_after. Returns: object
List SentinelOne STAR / cloud-detection rules including name, description, status, severity, and S1QL body (the custom rule contents).
Inputs: limit, tenant, name_contains. Returns: object
Fetch Deep Visibility events for a storyline (Management API). Use event_filter for S1QL: ObjectType = "URL" for URLs, event.type = "Process Creation" for processes.
Inputs: storyline (required), limit, tenant, to_date, +3 more. Returns: object
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.
Inputs: threat_id (required), tenant. Returns: object
Fetch recent SentinelOne threats. Returns threatName, storyline, user, computer, status, engines, maliciousProcessArguments, originatorProcess, initiatedByDescription.
Inputs: limit, tenant, sort_order, incident_status. Returns: object
Fetch unresolved threats created in the last N hours. Entry point for incident triage — resolved threats are excluded.
Inputs: limit, tenant, hours_back. Returns: object
List configured SentinelOne tenants from config.json.
Inputs: no named parameters. Returns: object
Mark one or more threats as resolved with analyst verdict. verdict: false_positive | true_positive | suspicious | undefined.
Inputs: threat_ids (required), note, tenant, analyst_verdict. Returns: object
Process pending XDR alerts from Elasticsearch and create them via GraphQL. Requires prior refresh_login for XDR visibility cookies.
Inputs: no named parameters. Returns: object
Ask SentinelOne Purple AI a natural-language query. Uses Playwright headful; reuses browser session across calls.
Inputs: query (required), tenant, timeout_seconds. Returns: object
Reset cached Purple AI browser session (forces re-login on next query).
Inputs: no named parameters. Returns: object
Refresh SentinelOne session cookies for one or all tenants. Stores cookies in each tenant's Azure Key Vault.
Inputs: tenant. Returns: object
Run a raw Deep Visibility S1QL query (init → poll → events). Example: storyline = "ABC123" AND event.type = "Process Creation".
Inputs: query (required), limit, tenant, to_date, +2 more. Returns: object
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.
Inputs: event_type (required), os, url, extra, +12 more. Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
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.
Remote MCP for Copilot CLI switch gate MCP, structured receipts, audit logs, and reviewer-ready evid
One MCP endpoint for your company's tools, with per-person sign-in, policy and audit.
Governed access to enterprise SaaS tools through Averta MCP agents.
Authenticated LLM MCP Agent
