Skip to main content
Glama
MadameFabulous

Chainsaw MCP Server

by MadameFabulous
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Chainsaw: hunt with detection rules

chainsaw_hunt

Scan evidence files with Sigma and Chainsaw detection rules to return aggregate detection counts by rule, level, host, channel, event ID, and hour, plus a preview.

Instructions

Hunt evidence with Sigma and Chainsaw detection rules.

Runs chainsaw hunt over the given paths, stores every detection as JSONL under a server-minted result handle, and returns aggregate counts (by rule, level, host, channel, event ID, hour) with a small preview. Prefer this over reading raw events.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindsNoRestrict loaded rules to these kinds: chainsaw, sigma.
pathsYesEvidence files or directories, relative to an allowed evidence root or absolute inside one. Directories are searched recursively.
sigmaNoApply the bundled Sigma rules through the mapping file.
fieldsNoDotted paths or shorthand names to project in the inline preview; see chainsaw_result_fields. Omit for the standard shorthand columns.
levelsNoRestrict rules to these levels: critical, high, medium, low, info.
mappingNoMapping file name inside the mappings directory. Default sigma-event-logs-all.yml; sigma-event-logs-legacy.yml for pre-Sysmon logs.
previewNoDetections to include inline (0-100).
to_timeNoDrop documents newer than this, format YYYY-MM-DDTHH:MM:SS.
statusesNoRestrict loaded rules to these statuses: stable, experimental.
timezoneNoRender timestamps in this IANA timezone (default UTC).
extensionNoOnly load files with this extension, e.g. evtx.
from_timeNoDrop documents older than this, format YYYY-MM-DDTHH:MM:SS.
extra_rulesNoAdditional Chainsaw-format rule directories: 'custom' for analyst-saved rules, or 'chainsaw/<subdir>' such as 'chainsaw/evtx/lateral_movement'.
skip_errorsNoContinue past unreadable files instead of failing the hunt.
load_unknownNoLet chainsaw try to parse files it cannot identify.
chainsaw_rulesNoApply the bundled Chainsaw rules (rules/ directory).
sigma_collectionsNoSigma collections or sub-trees to load, e.g. ['rules'], ['rules', 'rules-threat-hunting'] or ['rules/windows/process_creation']. Default: ['rules']. Use chainsaw_rule_stats to see what is installed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and the description meaningfully adds to this: it explains that detections are persisted as JSONL under a server-minted result handle and that the response is aggregate counts plus a small preview rather than raw detections. That side-effect (writing results) and the 'result handle' retrieval model are genuinely non-obvious. It stops short of naming the chainsaw_result_* retrieval path beyond a reference to chainsaw_result_fields.

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?

Two compact sentences, with the action and its scope front-loaded and the storage/return behavior immediately after. No filler, and every clause carries information the agent needs.

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?

Despite 17 parameters and no output schema, the description explains what is returned (aggregate counts by rule, level, host, channel, event ID, hour, plus a preview) and where full detections live, which compensates for the missing output schema. Minor gaps remain around how to fetch the full stored result set and rule-loading defaults, but nothing essential to invoking the tool correctly is missing.

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?

Schema description coverage is 100%, so the baseline is 3; every one of the 17 parameters is documented in the schema itself. The description adds no parameter-level meaning beyond what the schema provides, which is acceptable given the schema's completeness but not above baseline.

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?

States a specific verb and resource ('Hunt evidence with Sigma and Chainsaw detection rules') and follows with the exact underlying command ('Runs `chainsaw hunt` over the given paths'), making the operation unambiguous. It is distinguishable from siblings like chainsaw_search, chainsaw_dump, and the chainsaw_analyse_* family, which do not run detection rules.

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?

'Prefer this over reading raw events' gives a clear directional guideline toward this tool versus raw evidence inspection. However, it never names a concrete sibling alternative (e.g. chainsaw_search or chainsaw_dump) or states when NOT to use it, so the routing guidance is contextual but not exhaustive.

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

Deploy Server

Other Tools