Blitz Strike: an MCP penetration-testing server that refuses to report a hypothesis

What Blitz Strike solves, and for whom

Automated security assessment fails in two predictable ways. A scanner flags a pattern and calls it a finding, and the report fills with false positives. Or a real sink is found, reported, and turns out to be unreachable or already authenticated, and the report loses credibility. Blitz Strike is built around that pair. Its README states the project exists to eliminate those two failure modes, and it does so by refusing to treat a scan hit as anything other than a hypothesis: a live test is the verdict.

The audience is narrow and specific. This is for penetration testers, bug-bounty hunters, and application-security engineers who already work through an MCP client and want a structured methodology behind it rather than a pile of shell one-liners. It is also aimed at teams that want the methodology to be identical whether the engagement is driven from Claude Code, Cursor, Hermes, OpenCode, Claude Desktop or Gemini. The README's own framing, one server, every agent, is the whole pitch: the client is interchangeable, the doctrine is not.

The three tiers and how a target flows through them

Blitz Strike packages a methodology as callable MCP tools and runs the engagement server-side, which is why a single run_engagement call works from any client. The tiers are sequential.

BLITZ is reconnaissance and attack-surface mapping. The blitz_scan(path, max_files) tool walks a source tree and enumerates unauthenticated entry points and dangerous sinks with file:line references; blitz_file(path) does the same for one file. EAGLE-EYE is static analysis and data-flow tracing. It traces source-to-sink reachability and enriches findings against an escalation-chain graph, testing whether a sink is reachable, unauthenticated and exploitable rather than merely present. STRIKE is validation: live verification using marker reflection plus a negative control, scope enforcement, and orchestration. Nothing is reported until STRIKE confirms it.

The data layer behind this is shipped in the repository rather than fetched at install time. chains.json holds the escalation chains, tools-catalog.json holds the 130-tool catalog, manuals/ and manuals-index.json hold the exploit-tool manuals, and intelligence/ holds the intelligence data layer. The README says the relevant exploit-tool manual is attached to every result, so the agent does not have to guess at syntax. Heavy datasets are the exception: blitzstrike sync-data fetches payloads and templates on demand.

Installing Blitz Strike and running a first engagement

The zero-install path needs Node or Bun and nothing else. The README's quickstart runs doctor first, which reports the runtime, the state of the 130-tool catalog, FOFA credentials and whether the chains and tools-catalog data layers are present. Each issue it finds carries a fix: line.

npx -y blitzstrike doctor
npx -y blitzstrike install

The install step detects every agent CLI it knows about (Claude Code, Cursor, OpenCode, Codex, Hermes, Gemini, Windsurf, Copilot, Cline) and writes the correct MCP configuration to each in that client's native format. According to the README it merges the Blitz Strike entry in and never overwrites existing MCP servers; when no client is detected it prints the snippet for manual paste. Use install --dry-run to preview the config before anything is written.

If you prefer to run from source, the repository layout is a Bun project. The README gives this sequence.

git clone https://github.com/shinthink/blitzstrike.git
cd blitzstrike
bun install
bun run src/index.ts serve --mcp

For a manual client configuration, the README's snippet is the shape every MCP client expects.

{
  "mcpServers": {
    "blitzstrike": {
      "command": "blitzstrike",
      "args": ["serve", "--mcp"]
    }
  }
}

After restarting the agent, the first real use is one call. The README's example asks the agent to audit a source tree or a live URL, and states that the LLM classifies the target automatically: a URL goes to the live pipeline, a filesystem path goes to the source pipeline. The agent then drives recon, analyze, verify, review and report, guided by the bundled doctrine and the per-step next_steps. Expect the first doctor run to show a partial tool catalog. That is normal and it is the thing to read carefully.

Where the design bites back

The catalog check is the honest limitation. The README's own doctor output example shows 63/130 installed, with 67 on-demand. That means roughly half the tool catalog is not present on a fresh host, and tools that are absent cannot feed STRIKE's live verification step. A finding that EAGLE-EYE traces to a reachable, unauthenticated sink may still stall at validation if the tool needed to prove it was never installed. The methodology is sound; the coverage is a function of what you provisioned.

Scope enforcement is described as part of STRIKE, but the README does not document what happens when a target falls outside scope, nor does it document rollback or cleanup after a live test. Those are the questions a tester should ask before pointing this at anything they do not own. FOFA credentials are also part of the doctor check, which implies an external intelligence dependency for some recon paths; if you have no FOFA key, expect a WARN rather than a working enrichment step.

The larger architectural point is that Blitz Strike is not autonomous in the sense a scanner is. The LLM is the brain: it plans, routes, delegates and judges. Blitz Strike is the deterministic hands, knowledge and guardrails. If your workflow has no LLM in the loop, or your policy forbids one, this is the wrong tool, because the server deliberately does not decide what to attack on its own.

How it differs from running Nuclei and friends directly

The honest comparison is with the tools Blitz Strike orchestrates rather than with a single competitor. Nuclei is a template-driven scanner: you point it at a target, it matches templates, and it reports matches. The judgement about whether a match is exploitable is yours. Blitz Strike inverts that. Its STRIKE tier performs live verification with marker reflection and a negative control, so the output is meant to be a confirmed finding rather than a template hit, and the escalation-chain graph in chains.json sits between the raw hit and the report to say whether the finding is reachable and unauthenticated.

The trade-off is transparency and speed. A Nuclei run gives you raw template output you can read line by line. Blitz Strike gives you a server-side pipeline whose intermediate reasoning lives in the LLM's plan and in the doctrine files under skills/ and docs/. That is a real cost when you need to defend a finding to a client, because the evidence chain is generated rather than hand-assembled. The compensating benefit is consistency: the same methodology runs whether the engagement is driven from Cursor or from Claude Desktop, which is hard to achieve when each tester keeps their own shell history.

Maintenance, licensing and the cost of keeping up

The repository is not archived, and the last push was on 2026-09-17. The published package version is 2.4.80, while the most recent GitHub release is v1.0.0 from 2026-09-12, so the npm package and the release tags are not moving in lockstep; check the package version rather than the release page when you need to know what you are running. The CLI ships a blitzstrike update command that checks for a newer version and refreshes the data cache, which is the intended upgrade path.

Upgrade cost is dominated by the data layers, not the code. chains.json, tools-catalog.json, manuals/ and intelligence/ are bundled into the package, so a version bump can change the escalation graph and the manual set underneath you. If your team pins a version, pin it deliberately, because a chain that existed in one release may be reclassified in the next. The licence is MIT, which is permissive and places few obligations on internal use; the repository also carries THIRD-PARTY-NOTICES.md, and the tool catalog references external security tools with their own licences and their own rules about what you may point them at. Nothing here is legal advice, and the licence of the bundled manuals and payloads is worth reading before redistribution.

What doctor tells you before you trust a run

The doctor command is the cheapest piece of diligence in the project, and it is worth treating as a gate rather than a formality. It reports four things: the runtime, the security-tools catalog with an installed/on-demand split, FOFA credentials, and whether the chains and tools-catalog data layers are present. A missing data layer is a hard stop, because EAGLE-EYE's enrichment against the escalation-chain graph depends on it. A partial tool catalog is a soft stop: the methodology still runs, but the set of findings that can reach live validation shrinks to whatever is installed.

The install command deserves the same scrutiny. Because it merges into existing MCP client configs rather than replacing them, install --dry-run is the way to see exactly which files it intends to touch before it touches them. If you manage agent configuration centrally, that merge behaviour is convenient and also the reason you should review the diff: an entry added to ~/.claude.json or ~/.cursor/mcp.json is easy to forget and hard to explain later.

Editorial conclusion

Adopt Blitz Strike if you already drive an MCP client such as Claude Code, Cursor or OpenCode and you want recon, source-to-sink tracing and live validation behind one scope-enforced entry point, with the tool manual attached to each result. Do not adopt it if you need a zero-trust scanner on a production network, if you cannot run an external tool catalog on the host, or if you expect the server to decide what to attack without an LLM in the loop. Before trusting it, run npx -y blitzstrike doctor and read the 63/130 installed line: the missing tools are the ones that decide which findings can ever reach STRIKE validation, and that ratio is the real limit on your coverage.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. shinthink/blitzstrike on GitHub