BlitzStrike: An MCP Pentest Kit for AI Agents

A security toolkit that used to take a weekend to assemble now arrives as one npx command, and that's either good news or the thing you'll be reading about in an incident report. BlitzStrike is an MCP server that hands any agent a catalogue of 130 security tools and 57 escalation chains, and it went from first commit to v1.0.0 on the same day, 12 September 2026. By the 18th it had 634 stars.

This piece reports what it is and what its existence implies. No commands beyond the one that starts the server, no methodology, no chains. If you want those, the repository is public and you should be reading its own documentation with your own authorisation in hand.

What BlitzStrike is

It's a Model Context Protocol server, written in TypeScript on Bun, MIT licensed. Two commits, one tag, zero forks as of 18 September, which is worth holding in mind against the star count. An agent connects to it the way it connects to any MCP server, and the engagement runs server-side rather than as a long back-and-forth of individual tool calls.

That server-side detail is the design decision worth noticing. Most MCP servers are thin: the client asks for one thing, gets one result, decides what to do next, asks again. BlitzStrike exposes 33 MCP tools, one of which, run_engagement, carries a whole assessment through to submission-ready findings in a single call. The README names the clients it's been used from: Claude Code, Cursor, Hermes, OpenCode, Claude Desktop, and Gemini, plus any other MCP client.

The project describes the split as the LLM being "the brain" that plans, routes, delegates and judges, while BlitzStrike is "the deterministic hands + knowledge + guardrails." That's a reasonable description of where this category has landed generally, and it's the reason a catalogue like this is suddenly worth packaging.

One MCP server, every agent

Six months ago, wiring a security toolchain into an agent meant writing adapters. Each tool had its own flags, output format, and failure modes, and you wrote glue for every one.

MCP removed the glue. A server declares its tools once, and any compliant client can call them. BlitzStrike takes that to its logical end by declaring a lot of tools at once. The catalogue holds 130 entries, each carrying a command base, key flags, per-platform install command, an installed-check probe, tags, alternatives, and whether it needs root.

Read that claim carefully, because it's easy to misread. The README says the 130 are "self-written… not copied from any project," and what's self-written is the catalogue metadata, not the software. The tools themselves are the ones you already know: subfinder, amass and httpx under recon; sqlmap, hydra and hashcat under exploitation; ghidra and radare2 under reverse engineering; suricata, zeek, osquery and yara under blue team. Nobody rewrote Ghidra. Somebody wrote a uniform description of how to invoke it.

One nuance the headline number hides. Running the project's own health check reports the split as "63/130 installed, 67 on-demand." So 130 is the size of the catalogue, not the number of binaries sitting on your disk after installation; roughly half are fetched when something needs them. That's a meaningful difference if you were picturing a 130-tool payload, and it's the sort of thing worth checking on any project that leads with a big number.

What "57 escalation chains" actually means

An escalation chain, in this project's data model, is an ordered sequence of steps stored as data rather than code, in a file called chains.json. There are 57 of them. Each carries the steps and the tools each step expects, and per the release notes each step also carries an invariant check and a negative control, which the project glosses as "anti-grep-monkey". The server attaches the relevant manual for a matched chain when it reports a result.

Why store them as data? Because the alternative is hard-coding assessment logic into the server, and then every new technique is a code change and a release. Data-driven chains mean the knowledge layer updates independently of the software, and it means you can read what the thing is going to do before it does it. The repository invites contributions to chains, tools and data as separate concerns.

I'm not going to walk through any chain, and the practical reason is more interesting than the legal one: a chain is only meaningful against a specific target you're authorised to test, and reading one out of context teaches you nothing except how to misuse it.

The structural claim is what matters here. Packaging assessment methodology as data that an LLM can traverse is a different thing from packaging tools. Tools have always been a download away. Knowing which to run, in what order, against what evidence, was the part that lived in someone's head.

What the server actually exposes

The tool surface is larger than the three-tier summary suggests, and the shape of it tells you what the project is really betting on.

Reconnaissance offers a source-tree scan and a single-file scan. The trace tier returns a function's full body along with the sinks and auth gates in scope, plus a sink grep that only reports a hit inside a function body and flags whether it's guarded. Validation carries live HTTP verification with a marker, a negative control and a baseline, a scope check that's exclusion-aware and explicitly no-DoS, and the run_engagement call that chains the lot together. There's a CVE lookup against NVD 2.0 that needs no key, and a FOFA asset search that needs your own FOFA_EMAIL and FOFA_KEY.

Then there are two layers that aren't about running anything. A catalogue layer looks up a tool's flags and install command or auto-installs it, and a manuals layer serves the deep tool references. The v1.0.0 notes count 270 deep tool manuals plus 17 engagement playbooks and 32 universal skill playbooks; the README instead says 317 indexed manuals. The project's own two numbers don't agree, which is worth noticing on any project leading with counts. Those manuals aren't sitting there for humans to read: run_engagement attaches the relevant one per matched chain, so the agent reads the manual as part of the run.

Most of that knowledge is borrowed, and to the project's credit it says so in detail. THIRD-PARTY-NOTICES.md credits kali-pentest under Apache-2.0 for 270 of the deep tool manuals plus the 17 engagement playbooks, adversary-playbook (MIT) for 14 offensive playbooks, and hack.proof (MIT) for 18 security-audit playbooks. The intelligence data has the same shape, pulling WAF signatures, tech/CVE/port correlations, 66 payload categories and roughly 11,900 nuclei templates from airecon, PayloadsAllTheThings and nuclei-templates, all MIT, loaded at runtime. The attack-vector taxonomy is first-party.

A thorough attribution file on a six-day-old repository is a small signal worth more than the star count. Plenty of projects in this space vendor other people's data and forget to mention it.

The layer I'd watch is memory. BlitzStrike keeps an append-only JSONL file at ~/.blitzstrike/memory.jsonl, and every engagement writes the chains it matched back into it as deduplicated pattern entries. Only entries marked verified count as authoritative, and verified has a specific meaning here: the marker was reflected and the negative control stayed inert. A knowledge base that grows from confirmed results rather than from scan noise is a genuinely good idea, and it's also a file on your disk accumulating a record of everything you've tested, which deserves the same care as any other engagement artifact.

Validation before reporting, which is the genuinely useful idea

The line the README leads with is worth quoting: "A scan hit is a hypothesis. A live test is the verdict."

Anyone who has received an automated security report knows why that sentence exists. Pattern-matching scanners produce findings that are technically present and practically unreachable, and the cost lands on whoever has to triage three hundred of them to find the four that matter. The project names this directly as one of the two failure modes it exists to remove, the other being findings reported without live confirmation.

The three tiers map to that. Reconnaissance enumerates the exposed surface. Static analysis traces whether a sink is actually reachable, actually unauthenticated, actually exploitable, rather than merely present. Validation performs live verification with a negative control before anything is written into a report.

A negative control, in this context, means checking that your test fails when it should, not just that it succeeds when you hope. That's ordinary experimental hygiene and it's uncommon in tooling. Whether it works as advertised on a six-day-old project is exactly the question you'd want answered before trusting the output, and nobody has answered it yet.

Defensive or offensive? The repository says both, and that's the honest answer

The GitHub topics carry pentest, red-team, blue-team, and defensive-security at the same time, which reads like fence-sitting and isn't.

Attack-surface enumeration is the same operation whether you own the surface or not. A blue team runs it to find what's exposed before someone else does; a red team runs it to find what's exposed so they can use it. The tooling cannot tell the difference, and it never could. What distinguishes the two is authorisation, scope, and what you do with the result.

BlitzStrike does implement scope enforcement as part of the validation tier, which is at least an acknowledgement that a boundary needs to exist in software and not only in intent.

The thing that changed isn't capability. It's distribution. This capability previously required assembling tools, knowing methodology, and operating them, and each of those was a filter. npx removes the third filter entirely and the packaged chains substantially weaken the second. The first was never much of a filter anyway.

I don't think that argues against publishing it. Defenders benefit from the same removal of friction, and the alternative — capability circulating privately among people who build it themselves — has a worse history. But pretending the distribution change is neutral would be silly, and it's the reason this is worth writing about at all. The risk surface of agent tooling grows every time a capability becomes a one-line install.

What this means if you run agents, not pentests

Most readers here aren't going to run BlitzStrike. The relevant question is different: what does it mean that an MCP server can now hand an agent this much reach?

Your agent's capabilities are the union of every MCP server it's connected to, and that union is rarely written down anywhere. A server added in March for one task is still connected in September. This is the same accounting problem behind fake tool output attacks, where the risk isn't any individual tool but the gap between what an agent can do and what anyone believes it can do.

Worth doing this week, regardless of BlitzStrike: list every MCP server your agents can reach, and for each one, say out loud what it could do if a page or a file convinced the model to use it. If you've been reading about red-team skills for Claude, this is the same exercise from the defensive side.

FAQ

Is BlitzStrike legal to use?

The tooling is MIT licensed, so possessing and running it is fine. Pointing it at a system is governed by whether you have written authorisation from whoever owns that system, and that's true of every security tool regardless of packaging. Unauthorised testing is unauthorised access in most jurisdictions no matter how convenient the install was.

What is an MCP pentest server?

An MCP server that exposes security-assessment capabilities as tools an AI agent can call. Model Context Protocol is the standard interface agents use to reach external tools, so an MCP pentest server is that plumbing pointed at security tooling instead of at a database or a file system.

How many tools does BlitzStrike actually install?

Its own health check reports 63 of the 130 catalogue entries installed, with 67 fetched on demand. The 130 figure describes the documented catalogue.

Is it production-ready?

It tagged v1.0.0 on its first day, 12 September 2026, and nothing about a version number on a six-day-old repository tells you about reliability. There's no independent evaluation of its validation claims that I could find.

Does it work with Claude Code?

Yes, per the README, along with Cursor, Hermes, OpenCode, Claude Desktop, Gemini, and any other MCP client.

The part worth watching

BlitzStrike itself may not last; most six-day-old repositories don't. The pattern behind it will.

Packaging expert methodology as data an agent can traverse, then running the whole engagement server-side, is going to happen to every domain where the knowledge was the barrier. Security is just early because the knowledge was unusually well documented and the tools were already free. Watch for the same shape in compliance, in incident response, in anywhere a specialist's ordering of steps is the actual product.