Check connectivity (yekar.crowdstrike-falcon.check-connectivity) | Read | Verify the connection end to end: reaches the falcon-mcp deployment and confirms ITS Falcon API credentials authenticate against CrowdStrike. Run this first - it separates a bad server URL or token (Yekar.AI's side) from bad or unscoped Falcon API credentials (the deployment's side), which are different problems with different owners. |
List enabled modules (yekar.crowdstrike-falcon.list-enabled-modules) | Read | Which falcon-mcp modules the connected deployment actually loaded (detections, hosts, spotlight, intel, cases…). A deployment started with --modules exposes only a subset, and every other tool here fails with a not-found when its module is missing - this is how you confirm that diagnosis instead of guessing at an outage. |
Search detections (yekar.crowdstrike-falcon.search-detections) | Read | THE TRIAGE QUEUE - when someone asks for open incidents, open alerts, or what needs triage right now, this is the tool. Searches detections across every Falcon product (EPP, IDP, XDR, OverWatch, NG-SIEM) by severity, status, hostname, tactic or time range, returning full alert records with process context, device info and threat classification. (Falcon's separate case-management records are the formal tickets a triaged detection is promoted into - see Search cases.) |
Get detection details (yekar.crowdstrike-falcon.get-detection-details) | Read | Full records for detection ids you already hold - process tree, device, tactic and technique, resolution state. Use Search detections to find ids by criteria; use this once you have them. |
Update detections (yekar.crowdstrike-falcon.update-detections) | Write | Change the triage state of one or more detections: status, assignee, resolution tags, analyst comment, console visibility. This WRITES to the Falcon console - the change is visible to every analyst on the tenant and there is no undo beyond setting the fields back. |
Search hosts (yekar.crowdstrike-falcon.search-hosts) | Read | Find devices in the Falcon estate by hostname, platform, IP, OS version, sensor version, tags or last-seen time. Returns the device ids the detection and vulnerability tools take. |
Get host details (yekar.crowdstrike-falcon.get-host-details) | Read | Full device records for host ids you already hold - OS and sensor version, agent state, first/last seen, network addresses, groups and tags. |
Search vulnerabilities (yekar.crowdstrike-falcon.search-vulnerabilities) | Read | Falcon Spotlight vulnerability findings - which hosts are exposed to which CVEs, at what severity, in what remediation state. Filter by CVE, severity, status or host, and request the host_info / remediation / cve facets when you need the detail rather than just the counts. |
Search threat actors (yekar.crowdstrike-falcon.search-actors) | Read | CrowdStrike intelligence on adversary groups - motivation, origin, targeted industries and countries, known aliases and capabilities. Use it to attribute activity or to brief on an actor named in a detection. |
Search threat indicators (yekar.crowdstrike-falcon.search-indicators) | Read | CrowdStrike intelligence IOCs - domains, IPs, hashes and URLs with malicious-confidence ratings, first/last seen, and the actors and reports they belong to. This is the intel corpus for enrichment; it is not your tenant's own detections. |
Search intelligence reports (yekar.crowdstrike-falcon.search-reports) | Read | CrowdStrike's published threat reports and intelligence publications - titles, summaries, targeted sectors and the actors they cover. Use it for background on a campaign; the report bodies themselves may require a higher intel subscription tier on the deployment's API client. |
Get MITRE ATT&CK report (yekar.crowdstrike-falcon.get-mitre-report) | Read | The MITRE ATT&CK tactics and techniques CrowdStrike attributes to one threat actor - the actor's tradecraft laid out against the framework, for mapping observed behaviour to known TTPs. |
Search cases (yekar.crowdstrike-falcon.search-cases) | Read | Falcon case-management records - the formal tracked entity (name, severity 1–100, status, assignee, tags, attached evidence) that a triaged detection is promoted into. Use it for investigation and workload bookkeeping: what is being worked, by whom, at what severity. This is NOT the live alert queue - for what needs triage right now, use Search detections. |
Get cases (yekar.crowdstrike-falcon.get-cases) | Read | Full case-management records for case ids you already hold - status, severity, assignee, tags, version, and the alert and event evidence attached to each. |
Create case (yekar.crowdstrike-falcon.create-case) | Write | Promote triaged work into a tracked Falcon case: create a case-management record and attach the detections (alertIds) or LogScale events that justify it. This WRITES to the Falcon console - the case is visible to every analyst on the tenant, and calling twice creates two cases. |
Update case (yekar.crowdstrike-falcon.update-case) | Write | Change a Falcon case-management record's fields: title, description, status, severity, assignee. This WRITES to the Falcon console. Pass expectedVersion from the case you read to take the optimistic lock - without it, a concurrent edit by another analyst is overwritten with no warning. |
Get FQL guide (yekar.crowdstrike-falcon.fql-guide) | Read | The filter grammar for one search tool - the fields it accepts, their types, and worked examples, straight from the deployment rather than from memory. FQL is where these searches go wrong; read the guide before writing a non-trivial filter. |