Skip to main content
Glama
Sign In
timescale

RSigma

by timescale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

validate_rules

Validate that Sigma rules parse and compile cleanly: parse, build the detection engine, and check correlation references.

Instructions

Validate that Sigma rules parse and compile cleanly: parse, build the detection engine, and check correlation references. Optional pipelines, resolve_sources (resolve dynamic sources), and fail_level (error by default; warning also fails on parse warnings such as an invalid status). Accepts inline yaml or a file/directory path.

Input Schema

NameRequiredDescriptionDefault
pathNoPath to a Sigma file or directory. Mutually exclusive with `yaml`.
yamlNoInline Sigma YAML. Mutually exclusive with `path`.
pipelinesNoProcessing pipelines (builtin names like `ecs_windows` or file paths).
fail_levelNoLowest parse diagnostic severity that makes `ok` false: `error` (default) or `warning`.
resolve_sourcesNoResolve dynamic pipeline sources (file/command/HTTP) during validation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.25.0
    • addedInput schema / $defs
      Added value: +{
+  "FailLevel": {
+    "description": "Lowest parse diagnostic severity that fails validation.",
+    "oneOf": [
+      {
+        "const": "error",
+        "description": "Fail on parse errors only.",
+        "type": "string"
+      },
+      {
+        "const": "warning",
+        "description": "Fail on parse errors and parse warnings.",
+        "type": "string"
+      }
+    ]
+  }
+}
    • addedInput schema / properties / fail_level
      Added value: +{
+  "$ref": "#/$defs/FailLevel",
+  "description": "Lowest parse diagnostic severity that makes `ok` false: `error`\n(default) or `warning`."
+}
  2. Addedv0.21.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does disclose behavior beyond the schema: the validation stages, the default fail_level of error, and that warning also fails on parse warnings such as an invalid status. It doesn't state whether resolve_sources performs network/file access with side effects or what diagnostics are returned, which keeps it below 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.

Conciseness4/5

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

Front-loads the core action and follows with the optional knobs in one dense paragraph; every clause carries information. The nested parentheticals make it slightly crowded but nothing is wasted.

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

Completeness4/5

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

No output schema exists, so the description bears some return-value weight; it reveals that fail_level makes `ok` false, which hints at the result shape, but the rest of the diagnostic output is undescribed. Combined with 100% schema coverage and all-optional parameters, this is close to complete.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the mutual-exclusivity of yaml and path, that builtin pipeline names like ecs_windows are accepted, and the concrete consequence of fail_level warning (invalid status fails). That is value beyond the schema text, though not exhaustive.

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

Purpose4/5

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

States a specific verb and resource (validate Sigma rules) and enumerates the concrete work: parse, build the detection engine, check correlation references. That distinguishes it from lint_rules and fix_rules implicitly, but no sibling is named to sharpen the boundary.

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

Usage Guidelines3/5

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

The description implies usage (validate a rule before converting or testing it) through the context of what it checks, but never says when to prefer this over lint_rules, fix_rules, or parse_rule, and states no prerequisites or exclusions.

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

Deploy Server

Other Tools