The RSigma MCP server exposes a complete detection engineering toolkit for AI agents, enabling Sigma rule parsing, linting, validation, auto-fixing, evaluation, conversion, and documentation—without a local RSigma installation.
Rule Management: Parse Sigma rules (multi-document) into AST, lint against 85 checks with auto-fix (optional write-back), validate compilation and correlation references, and author ADS documentation.
Detection & Evaluation: Evaluate JSON events via stateless or stateful correlation engines with pipeline enrichers and configurable verbosity; ingest events from various formats (JSON, syslog, CEF, OTLP) with auto-detection; apply processing pipelines for field mapping and transformations; route events based on schema recognition.
Query Conversion: Convert rules to backend-native queries (PostgreSQL, LynxDB, Fibratus, or any sigma-cli backend); reverse-convert SIEM queries (e.g., Lucene) into draft Sigma rules.
Discovery & Utilities: List fields with provenance per rule, available backends, built-in pipelines; resolve pipeline transformations and dynamic sources; parse condition expressions into trees.
Operational & Integration: Run as a streaming detection daemon with hot-reload and Prometheus metrics; interact with the daemon to inspect status or stream detections; integrate with IDEs via an LSP server for real-time diagnostics and code actions.
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 85 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 a detection rule 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 85 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
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
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, ...)
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 0.0.0.0: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
# 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. See the MCP server guide.
Use 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. | |
| 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. It discloses the main behavior (reporting and scaffolding a template) and implies it is a non-destructive reporting tool, but it does not clarify whether any file writes occur, how the 'active config' is determined, or what happens on input errors. This is adequate but not rich in behavioral detail.
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, well-structured sentence that front-loads the primary action ('Report') and efficiently packs the key output details without any filler. Every phrase earns its place, making it concise and easy to parse.
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 reporting tool with no output schema, the description explains the return values (ADS sections, missing sections, scaffolded template) and input options. It lacks information about error handling, output formatting, or how the active config is resolved, but these are secondary for a report tool. The core completeness is solid, though not exhaustive.
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 per the rubric, the baseline is 3. The description repeats the parameter names ('yaml' and 'path') but adds no additional meaning beyond what the schema already provides. It doesn't explain mutual exclusivity, directory support, or resolution behavior, which the schema already covers.
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's purpose: 'Report each detection rule's ADS sections, the required sections it is missing under the active config, and a scaffolded `rsigma.ads.*` template to complete.' This uses a specific verb ('Report') with a resource ('detection rule's ADS sections') and details the exact output, which distinguishes it from sibling tools like `lint_rules` or `convert_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 implies usage by stating what it does and that it accepts inline YAML or a file path, but it does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context is clear enough for an agent to infer when it's appropriate, but there is no direct comparison to siblings.
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`. `lookup` enrichers are not supported here (no dynamic-source cache); use the daemon for those. | |
| 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`. | |
| 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?
With no annotations provided, the description carries the full burden. It goes beyond the obvious by explaining the engine selection behavior: 'Detection-only rules use the stateless engine; collections with correlations use the stateful correlation engine.' This is valuable behavioral context. It also mentions optional `pipelines` and `match_detail`, hinting at configurability. It doesn't mention side effects or return format, but given it's a pure evaluation tool, the key behavioral trait is covered.
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, each earning its place: first sentence states purpose, second explains engine behavior, third covers inputs and options. It is front-loaded with the most important information and contains zero filler. This is an exemplary level of conciseness for a tool with 9 parameters.
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 complexity (9 parameters, mutual exclusions, stateful/stateless engines) and the absence of an output schema, the description is quite complete. It covers the core input mechanisms, the engine dichotomy, and optional settings. However, it doesn't outline the expected return structure beyond 'matches,' which could be ambiguous for a tool with no output schema. A bit more detail on response format would make it fully 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 description coverage is 100%, so the baseline is 3. The description repeats the main input methods (yaml/path, events/events_path) but adds no new semantic detail beyond what the schema already provides. It does group the parameters into logical pairs, which is helpful, but it doesn't compensate for any missing schema information because none is missing.
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's purpose: 'Evaluate JSON events against Sigma rules and return matches.' The verb 'evaluate' and resources 'JSON events' and 'Sigma rules' precisely define the operation. It distinguishes itself from sibling tools like lint_rules or validate_rules, which focus on static analysis, whereas this tool executes rules against events.
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 on how to use the tool ('Rules via inline `yaml` or `path`; events via an inline `events` JSON array or an NDJSON `events_path`') and explains when different engines apply (detection-only vs stateful correlation). It doesn't explicitly name alternative tools for exclusion, but the strong purpose clarity makes the intended use implied. This earns a 4 rather than a 5 because there is no explicit 'when not to use' guidance.
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. | |
| 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 burden of behavioral transparency. It mentions returning findings and auto-fix availability but does not explicitly state that the tool is read-only or does not modify files. This leaves some ambiguity about 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?
The description is two sentences, front-loaded with the core purpose, and every word adds value. No unnecessary filler or repetition.
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 parameters, no output schema), the description covers input methods and return fields. It does not explain prerequisites or output format beyond listed fields, but that is adequate for a linting 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 coverage is 100%, so the description adds marginal value. It reinforces that path can be a file or directory and that yaml is inline, but these details are already in the schema. No additional semantic nuance is provided.
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 lints Sigma rules against the specification, specifying the verb 'lint' and the resource 'Sigma rules'. It distinguishes itself from siblings like parse_rule or convert_rules by focusing on validation and returning findings with specific fields.
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 on how to use the tool: accepts inline yaml, a file path, or a directory path. However, it does not explicitly state when not to use it or mention alternatives, leaving usage guidance slightly incomplete.
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. | |
| 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?
Describes return of AST or parse errors and support for multi-document. No annotations, so description carries burden; however, does not explicitly state read-only or idempotent nature.
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: first covers purpose and output, second covers parameters. No extraneous information, front-loaded.
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?
Adequate for a simple parse tool with two parameters; explains inputs, outputs, and error handling. Without output schema, could detail return format more, but sufficient for invocation.
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%, description adds mutual exclusivity and path resolution behavior beyond schema descriptions, providing useful context.
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?
Clearly states verb 'parse', resource 'Sigma YAML', and output 'structured AST as JSON' or parse errors. Differentiates from siblings like parse_condition and convert_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?
Specifies input modes (inline yaml or file path) but does not explicitly state when to use versus alternatives. Context from sibling tools implies differentiation.
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 logsource_product/category/service; 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 provided, the description carries the full burden. It discloses that the result is 'a reviewable skeleton,' specifies the supported Lucene subset in detail, and clearly reports error behavior for 'Boosting, fuzzy/proximity, and non-numeric ranges.' This adds meaningful 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 three dense, information-packed sentences with no redundancy or filler. It front-loads the purpose and efficiently covers scope, dialect details, metadata requirements, and error conditions.
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 output schema and no annotations, the description covers the essential aspects: purpose, dialect scope, required metadata inputs, and error conditions. The only minor gap is that it does not specify the exact return structure beyond 'draft Sigma rule (YAML),' but the description is otherwise sufficient for operation.
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 parameters already have individual descriptions. The tool description adds value by explaining why metadata parameters are needed (query carries no metadata) and provides detailed syntax for the dialect parameter, going beyond the schema's brief field labels.
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's function: 'Reverse-convert a SIEM query into a draft Sigma rule (YAML).' It is specific in verb and resource and distinguishes itself from siblings like convert_rules by explicitly indicating the reverse direction (SIEM query → Sigma) and the YAML output format.
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 useful context by noting that 'a query carries no metadata' and instructs to pass title/id/level/status and logsource fields. However, it does not explicitly state when to use this tool versus alternatives like convert_rules or parse_rule, nor does it provide exclusions or when-not-to-use conditions.
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.
Each tool targets a distinct aspect of Sigma rule processing (parsing, linting, fixing, converting, listing backends/pipelines/fields, resolving pipelines), with no overlapping functionality.
All tool names follow the consistent verb_noun pattern in lowercase snake_case (e.g., list_builtin_pipelines, parse_condition, convert_rules), making it easy to predict tool purpose from its name.
9 tools cover the main workflows for Sigma rules—parsing, linting, fixing, conversion, and metadata listing—without being excessive or insufficient for the domain.
The tool set covers the full lifecycle of Sigma rule handling: parsing, validation via linting, auto-fixing, conversion to backends, and retrieval of supporting metadata (backends, pipelines, fields).
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/timescale/rsigma'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
