RSigma’s MCP server exposes its Sigma detection engineering toolchain to AI agents.
Parse Sigma YAML rules and condition expressions into structured AST/JSON.
Validate and lint rules against the Sigma specification, including auto-fixes.
Convert rules to native PostgreSQL/LynxDB/Fibratus queries or delegate to sigma-cli backends.
Reverse-convert SIEM queries into draft Sigma rules.
Evaluate JSON/NDJSON events against rules with optional pipelines and correlation support.
List referenced fields, builtin pipelines, and available conversion backends.
Resolve processing pipelines and dynamic sources.
Report ADS sections and scaffold missing rsigma.ads.* metadata.
Replay embedded rsigma.exemplars tests for detection and correlation rules.
Tune rules by proposing filters from false-positive and true-positive events.
Delivers detection alerts to Discord via webhook with templated payloads and HMAC signing.
Ingests logs from Fluent Bit via the OpenTelemetry protocol for real-time detection.
Integrates with GitHub Actions for CI: linting, validation, field-drift diff, backtesting, and coverage in a single pull-request check.
Accepts log forwarding from Grafana Alloy (and other OpenTelemetry-compatible agents) for detection.
Receives logs via OTLP (HTTP/gRPC) and exports detection results to an OTLP collector.
Sends detection alerts to PagerDuty via webhook with retry, rate limiting, and dead-letter queue.
Exposes detection pipeline metrics in Prometheus format for monitoring and alerting.
RSigma is a complete detection engineering toolkit for the Sigma detection standard, including a parser, evaluation engine, rule conversion, streaming runtime, linter, CLI, MCP, and LSP.
RSigma parses Sigma YAML rules into a strongly-typed AST, compiles them into optimized matchers, and evaluates them against log events in real time. It handles stateful correlation logic in-process with memory-efficient compressed event storage. Or as Zack Allen put it in DEW #149, "RSigma is essentially a SIEM."
You can send events in many formats, including JSON, syslog (RFC 3164/5424), logfmt, CEF, EVTX (Windows Event Log), plain text, and OTLP (OpenTelemetry Protocol), with auto-detection by default. pySigma-compatible processing pipelines handle field mapping and backend configuration. OTLP support lets any OpenTelemetry-compatible agent (Grafana Alloy, Vector, Fluent Bit, OTel Collector) forward logs to RSigma via HTTP or gRPC for detection.
For rule quality and editor integration, a built-in linter validates rules against 90 checks derived from the Sigma v2.1.0 specification, and an LSP server provides real-time diagnostics, completions, hover documentation, and quick-fix code actions in any editor.
RSigma builds on open industry standards throughout: Sigma for detection rules, OpenTelemetry for log ingestion and detection export, and STIX and TAXII for threat intelligence.
Full documentation, including guides, CLI reference, and library API docs, lives at rsigma.io.
Sigma parsing: Parses Sigma YAML into a strongly-typed AST with support for detection, correlation, and filter rules
Array matching (experimental): Matches members of arrays in nested event data with any/all-member semantics, same-element correlation, and positional indexing, opt-in via sigma-version: 3
Rule drafting: Drafts detection rules and temporal correlations from exemplar events contrasted against a baseline corpus with rule draft
Rule tuning: Proposes a spec-native filter from false-positive events, verifies that every known true positive still fires, and refuses unsafe separators with rule tune
Built-in linter: Validates rules with 90 checks, four severity levels, suppressions, custom tag namespaces, and auto-fix for 14 safe rules
ADS metadata: Documents rules with Palantir ADS sections under rsigma.ads.*, enforced by the linter and scaffolded with rule doc
LSP server: Provides real-time diagnostics, completions, hover documentation, document symbols, and quick-fix code actions in VSCode, Neovim, and any LSP-capable editor
MCP server: Exposes the toolchain to AI agents (Cursor, Claude Code, ...) as structured MCP tools over stdio or Streamable HTTP with rsigma mcp serve
Detection diagnostics: Explains why a rule did or did not match an event with engine explain, diffs pipeline transformations with pipeline diff, and introspects live correlation windows
Corpus backtesting: Replays an event corpus against declared per-rule expectations with rule backtest, emitting a JSON or JUnit XML report for CI
Output formats: Structured commands render JSON, NDJSON, table, CSV, or TSV with a TTY-aware default via a global --output-format flag; artifact and protocol commands keep their fixed wire format (see the per-command contract)
CI integration: Gates a rule repository in one pull-request check with the timescale/rsigma-action GitHub Action, wrapping lint, validate, fields-drift diff, backtest, and coverage
Configuration: Layers settings from YAML config files, environment variables, and CLI flags, managed with the rsigma config command group
Signed artifacts: Ships multi-arch Docker images with cosign signatures, SBOM, and SLSA Build L3 provenance, plus prebuilt binaries for Linux, macOS, and Windows
Rule evaluation: Compiles rules into optimized matchers and evaluates them against events in real time, with stateless detection and stateful correlation (sliding/tumbling/session windows, group-by, chaining, suppression)
Streaming daemon: Runs as a long-lived detection daemon with hot-reload, Prometheus metrics, stdin/HTTP/NATS/OTLP/Unix-socket input, and async sinks (stdout, file, NATS, OTLP, webhook, Unix socket) with per-sink retry, DLQ, and a per-sink wire format (native NDJSON or OCSF Detection Finding JSON)
Input formats: Ingests JSON, syslog (RFC 3164/5424), logfmt, CEF, EVTX (Windows Event Log), plain text, and OTLP logs with format auto-detection
Processing pipelines: Maps fields and transforms rules with pySigma-compatible pipelines (transformations, conditions, finalizers)
Dynamic pipelines: Populates any pipeline value from external sources (HTTP, files, commands, NATS) with template expansion, auto-refresh, and extraction via jq, JSONPath, or CEL
Schema recognition: Recognizes which schema each event uses (ECS, Sysmon, CEF, OCSF, or user-defined) with engine classify, watches a live daemon for unrecognized sources, and mines candidate signatures with engine discover-schemas
Schema routing: Builds one engine per pipeline set and dispatches each classified event to its engine, feeding a shared correlation store
Logsource routing: Skips rules whose logsource conflicts with an event's declared product/service/category, so a mixed-product stream only pays for the rules that can match
Eval prefilters: Prunes large rule sets before evaluation with a bloom substring prefilter and a cross-rule Aho-Corasick index
NATS JetStream: Consumes and publishes over JetStream with authentication (credentials, mTLS), replay, consumer groups, and dead-letter queues
OTLP integration: Receives logs from any OpenTelemetry-compatible agent (Grafana Alloy, Vector, Fluent Bit, OTel Collector) via HTTP or gRPC, and exports detections to an OTLP collector
TLS termination: Terminates TLS in-process on the daemon API listener with optional mutual TLS and cross-platform certificate hot-reload
State persistence: Persists correlation, alert-pipeline, risk, and disposition state to SQLite with --state-db and restores it across restarts. The capture ring is not persisted.
Live operations: Inspects a running daemon with engine status, records replayable fixtures with engine tap, and streams live detections with engine tail
Enrichment: Injects context (asset info, IP reputation, identity, GeoIP, runbook URLs, ...) into detection and correlation results via template, lookup, http, and command primitives
Risk-based alerting: Scores each firing per entity (user, host, source IP) and raises a single incident when an entity's accumulated risk crosses a threshold
Alert pipeline: Silences, inhibits, and deduplicates results, then groups the survivors into incidents, modeled on Alertmanager
Webhook alerts: Delivers detections to Slack, Teams, Discord, PagerDuty, or any HTTP endpoint with templated payloads, HMAC request signing, per-webhook retry, rate limiting, and DLQ
Triage feedback: Ingests analyst dispositions into a per-rule false-positive ratio that feeds the detection scorecard
Verdict-driven corpora: Retains admitted group_by detection events and writes TP/FP bundles after an accepted disposition for rule backtest and rule tune --from-dispositions
ATT&CK coverage: Exports an ATT&CK Navigator layer with rule coverage and reports gaps against Atomic Red Team, the SigmaHQ baseline, and a target technique list
Telemetry visibility: Scores data-source maturity with rule visibility, exporting DeTT&CT administration files and a Navigator layer that surfaces blind spots
Field observability: Surfaces which event fields no rule references and which rule fields never appear in events, live on the daemon or as a one-shot report from engine eval
Detection scorecard: Fuses backtest, coverage, production-volume, and triage signals with rule scorecard into per-rule keep/tune/retire verdicts
Rule hygiene: Flags retirement candidates with rule hygiene: silent, noisy, untagged, unowned, incomplete ADS, broken field coverage, or stale status
Rule conversion: Converts rules into backend-native queries via a pluggable backend trait, with native PostgreSQL/TimescaleDB, LynxDB, and Fibratus backends plus sigma-cli delegation for 30+ pySigma backends (Splunk, Elasticsearch, Microsoft Sentinel, ...)
Hunt execution: Runs converted detection rules read-only against a PostgreSQL/TimescaleDB archive with hunt run and streams matching rows back as exemplar-shaped NDJSON that rule draft, rule tune, rule test, and rule backtest consume directly
Field catalog: Lists every field a ruleset references, before or after pipeline mapping, with rule fields
Related MCP server: wrg-sigma-rules
Crate | Description |
Parse Sigma YAML into a strongly-typed AST | |
Intermediate representation shared by evaluation and conversion | |
Compile and evaluate rules against JSON events | |
Transform rules into backend-native query strings | |
Streaming runtime with input adapters, log processor, and hot-reload | |
Model Context Protocol (MCP) server exposing the toolchain as tools for AI agents | |
CLI for parsing, validating, linting, evaluating, converting rules, field catalog, and running a detection daemon | |
Language Server Protocol (LSP) server for IDE support | |
STIX 2.1 library: typed objects, bundle parse/stream, semantic validation, and pattern engine |
To learn more about RSigma, read these articles:
RSigma has been featured in:
Detection Engineering Weekly #149 (March 2026) "Building a tool like RSigma is challenging because the Sigma specification has evolved into a robust domain-specific language over the years."
tl;dr sec #320 (March 2026) "Accurately evaluating the full spectrum of what Sigma rules can express is quite complex, it's pretty neat to read about how RSigma handles all of these conditional expressions, correlating across rules, etc."
The Deep Purple Sec by BlackNoise - March 2026 (April 2026) "Defensive teams can pipe logs through CLI commands, apply field-mapping pipelines, and chain correlations for multi-stage attack detection."
Detection Engineering Weekly #154 (April 2026) "RSigma is not a SIEM, but it's an impressive feat to build a self-contained Rust binary that operates much like one. For teams doing pre-SIEM rule validation or forensics, it's a solid plug-and-play option."
Detection Engineering Weekly #157 (May 2026) "Instead of hardcoding IOC values in rule YAML, you declare external sources in the pipeline config, and RSigma fetches and injects them at evaluation time. This works very similarly to how I've seen SIEMs implement threat intelligence pipelines, but since it's RSigma, it's self-contained within its ecosystem."
Prebuilt binaries for Linux, macOS, and Windows (amd64 and arm64), with SLSA Build L3 provenance, are attached to every GitHub release.
Or install from crates.io:
# Install the CLI
cargo install --locked rsigma
# Install the LSP server
cargo install --locked rsigma-lspTo build from source:
cargo build --release --all-features --workspaceMulti-arch images (linux/amd64, linux/arm64) are published to GHCR on every release, signed with cosign and carrying an SPDX SBOM and SLSA Build L3 provenance. See the Docker deployment guide.
docker pull ghcr.io/timescale/rsigma:latest
docker run --rm ghcr.io/timescale/rsigma:latest --helpRun with full runtime hardening:
docker run --rm \
--read-only \
--cap-drop=ALL \
--security-opt=no-new-privileges:true \
-v /path/to/rules:/rules:ro \
ghcr.io/timescale/rsigma:latest rule validate /rules/Verify the image signature:
cosign verify \
--certificate-identity-regexp 'github.com/timescale/rsigma' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/timescale/rsigma:latest# Evaluate a single event against Sigma rules
rsigma engine eval -r rules/ -e '{"CommandLine": "cmd /c whoami"}'
# Stream NDJSON from stdin (auto-selected when stdout is piped)
cat events.ndjson | rsigma engine eval -r rules/
# Interactive triage in a terminal: width-aligned table view
rsigma engine eval -r rules/ -e @events.ndjson --output-format table
# Recognize which schema each event is (ECS, Sysmon, CEF, OCSF, ...)
cat events.ndjson | rsigma engine classify --output-format table
# Pipe a CSV view into a spreadsheet or data tool
rsigma engine eval -r rules/ -e @events.ndjson --output-format csv > matches.csv
# Run as a daemon with hot-reload and Prometheus metrics
rsigma engine daemon -r rules/ -p ecs.yml --api-addr 127.0.0.1:9090
# Accept events via HTTP POST
rsigma engine daemon -r rules/ --input http
# Check a running daemon's status (rules loaded, events processed, uptime)
rsigma engine status
# Record 30s of a running daemon's live events to a replayable fixture
# (opt-in: start the daemon with --enable-tap)
rsigma engine tap --duration 30s --redact-fields user.email,src_ip -o fixture.ndjson
# Stream a running daemon's live detections to the terminal
# (opt-in: start the daemon with --enable-tail)
rsigma engine tail --level high
# Convert rules to PostgreSQL SQL for historical threat hunting
rsigma backend convert rules/ -t postgres
# Any non-native target delegates to sigma-cli when it is installed (pipx install sigma-cli)
rsigma backend convert rules/ -t splunk
# Draft a detection rule from exemplar events, contrasted against a baseline corpus
rsigma rule draft -e @incident.ndjson --baseline @normal-day.ndjson
# Draft a temporal correlation from grouped, timed exemplars
rsigma rule draft --groups @observed.ndjson --negative @benign.ndjson
# Backtest a corpus against per-rule expectations (CI fixture harness)
rsigma rule backtest -r rules/ --corpus ci/corpus/ --expectations ci/expectations.yml
# Map coverage onto MITRE ATT&CK: export a Navigator layer and gate on a target list
rsigma rule coverage -r rules/ --navigator coverage.json --targets threat-model.txt --fail-on-gapsSee the Quick Start guide for a guided tour and the CLI README for complete documentation of all subcommands and flags.
Expose the toolchain to MCP-aware agents (Cursor, Claude Code, ...) over stdio:
# Run the MCP server (register it in your agent's mcp.json / via `claude mcp add`)
rsigma mcp serve --rules-dir rules/The agent then calls structured tools (parse_rule, lint_rules, validate_rules, evaluate_events, convert_rules, list_fields, ...) and gets back JSON. Point --daemon-url at a running daemon to add the Operate-cycle tools. See the MCP server guide.
To teach an agent the current CLI and that loop, install the skill (Sigma YAML authoring is a separate skill):
npx skills add timescale/sigma-rules -g -y
npx skills add timescale/rsigma -g -yUse the crates directly from Rust:
use rsigma_parser::parse_sigma_yaml;
use rsigma_eval::Engine;
use rsigma_eval::event::JsonEvent;
use serde_json::json;
let yaml = r#"
title: Detect Whoami
logsource:
product: windows
category: process_creation
detection:
selection:
CommandLine|contains: 'whoami'
condition: selection
level: medium
"#;
let collection = parse_sigma_yaml(yaml).unwrap();
let mut engine = Engine::new();
engine.add_collection(&collection).unwrap();
let event = JsonEvent::borrow(&json!({"CommandLine": "cmd /c whoami"}));
let matches = engine.evaluate(&event);
assert_eq!(matches[0].rule_title, "Detect Whoami");
A Sigma rule is parsed into a strongly-typed AST (rsigma-parser), lowered into a shared intermediate representation (rsigma-ir), then compiled and evaluated against live events (rsigma-eval inside rsigma-runtime), converted into backend-native queries (rsigma-convert), or served to editors and AI agents (rsigma-lsp, rsigma-mcp). The evaluation library also powers exemplar-driven rule drafting and verified filter tuning through the CLI and MCP. The full walkthrough, covering every module and all four execution shapes, lives in the Architecture reference.
RSigma is designed for high-throughput detection. On an Apple M4 Pro:
Parsing: 12.4 MiB/s for 1000 rules
Detection: 1.12M events/sec (JSON runtime pipeline, 100 rules)
Correlation: 501K events/sec (temporal + event-count)
Dynamic pipelines: 2.85M events/sec once built (no per-event overhead)
See BENCHMARKS.md for full Criterion results across all subsystems.
pySigma: reference Python implementation
Sigma Specification V2.1.0: formal specification
sigma-rust: Pratt parsing approach
sigmars: correlation support patterns
sigma_engine: official SigmaHQ Rust library for parsing and matching Sigma rules against events
pySigma-backend-sqlite: SQLite backend for pySigma (inspiration for the PostgreSQL backend)
pySigma-backend-athena: AWS Athena backend for pySigma (SELECT fields, CTE-based correlation, sliding window patterns)
MIT
Report each detection rule's ADS (Alerting and Detection Strategy) sections, the required sections it is missing under the active config, and a scaffolded rsigma.ads.* template to complete. Accepts inline yaml or a file path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma YAML file (or directory, where the tool supports it). Mutually exclusive with `yaml`. Resolved against `--rules-dir` when relative, and must stay inside it when one is configured. | |
| yaml | No | Inline Sigma YAML (single or multi-document). Mutually exclusive with `path`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the report contents (per-rule sections, missing required sections, a scaffold template) and the two input modes, but says nothing about whether anything is written to disk, what permissions are needed, or how the scaffold should be applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the substantive report contents front-loaded and the input modes compressed into a trailing clause. No padding, though the second sentence largely duplicates schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, zero-required reporting tool with no output schema and no annotations, the description covers what is produced and how input is supplied, which is enough for an agent to call it correctly. Minor gaps around write side effects and config expectations keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters document mutual exclusivity and path resolution rules. The description's 'Accepts inline yaml or a file path' merely restates the schema, adding no new semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Report) and resource (each detection rule's ADS sections, missing required sections, and a scaffolded rsigma.ads.* template), which is precise enough to distinguish it from parse_rule or lint_rules. It stops short of explicitly naming a sibling alternative, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus lint_rules, validate_rules, or parse_rule, nor any prerequisites or exclusions. The phrase 'under the active config' hints at a configuration dependency but does not tell the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Sigma rules to backend-native queries. target is one of postgres/lynxdb/fibratus (native); when the server runs with --allow-sigma-cli, any other target is delegated to an installed sigma-cli, reaching the full pySigma backend set. Accepts inline yaml or a file/directory path, optional pipelines, format, backend options, and skip_unsupported.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma file or directory. Mutually exclusive with `yaml`. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| format | No | Backend-specific output format. Defaults to `default`. | |
| target | Yes | Backend target: `postgres` (aliases `postgresql`, `pg`), `lynxdb`, or `fibratus` convert natively; any other target is delegated to an installed sigma-cli when the server runs with `--allow-sigma-cli`. | |
| options | No | Backend options as key=value pairs (e.g. `table` -> `events`). | |
| pipelines | No | Processing pipelines (builtin names or file paths). | |
| skip_unsupported | No | Report unconvertible rules as warnings instead of failing the call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two conversion modes (native vs delegated), the effect of skip_unsupported, and the role of the target parameter. This adds behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second lists parameters and key conditions. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description provides sufficient context on conversion modes and parameter roles. It does not describe the output format, but the core functionality is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema_description_coverage is 100%, the baseline is 3. The description paraphrases the schema's parameter information without adding significant new meaning beyond listing the parameters and noting mutual exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Convert Sigma rules to backend-native queries' with a specific verb and resource, and distinguishes between native and delegated targets, differentiating it from sibling tools like parse_rule or fix_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use native targets vs delegated sigma-cli mode, including the prerequisite --allow-sigma-cli flag. It does not explicitly mention when not to use the tool or cite alternatives, but the guidance on target selection is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JSON events against Sigma rules and return matches. Detection-only rules use the stateless engine; collections with correlations use the stateful correlation engine. Rules via inline yaml or path; events via an inline events JSON array or an NDJSON events_path. Optional pipelines and match_detail (off/summary/full).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma file or directory. Mutually exclusive with `yaml`. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| events | No | Inline events as a JSON array of objects. Mutually exclusive with `events_path`. | |
| enrichers | No | Inline enrichers config (YAML/JSON) applied to results before returning. Mutually exclusive with `enrichers_path`. Only `template` enrichers are supported here; use the daemon for `lookup`, `http`, `command`, and `stix`. | |
| pipelines | No | Processing pipelines (builtin names or file paths). | |
| events_path | No | Path to an NDJSON file of events. Mutually exclusive with `events`. | |
| match_detail | No | Match-detail verbosity: `off` (default), `summary`, or `full`. | |
| enrichers_path | No | Path to an enrichers config file. Mutually exclusive with `enrichers`. | |
| emit_detections | No | Emit matches for rules referenced by correlations, including correlations that feed another correlation. | |
| timestamp_fields | No | Extra event field names to try for correlation timestamp extraction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses that engine selection is automatic based on rule type and that inputs are mutually exclusive, but it says nothing about error behavior, permissions, performance, or the shape of the returned matches, which matters for a 10-parameter execution tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, front-loaded with the core action and then layered with engine semantics and input modes. Dense but every sentence carries information; nothing is padding, though it leans on terse notation that assumes familiarity with the domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should say more about what a match looks like and how match_detail levels change the response. It also omits any mention of enrichers, emit_detections, or timestamp_fields, which are documented only in the schema. Adequate for selecting the tool, thin for interpreting its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema, including mutual-exclusivity constraints. The description restates a subset (yaml/path, events/events_path, pipelines, match_detail) without adding syntax, defaults, or format detail beyond it, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Evaluate JSON events against Sigma rules and return matches.' That is clearly distinct from parse/lint/validate/convert siblings, which operate on rules rather than executing them against event data. It stops short of explicitly naming the closest alternative (e.g. test_exemplars), so it is clear but not sibling-differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real routing guidance between the stateless engine for detection-only rules and the stateful correlation engine for collections with correlations, which helps the agent understand execution mode. However, it never says when to reach for this tool instead of test_exemplars, tune_rules, or validate_rules, so the broader when-to-use question is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply safe auto-fixes (lowercase keys, status/level typos, duplicate removal, ...) to Sigma YAML, preserving comments and formatting. Returns the fixed YAML and applied/failed/skipped-unsafe counts. Unsafe fixes are never auto-applied. With write: true (only valid with a file path) the change is persisted to disk. Optional lint_rules restricts which lint rules are fixed.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a single Sigma YAML file. Mutually exclusive with `yaml`. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| write | No | Persist the fixed YAML back to disk. Only valid with a `path` input. | |
| lint_rules | No | Restrict fixes to these lint rule ids (e.g. `non_lowercase_key`). Empty means apply every available safe fix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that unsafe fixes are never auto-applied, that write persists changes to disk, and that formatting is preserved. This adequately discloses key behavioral traits without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main action, and provides necessary details efficiently. It avoids unnecessary words but could be slightly more organized with bullet points or clearer separation of return value and optional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (fixed YAML and counts). It covers all parameters and safety constraints. It lacks mention of error handling or validation, but overall it is sufficiently complete for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reiterates constraints already in the schema (e.g., write:true only with path). It adds no new parameter-level information beyond summarizing the purpose, which is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies safe auto-fixes to Sigma YAML, listing examples like lowercase keys and typos. It distinguishes from sibling tools by focusing on fixing rather than listing, parsing, or converting rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that unsafe fixes are never applied and that write:true requires a file path. It also mentions optional lint_rules to restrict fixes, providing context on when to use parameters. However, it does not explicitly contrast with alternatives like lint_rules or convert_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint Sigma rules against the specification, returning findings with lint rule id, severity, message, line, and whether an auto-fix is available. Accepts inline yaml, a file path, or a directory path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma YAML file (or directory, where the tool supports it). Mutually exclusive with `yaml`. Resolved against `--rules-dir` when relative, and must stay inside it when one is configured. | |
| yaml | No | Inline Sigma YAML (single or multi-document). Mutually exclusive with `path`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the shape of the returned findings and the accepted input forms, which is genuinely useful, but says nothing about read-only safety, whether directories are traversed recursively, or how errors are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the action and its output contract come first, the accepted input forms second. No filler and no restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully fills the gap by naming the returned finding fields. Combined with the fully documented input schema, an agent has enough to call it, though the relationship to validate_rules and fix_rules remains unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, including the mutual exclusivity and path resolution rules. The description's restatement of 'inline yaml, a file path, or a directory path' adds a small amount of orientation but nothing the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — linting Sigma rules against the specification — and enumerates the finding fields returned. It is clear on its own, but it never distinguishes itself from sibling validate_rules or explains what linting adds over validation, so an agent must guess between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use statement. The mention of 'whether an auto-fix is available' implicitly points toward fix_rules as a follow-up, but the choice between lint_rules and validate_rules is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available conversion backends (targets) with their output formats and correlation methods. When the server runs with --allow-sigma-cli, installed sigma-cli targets are appended with engine "sigma-cli".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses a specific conditional behavior (sigma-cli targets appended when server runs with --allow-sigma-cli), but does not mention read-only nature, authentication needs, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence covers primary purpose, second adds an important conditional. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, description provides enough context: what is listed (backends with formats and methods) and a conditional behavior. Could be slightly more complete by noting it is a read-only listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds meaning beyond schema by detailing that the list includes output formats and correlation methods, plus the sigma-cli conditional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'conversion backends', specifying the output includes 'output formats and correlation methods'. It distinguishes from sibling list tools like list_builtin_pipelines and list_fields by targeting backends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering available backends, but lacks explicit guidance on when to use this tool versus alternatives like list_builtin_pipelines or list_fields. No when-not or context exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the builtin processing pipelines with their priority and shape.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'list', indicating a read-only operation, which is consistent. It does not detail sorting, pagination, or other behaviors, but for a straightforward list, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the purpose and key output traits (priority and shape). No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description indicates what the output contains (pipelines with priority and shape). It is adequately complete for a simple list tool, though more detail could be added.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description does not need to add parameter semantics. According to the guidelines, 0 parameters defaults to baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists builtin processing pipelines and specifies the output includes priority and shape. It distinguishes from sibling list tools like list_backends and list_fields that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing builtin pipelines, but does not explicitly state when to use it versus alternatives like resolve_pipeline or list_backends. No exclusions or contextual advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the event fields referenced by Sigma rules, with provenance (which rules and source kinds reference each field). Optional pipelines are applied first so the field names match what the engine evaluates. Accepts inline yaml or a file/directory path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma file or directory. Mutually exclusive with `yaml`. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| pipelines | No | Processing pipelines to apply before extracting fields. | |
| include_filters | No | Include fields referenced by filter rules. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses pipeline application and input options, but does not mention return format, pagination, performance, or any read-only hint. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Critical information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, 0 required, and no output schema, the description covers the main behavior, input modes, and pipeline purpose. It is complete enough for a listing tool, though return format could be hinted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining why pipelines are applied ('so the field names match what the engine evaluates') and clarifies that path and yaml are mutually exclusive input methods.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('event fields referenced by Sigma rules'), and adds detail about provenance. It clearly distinguishes from sibling tools (e.g., list_builtin_pipelines, lint_rules) which do different things.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (e.g., when you want to inspect field usage after applying pipelines) but does not explicitly state when to use this tool versus alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Sigma condition expression (e.g. selection and not 1 of filter_*) into a parse-tree as JSON, or return a structured parse error.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | A Sigma condition expression, e.g. `selection and not filter`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It correctly states the output (parse tree or error), but does not disclose whether the operation is idempotent, side-effect free, or if any authentication is required. For a simple parse operation, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core purpose. No unnecessary words or repetitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one simple string parameter and no output schema, the description covers the input, output, and an example. It is missing some details about the structure of the parse tree or error, but these are minor for a tool that returns JSON. Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds an example ('e.g. `selection and not filter`') which clarifies the expected format beyond the schema's type definition. This adds value for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Parse', the resource 'Sigma condition expression', and the output 'parse-tree as JSON' or 'structured parse error'. It includes an example, and the tool is well-differentiated from siblings like parse_rule which handles full rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like parse_rule. The description only implies usage for parsing condition expressions, but does not provide context on when it is appropriate or when another tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse Sigma YAML (rules, correlations, filters; multi-document supported) into a structured AST as JSON, or return structured parse errors. Accepts inline yaml or a file path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma YAML file (or directory, where the tool supports it). Mutually exclusive with `yaml`. Resolved against `--rules-dir` when relative, and must stay inside it when one is configured. | |
| yaml | No | Inline Sigma YAML (single or multi-document). Mutually exclusive with `path`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the return shape (structured AST as JSON, or structured parse errors), multi-document support, and both input modes. It omits whether the operation is purely read-only and any directory-resolution caveats, but the behavior relevant to invoking it correctly is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the core action and packs the accepted formats and output shape without redundancy. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description covers the return value (AST JSON or structured errors), inputs, and multi-document handling. The only gap is the behavior when neither optional input is supplied (both are optional, 0 required), which is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the mutual exclusivity and path resolution rules in detail. The description's 'inline yaml or a file path' adds nothing beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Parse Sigma YAML ... into a structured AST as JSON') and enumerates what it handles (rules, correlations, filters; multi-document). This clearly distinguishes it from siblings like lint_rules, validate_rules, and convert_rules, which also touch Sigma rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the accepted input modes (inline `yaml` or file `path`), which implies when to use it, but gives no explicit when-to-use versus validate_rules/lint_rules/parse_condition, and no prerequisites or exclusions. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a processing pipeline (a builtin name like ecs_windows or a YAML file path) and report its name, priority, transformations, and dynamic sources. With resolve_sources, dynamic file/command/HTTP sources are resolved and their data keys reported.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline | Yes | A builtin pipeline name (`ecs_windows`, `fibratus_windows`, `sysmon`) or a path to a pipeline YAML file. | |
| resolve_sources | No | Resolve dynamic sources (file/command/HTTP) and report their data keys. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It states what the tool returns (name, priority, transformations, dynamic sources) and that resolve_sources triggers additional resolution. However, it does not disclose whether the tool is read-only, required permissions, error behavior, or if it modifies state. The description is adequate but missing these traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with zero wasted words. The main purpose is stated first, followed by the optional behavior. Every sentence adds value, and the structure is front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the main purpose and the optional parameter. However, it does not describe the return format, which would be helpful since there is no output schema. It also omits error scenarios or prerequisites. The description is adequate but not fully complete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters thoroughly. The description adds context by integrating resolve_sources into the overall behavior, but it does not provide additional meaning beyond the schema's own descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a processing pipeline (builtin name or YAML file path) and reports its properties like name, priority, transformations, and dynamic sources. It differentiates between resolving with and without the resolve_sources flag, and the verb 'resolve' paired with the resource 'pipeline' is specific. Among siblings like list_builtin_pipelines, this tool focuses on a single pipeline, so purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like list_builtin_pipelines or parse_condition. It does not provide when-not-to-use scenarios or prerequisites. While the second sentence explains the resolve_sources option, it lacks context on choosing between this tool and others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse-convert a SIEM query into a draft Sigma rule (YAML). dialect selects the source query language (lucene today, the Lucene / Elasticsearch query_string subset: field:value with wildcards, quoted phrases, /regex/, [a TO b] ranges, comparison shorthand, field:(a OR b) groups, exists, keyword terms, and AND/OR/NOT with grouping). A query carries no metadata, so pass title/id/level/status and at least one of logsource_product/category/service, which a Sigma rule requires; the result is a reviewable skeleton. Boosting, fuzzy/proximity, and non-numeric ranges are reported as errors.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Rule id (UUID). | |
| level | No | Rule level: informational, low, medium, high, or critical. | |
| query | Yes | The query to convert. | |
| title | No | Rule title (recommended; a query has no title of its own). | |
| status | No | Rule status: stable, test, experimental, deprecated, or unsupported. | |
| dialect | No | Source query dialect. Defaults to `lucene` (the only dialect today). | |
| logsource_product | No | Logsource product (e.g. windows). | |
| logsource_service | No | Logsource service (e.g. sysmon). | |
| logsource_category | No | Logsource category (e.g. process_creation). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the output is a reviewable draft skeleton rather than a finished rule, and that boosting, fuzzy/proximity and non-numeric ranges surface as errors. It stops short of describing permissions, side effects, or whether anything is persisted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and target in the first clause, then supporting detail. The long parenthetical enumerating the Lucene subset is dense but earns its place by defining the accepted dialect; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Nine parameters, no output schema, and no annotations, so the description must cover a lot and mostly does: purpose, dialect scope, mandatory metadata, draft output nature, and error behavior. Only the concrete shape of the returned YAML skeleton and any file-write behavior remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds real meaning: it spells out the accepted Lucene subset (field:value, wildcards, quoted phrases, /regex/, [a TO b], field:(a OR b), _exists_), and explains that at least one logsource_* is needed because a Sigma rule requires it, which upgrades the schema's neutral 'e.g.' hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb (reverse-convert), a specific source resource (a SIEM query), and a specific target (a draft Sigma rule in YAML). The 'reverse-' prefix implicitly distinguishes it from the sibling convert_rules, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes the context clearly: use this when you have a SIEM query and need a Sigma rule, with `dialect` selecting the source language (lucene only today). It also states the required accompanying metadata, but never names an explicit alternative tool or a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay embedded rsigma.exemplars on Sigma detection and correlation rules and return pass/fail results. Provide exactly one of inline yaml or a path confined to --rules-dir. Optional pipelines are builtin names or confined YAML files. Shape, identity, and reference problems are configuration errors; a failed assertion is a finding, not a load error.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Sigma file or directory path. Confined to `--rules-dir` when configured. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| pipelines | No | Processing pipelines as builtin names or confined file paths. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return shape (pass/fail), path confinement to `--rules-dir`, pipeline sourcing rules, and an important error-vs-finding distinction. It omits details like failure output format and whether execution is sandboxed, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action and outcome, then constraints, then error semantics. Domain jargon ('rsigma.exemplars', 'confined') is dense but each sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the action, the required input constraint, optional pipelines, and the crucial distinction between configuration errors and assertion findings, which an agent needs to interpret results. With no output schema, it adequately signals that results are pass/fail, though it could say more about result detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds value by strengthening mutual exclusivity to 'exactly one' of yaml/path and by clarifying that pipelines are builtin names or confined YAML paths, beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Replay embedded rsigma.exemplars') and resource (Sigma detection and correlation rules) with the outcome (pass/fail results). It carves out a distinct niche versus siblings like validate_rules and lint_rules by framing failures as findings rather than load errors, though it never explicitly names a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage rule — 'Provide exactly one of inline `yaml` or a `path`' — and clarifies the error taxonomy (configuration errors vs findings). It does not explicitly state when to prefer this over lint_rules/validate_rules, but the context is clear enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose a spec-native Sigma filter rule from false-positive and true-positive JSON event arrays. Rules come from inline yaml or a path confined to --rules-dir; select the target with rule when needed. Optional pipelines transform the target before tuning. The result includes filter YAML, field rationale, clusters, coverage, and closed before/after verification. No proposal may suppress a true positive.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Sigma file or directory path. Confined to `--rules-dir` when configured. | |
| rule | No | Target rule id, falling back to an exact title. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| author | No | Filter author metadata. | |
| filter_id | No | Caller-supplied filter id. Omit to leave the YAML id unset. | |
| pipelines | No | Processing pipelines as builtin names or confined file paths. | |
| max_fields | No | Maximum fields in one selection. | |
| min_fields | No | Minimum fields required in every emitted selection. | |
| max_clusters | No | Maximum selections in the emitted filter. | |
| allow_partial | No | Permit verified partial FP coverage. | |
| true_positives | Yes | Known true-positive events that the filter must preserve. | |
| false_positives | Yes | Events confirmed as false positives. | |
| min_cluster_support | No | Minimum FP events required for every emitted selection. | |
| max_value_cardinality | No | Maximum exact values in one OR list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool proposes (not mutates) a rule, includes verification ('closed before/after verification'), enforces a hard constraint ('No proposal may suppress a true positive'), and outlines the result components (filter YAML, field rationale, clusters, coverage). It doesn't mention auth or rate limits, but the non-destructive 'propose' nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and packs essential behavioral and output details without redundancy. Every clause adds value, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no output schema, this description is remarkably complete. It covers inputs, source selection, optional transformation, output contents, and a critical invariant. The schema covers the parameter details, so the description needs only focus on high-level behavior and constraints, which it does thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds meaningful context for key parameters by explaining the sources (inline `yaml` or `path`), target selection (`rule`), and the optional role of `pipelines`. This goes beyond the schema's field descriptions, particularly in clarifying the relationship between `yaml` and `path`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Propose') and resource ('spec-native Sigma filter rule') with explicit inputs (false-positive and true-positive JSON event arrays). It distinguishes this tool from siblings like `validate_rules` or `convert_rules` by focusing on filter rule generation from FP/TP data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for how the tool is used (via inline yaml or path confined to --rules-dir, optional pipelines, target selection with rule) and implies the use case of tuning rules against event arrays. It doesn't explicitly mention when not to use it or name alternatives, but the context is strong enough for an agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate that Sigma rules parse and compile cleanly: parse, build the detection engine, and check correlation references. Optional pipelines and resolve_sources (resolve dynamic sources). Accepts inline yaml or a file/directory path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a Sigma file or directory. Mutually exclusive with `yaml`. | |
| yaml | No | Inline Sigma YAML. Mutually exclusive with `path`. | |
| pipelines | No | Processing pipelines (builtin names like `ecs_windows` or file paths). | |
| resolve_sources | No | Resolve dynamic pipeline sources (file/command/HTTP) during validation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the validation process and the optional resolve_sources behavior, but with no annotations, it fails to disclose whether the tool has side effects, requires specific permissions, or returns specific output. It does not state that validation is read-only or what happens on failure, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and followed by concise parameter guidance. Every clause earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with no output schema and no annotations, the description covers the main inputs, the process, and optional behaviors. It lacks explicit mention of return values or error handling, but the core context is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all four parameters with descriptive texts. The description reiterates the yaml/path mutual exclusivity and briefly defines resolve_sources, but adds minimal value beyond the schema, which already explains each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly and specifically states the tool's purpose: 'Validate that Sigma rules parse and compile cleanly' and details the validation process (parse, build detection engine, check correlation references). This distinguishes it from siblings like lint_rules, parse_rule, and convert_rules, which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what the tool does and how to invoke it (accepts inline yaml or path, optional pipelines and resolve_sources). It does not explicitly state when to use it versus alternatives or provide exclusions, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.24.0evaluate_events1 field changedInput schema / properties / emit_detectionsAdded value: +{
+ "default": false,
+ "description": "Emit matches for rules referenced by correlations, including\ncorrelations that feed another correlation.",
+ "type": "boolean"
+}v0.23.0author_ads1 field changedInput schema / properties / path / descriptionPrevious value: -"Path to a Sigma YAML file (or directory, where the tool supports it).\nMutually exclusive with `yaml`. Resolved against `--rules-dir` when relative."New value: +"Path to a Sigma YAML file (or directory, where the tool supports it).\nMutually exclusive with `yaml`. Resolved against `--rules-dir` when\nrelative, and must stay inside it when one is configured."evaluate_events1 field changedInput schema / properties / enrichers / descriptionPrevious value: -"Inline enrichers config (YAML/JSON) applied to results before returning.\nMutually exclusive with `enrichers_path`. `lookup` enrichers are not\nsupported here (no dynamic-source cache); use the daemon for those."New value: +"Inline enrichers config (YAML/JSON) applied to results before returning.\nMutually exclusive with `enrichers_path`. Only `template` enrichers are\nsupported here; use the daemon for `lookup`, `http`, `command`, and `stix`."lint_rules1 field changedInput schema / properties / path / descriptionPrevious value: -"Path to a Sigma YAML file (or directory, where the tool supports it).\nMutually exclusive with `yaml`. Resolved against `--rules-dir` when relative."New value: +"Path to a Sigma YAML file (or directory, where the tool supports it).\nMutually exclusive with `yaml`. Resolved against `--rules-dir` when\nrelative, and must stay inside it when one is configured."parse_rule1 field changedInput schema / properties / path / descriptionPrevious value: -"Path to a Sigma YAML file (or directory, where the tool supports it).\nMutually exclusive with `yaml`. Resolved against `--rules-dir` when relative."New value: +"Path to a Sigma YAML file (or directory, where the tool supports it).\nMutually exclusive with `yaml`. Resolved against `--rules-dir` when\nrelative, and must stay inside it when one is configured."v0.22.0test_exemplarsv0.21.0author_adsevaluate_eventsreverse_converttune_rulesvalidate_rulesv0.20.0convert_rulesfix_ruleslint_ruleslist_backendslist_builtin_pipelineslist_fieldsparse_conditionparse_ruleresolve_pipelineScored across 15 tools
Most tools have clearly distinct purposes (e.g., convert_rules vs reverse_convert, evaluate_events vs test_exemplars, list_* vs resolve_pipeline). However, the parse/validate/lint/fix cluster (parse_rule, validate_rules, lint_rules, fix_rules) has overlapping boundaries that could lead an agent to pick the wrong one despite detailed descriptions.
All 15 tools use snake_case with a predictable verb_noun pattern (evaluate_events, parse_rule, lint_rules, list_backends, etc.). The only mild deviation is reverse_convert, which is still snake_case and understandable, so consistency is excellent.
15 tools is at the upper end of the ideal 3-15 range but each tool covers a distinct facet of the Sigma rule lifecycle (authoring, parsing, validation, conversion, evaluation, pipelines). The count is well-scoped for the broad purpose of a Sigma rule toolkit.
The surface covers the core Sigma lifecycle very well: authoring (reverse_convert, tune_rules, author_ads), parsing (parse_rule, parse_condition), validation (validate_rules, lint_rules), fixing (fix_rules), conversion (convert_rules, list_backends), evaluation (evaluate_events), testing (test_exemplars), and pipeline/field introspection. Minor gaps exist, such as no rule search/index or diffing tool, but agents can work around these with file paths.
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
