What can you do with this server?

This MCP server wraps the Hayabusa Windows event log forensic tool, enabling LLM clients to analyze .evtx files directly. Capabilities include: * Forensic analysis: Run detection timelines (CSV/JSON), keyword/regex search, extract and decode base64 strings, extract pivot keywords (users, IPs, processes, etc.), summarize logon events, and detect critical systems (domain controllers, file servers). * Metrics and summarization: Count events by Event ID or computer name, view log channel metadata (channels, event count, date range), and produce combined high-level first-pass scans (scan_evtx). * Rule and detection management: Get Hayabusa version and output profiles; update, list, and filter Sigma detection rules; analyze ATT&CK detection coverage; and suggest relevant rules by free-text query or ATT&CK technique. * Read-only resources: Browse rule catalogs by category, view full rule details by Sigma ID, and explore ATT&CK coverage by technique or tactic.

How do I use mcp-hayabusa?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-hayabusa Generate a CSV timeline from the system.evtx file in C:\logs" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-hayabusa

by omeryemba

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcp-hayabusa

Tests Version

See CHANGELOG.md for release notes.

An MCP (Model Context Protocol) server that wraps Hayabusa, the Rust-based Windows event log (.evtx) fast forensic timeline generator and threat hunting tool.

It shells out to a local hayabusa binary and exposes its analysis capabilities as MCP tools that an LLM client (Claude Desktop, Claude Code, etc.) can call directly against .evtx files.

Prerequisites

Python >= 3.10
The hayabusa binary, either on PATH or pointed to via the HAYABUSA_BIN environment variable.

Related MCP server: mcp-hayabusa

Install

pip install -e ".[dev]"

Run

mcp-hayabusa

python -m mcp_hayabusa

The server communicates over stdio, so it's meant to be launched by an MCP client rather than run interactively.

Example Claude Desktop / Claude Code config

{
  "mcpServers": {
    "hayabusa": {
      "command": "mcp-hayabusa",
      "env": {
        "HAYABUSA_BIN": "C:\\tools\\hayabusa\\hayabusa.exe"
      }
    }
  }
}

Tools

Tool	Description
`hayabusa_version`	Get the installed hayabusa binary's version.
`hayabusa_list_profiles`	List available output profiles.
`hayabusa_update_rules`	Update the Sigma detection rule set.
`get_hayabusa_rules`	List available Hayabusa/Sigma detection rules from the local rules directory, with an optional keyword filter.
`hayabusa_csv_timeline`	Run `csv-timeline` over an `.evtx` file or directory; returns bounded rows + total count.
`hayabusa_json_timeline`	Run `json-timeline` over an `.evtx` file or directory; returns bounded JSON records + total count.
`hayabusa_eid_metrics`	Count event occurrences by Event ID.
`hayabusa_computer_metrics`	Count events per computer name.
`hayabusa_log_metrics`	Output `.evtx` file metadata (channels, event count, date range, etc.).
`hayabusa_logon_summary`	Summarize successful and failed logon events.
`hayabusa_pivot_keywords_list`	Extract pivot keywords (users, computers, IPs, processes, command lines, etc.) by category.
`hayabusa_extract_base64`	Extract and decode base64-encoded strings from event fields.
`hayabusa_config_critical_systems`	Detect likely domain controllers and file servers from the logs.
`hayabusa_search`	Keyword/regex search over `.evtx` event records.
`scan_evtx`	High-level first-pass scan: combines log metadata, a detection timeline (filtered by min level and an optional rule-title keyword filter), and event ID metrics. Returns a concise `summary`/`top_findings` result by default, or the full combined result with `output_format="full"`.
`analyze_coverage`	ATT&CK detection coverage over the installed rule set: an overall technique/tactic breakdown sorted weakest-covered first, or a focused answer for one `technique_id`. Coverage is measured only against techniques/tactics referenced by installed rules, not the full ATT&CK matrix — see the tool's `coverage_scope` caveat.
`suggest_rule`	Rank installed Sigma rules by relevance to a free-text query (title match > tags match > description match), optionally scoped to an ATT&CK `technique_id`. Finds and ranks existing rules; unlike `get_hayabusa_rules`'s exact substring match, results are relevance-ordered and capped at `max_suggestions`.

Resources

Unlike the tools above (which run analysis against .evtx files you point them at), these are read-only MCP resources for browsing the installed detection rule set itself — no .evtx file required. ATT&CK technique/tactic data is derived entirely from each Sigma rule's own tags: field (e.g. attack.t1059.001, attack.execution), not a bundled MITRE dataset, so it always matches whatever rules are actually installed. Each technique also gets a mitre_url (computed from the ID, e.g. https://attack.mitre.org/techniques/T1059/001/) and each tactic a hand-maintained display_name (e.g. credential-access → "Credential Access") — see CLAUDE.md for why technique IDs are not similarly enriched with human-readable names.

Resource URI	Description
`hayabusa://rules`	Browsable rule catalog index, grouped by category, with per-category rule counts.
`hayabusa://rules/{rule_id}`	Full detail for a single rule by its Sigma `id`.
`hayabusa://attack/techniques`	ATT&CK technique ID -> detecting rules (detection coverage by technique).
`hayabusa://attack/techniques/{technique_id}`	Rules detecting a single ATT&CK technique, e.g. `hayabusa://attack/techniques/T1059.001`.
`hayabusa://attack/tactics`	ATT&CK tactic -> detecting rules (detection coverage by tactic).

Tests

pytest

All tests run against mocked subprocess calls, so no real hayabusa binary or .evtx file is required. Coverage is split across tests/test_hayabusa.py (the CLI wrapper functions), tests/test_knowledge.py (rule catalog/ATT&CK aggregation, against real small YAML fixtures), tests/test_config.py (binary resolution via HAYABUSA_BIN/PATH), and tests/test_server.py (the MCP tool and resource registrations themselves).

This does not apply to validate-rule-execution.py below, which is a separate, real-binary-required check, not part of pytest.

Custom Detection Rule Validation

This project's custom Sigma rules under rules/ are checked two ways:

validate-rule.py (.claude/skills/detection-engineering/scripts/validate-rule.py) — metadata-only: ATT&CK tag, level, falsepositives, and that a sibling .testcases.md file exists. Needs only pyyaml, no real binary. Runs in CI (validate-rules job).
validate-rule-execution.py (.claude/skills/detection-engineering/scripts/validate-rule-execution.py) — actually runs each rule against a real .evtx fixture via a real hayabusa binary and checks it fires/doesn't fire as documented in machine-readable ```yaml blocks embedded in the rule's .testcases.md. Requires the mcp_hayabusa package installed (pip install -e .) and a real hayabusa binary on PATH/HAYABUSA_BIN. Runs in CI (validate-rule-execution job, which downloads a pinned hayabusa binary), but you can also run it locally before treating a rule change as done:
```
python .claude/skills/detection-engineering/scripts/validate-rule-execution.py rules/
```
Fixtures are resolved from the HAYABUSA_SAMPLE_EVTX_DIR environment variable if set (point this at a fuller local corpus, e.g. EVTX-ATTACK-SAMPLES), otherwise from the small real fixtures vendored under tests/fixtures/evtx/ (see tests/fixtures/evtx/PROVENANCE.md for their sourcing). Exit codes: 0 all cases passed, 1 a case contradicted its documented expectation, 2 a usage/parse error, 3 no failures but at least one rule's cases were all skipped (missing binary or fixture) — kept distinct from 0 so a missing prerequisite can never look like a clean pass.

Threat Intelligence Ingestion

The /ingest-ti command (.claude/commands/ingest-ti.md) ingests IOC data from local files, normalizes it, and correlates it against this project's Sigma rule coverage. Two scripts back it, under .claude/skills/ingest-ti/scripts/:

ingest_ti.py — normalizes one input file (a native {type, value, confidence, source, first_seen, attack_technique, notes} JSON list, or a MISP Event.Attribute[] JSON export) into that fixed schema. Needs only the Python standard library. Exit codes: 0 clean, 1 some indicators skipped/coerced, 2 usage/parse error.
correlate_ti.py — takes 1+ normalized files, dedups/merges IOCs sharing a (type, value) key, and checks every ATT&CK technique they reference against this repo's installed Sigma rules via analyze_coverage/suggest_rule (mcp_hayabusa.knowledge). Optionally correlates against a saved Hayabusa scan result (--hayabusa-result) via a textual substring match. Exit codes: 0 clean, 1 issues found and/or an uncovered technique, 2 usage/parse error.

python .claude/skills/ingest-ti/scripts/ingest_ti.py intel/misp_export.json > /tmp/norm1.json
python .claude/skills/ingest-ti/scripts/correlate_ti.py /tmp/norm1.json --hayabusa-result artifacts/scan.json

v1 supports native and MISP JSON only — no STIX/TAXII or live TI feed APIs (see .claude/skills/ingest-ti/SKILL.md's "Explicitly out of scope for v1"). Both scripts are unit-tested the normal mocked-nothing way in tests/test_ingest_ti.py/tests/test_correlate_ti.py, covered by the existing pytest job — no dedicated CI job is needed since neither script touches an external binary or network.

Lint / Typecheck

ruff check .
mypy

Both run in CI (see the lint job in .github/workflows/test.yml), alongside mypy tests since the tests directory isn't covered by [tool.mypy]'s default package selection.

Available Tools

9 tools

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.

ParametersJSON Schema

Name	Required	Description	Default
`max_items`	No
`rules_dir`	No
`technique_id`	No

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It explains coverage is based on tags, that returning rule_count 0 is normal, and mentions coverage_scope field. Minor omissions: not stating read-only nature or permissions, but overall transparent.

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 main purpose, behavior details, important caveat, and Args list. Every sentence adds value, though slightly verbose. Good front-loading of key info.

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?

No output schema, but description adequately describes return structure (overall breakdown or focused answer, coverage_scope field). Sufficient for the tool's complexity.

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?

Schema description coverage is 0%, yet the description fully explains all three parameters: technique_id (focused vs full), rules_dir (default path), and max_items (default, ignored with technique_id). Adds significant context beyond schema.

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?

The description clearly states it analyzes ATT&CK detection coverage across installed Sigma rules. It distinguishes behavior with and without technique_id, and implicitly differentiates from sibling tools like search or suggest_rule by focusing on coverage analysis.

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?

The description provides clear context and an important caveat explaining what coverage means (tags on installed rules, not full ATT&CK matrix). However, it does not explicitly state when to avoid this tool or mention specific alternatives among siblings.

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

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).

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`max_hosts`	No

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden and thoroughly discloses the interactive yes/no prompt issue, the resulting timeout behavior, and the interpretation of 'prompt_interrupted' and absent category fields. This is excellent transparency for a tool with hidden side effects.

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?

The description is somewhat lengthy but well-structured: purpose first, then detection method, then behavioral caveat, then parameters. Every sentence adds value, though the interactive prompt explanation could be slightly condensed. Still, it earns its length.

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

Completeness5/5

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

Given two parameters, no output schema, and the complexity of the interactive prompt issue, the description covers all necessary aspects: purpose, detection logic, behavioral edge cases, and parameter details. It is fully sufficient for an AI to invoke correctly.

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

Parameters4/5

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

Although schema coverage is 0%, the description explains both parameters: 'target' as a path to .evtx file/directory, and 'max_hosts' with default 200. This adds meaning beyond the parameter names in the schema, though it could specify valid file types or directory structure.

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?

The description clearly states the tool finds domain controllers and file servers from .evtx logs, with specific detection methods (EID 4768 for DCs, EID 5145 for file servers). The verb 'find' and resource 'critical systems' are specific and distinct from siblings like 'hayabusa_search' or 'scan_evtx'.

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?

The description explains the tool's purpose and highlights a critical behavioral difference (interactive prompt, timeout) compared to 'other tools here'. It does not explicitly list when not to use it or name specific alternatives, but the context is clear enough for an AI to decide.

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

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).

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`max_rows`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses the return structure (two bounded result sets with metadata) and parameter behavior (target as file/directory, max_rows default 200), covering key behavioral traits.

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

Conciseness5/5

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

The description is concise, front-loaded with the core purpose, and efficiently provides parameter and output details without extraneous text.

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

Completeness5/5

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

With no output schema, the description adequately explains the output format (two result sets with metadata and rows) and both parameters, covering all necessary context for a tool of this complexity.

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

Parameters4/5

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

Schema coverage is 0%, but the description adds meaningful details: target description as path to .evtx file or directory, and max_rows as per-result-set limit with default.

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?

The description clearly states it summarizes successful and failed logon events from .evtx files, which distinguishes it from sibling tools like hayabusa_search (general search) and scan_evtx (generic scan).

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

Usage Guidelines3/5

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

The description implies usage for logon event summarization but does not explicitly advise when to use this tool versus alternatives like hayabusa_search or scan_evtx.

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

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).

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`min_level`	No
`max_keywords`	No

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description provides some behavioral context: it returns a bounded keyword list per category and depends on a config file. However, it does not mention side effects (e.g., read-only, file locking, permissions), performance for large files, or error scenarios. Additional behavioral details beyond the output structure are missing.

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

Conciseness5/5

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

The description is concise and well-structured: a one-sentence purpose, a return-format note, then a clear Args list. Every sentence adds value, and the key action is front-loaded. No redundant or irrelevant content.

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

Completeness3/5

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

Given no output schema and no annotations, the description explains the return format (dict of category->list) but not exact data types or categories. It omits edge cases, error handling, and performance notes. While serviceable for a simple listing tool, it lacks completeness for an agent to fully understand outputs and limitations.

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?

The schema has 0% description coverage, but the description fully explains each parameter: target (path to file or directory), min_level (optional with example values), and max_keywords (default 200). This adds rich semantics beyond the schema's type and title, making the parameters actionable for an agent.

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?

The description clearly states the tool extracts pivot keywords (users, computers, IPs, etc.) from .evtx files and returns a dict of category->keyword list. This distinguishes it from siblings like hayabusa_search (search events) and scan_evtx (generic scan). The verb 'Extract' and specific resource 'pivot keywords' make the purpose unambiguous.

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

Usage Guidelines3/5

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

The description explains what the tool does but does not explicitly state when to use it over alternatives. It implies usage for obtaining pivot keywords but lacks when-not or alternative tool guidance. Sibling tools are listed but not differentiated in usage context.

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

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).

ParametersJSON Schema

Name	Required	Description	Default
`regex`	No
`target`	Yes
`keywords`	Yes
`max_rows`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations and no disclosure of behavioral traits like read-only nature, error handling, or performance implications beyond basic search function.

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?

Concise and well-structured: one-line summary followed by bulleted args. No extraneous text, though slightly more context on behavior could fit.

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

Completeness3/5

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

Covers all parameters but lacks output description, error handling, or performance notes. Adequate for a simple search tool given no annotations or output schema.

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

Parameters4/5

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

With 0% schema description coverage, the Args section explains all four parameters (target, keywords, regex, max_rows) with clear semantics and defaults, adding value.

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?

Clear verb ('search') and specific resource ('.evtx event records') with differentiation from sibling tools focused on logon summaries or rule scanning.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., scan_evtx, hayabusa_logon_summary) or what contexts are appropriate.

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

hayabusa_update_rulesB

Download or update hayabusa's Sigma detection rule set.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states that rules are downloaded or updated, but omits details like whether existing rules are overwritten, if network access is required, or any side effects. This is minimal disclosure.

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

Conciseness5/5

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

The description is a single, 10-word sentence that conveys the tool's purpose without unnecessary words. Every word earns its place.

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

Completeness3/5

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

Given the tool has no parameters and a simple action, the description conveys the core purpose. However, it lacks context about potential impacts (e.g., overwriting local rules) and prerequisites. It is adequate but could be more informative.

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

Parameters3/5

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

The input schema has no parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. Following the rule, baseline is 3 when coverage is high.

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?

The description uses specific verbs 'Download or update' and identifies the resource 'hayabusa's Sigma detection rule set', making the action and target clear. It distinguishes itself from siblings like hayabusa_search (searching) and scan_evtx (scanning).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It merely states what it does, leaving the agent to infer context from the action. No exclusions or when-not-to-use information is given.

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

hayabusa_versionA

Get the installed hayabusa binary's version string.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

The description accurately indicates a read-only, non-destructive operation. No annotations are provided, but the description suffices for such a simple tool.

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

Conciseness5/5

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

Single sentence, no wasted words.

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

Completeness5/5

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

Given zero parameters and an existing output schema, the description fully captures the tool's purpose.

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

Parameters4/5

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

No parameters exist, so baseline 4 applies. The description adds meaning by specifying what value is returned.

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?

Clearly states the action 'Get' and the resource 'installed hayabaya binary's version string'. Differentiates from siblings that perform other operations.

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?

No explicit when/when-not guidance, but the tool is simple and self-explanatory. For a version query, no alternatives are needed.

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

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.

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`max_rows`	No
`min_level`	No
`max_results`	No
`rule_filter`	No
`output_format`	No	summary

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It explains that the tool combines sub-tools, details output formats, and warns about rule_filter only considering max_rows detections. However, it does not mention side effects or permissions.

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?

The description is well-structured with an Args list, but it is somewhat lengthy. Every sentence is useful, though some redundancy could be trimmed.

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

Completeness5/5

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

Despite no output schema, the description covers both output formats and their contents. All parameters are explained, and the tool's purpose as a combination of sub-tools is clear. Complete for a scanning tool.

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?

Schema coverage is 0%, but the description thoroughly explains all 6 parameters (target, min_level, rule_filter, output_format, max_results, max_rows) with their defaults and interactions, providing critical context beyond the schema.

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?

The description clearly states 'first-pass scan of an .evtx file or directory' as a convenience tool combining multiple functions. It distinguishes itself from sibling tools like hayabusa_search by being a high-level overview.

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

Usage Guidelines3/5

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

The description implies usage for initial exploration ('first look at a target'), but it does not explicitly specify when to use alternatives or provide exclusion criteria.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`rules_dir`	No
`technique_id`	No
`max_suggestions`	No

TDQS

A4.7/5.0

Behavior5/5

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

The description details the scoring mechanism (title match > tags > description match), the return of only top max_suggestions candidates, and that it ranks existing rules without writing new ones. Even without annotations, the behavioral traits are well disclosed.

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?

The description is well-structured with a clear purpose first, then contrast, usage guidance, and parameter details. It is slightly verbose but every sentence adds value; minor trimming could improve conciseness.

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

Completeness3/5

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

The description lacks details about the return value structure (e.g., list of rules with scores). Given no output schema, this gap reduces completeness. Otherwise, it covers inputs and behavior well.

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?

Despite 0% schema description coverage, the description compensates with thorough inline parameter explanations, including default values, constraints (e.g., query non-empty), and optional parameters like technique_id and rules_dir.

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?

The description clearly states the tool suggests existing installed Sigma rules relevant to a free-text query. It distinguishes the tool's purpose from get_hayabusa_rules by explaining different matching and ranking behaviors.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool ('is there already a rule for X' / 'which existing rule is closest to Y') and contrasts it with get_hayabusa_rules, which provides exact substring matching. It also clarifies that the tool does not write or generate new rules.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0Jul 26, 2026
- First observedanalyze_coverage
- First observedhayabusa_config_critical_systems
- First observedhayabusa_logon_summary
- First observedhayabusa_pivot_keywords_list
- First observedhayabusa_search
- First observedhayabusa_update_rules
- First observedhayabusa_version
- First observedscan_evtx
- First observedsuggest_rule

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-26 15:44 across 9 tools

Disambiguation5/5

Each tool targets a distinct task: rule updates, logon summary, version retrieval, keyword extraction, critical system detection, search, combined scan, coverage analysis, and rule suggestion. No two tools have overlapping purposes.

Naming Consistency2/5

Naming is inconsistent: six tools use the 'hayabusa_' prefix, while three (scan_evtx, analyze_coverage, suggest_rule) do not. Verb patterns also vary (e.g., 'update_rules' vs 'logon_summary').

Tool Count5/5

With 9 tools, the server is well-scoped for Windows event log analysis. Each tool addresses a specific need without redundancy or excessive granularity.

Completeness4/5

The surface covers rule management, detection, search, keyword extraction, system identification, and coverage analysis. Minor gaps exist (e.g., no dedicated tool to list all rules or export results), but core workflows are supported.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
1
clawmanagerfleet-mcp
com.clauxel.clawmanagerfleet
A paid remote MCP for ClawManager, built to return verdicts, receipts, usage logs, and audit-ready J
Payments & Billing Monitoring
2
pentest-mcp-server A
io.github.cyanheads
Offline methodology engine for authorized penetration testing, CTF, and security research.
Penetration Testing Security
721
Virustotal A
io.github.pipeworx-io
VirusTotal MCP — file / URL / domain / IP reputation (BYO key)
Security Monitoring
352

Related MCP Servers

hayabusa-mcp
Security Observability
Pirate-Kitty
A
license
Not graded
quality
B
maintenance
Enables Windows Event Log (EVTX) analysis by wrapping Hayabusa, exposing scan and rule retrieval tools.
Updated 2 months ago (2026-07-17 20:44 UTC)
MIT
mcp-hayabusa
Security Observability
TregardLabs-Dana
F
license
Not graded
quality
B
maintenance
Enables scanning Windows EVTX event log files with Hayabusa, returning structured detection results through an MCP tool.
Updated 2 months ago (2026-07-21 01:22 UTC)
-
mcp-hayabusa
Security Monitoring
baobao26
F
license
Not graded
quality
B
maintenance
An MCP server that wraps the Hayabusa CLI, enabling analysis of Windows EVTX event log files and browsing of its detection rule set.
Updated 2 months ago (2026-07-18 14:18 UTC)
-
mcp-hayabusa
Security Command Line
msadigo
A
license
A
quality
B
maintenance
Enables MCP clients to run Hayabusa detection scans over Windows event log (.evtx) files for forensic analysis and threat hunting.
Updated 2 months ago (2026-07-18 20:38 UTC)
2
MIT