detection-enabler
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEM_ES_URL | No | Elasticsearch endpoint URL. | http://localhost:9200 |
| DEM_API_KEY | No | Read-only Elastic API key credential. | |
| DEM_PASSWORD | No | Read-only Elastic password credential. Must be used together with DEM_USERNAME. | |
| DEM_USERNAME | No | Read-only Elastic username credential. Must be used together with DEM_PASSWORD. | |
| DEM_STATE_DIR | No | Directory for requests and the audit log. | ~/.local/state/detection-enabler-mcp |
| DEM_KIBANA_URL | No | Kibana endpoint URL. | http://localhost:5601 |
| DEM_KIBANA_SPACE | No | Kibana space to use. | default |
| DEM_NOISY_ALERTS_PER_DAY | No | Alert-per-day threshold above which the verdict is noisy. | 50 |
| DEM_DEFAULT_LOOKBACK_HOURS | No | Window in hours used for freshness, field, and volume checks. | 24 |
| DEM_MIN_FIELD_COVERAGE_PCT | No | Minimum field coverage percentage; below this, a field counts as missing. | 1.0 |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_rulesB | List detection rules (optionally filtered by name). Returns ids, types and enabled state. |
| check_rule_readinessA | Check whether a rule will work here: source indices exist, data is recent, required fields are populated, and the projected alert volume is below the noise threshold. |
| request_rule_enableB | Ask a human to enable a rule. Re-runs the readiness check and files a pending request. This does NOT enable the rule. Rules that are not 'ready' are refused. |
| get_enable_requestB | Get the status of an enable request (pending, approved, denied, enabled, failed, expired). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
check_rule_readiness and request_rule_enable both involve a readiness check, but one is read-only and the other files a request; descriptions clarify the distinction. list_rules and get_enable_request have clearly separate purposes.
All names are snake_case with a verb-first pattern (check_, request_, get_, list_), which is consistent overall. 'request_rule_enable' is slightly awkward phrasing but still follows the verb_noun convention.
Four tools for a narrow workflow (list rules, check readiness, request enable, check request status) is well-scoped; each tool earns its place without redundancy.
The core lifecycle is covered: list rules, check readiness, request enable, and track request status. Minor gaps exist—no tool to list all enable requests or cancel a pending request—but agents can work around these by tracking IDs from request responses.