One-call situational awareness: manager version and uptime, the state of every Wazuh daemon, cluster status, agent connection counts and Indexer cluster health. Call this first when asked 'is Wazuh healthy' or when starting an investigation.

Detailed cluster view: whether clustering is enabled, each node's role and address, and the manager's own healthcheck output including per-node sync status and agent distribution.

Read and filter ossec.log entries from the manager. Use this to diagnose ingestion problems, integration failures or daemon errors — filter to level='error' to see only what is broken.

Event-processing statistics from the manager: analysisd queue usage and event rates, remoted reception counts, or hourly/weekly alert volumes. Use analysisd stats to spot dropped events and queue saturation.

Read the manager's running ossec.conf configuration, optionally narrowed to one section. Use this to confirm what is actually enabled — which modules, integrations, log sources or remote settings.

Escape hatch for Manager API endpoints without a dedicated tool — for example /agents/stats/distinct, /tasks/status, /security/users, /overview/agents, or /experimental/* inventory endpoints. GET only, so it cannot change state. Prefer the purpose-built tools when one fits; they shape their output for readability.

List and filter agents enrolled with the Wazuh manager. Use this to answer 'which endpoints are disconnected', 'what agents are in group X', or 'which agents run an outdated version'. Supports server-side filtering, sorting and paging.

Full picture of a single agent: registration and connection state, operating system, hardware, group membership and installed-package count. Start here when investigating a specific endpoint.

Aggregate health of the whole agent fleet: connection-state counts, OS distribution, agents on outdated versions and agents with no group. The fastest way to answer 'how healthy is my deployment'.

List configured agent groups with their member counts and configuration checksums. Pass a group name to list its members instead.

Fetch the configuration a running agent has actually loaded for one module — useful for confirming a group change or centralised config reached the endpoint. Common pairs: component='syscheck' configuration='syscheck', component='wmodules' configuration='wmodules', component='agent' configuration='client'.

Restart one or more agents. This interrupts monitoring on the target endpoints while they come back up, and requires WAZUH_ALLOW_WRITE=true.

Search security alerts in the Wazuh Indexer over a time window. This is the main tool for questions like 'show me critical alerts in the last hour', 'what fired on server-db-01 yesterday', 'find SSH brute force attempts', or 'alerts matching MITRE T1110'. Returns a compact projection of each alert by default.

Group alerts by one or two fields and return counts — the tool for 'top 10 rules today', 'which agents are noisiest', 'alert counts by MITRE tactic', or 'top source IPs per agent'. Far cheaper than fetching alerts and counting them yourself.

Bucket alert counts into time intervals to show trend and spikes — 'was there a spike overnight', 'alert volume per hour this week'. Optionally splits each interval by a field such as severity or agent.

Escape hatch: send a raw OpenSearch query DSL body to a Wazuh index for anything the purpose-built alert tools cannot express — unusual aggregations, scripted fields, composite queries. Restricted to wazuh-* indices and read-only _search.

List the wazuh-* indices with health, document counts and sizes, plus Indexer cluster health. Use this to confirm what data exists and how far back it goes before querying.

List CVEs Wazuh has detected on endpoints, filterable by agent, severity, CVE ID and package. Answers 'what critical CVEs do we have', 'is CVE-2024-3094 anywhere in the estate', or 'which vulnerable packages are on this host'. Works on both 4.8+ (Indexer state) and earlier (Manager API) deployments.

Aggregate vulnerability exposure across the fleet: counts by severity, the most affected agents, the most common CVEs and the worst offending packages. Use this for exposure reporting and to decide where to look in detail.

Search the manager's ruleset. Use this to explain why an alert fired, to find every rule covering a compliance control ('which rules map to PCI DSS 10.2.4'), or to audit which high-severity rules are enabled.

Fetch a single rule including its full XML definition, so you can explain exactly what conditions trigger it and what it is mapped to.

Enumerate the rule groups in the ruleset, or every value present for one compliance framework. Useful for discovering valid filter values before calling wazuh_list_rules or wazuh_search_alerts.

Search the decoders that parse raw logs into fields. Use this when an alert's fields look wrong or absent, to see how a log source is being parsed.

Look up MITRE ATT&CK techniques, tactics, groups, software or mitigations from the manager's bundled catalogue. Use it to expand a technique ID seen in an alert into its description, tactics and mitigations.

List the CDB (constant database) lists used by rules for lookups such as known-bad IPs, allowed users or audit keys, optionally including their contents.

List an agent's Security Configuration Assessment policies with pass/fail counts and hardening scores — CIS benchmarks and similar. Use this to answer 'how well hardened is this host' before drilling into individual failed checks.

List the individual configuration checks in one SCA policy, including the remediation text for each. Filter to result='failed' to get an actionable hardening list for a host.

Query File Integrity Monitoring (syscheck) state for an agent: which monitored files and registry keys exist, their hashes, permissions and how many times they have changed. Use it to answer 'was this binary modified' or 'what changed in /etc'.

Read rootcheck findings for an agent — rootkit signatures, hidden processes and legacy policy-monitoring hits. Note this is Wazuh's older assessment module; SCA (wazuh_sca_checks) is the modern equivalent and usually more useful.

Ask agents to start a syscheck (FIM) scan now instead of waiting for the schedule. This puts load on the target endpoints and requires WAZUH_ALLOW_WRITE=true.

Read collected inventory from one endpoint: installed packages, running processes, listening ports, network interfaces and addresses, hardware, OS or Windows hotfixes. Use it for questions like 'what is listening on this host', 'is package X installed', or 'what patches are missing'.

Search for a package across every agent at once — the tool for vulnerability response questions like 'which hosts have log4j installed' or 'who is still on OpenSSL 1.1.1'. Returns the matching package and version per agent.

Build a ready-to-share report by combining several Wazuh sources into one narrative with a markdown rendering. Report types: executive_summary (posture overview for leadership), threat_activity (top threats, MITRE breakdown, attacking IPs), agent_health (connectivity and version drift), vulnerability_exposure (CVE exposure by severity and host), compliance (control coverage for a framework), file_integrity (FIM change activity), authentication (login failures and brute-force patterns). Use this instead of stitching many tool calls together by hand.

Execute an active-response command on agents — blocking an IP with firewall-drop, disabling an account, null-routing a host. This changes the state of production endpoints and can cut off network access, so it requires WAZUH_ALLOW_WRITE=true and should be confirmed with a human before use.