Loading ToolBench
Model Context Protocol (MCP) server exposing the rsigma Sigma toolchain as tools and resources
rsigma-mcp provides 23 tools with consistent naming (verb_noun pattern) and descriptions present for all tools. However, critical gaps exist: input schemas are inferred from parameter lists but lack explicit JSON Schema type definitions in visible source; parameter descriptions are minimal (10-30 chars, well below the 72-char baseline); output schemas are undocumented; error handling lacks recovery guidance. Tools like parse_rule, validate_rules, and convert_rules accept both inline YAML and file paths but descriptions don't clarify mutual exclusivity or precedence. The daemon-facing tools (list_incidents, create_silence, post_disposition) lack permission/scope declarations. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the spec.
Author ADS (Attack Detection Strategy) metadata for Sigma rules
Convert Sigma detection rules to backend-native query strings
Create a silence in the daemon
Evaluate Sigma detection rules against events
Automatically fix Sigma detection rules
Get a specific incident from the daemon
Get an incident bundle from the daemon
Get rule quality metrics from the daemon
Input schemas lack explicit JSON Schema type definitions. Parameters are listed with descriptions but no visible type, format, or constraint declarations (e.g., is 'filter' a string pattern, regex, or structured query?). This forces LLMs to guess parameter types and valid formats.
Output schemas are completely undocumented. Tools return results but no schema is visible describing field names, types, or structure. LLMs cannot plan downstream tool calls or extract required IDs (e.g., does list_incidents return incident_id or id?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Lint Sigma detection rules for style and best-practice violations
List available conversion backends
List built-in Sigma pipelines
List fields available in Sigma rules
List incidents from the daemon
List risk entities from the daemon
List silences from the daemon
Parse a Sigma rule condition expression
Parse a Sigma detection rule from YAML content or file
Post a disposition verdict to the daemon
Resolve a Sigma pipeline configuration
Reverse-engineer Sigma rules from backend-native queries
Test Sigma rules against exemplar events
Tune Sigma detection rules for performance and accuracy
Validate Sigma detection rules against the schema
Parameter descriptions are too brief (10-30 chars vs. 72-char baseline). Examples: 'Inline YAML rule content' (24 chars), 'Condition expression to parse' (29 chars). Descriptions lack context on format, constraints, or when to use each parameter variant (yaml vs. path).
Mutually exclusive parameters (yaml vs. path) lack explicit documentation. Tools accept both inline content and file paths but descriptions don't clarify precedence, whether both can be provided, or what happens if both are omitted. LLMs will pass both, causing ambiguous behavior.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. create_silence and post_disposition are marked WRITE but lack destructiveHint annotation. This prevents clients from applying appropriate safeguards (confirmation, audit logging).