Skip to main content
Glama
msadigo

mcp-hayabusa

by msadigo

scan_evtx

Scan Windows Event Log (.evtx) files with Hayabusa rules to detect threats. Output results in CSV or JSON, filter by rule text or severity.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
utcNo
targetYes
is_fileNo
min_levelNo
rules_dirNo
max_resultsNo
output_pathNo
rule_filterNo
output_formatNojson
result_detailNosummary
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description discloses key behaviors: wraps hayabusa commands, runs non-interactively, temporary file handling for output_path, rule_filter copying, and result_detail controls. Could add error handling or permissions but is comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose first, then parameter details, then return. Each sentence adds value, though slightly lengthy. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (10 params, no annotations, no output schema), description covers parameters, return shape, and behavioral nuances. Lacks error cases or performance notes but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description fully explains all 10 parameters with context, defaults, and relationships to underlying tool. Adds meaning beyond field names, e.g., rule_filter copies files, result_detail controls preview.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it runs a Hayabusa detection scan on .evtx files, distinguishing it from sibling tool 'get_hayabusa_rules' which retrieves rules. Verb 'scan' and resource 'Windows Event Log (.evtx) data' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains when to use the tool (scanning evtx files) and contrasts with sibling tool. Provides context on interactive vs non-interactive, default behaviors, and output handling. Lacks explicit when-not-to-use or alternative tools beyond the sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/msadigo/mcp-hayabusa'

If you have feedback or need assistance with the MCP directory API, please join our Discord server