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_adsB | 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_eventsB | 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 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.