mcp-hayabusa
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HAYABUSA_BIN | No | Full path (or PATH-resolvable name) of the hayabusa binary to invoke. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_evtxA | Run a Hayabusa detection scan over Windows Event Log (.evtx) data. Wraps Args:
target: Path to a single .evtx file (set is_file=True) or a
directory containing .evtx files.
is_file: True if Returns: A dict shaped per result_detail; see above. |
| get_hayabusa_rulesA | List available Hayabusa/Sigma detection rules, optionally filtered by keyword. Useful for understanding what rules exist before running scan_evtx — e.g. call with keyword="mimikatz" to see which rules would be loaded by scan_evtx(rule_filter="mimikatz"), since both use the same case-insensitive match against rule file text. Args: keyword: Only return rules whose rule file text contains this string (case-insensitive), e.g. "lateral" or "mimikatz". Omit to list all rules (subject to max_results). rules_dir: Optional path to a custom Sigma/Hayabusa rules directory. Defaults to Hayabusa's bundled ./rules. max_results: Cap on the number of rules returned (default 50). total_matched in the response is always the true match count. Returns: A dict with total_matched (true count of matching rule files) and rules: a list of {path, id, title, level, status, description, author, tags, logsource}, capped at max_results. |
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 2 tools
The two tools have clearly distinct purposes: one lists available rules, the other performs a scan. There is no overlap or ambiguity.
Both tools use consistent snake_case naming with a verb_noun pattern (get_hayabusa_rules, scan_evtx), which is predictable and clear.
Two tools is slightly on the low side, but it aligns with the focused scope of the MCP server (rule listing and scanning). It is reasonable for a targeted purpose.
The core workflow of listing rules and scanning EVTX files is covered. Minor gaps exist (e.g., no tool for retrieving previous scan results or managing rules), but the essential functionality is present.