mcp-hayabusa
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HAYABUSA_BIN | No | Path to the hayabusa binary. If not set, the system PATH will be searched. |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hayabusa_versionA | Get the installed hayabusa binary's version string. |
| hayabusa_list_profiles | List the output profiles available in this hayabusa installation. |
| hayabusa_update_rulesB | Download or update hayabusa's Sigma detection rule set. |
| get_hayabusa_rules | List available Hayabusa detection rules (the installed rule catalog). Unlike other tools here, this reads the Sigma rule YAML files directly from hayabusa's local rules directory instead of shelling out to hayabusa -- hayabusa has no subcommand that lists its full rule catalog, only rules that actually fired during a scan. Args: keyword: Optional keyword to filter rules by (case-insensitive substring match against each rule's title, description, and tags). If omitted, all rules are considered. rules_dir: Optional path to a rules directory. Defaults to the "rules" directory next to the resolved hayabusa binary. max_rules: Maximum number of matching rules to return (default 200). |
| hayabusa_csv_timeline | Run hayabusa csv-timeline over an .evtx file or a directory of them. Produces a detection timeline and returns up to max_rows result rows plus the total row count so large results stay bounded. Args: target: Path to an .evtx file or a directory containing .evtx files. profile: Optional hayabusa output profile name (see hayabusa_list_profiles for available options). min_level: Optional minimum alert level to include, e.g. "informational", "low", "medium", "high", or "critical". rules_dir: Optional path to a custom Sigma rules directory. max_rows: Maximum number of result rows to return (default 200). |
| hayabusa_json_timeline | Run hayabusa json-timeline over an .evtx file or a directory of them. Same behavior as hayabusa_csv_timeline but returns structured JSON detection records instead of CSV rows. |
| hayabusa_eid_metrics | Count event occurrences by Event ID across .evtx file(s). Args: target: Path to an .evtx file or a directory containing .evtx files. max_rows: Maximum number of result rows to return (default 200). |
| hayabusa_extract_base64 | Extract and decode base64-encoded strings found in .evtx event fields. Useful for catching obfuscated PowerShell/command-line payloads. Args: target: Path to an .evtx file or a directory containing .evtx files. max_rows: Maximum number of result rows to return (default 200). |
| hayabusa_log_metrics | Output evtx file metadata (channels, event count, date range, etc.). Args: target: Path to an .evtx file or a directory containing .evtx files. max_rows: Maximum number of result rows to return (default 200). |
| hayabusa_computer_metrics | Count events per computer name across .evtx file(s). Args: target: Path to an .evtx file or a directory containing .evtx files. max_rows: Maximum number of result rows to return (default 200). |
| hayabusa_logon_summaryA | Summarize successful and failed logon events across .evtx file(s). Returns two bounded result sets, "successful" and "failed", each with its own total_rows/returned_rows/truncated/rows. Args: target: Path to an .evtx file or a directory containing .evtx files. max_rows: Maximum number of rows to return per result set (default 200). |
| hayabusa_pivot_keywords_listA | Extract pivot keywords (users, computers, IPs, etc.) from .evtx file(s). Returns a dict of category name -> bounded keyword list, e.g. "Users", "IP Addresses", "Processes", "Command Lines" (categories come from hayabusa's pivot_keywords.txt config). Args: target: Path to an .evtx file or a directory containing .evtx files. min_level: Optional minimum alert level to include, e.g. "informational", "low", "medium", "high", or "critical". max_keywords: Maximum number of keywords to return per category (default 200). |
| hayabusa_config_critical_systemsA | Find likely domain controllers and file servers from .evtx event logs. Detects domain controllers via Security EID 4768 (Kerberos TGT requests, only logged by DCs) and file servers via Security EID 5145 (network share access, excluding the universal IPC$ share). Unlike other tools here, hayabusa has no file-output option for this subcommand and normally asks an interactive yes/no question about saving each found category to its local config. That prompt can't be answered non-interactively, so on a hit this call may take close to its timeout to return; when it does, prompt_interrupted will be true in the result and any category not present in "categories" was never reached, not confirmed as empty. Args: target: Path to an .evtx file or a directory containing .evtx files. max_hosts: Maximum number of hostnames to return per category (default 200). |
| hayabusa_searchB | Search .evtx event records for one or more keywords or regex patterns. Args: target: Path to an .evtx file or a directory containing .evtx files. keywords: Keywords (or regex patterns, if regex=True) to search for. regex: Treat keywords as regular expressions instead of literal strings. max_rows: Maximum number of matching rows to return (default 200). |
| scan_evtxA | Run a high-level first-pass scan of an .evtx file or directory. A convenience tool that combines hayabusa_log_metrics, hayabusa_csv_timeline (filtered by min_level), and hayabusa_eid_metrics into one call, plus a compact "summary" section, so a first look at a target doesn't require several separate tool calls. Args: target: Path to an .evtx file or a directory containing .evtx files. min_level: Optional minimum alert level for the detection timeline, e.g. "informational", "low", "medium", "high", or "critical". rule_filter: Optional keyword to filter detections by. Only detections whose rule title contains this keyword (case-insensitive) are included. Matching only considers detections already fetched within max_rows -- raise max_rows if a large, truncated result set might hide matches. output_format: "summary" (default) returns a concise result -- aggregate counts plus a bounded "top_findings" list -- suited for reasoning over. "full" returns the complete result: file metadata, the full detection timeline, event ID metrics, and the summary, all still subject to rule_filter/max_results. max_results: Optional maximum number of detections ("findings") to return, applied after rule_filter. Defaults to max_rows, preserving prior behavior when omitted. max_rows: Maximum number of rows to fetch per sub-result (default 200). Also bounds how many detections rule_filter can search. |
| analyze_coverageA | Analyze ATT&CK detection coverage across the installed Sigma rule set. With no technique_id, returns an overall breakdown of how many rules cover each ATT&CK technique/tactic referenced anywhere in the rule set, sorted ascending by rule count so the weakest-covered techniques/tactics are easy to spot. With technique_id, returns a focused answer for just that one technique instead (rule_count 0 / covered=False if no installed rule references it -- not an error, a normal coverage answer). IMPORTANT: coverage here means "referenced by tags on installed rules," not a gap analysis against the full MITRE ATT&CK matrix -- no MITRE reference dataset is bundled, so this cannot report techniques with zero rules across all of ATT&CK, only the distribution across what is actually installed. See coverage_scope in the result for this caveat. Args: technique_id: Optional single ATT&CK technique ID (e.g. "T1059.001") to report focused coverage for instead of the full breakdown. rules_dir: Optional path to a rules directory. Defaults to the "rules" directory next to the resolved hayabusa binary. max_items: Maximum number of techniques/tactics to include in the overall breakdown lists (default 200). Ignored when technique_id is given. |
| suggest_ruleA | Suggest existing installed Sigma rules relevant to a free-text query. Unlike get_hayabusa_rules (exact case-insensitive substring match, returns every match), this scores each rule by how many of query's terms it matches -- a title match outweighs a tags match, which outweighs a description-only match -- and returns only the top max_suggestions candidates, most relevant first. Use this for "is there already a rule for X" / "which existing rule is closest to Y"; it finds and ranks existing rules, it does not write or generate new ones. Args: query: Free-text description of the detection you're looking for, e.g. "mimikatz credential dumping". Required, non-empty. technique_id: Optional ATT&CK technique ID (e.g. "T1003.001") to restrict candidates to rules already tagged with that technique before ranking. max_suggestions: Maximum number of ranked candidates to return (default 10). rules_dir: Optional path to a rules directory. Defaults to the "rules" directory next to the resolved hayabusa binary. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| rule_catalog | Browsable index of the installed Sigma detection rule catalog, grouped by category (e.g. sigma/builtin), with per-category rule counts. For ad hoc keyword search across rules, use the get_hayabusa_rules tool instead. |
| attack_technique_coverage | ATT&CK technique ID -> detecting rules, derived from each rule's tags (e.g. attack.t1059.001). Shows which techniques have detection coverage and how many rules cover each. |
| attack_tactic_coverage | ATT&CK tactic -> detecting rules, derived from each rule's tags (e.g. attack.execution). Shows which tactics have detection coverage and how many rules cover each. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/omeryemba/mcp-hayabusa'
If you have feedback or need assistance with the MCP directory API, please join our Discord server