Skip to main content
Glama
msadigo

mcp-hayabusa

by msadigo

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HAYABUSA_BINNoFull 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
scan_evtxA

Run a Hayabusa detection scan over Windows Event Log (.evtx) data.

Wraps hayabusa csv-timeline / hayabusa json-timeline, always run non-interactively (no rule-config wizard, no launch banner).

Args: target: Path to a single .evtx file (set is_file=True) or a directory containing .evtx files. is_file: True if target is a single .evtx file rather than a directory. output_format: "csv" (uses csv-timeline), or "json"/"jsonl" (both use json-timeline; jsonl adds Hayabusa's -L flag). This controls Hayabusa's own output format, not the shape of the dict returned by this tool — see result_detail for that. rules_dir: Optional path to a custom Sigma/Hayabusa rules directory or file (passed as -r). Defaults to Hayabusa's bundled ./rules. Ignored if rule_filter is set (see below). rule_filter: Only run rules whose rule file text contains this string (case-insensitive), e.g. "lateral" or "mimikatz". Hayabusa has no native free-text rule filter, so this copies matching rule files from rules_dir (or Hayabusa's default ./rules) into a temporary rules directory and scans with just those loaded. min_level: Optional minimum alert level to load: "informational", "low", "medium", "high", or "critical" (passed as -m). utc: Output timestamps in UTC instead of local time (-U). output_path: Where to write the full result file. If omitted, a temporary file is used and deleted after a preview is extracted, so the full result set is only kept on disk when you pass this explicitly. result_detail: "summary" (default) returns counts by level, the top matching rules, and a condensed preview (key fields only); stdout/stderr tails are only included on non-zero exit. "full" returns the complete record preview with all fields plus stdout/stderr tails, as before. max_results: Cap on the number of preview records returned (default 20). Does not affect record_count, which is always the true total.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one lists available rules, the other performs a scan. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools use consistent snake_case naming with a verb_noun pattern (get_hayabusa_rules, scan_evtx), which is predictable and clear.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityStale
ResponsivenessNo issues