Security Detections MCP: querying Sigma, Splunk ESCU, Elastic, KQL, Sublime and CrowdStrike CQL from one MCP server
MCP to help Defenders Detection Engineer Harder and Smarter
At a glance
- What is it?
- Security Detections MCP is a TypeScript Model Context Protocol server that indexes local detection repositories and exposes them to an LLM client. The local package exposes 81 tools; the hosted endpoint exposes about 25 read-only tools on a 200 calls per day free tier.
- Who is it for?
- Adopt the local package if your detection content already lives in git checkouts on the same machine as your MCP client, and you want the full 81-tool surface pointed at those files. Do not adopt it if you need a guarantee about licence terms, since the repository metadata supplied here lists the licence as unknown, or if your rules are only reachable through a vendor API rather than a filesystem path.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 91 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between a detection repo and an LLM that can read it
Detection engineers accumulate rules in several dialects at once. A Sigma rule, a Splunk ESCU search, an Elastic rule, a KQL query, a Sublime detection and a CrowdStrike CQL query can all describe the same behaviour, and they usually sit in separate repositories with separate directory conventions. The README frames the project as an MCP server that lets an LLM query a unified database of those six formats. That is the whole proposition: one MCP endpoint in front of a merged index, instead of pasting rule text into a chat window or grepping six checkouts by hand. The audience is narrow and identifiable. It is the person who already knows what a Sigma rule looks like, already has the repositories cloned, and wants an assistant that can answer questions like which of my rules touch a given technique. It is not aimed at someone who wants a detection rule generator from scratch.
Local indexing versus the hosted endpoint: two products in one repository
The README splits the project into two modes and the split is the most consequential design decision in it. Local mode is the npm package. It runs on your machine, indexes your own detection repositories, and exposes all 81 tools. Hosted mode is a Streamable HTTP server at detect.michaelhaag.org/api/mcp/mcp. It requires a token, exposes roughly 25 read-only tools, stays in sync with the latest content, and is capped at 200 calls per day on the free tier. The trade is explicit: local gives you the full tool surface and your private rules, hosted gives you zero setup and someone else's content set. If your detection content is not public, hosted mode cannot see it. If you need write or analysis tools beyond the read-only set, hosted mode does not have them. The README does not enumerate which 25 tools are in the hosted set, so that boundary has to be checked in the client after connecting.
What the server actually indexes, and where the numbers come from
The feature list claims 8,200+ detections across the six formats, plus MITRE ATT&CK STIX content described as 172 threat actors and 784 software items. The README text is truncated mid-sentence at that point, so the remainder of the STIX figures is not available here. The one concrete architectural detail visible is the STIX graph work named in the v3.2.0 release title, Procedure-Level Coverage Analysis & STIX Graph. That release name is the only evidence in the supplied material that the server models procedure-level relationships rather than treating each rule as an isolated document. Everything else about the index structure, the storage engine, and how the six formats are normalised into a common schema is not described in the material available, and should not be assumed.
Install commands and the environment variables that do the real work
The install itself is a one-liner per client. For Claude Code: claude mcp add security-detections -- npx -y security-detections-mcp. For OpenAI Codex: codex mcp add security-detections -- npx -y security-detections-mcp. Claude Desktop takes a JSON block in claude_desktop_config.json with command npx and args ["-y", "security-detections-mcp"]. The README also ships deeplink buttons for Cursor and VS Code that encode the same config. The part that matters is not the install, it is the configuration. After install you set env vars to point at your repositories: SIGMA_PATHS, SPLUNK_PATHS, STORY_PATHS, ELASTIC_PATHS, KQL_PATHS, SUBLIME_PATHS and CQL_HUB_PATHS. The Cursor deeplink in the README shows the expected shape, comma-separated absolute paths, for example SIGMA_PATHS set to /path/to/sigma/rules,/path/to/sigma/rules-threat-hunting and SPLUNK_PATHS set to /path/to/security_content/detections. Note that STORY_PATHS points at a stories directory, not a detections directory, which suggests the index distinguishes narrative content from rule content. The README says a setup guide covers macOS, Windows (WSL and native) and Linux step by step, and that local mode needs Node.js and about 10 minutes.
Hosted mode, tokens and the model routing table
Hosted setup is three steps: create a token at detect.michaelhaag.org/account/tokens, pick your client, replace the placeholder sdmcp_YOUR_TOKEN_HERE in the generated config. Claude Code takes claude mcp add --transport http security-detections https://detect.michaelhaag.org/api/mcp/mcp --header "Authorization: Bearer sdmcp_YOUR_TOKEN_HERE". Claude Desktop does not speak remote HTTP natively according to the README, so it goes through mcp-remote as a stdio bridge. Codex uses an environment variable instead of an inline header: export SDMCP_TOKEN then pass --bearer-token-env-var SDMCP_TOKEN. The repository also documents a web chat with three routing tiers. Free tier defaults to nvidia/nemotron-3-super-120b-a12b:free with three named fallbacks. Pro and Admin route through an app-managed OpenRouter path keyed off a Preferred Model setting in /account, mapping auto, claude, claude-opus, gpt and gpt-codex to specific models. BYOK takes precedence, keyed off the prefix of the key you supply: sk-ant- routes to Anthropic, sk- to OpenAI, sk-or- to the same Preferred Model table. This routing is a property of the hosted web application, not of the MCP server itself, and conflating the two would be a mistake.
Where this breaks down
Three limitations are visible in the material. First, the licence is listed as unknown in the repository metadata supplied here. For a tool that an organisation might wire into its detection workflow, that is a blocking question, and nothing in the README answers it. Second, the hosted tier is capped at 200 calls per day. An MCP client does not make one call per user question; it makes a sequence of tool calls, and a coverage analysis across 8,200 detections will not fit in that budget. The README does not state what happens when you exceed the cap. Third, local mode only indexes what you point it at. If your rules live behind a vendor API, a SaaS console, or a CI artefact store rather than a filesystem path, the env var model does not reach them. The README also does not describe incremental reindexing, so it is unclear whether adding a rule to a watched directory requires a server restart. Treat that as unverified rather than assuming either behaviour. A fourth point is structural rather than a defect: the local and hosted tool sets differ, 81 versus roughly 25, and the README does not list which tools fall on which side. Anyone planning a workflow around a specific capability should confirm it exists in their chosen mode first.
Sigma CLI, Uncoder and the difference in approach
The obvious alternative for the Sigma portion is the official Sigma tooling, pySigma and the sigmac successor sigma-cli, which converts rules between backends and validates them. The difference is directional. Sigma CLI operates on rules as files and produces files: you point it at a rule, it emits a Splunk or Elastic query. Security Detections MCP operates on rules as a queryable corpus and answers questions about them through an LLM, which is why the tool count is in the tens rather than the single digits. If your task is translate this rule, use sigma-cli. If your task is which of my rules cover this technique and how do they differ across formats, that is the shape this project targets. A second comparison point is doing nothing and letting the model read files directly through a general filesystem MCP server. That works for one repository with consistent naming. It degrades once you have six dialects, six directory layouts, and a need to relate rules to ATT&CK techniques, which is the problem the unified index exists to solve.
Maintenance, releases and what to check before depending on it
The release cadence visible here is two releases in roughly two months, v3.2.0 in April 2026 with Procedure-Level Coverage Analysis & STIX Graph, and v3.3.0 in June 2026. The repository is not archived and the last push timestamp matches the v3.3.0 release date, which suggests releases are cut from the main line rather than from a long-lived branch. That is a normal pattern for a single-maintainer tool and it carries the usual cost: the upgrade path is npx -y security-detections-mcp, which pulls whatever is current at the moment your client starts, so there is no version pin in the documented install commands. If you need reproducibility, you would have to pin the package version yourself rather than use the documented one-liner. On licensing, the metadata supplied lists the licence as unknown, and the README does not state one. That is not a legal opinion, just an observation about what the material does and does not contain. Anyone embedding this in a commercial product or an internal platform should resolve that question from the repository itself before doing so, because the answer is not available in the README or in the metadata reviewed here.
Editorial conclusion
Adopt the local package if your detection content already lives in git checkouts on the same machine as your MCP client, and you want the full 81-tool surface pointed at those files. Do not adopt it if you need a guarantee about licence terms, since the repository metadata supplied here lists the licence as unknown, or if your rules are only reachable through a vendor API rather than a filesystem path. Before wiring it into a client, verify three things: which env vars your rule layouts actually match (SIGMA_PATHS, SPLUNK_PATHS, STORY_PATHS, ELASTIC_PATHS, KQL_PATHS, SUBLIME_PATHS, CQL_HUB_PATHS), what the hosted tier's 200 calls per day means for your query volume, and whether the tool inventory you need is in the read-only hosted set or only in the local set.
Community notes