RSigma
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RSIGMA_MCP_AUTH_TOKEN | No | Static bearer token required on every HTTP request (Authorization: Bearer <token>), compared in constant time. Maps to --auth-token. Flag/env only, never read from config files. | |
| RSIGMA_MCP__HTTP_ADDR | No | Bind address for the Streamable HTTP transport (e.g. 127.0.0.1:9100); unset means stdio. Maps to mcp.http_addr / --http. | |
| RSIGMA_MCP__RULES_DIR | No | Default root directory for relative path arguments in tool calls. Maps to mcp.rules_dir / --rules-dir. | |
| RSIGMA_MCP__LINT_CONFIG | No | Path to the lint config file (.rsigma-lint.yml) applied by the lint_rules tool. Maps to mcp.lint_config / --lint-config. | |
| RSIGMA_MCP__ALLOW_SIGMA_CLI | No | Allow the convert_rules tool to delegate unsupported targets to an installed sigma-cli. Maps to mcp.allow_sigma_cli / --allow-sigma-cli. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| author_adsA | Report each detection rule's ADS (Alerting and Detection Strategy) sections, the required sections it is missing under the active config, and a scaffolded |
| convert_rulesA | Convert Sigma rules to backend-native queries. |
| evaluate_eventsA | 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 |
| fix_rulesA | 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 |
| lint_rulesA | Lint Sigma rules against the specification, returning findings with lint rule id, severity, message, line, and whether an auto-fix is available. Accepts inline |
| list_backendsA | 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". |
| list_builtin_pipelinesA | List the builtin processing pipelines with their priority and shape. |
| list_fieldsA | List the event fields referenced by Sigma rules, with provenance (which rules and source kinds reference each field). Optional |
| parse_conditionA | Parse a Sigma condition expression (e.g. |
| parse_ruleA | Parse Sigma YAML (rules, correlations, filters; multi-document supported) into a structured AST as JSON, or return structured parse errors. Accepts inline |
| resolve_pipelineA | Resolve a processing pipeline (a builtin name like |
| reverse_convertA | Reverse-convert a SIEM query into a draft Sigma rule (YAML). |
| test_exemplarsA | Replay embedded rsigma.exemplars on Sigma detection and correlation rules and return pass/fail results. Provide exactly one of inline |
| tune_rulesA | Propose a spec-native Sigma filter rule from false-positive and true-positive JSON event arrays. Rules come from inline |
| validate_rulesA | Validate that Sigma rules parse and compile cleanly: parse, build the detection engine, and check correlation references. Optional |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Lint rule catalogue | |
| ADS section catalogue | |
| Sigma field modifiers | |
| MITRE ATT&CK tactics |
TDQS
Scored across 15 tools
Most tools have clearly distinct roles, but there is a cluster of YAML-consuming validation tools (parse_rule, validate_rules, lint_rules, fix_rules) whose boundaries require careful reading of descriptions to distinguish parse-only vs parse+compile vs spec-lint vs auto-fix. Similarly list_builtin_pipelines vs resolve_pipeline and convert_rules vs reverse_convert are related but description text keeps them separable.
All 15 tools follow a consistent snake_case verb_noun convention (author_ads, parse_rule, convert_rules, evaluate_events, fix_rules, lint_rules). Even the multi-word names (reverse_convert, resolve_pipeline, list_builtin_pipelines) keep the same structure, making the set highly predictable.
15 tools is well-scoped for a comprehensive Sigma rule analysis suite, covering parsing, validation, linting, fixing, conversion, evaluation, tuning, and introspection. Each tool maps to a distinct stage of the rule lifecycle and none appears redundant.
The surface covers a full rule lifecycle: author scaffold (author_ads), parse, validate, lint, fix, convert both directions, evaluate, tune, and field/pipeline/backend introspection. A minor gap is the absence of a general rule-creation or template-scaffolding tool beyond the ADS-specific and reverse-convert paths.